Visió de conjunt

Aquesta entrada es descriu un estudi de cas que descriu un present MRO (Manteniment, Reparació i operacions) procés d'aprovació d'un flux de treball implementats en MOSS.

Això no és un debat obertament tècnic, però en canvi necessita serveix per donar un exemple de món real que demostra com la plataforma de molsa conèixer un món real.

(Aquesta entrada és creu publicat entre http://paulgalvin.spaces.live.com i http://blogs.conchango.com)

Fons

Procés MRO del client havia caracteritzat per la següent

• Procés d'aprovació manual.
• Algun suport utilitza Superar fulls de càlcul.
• Procés d'aprovació irregular. El mateix procés d'aprovació MRO compra que varien el dia a dia, persona per persona.
• Munt de paper i mà escrit signatures — comprar requisitions necessaris fins a 3 signatures escrits abans d'aprovació definitiva.

Els objectius d'aquest projecte inclòs:

• Plenament automatitzar el procés.
• Fer complir les normes d'empresa per a l'aprovació.
• Proporciona una vista consolidada de la MRO compra a diferents gestors.
• Pista d'auditoria detallada.

Com a efecte secundari de la solució, signatures escrits ja no es requerien.

Procés d'aprovació

El procés d'aprovació consisteix en nedar quatre "carrils": Causant, Gestor directe, Director funcional i gerent de la divisió.

Causant:

Veu la necessitat per a la compra i comença el procés. Tingueu en compte que el causant pot o no pot realment entrar a la sol·licitud de compra, però en canvi directe un altre membre del personal per fer-ho. Algunes vegades, el causant no té els coneixements tècnics d'emplenar la sol·licitud de PO. Per exemple, un usuari pot voler exemple un nou ordinador portàtil, però no sap el millor venedor, Estàndards, etc. En aquest cas, les obres d'autor amb això i en realitat omple la sol·licitud.

Gestor directe:

Aquest és el gestor directe del causant (que pot ser diferent de la persona que en realitat va entrar la requisicions PO en MOSS). Gestors directes ha d'aprovar la sol·licitud PO abans el sistema busca aprovació més en la línia.

Director funcional:

El director funcional és la persona responsable de garantir que la proposta de compra conforme als estàndards d'empresa en l'àmbit d'una determinada funció corporatiu. Per exemple, Compres són aprovats per un director de TI funcional.

Gerent de la divisió:

Gestors de divisió aprovar compra requisitions estrictament per la quantitat de dòlars. Gerent de la divisió aprovar la compra requisitions en més d'una quantitat de dòlars configurable.

La solució

Hem utilitzat les següents eines i components d'implementar la solució:

MOSS: Serveix com a plataforma de la qual tota la resta es "penja". MOLSA proporciona serveis de base per a la seguretat, dades mestres, senders d'auditoria i altres característiques.

Serveis dels formularis de InfoPath: Un component de molsa, Això permet usuaris per omplir requisitions compra mitjançant un navegador web.

Dissenyador de SharePoint (SPD): Utilitzàvem SPD d'implementar el procés automatitzat de flux de treball.

Servei web: Un servei de web c# realça l'experiència d'usuari permetent en cascada llistes de seleccions en forma l'InfoPath i proporciona millor actuació pel que fa a les dades de filtratge. Veure aquí per a una immersió profunda tècnica sobre aquest tema i les nostres raons per utilitzar-lo.

Llistes de costum: Perfils d'usuari MOSS proporcionat cap directe d'un usuari determinat, però no va proporcionar la major part de les dades que controlaven les decisions de flux de treball (e. g. Si el director de la divisió és necessària per aprovar la sol·licitud de PO). Fem servir llistes personalitzades en un "dades d'empresa" lloc per mantenir dades com "Divisió director aprovació dòlar quantitat", "Funcionals àrea Manager" i així successivament. Llistes molt ben integrat amb l'InfoPath i també proporcionar creació/actualització/supressió (PORQUERIA) funcionalitat amb l'auditoria i seguretat de la caixa.

Cas d'ús

Aquest cas d'ús il. lustra com encaixa la solució:

1. Paul vol un portàtil nou. Descriu les seves necessitats per Vivek, una persona de TI familiaritzat amb estàndards de corporatius portàtil, venedors preferits, etc.
2. Vivek registres en MOSS, accedeix al formulari de sol·licitud PO i entra en la sol·licitud en nom de Paul. Forma Vivek demana per a una categoria de compra que llavors utilitza els serveis web a una llista desplegable de proveïdors de companyia aprovada de poblar. Vivek també especifica l'àrea funcional corporativa d'aquesta compra (e. g. "QUE" o "Finances").
3. SPD basat en un flux de treball s'inicia, determina cap directe de Paul i encamina la sol·licitud a la seu mànager, Stacy.
4. Stacy aprova la sol·licitud de compra.
5. SPD workflow inspecciona la requisicions i determina que és una compra de TI. -Rutes el flux de treball de director d'IT funcional, Wonson.
6. Wonson s'aprova la sol·licitud.
7. SPD workflow nou inspecciona la requisicions i determina que l'import de compra supera una quantitat de dòlars d'àrea i encamina a la gerent de la divisió d'aprovació.
8. El gerent de la divisió s'aprova la sol·licitud de compra.

Notes

• El cas d'ús demostra un "net" córrer sense rebuigs ni salts.
• Cada Aprovador té la capacitat per aprovar o rebutjar la sol·licitud, així com proporcionar comentaris escrits. Aquestes es registren en la pista d'auditoria.
• Si un gestor responsable rebutja la sol·licitud de compra en qualsevol moment, la requisicions PO està "mort" i el procés hagi iniciat des del principi.
• Flux de treball notifica el causant en cada pas del procés.
• Cap escrits signatures — el client determinat (després d'algunes recomanacions contundents) que l'auditoria recorreguda com proporcionats mitjançant la història d'un flux de treball, se serveix a les seves necessitats d'auditoria.
• Esforç — va prendre diverses setmanes aproximadament tres homes per implementar aquesta solució.

Conclusió

Aquesta solució aprofita MOSS com una plataforma de temps d'execució i desenvolupament. El client era capaç a força característiques principals molsa per automatitzar un procés de negocis de rutina que va afectar a gairebé tots els empleats de la companyia. Un servei web senzill amb l'excepció (que això mateix aprofita la molsa), gairebé no real "programació" era necessari.

La solució també serveix d'aparador"" per al client, demostrant com diferents característiques molsa es poden combinar per crear una aplicació plenament presentat negoci i generar noves oportunitats en el futur.

Glossari

MRO: Manteniment, reparació i operacions. Aquestes compres típicament inclouen elements com ara Quaderns de notes, cadires, ordinadors personals, Impressores, els telèfons mòbils i similars.