MRO Workflow Fallstudie mit MOSS, SPD, InfoPath & Web-services.

Übersicht

Dieser Eintrag beschreibt eine Fallstudie beschreibt eine tatsächliche MRO (Wartung, Reparatur und Operationen) Workflowgenehmigungsprozess implementiert in MOSS.

Dies ist kein offen technische Diskussion, aber stattdessen dazu dient, ein Real-World Beispiel, das veranschaulicht, wie die MOSS-Plattform erfüllt eine reale bieten müssen.

(Dieser Eintrag ist Kreuz und zwischen http://paulgalvin.spaces.live.com und http://blogs.conchango.com)

Hintergrund

MRO-der Client-Prozess hatte folgende geprägt

  • Manuelle Genehmigungsprozess.
  • Einige Unterstützung mit excel-Tabellen.
  • Unregelmäßige Genehmigungsprozess. Der selben MRO Kauf Genehmigungsprozess würde Tag zu Tag variieren., Person von person.
  • Viel Papier und handschriftliche Unterschriften — Bestellanforderungen Sie benötigt bis zu 3 schriftliche Unterschriften vor der endgültigen Genehmigung.

Die Ziele dieses Projektes enthalten:

  • Vollständige Automatisierung des Prozesses.
  • Unternehmen-Normen zur Genehmigung zu erzwingen.
  • Bereitstellen Sie konsolidierte Ansicht der MRO Einkauf zu verschiedenen Managern.
  • Detaillierten Audit trail.

Als Nebeneffekt der Lösung, schriftliche Unterschriften wurden nicht mehr benötigt.

Genehmigungsprozess

Der Genehmigungsprozess besteht aus vier "schwimmen Bahnen": Urheber, Direkten Vorgesetzten, Funktionalen Manager und Leiter der division.

Urheber:

Sieht die Notwendigkeit für den Kauf und startet den Prozess. Beachten Sie, dass der Urheber kann oder nicht wirklich die Bestellanforderung betreten kann, sondern Sie stattdessen direkt einen anderen Bediensteten zu tun. Einige Male, der Urheber muss nicht das technische Know-how der Bestellanforderung PO ausfüllen. Zum Beispiel, ein Benutzer kann möchte einen neuen Laptopcomputer zu requirieren, aber der beste Anbieter nicht kennt, IT-standards, usw.. In diesem Fall, die Urheber-arbeiten mit ihm und es tatsächlich füllt der Bestellanforderung.

Direkten Vorgesetzten:

Dies ist die direkten Vorgesetzten des Urhebers (die von der Person abweichen kann, tatsächlich die PO-Banf MOSS eingegangen). Direkte Manager müssen der PO-BANF genehmigen, bevor das System Zustimmung weiter auf der ganzen Linie sucht.

Funktionalen Manager:

Der funktionale Manager ist dafür verantwortlich, dass der geplante Kauf Unternehmen Standards im Rahmen eines bestimmten Unternehmens Funktion entspricht den einzelnen. Zum Beispiel, IT-Käufe werden durch funktionale IT-Manager genehmigt..

Bereichsleiter:

Bereichsleiter Bestellanforderungen streng durch Dollarbetrag genehmigen. Bereichsleiter genehmigen Bestellanforderungen eine konfigurierbare Dollarbetrag übersteigenden.

Die Lösung

Wir haben die folgenden Tools und Komponenten zur Implementierung der Lösung:

MOOS: Dient als Plattform, aus denen alles andere "hängt". MOSS bietet Fundament für Sicherheit, Stammdaten, Audittrails und andere Funktionen.

InfoPath Forms services: Eine MOSS-Komponente, Dies ermöglicht Benutzern, Bestellanforderungen über einen Webbrowser auszufüllen.

SharePoint Designer (SPD): Wir verwendet SPD, um den automatisierten Workflow-Prozess zu implementieren.

Web-Service: Ein c#-Webdienst verbessert die Benutzerfreundlichkeit durch kaskadierende Auswahl-Listen im InfoPath-Formular aktivieren und bietet eine bessere Leistung in Bezug auf das Filtern von Daten. Siehe Hier für eine technische Tieftauchen zu diesem Thema und unsere Gründe für die Verwendung.

Benutzerdefinierte Listen: MOSS-Benutzerprofile gemäß eines bestimmten Benutzers direkten Vorgesetzten, aber die meisten Daten nicht bieten konnte, die Entscheidungen der Workflow gesteuert (zB. ob Bereichsleiter erforderlich ist, um die PO-Banf genehmigen). Wir verwendet benutzerdefinierte Listen in eine "Enterprise-Daten" Website-Daten wie z. B. "Divisional Manager Genehmigung Dollar-Betrag", "Funktionelle Area Manager" und So weiter. Listen mit InfoPath sehr schön integriert und bieten auch erstellen/aktualisieren/löschen (CRUD) Funktionalität mit Überwachungs- und Out of the box.

Anwendungsfall

Dieser Anwendungsfall wird veranschaulicht, wie die Lösung zusammen hängen:

  1. Paul will einen neuen laptop. Er beschreibt seine Bedürfnisse, Vivek, ein IT-Mitarbeiter mit Firmen Laptop Normen vertraut, bevorzugte Lieferanten, usw..
  2. Vivek Protokolle in MOSS, greift auf das PO BANF-Formular und betritt die Bestellanforderung im Auftrag von Paul. Form aufgefordert eine Kauf-Kategorie, die dann die Webdienste verwendet, um eine Dropdown-Liste der Unternehmen genehmigte Anbieter füllen, Vivek. Vivek gibt auch den Firmen Funktionsbereich von diesem Kauf (zB. "ES" oder "Finance").
  3. SPD-basierten Workflow gestartet, Pauls direkten Vorgesetzten bestimmt und leitet die Anforderung an seinem manager, Stacy.
  4. Stacy billigt die Bestellanforderung.
  5. SPD Workflow prüft der Bestellanforderung und feststellt, dass es ist ein IT-Kauf. Es leitet den Workflow an der funktionale IT-manager, Wonson.
  6. Wonson billigt der Bestellanforderung.
  7. SPD Workflow wieder prüft der Bestellanforderung und feststellt, dass der Kaufbetrag einen Maxium Dollar-Betrag übersteigt und sie an die Bereichsleiter für die Zulassung leitet.
  8. Die Bereichsleiter genehmigt die Bestellanforderung.

Hinweise

  • Der Anwendungsfall zeigt eine "saubere" Führen Sie ohne Ablehnungen oder Sprünge.
  • Jede genehmigende Person hat die Fähigkeit, genehmigen oder ablehnen der Bestellanforderung sowie schriftliche Stellungnahmen. Diese werden im Audit-Trail protokolliert..
  • Lehnt ein Verantwortlicher Manager die Bestellanforderung zu einem beliebigen Zeitpunkt, die PO-Bestellanforderung ist "tot" und der Prozess muss von Anfang an gestartet werden.
  • Workflow benachrichtigt den Absender bei jedem Schritt des Prozesses.
  • Keine schriftlichen Unterschriften — der Client bestimmt (nach einigen kraftvollen Empfehlungen) dass das Audit-trail gemäß über Workflow-Historie, Ihre Überwachungsbedarf serviert.
  • Aufwand — Es dauerte etwa drei Mann Wochen diese Lösung implementieren.

Abschluss

Diese Lösung nutzt MOSS als Entwicklung und Laufzeit-Plattform. Der Client konnte nutzen Kern-MOSS-Funktionen um eine routinemäßige Geschäftsprozess zu automatisieren, der fast jeder Mitarbeiter im Unternehmen betroffen. Mit Ausnahme von einer einfachen Web-service (die wiederum nutzt MOSS), fast keine eigentliche "Programmierung" Es bedurfte.

Die Lösung dient auch als "Schaufenster" für den client, zeigen, wie verschiedene MOSS-Funktionen kann kombiniert werden, um ein voll ausgestattetes Business-Anwendung zu erstellen und generieren neue Beratungs-Möglichkeiten in der Zukunft.

Glossar

MRO: Wartung, Reparatur und Operationen. Diese Käufe beinhalten in der Regel Elemente wie Notizblöcke, Stühle, Personal Computer, Drucker, Handys und dergleichen.

Ein Gedanke zu "MRO Workflow Fallstudie mit MOSS, SPD, InfoPath & Web-services.

Hinterlasse eine Antwort

Deine Email-Adresse wird nicht veröffentlicht. erforderliche Felder sind markiert *