Overzicht

Dit bericht beschrijft een case-studie met een beschrijving van een werkelijke MRO (Onderhoud, Reparatie en operaties) goedkeuring workflowproces implemented in MOSS.

Dit is niet een openlijk technische discussie, maar in plaats daarvan dient om een echte wereld voorbeeld dat aantoont hoe de MOSS platform ontmoette een levensechte te verstrekken nodig.

(Dit item is cross-gepost tussen http://paulgalvin.spaces.live.com en http://blogs.conchango.com)

Achtergrond

Het clientproces MRO had gekenmerkt door de volgende

• Handmatige goedkeuringsproces.
• Sommige ondersteuning met behulp van excel-werkbladen.
• Onregelmatige goedkeuringsproces. Het dezelfde MRO aankoop goedkeuringsproces zouden variëren van dag tot dag, persoon door persoon.
• Veel van papier en handgeschreven handtekeningen — Koop vorderingen nodig tot 3 schriftelijke handtekeningen voor definitieve goedkeuring.

De doelstellingen van dit project opgenomen:

• Volledig automatiseren naar de procédé.
• Afdwingen van onderneming normen voor goedkeuring.
• Totaaloverzicht van MRO inkoop naar verschillende managers bieden.
• Gedetailleerde audittrail.

Als een neveneffect van de oplossing, schriftelijke handtekeningen werden niet langer nodig.

Goedkeuringsproces

Het goedkeuringsproces bestaat uit vier 'zwemmen rijstroken': Opdrachtgever, Directe manager, Functionele manager en divisie manager.

Opdrachtgever:

Ziet de noodzaak voor de aankoop en begint het proces. Merk op dat de opdrachtgever kan of kan niet daadwerkelijk de aankoop opeising invoert, maar in plaats daarvan direct een ander personeelslid te doen. Sommige tijden, de opdrachtgever hoeft niet de technische expertise om de PO opeising in te vullen. Bijvoorbeeld, een gebruiker kan wil een nieuwe laptopcomputer Inkoopbeheer, maar weet niet de beste verkoper, IT-standaarden, etc. In dit geval, de opdrachtgever werken met en het eigenlijk het invullen van het inkoopvoorstel.

Directe manager:

Dit is de directe manager van de opdrachtgever (die kunnen afwijken van de persoon die de PO opeising daadwerkelijk aangegaan in MOSS). Directe managers moeten de opeising van het PO goedkeuren voordat het systeem goedkeuring verder langs de lijn zoekt.

Functionele Manager:

De functionele manager is de persoon die verantwoordelijk is om ervoor te zorgen dat de voorgenomen aankoop aan de normen van de onderneming in het kader van een bepaalde zakelijke functie voldoet. Bijvoorbeeld, IT-aankopen zijn goedgekeurd door een functionele IT-manager.

Divisie Manager:

Divisie managers goedkeuren aankoop vorderingen strikt door de dollarbedrag. Divisie manager goedkeuren aankoop vorderingen die een configureerbare dollarbedrag overschrijden.

De oplossing

We gebruikten de volgende hulpprogramma's en onderdelen om de oplossing te implementeren:

MOSS: Fungeert als het platform uit die alles "hangt". MOSS biedt fundament voor beveiliging, stamgegevens, audit trails en andere functies.

InfoPath-formulierservices: Een component MOSS, Hierdoor kunnen gebruikers om aankoop vorderingen via een webbrowser in te vullen.

SharePoint Designer (EPD): Wij EPD gebruikt de geautomatiseerde workflowproces uit te voeren.

Webservice: Een c#-webservice verbetert de gebruikerservaring doordat trapsgewijze selecties lijsten in het InfoPath-formulier en levert betere prestaties met betrekking tot het filteren van gegevens. Zie Hier voor een technische diepe duik over dit onderwerp en onze redenen voor het gebruik ervan.

Aangepaste lijsten: MOSS gebruikersprofielen verstrekt van een bepaalde gebruiker directe manager, maar deed niet bieden de meeste gegevens die gecontroleerd werkstroom besluiten (bijvoorbeeld. of de afgesplitste manager is vereist om goed te keuren de opeising PO). We gebruikten aangepaste lijsten in een "-bedrijfsgegevens" site om gegevens zoals "Afgesplitste Manager goedkeuring dollarbedrag", "Functionele Area Manager" enzovoort. Lijsten heel mooi geïntegreerd met InfoPath en bieden ook maken/bijwerken/verwijderen (CRUD) functionaliteit met controle en veiligheid uit de doos.

Use-Case

Deze use-case illustreert hoe de oplossing in elkaar past:

1. Paul wil een nieuwe laptop. Hij beschrijft zijn behoeften aan Vivek, een IT-persoon bekend met de zakelijke laptop normen, voorkeur leveranciers, etc.
2. Vivek Logboeken in MOSS, toegang heeft tot de PO inkoopvoorstel vorm en voert de opeising namens Paul. Het formulier gevraagd een aankoop-categorie die vervolgens de webservices gebruikt voor het vullen van een drop-down lijst van verkopers bedrijf goedgekeurde Vivek. Vivek specificeert ook de corporate functioneel gebied van deze aankoop (bijvoorbeeld. "HET" of 'Finance').
3. SPD gebaseerd werkstroom is gestart, Paul de directe manager bepaalt en de behoefteregel wordt rondgestuurd naar zijn manager, Stacy.
4. Stacy hecht zijn goedkeuring aan de aankoop opeising.
5. SPD werkstroom inspecteert de opeising en bepaalt kleur is een IT-aankoop. Het routeert de werkstroom naar de functionele manager van IT, Wŏnsan.
6. Wŏnsan hecht zijn goedkeuring aan het inkoopvoorstel.
7. SPD workflow opnieuw inspecteert de behoefteregel en bepaalt dat het aankoopbedrag een maxium dollarbedrag overschrijdt en stuurt het door naar de manager van de afdeling voor goedkeuring.
8. De divisie manager hecht zijn goedkeuring aan de aankoop opeising.

Notities

• De use-case toont een 'schone" met geen afwijzingen of sprongen worden uitgevoerd.
• Elke fiatteur heeft de mogelijkheid om goedkeuren of verwerpen van de opeising, evenals bieden schriftelijke opmerkingen. Deze worden vastgelegd in het controlepad.
• Als een verantwoordelijke manager de aankoop opeising op elk gewenst moment verwerpt, de PO opeising is "dood" en het proces moet worden gestart vanaf het begin.
• Werkstroom waarschuwt de opdrachtgever bij elke stap van het proces.
• Geen schriftelijke handtekeningen — de client bepaald (Na enkele krachtige aanbevelingen) dat de audit trail zoals bepaald via werkstroomgeschiedenis, geserveerd hun controle behoeften.
• Inspanning — het duurde ongeveer drie man weken om deze oplossing te implementeren.

Conclusie

Deze oplossing maakt gebruik van MOSS als ontwikkeling en runtime-platform. De client kon hefboomeffect MOSS kerneigenschappen automatiseren van een routine bedrijfsproces waarop bijna elke werknemer in de onderneming. Met uitzondering van een eenvoudige webservice (die zelf hefboomwerkingen MOSS), bijna geen werkelijke 'programmeren" nodig was.

De oplossing dient ook als een "showcase" voor de client, demonstreren hoe verschillende MOSS functies kan worden gecombineerd om een volledig functionele bedrijfstoepassing maken en het genereren van nieuwe consulting kansen in de toekomst.

Woordenlijst

MRO: Onderhoud, reparatie en operaties. Deze aankopen omvatten items zoals blocnotes, stoelen, Personal computers, printers, mobiele telefoons en dergelijke.