Visión general

Este artículo describe un estudio de caso describe un real MRO (Mantenimiento, Reparación y operaciones) proceso de aprobación de trabajo implementado en MOSS.

Esto no es un debate técnico abiertamente, Pero en cambio sirve para ofrecer un ejemplo real que demuestra cómo la plataforma MOSS conocieron un mundo real.

(Esta entrada es Cruz publicada entre http://paulgalvin.spaces.live.com y http://blogs.conchango.com)

Fondo

El proceso del cliente MRO había estado caracterizado por los siguientes

• Proceso de aprobación manual.
• Algunos apoyo usando hojas de cálculo de excel.
• Proceso de aprobación irregular. El mismo proceso de aprobación de compra MRO variará día a día, persona por persona.
• Montón de papel y las firmas manuscritas — requerido hasta requisiciones de compra 3 firmas escritas antes de la aprobación final.

Los objetivos de este proyecto incluido:

• Automatizar completamente el proceso de.
• Hacer cumplir las normas de la empresa para su aprobación.
• Proporciona una vista consolidada de MRO comprar a varios gerentes.
• Auditoría detallada.

Como un efecto secundario de la solución, escrito firmas ya no eran necesarias.

Proceso de aprobación

El proceso de aprobación consta de cuatro carriles de"nadar": Originador, Gerente directo, Gerente funcional y Gerente de la división.

Originador:

Ve la necesidad de la compra e inicia el proceso. Nota que el autor puede o no puede entrar realmente en la requisición de compra, pero directa en su lugar otro miembro del equipo para hacerlo. Algunas veces, el remitente no tiene los conocimientos técnicos para completar la solicitud PO. Por ejemplo, un usuario puede desear a requisar un nuevo ordenador portátil, Pero no sabe que el mejor vendedor, Normas de ti, etc.. En este caso, las obras de autor con él y él realmente llena la requisición de.

Gerente directo:

Este es el encargado directo del emisor (que puede ser diferente de la persona que en realidad entró la requisición de PO en MOSS). Gestores directos deben aprobar la solicitud PO antes de que el sistema busca aprobación más abajo de la línea.

Gerente funcional:

El Gerente funcional es la persona responsable de asegurar que la compra propuesta cumple con los estándares de la empresa en el ámbito de una función corporativa en particular. Por ejemplo, LO compras son aprobadas por un gerente funcional.

Gerente de división:

Los gerentes de división aprobación requisiciones de compra estrictamente por monto en dólares. Gerente de división aprobar las requisiciones de compra que exceda una cantidad configurable.

La solución

Hemos utilizado las siguientes herramientas y componentes para implementar la solución:

MOSS: Sirve como la plataforma que todo lo demás "se cuelga". MOSS provee servicios de cimiento para la seguridad, datos maestros, Auditoría y otras características.

Servicios de formularios de InfoPath: Un componente MOSS, Esto permite a los usuarios rellenar las requisiciones de compra mediante un navegador web.

SharePoint Designer (SPD): Utilizamos SPD para implementar el proceso de flujo de trabajo automatizado.

Servicio Web: Un servicio web c# mejora la experiencia del usuario al permitir listas de selecciones en cascada en el formulario de InfoPath y proporciona un mejor rendimiento con respecto al filtrado de datos. Ver aquí para un buceo técnico profundo sobre este tema y nuestras razones para usarlo.

Listas personalizadas: Perfiles de usuario MOSS siempre Gerente directo de un usuario, pero no proporciona la mayor parte de los datos que controla las decisiones de flujo de trabajo (por ejemplo:. Si el gerente divisional es necesaria para aprobar la solicitud de PO). Utilizamos listas personalizadas en un "datos de la empresa" sitio para mantener datos tales como "Gerente Divisional aprobación cantidad de dólares", "Gestor de área funcional" y así sucesivamente. Listas muy bien integración con InfoPath y también proporcionan crear/actualizar/eliminar (CRUD) funcionalidad de auditoría y seguridad fuera de la caja.

Caso de uso

Este caso ilustra cómo encaja la solución:

1. Paul quiere un nuevo ordenador portátil. Él describe sus necesidades a Vivek, una persona es familiar con los estándares corporativos del ordenador portátil, recomendado: vendedores, etc..
2. Vivek registros en MOSS, Acceda el formulario de requisición de PO y entra en la solicitud en nombre de Paul. El formulario solicita Vivek para una categoría de compra que utiliza los servicios web para rellenar una lista desplegable de proveedores aprobados por la empresa. Vivek también especifica el área funcional corporativo de esta compra (por ejemplo:. "" o "Hacienda").
3. SPD basado en flujos de trabajo comienza, determina el encargado directo de Pablo y las rutas de la requisición a su manager, Stacy.
4. Stacy aprueba la solicitud de compra.
5. Flujo de trabajo de SPD examina la solicitud y determina que es una compra de ti. Rutas del flujo de trabajo para el Gerente funcional, Wonson.
6. Wonson aprueba la solicitud.
7. Flujo de trabajo SPD otra vez examina la solicitud y determina que el monto de la compra supera un monto máximo en dólares y lo encamina al Gerente de la División para su aprobación.
8. El Gerente de la división aprueba la solicitud de compra.

Notas

• El caso de uso muestra una"" correr con saltos ni rechazos.
• Cada aprobador tiene la capacidad de aprobar o rechazar la solicitud, así como proporcionar comentarios por escrito. Estos se registran en la pista de auditoría.
• Si un administrador responsable rechaza la requisición de compra en cualquier momento, la requisición de PO está "muerta" y el proceso debe iniciarse desde el principio.
• Flujo de trabajo notifica el creador en cada paso del proceso.
• Sin firmas escritas — el cliente determinado (después de algunas recomendaciones contundentes) que el audit trail como proporcionada a través de la historia de flujo de trabajo, sirve a sus necesidades de auditorías.
• Esfuerzo — man aproximadamente tres semanas para implementar esta solución.

Conclusión

Esta solución aprovecha el musgo como una plataforma de tiempo de ejecución y desarrollo. El cliente fue capaz de aprovechar características MOSS para automatizar un proceso de rutina empresarial que afectó a casi todos los empleados de la empresa. Con la excepción de un servicio web simple (que se aprovecha el musgo), casi no hay real "programación" fue requerido.

La solución también sirve como un escaparate"" para el cliente, demostrar cómo las diferentes características MOSS puede combinarse para crear una aplicación de negocios completa y generar nuevas oportunidades de consultoría en el futuro.

Glosario

MRO: Mantenimiento, reparación y operaciones. Estas compras suelen incluyen artículos como libretas, sillas, ordenadores personales, impresoras, los teléfonos celulares y similares.