|
|
|
|
|
|
||||||||||||||||||||||||||
|
Collinor GPM - ProduktbeschreibungCollinor-GPM White Paper. Version 1.03 vom 01.02.2005. Siegfried Knöpfler.1 Prozesse und ProjekteInhalt dieses "White Paper" ist die Geschäftsprozessmodellierung (GPM) in Collinor IRP, die sich vor allem durch die integrative Sicht auf Geschäftsprozesse und deren projektmäßige Durchführung auszeichnet. |
|
||
1.1 Geschäftsprozesse im modernen UnternehmenGeschäftsprozesse sind zunehmend durch komplexe Ablaufstrukturen gekennzeichnet, die zudem flexibel situations- und kundenbezogen angepasst werden müssen. Sie bestehen selten noch aus einem in sich geschlossenen Produktionsprozess, sondern münden in abteilungs- und unternehmensübergreifende Projekte, die Lieferanten- und Partnerfirmen einbeziehen. Damit entsteht die Notwendigkeit, das Geschäftsprozessmodell ständig aktuell und für die Mitarbeiter transparent zu halten. Unterschiedliche Systeme für die Dokumentation und die Unterstützung der Durchführung von Geschäftsprozessen sollten dabei vermieden werden.Instrumentarien, die Geschäftsprozesse personen-, zeit- und ortsunabhängig dokumentieren und strukturieren, sichern und optimieren die Innovationsfähigkeit der Unternehmen. Sie beschreiben Abläufe, Zuständigkeiten, Ziele und Bewertungsmaßstäbe. Die Informationstechnik entwickelt sich auch hier zum strategischen Erfolgsfaktor, wenn Geschäftsprozesse kontinuierlich DV-gestützt definiert und bearbeitet werden. Am Ende eines Innovationszyklus stehen dann ein verkürzter Ablauf, geringere Kosten, bessere Qualität oder ein höheres fachliches Niveau. Um diese Ziele zu erreichen, müssen Informationen in einem System zusammengeführt werden, das Daten verschiedener Herkunft integriert. Zu den Informationsquellen zählen unter anderem ERP- und CAD-Anwendungen oder Office-Pakete. 1.2 Problemlösung mit Collinor IRPDas von der Collinor Software GmbH in Köln entwickelte und vertriebene Softwarepaket Collinor IRP erlaubt die Definition von Geschäftsprozessen mit allen benötigten Personen, Datenobjekten, Anwendungsfunktionen und Geschäftsregeln. Die Ausführung von Geschäftsprozessen wird durch umfangreiche Projektmanagementfunktionen aktiv unterstützt und gemäß den Geschäftsregeln überwacht.Zielsetzung von Collinor IRP ist es, in einem Unternehmen alle an einem Geschäftsprozess beteiligten Objekte in ihren Zusammenhängen darstellen, planen und gemäß den Geschäftsregeln steuern und überwachen zu können. Organisatorische Richtlinien und erforderliche Qualitätsanforderungen sollen beschrieben und durch das System aktiv umgesetzt werden. Dazu ist es notwendig, Geschäftsprozesse wiederverwendbar zu beschreiben und der möglichen hohen Dynamik eines Prozesses Rechnung zu tragen, indem z.B. alternative Bearbeitungswege definiert und Regeln, unter denen sie beschritten werden können, formuliert werden. Die Geschäftsprozessmodelle werden dann (gesteuert von Collinor IRP) als Projekte ausgeführt. Grundsätzlich kann dieses Verfahren für alle Geschäftsprozesse Anwendung finden, also auch für die, die eine hohe IT-Unterstützung erfahren. Collinor sieht aber in der Unterstützung des Produktneuentwicklungsprozesses den Einsatz-Schwerpunkt, da hier das größtmögliche Wertschöpfungspotential besteht. 1.3 Struktur von Collinor IRPMit dem Projektmanagementsystem Collinor IRP stellt Collinor ein Produkt zur Verfügung, das den Benutzer bei Planung, Durchführung und Auswertung seiner Geschäftsabläufe umfassend unterstützt. Der Anspruch lautet dabei nicht, die oft komplexen, vielschichtigen und organisationsübergreifenden Prozesse eines Betriebes zu automatisieren. Im Gegenteil: die Kontrolle und das Management solcher Abläufe muss dem erfahrenen Experten überlassen bleiben. Collinor IRP stellt diesem jedoch geeignete Werkzeuge zur Seite, die ihm ermöglichen,
Zu diesen Werkzeugen hat der Benutzer in einer integrierten Arbeitsumgebung mit durchgängiger Bedienlogik Zugang. 1.4 Spezifischer Nutzen von Collinor-GPMCollinor-GPM, die Geschäftsprozessmodellierungs-Komponente von Collinor IRP, bezieht ihren besonderen Nutzwert aus der Integration von GPM und PM (Projektmanagement), nämlich aus der im Markt einmaligen Verknüpfung von GP-Modellen und Projektmanagement-Strukturen, d.h. Strukturen zur Planung und Durchführung von Projekten.
2 Geschäftsprozess-Modellierung mit Collinor-GPMDie Geschäftsprozessmodellierung (GPM) mit Collinor-GPM wird in zweifacher Weise unterstützt, zum einen durch das Werkzeug Collinor-GPM, die GPM-Komponente von Collinor IRP, zum anderen durch die Verfahrensweise, die Collinor zum methodischem Vorgehen zur Erstellung optimal adäquater GP-Modelle inklusive der Interaktionsmodellierung entwickelt hat.2.1 Diagramm-ErstellungDie Collinor-GPM-Diagramme sind ihrer Semantik nach eine Erweiterung von Activity Diagrams (AD) der UML (Unified Modeling Language). Allerdings verwenden GPM-Diagramme auch im gemeinsamen Bereich Symbole, die von AD-Symbolen abweichen: mit den vertrauten GPM-Symbolen ist erwiesenermaßen die Verständlichkeit auf der Fachseite deutlich besser.Abbildung 1 zeigt einen Blick auf den "Desktop" eines GP-Modell-Designers. Am linken Rand des Arbeitsfensters ist die Leiste der Diagramm-Elemente zur Darstellung von Prozess-Schritt, Subprozess-Aufruf, Verzweigung (mit zwei Ausgängen) bzw. "Guard" (mit einem Ausgang), Konnektor, Parallel-Split, Parallel-Join, Ressource (verschiedener Kategorie), Rolle, Org-Einheit, Annotation, SW-Funktion, einfach und doppelt gerichteter Pfeil zu sehen. Ein Pfeil kann nur zwischen bereits angelegten Symbolen eingetragen werden, wodurch sich seine Semantik i.A. automatisch als Ablaufpfeil oder als Beziehungspfeil einer bestimmten Sorte ergibt; weitere Spezifikation ist wie in Abbildung 7 möglich. Am oberen Rand des Arbeitsfensters sind Schaltflächen vorgesehen für die wichtigsten Operationen wie Neuanlegen, Öffnen, Abspeichern oder Aktualisieren eines Diagramms, Öffnen der Liste der in Diagrammen existierenden Elemente (z.B. zwecks referenzierender Verwendung), Selektion aller Elemente eines Diagramms, Ausrichtung am Gitter, vertikale oder horizontale Ausrichtung, Ausschneiden, Kopieren, Einfügen eines oder mehrerer Symbole, Löschen von Symbolen oder Beziehungen, HTML-Export eines Diagramms (mit allen textlichen Angaben und Links auf zugehörige Diagramme), Drucken eines Diagramms und Kopieren der Graphik. Die Schaltflächenleiste kann natürlich individuell angepasst werden.  Abbildung 1: Collinor-GPM-Desktop In Abbildung 1 wird eine Situation wiedergegeben, in der das Symbol für einen Subprozess-Aufruf selektiert ist. Die dickere Umrandung zeigt an, dass ein Diagramm existiert, das den Subprozess selbst definiert. Mit Doppelklick auf das Subprozess-Symbol kann in das zugrunde liegende Diagramm zur Bearbeitung wie in Abbildung 7 gewechselt werden; alternativ kann aus dem Kontextmenü ein sog. Info-Fenster für den Subprozess geöffnet werden, so dass dieser einsehbar wird, ohne die aktuelle Bearbeitung verlassen zu müssen. Aus Gründen des Layouts des vorliegenden Papiers wurde in der Abbildung 1 das Info-Fenster partiell vor das Arbeitsfenster geschoben, was sonst nicht so sinnvoll wäre!  Abbildung 2: Prozess Festmenü-Bereitung, Teil 1 Außer der in Abbildung 1 gezeigten hierarchischen (vertikalen) Aufteilung eines Prozesses auf Diagramme ist auch horizontale Aufteilung in sog. "Kacheln" möglich: Die Hauptkachel hat immer den Einstiegskonnektor "Start", die zugehörigen Fortsetzungskacheln haben davon verschiedene, frei wählbare Einstiegskonnektoren, auf die aus anderen Kacheln verwiesen wird. Im Beispiel der Abbildung 2 und Abbildung 3 heißt der Einstiegskonnektor der Fortsetzungskachel "Zubereitung", auf ihn wird aus der Start-Kachel verwiesen, was dort wiederum durch die dickere Umrandung des Symbols angezeigt wird. Auch hier öffnet Doppelklick auf den Verweiskonnektor die Fortsetzungskachel im Arbeitsfenster, während in einer Fortsetzungskachel Doppelklick auf den Einstiegskonnektor zur Kachel (bzw. zu einer Kachel-Auswahlliste) zurückführt, aus der (bzw. aus denen) auf die Kachel verwiesen wird. (Vorwärts- und Abwärtsverweise sind immer eindeutig, Rückwärts- und Aufwärtsverweise häufig nicht.)  Abbildung 3: Prozess Festmenü-Bereitung, Teil 2 Ein neues Subprozess- oder Fortsetzungskachel-Diagramm wird am bequemsten dadurch angelegt, dass auf das verweisende Symbol doppelgeklickt wird; dabei werden relevante Informationen automatisch ins neue Diagramm mit übernommen, bei Subprozessen z.B. alle dem Aufruf zugeordneten Elemente. Im Anhang (Kap. 4) wird überblicksartig die Semantik der wichtigsten Symbol-Arten und ihrer möglichen Beziehungen allgemein erläutert. Speziell nun soll ein Beispiel eines sehr geläufigen Produktionsprozesses aus der Alltagswelt vorgestellt werden: Abbildung 2 zeigt das Diagramm des Anfangsteils eines Prozesses zur Festmenü-Bereitung, nämlich die Planungs- und Einkaufs-Schritte, das Diagramm der Abbildung 3 zeigt den weiteren Prozessverlauf, nämlich die Zubereitungs-Schritte. Wie man sieht, ist ein Prozess eine strukturierte Abfolge von Prozess-Schritten, d.h. von Tätigkeiten, die Menschen oder Maschinen, häufig auch Menschen mit Maschinen durchführen. Ein solcher Schritt wird vom vorhergehenden oder nachfolgenden meistens nicht nur durch andere Tätigkeit sondern auch durch andere Bearbeitungsobjekte abgegrenzt. Prozess-Schritte werden deshalb in der Form <Objekt> <Verb> benannt, z.B. "Menüfolge auswählen". Während Zuordnung einer Rolle zu einem Prozess-Schritt, wie Rolle "Gastgeberin" zum Schritt "Menüfolge auswählen", anzeigt, dass die Rolle mit der Durchführung des Prozess-Schrittes (auch) befasst ist, gilt per Konvention, dass die Rollenzuordnung zu einem Konnektor für alle nachfolgenden Schritte gilt, bis ggf. bei einem späteren Konnektor eine neue Zuordnung erfolgt. Im vorliegenden Beispiel heißt das also, dass die Rolle "Koch" mit der Durchführung aller Prozess-Schritte befasst ist. Führt ein Pfeil von einer Ressource zu einem Prozess-Schritt, so ist diese Input für den Schritt, bei umgekehrter Pfeilrichtung ist die Ressource Output, d.h. sie wird in diesem Prozess-Schritt erzeugt. Im ersten Prozess-Schritt, "Menüfolge auswählen", wird also die "Gästeliste" gelesen und die "Menüfolge" erstellt. Ein Doppelpfeil zwischen Prozess-Schritt und Ressource bedeutet Veränderung (Update) derselben, vgl. u.a. den Schritt "haltbare Zutaten einkaufen" in Abbildung 2. Wenn eine Ressource erzeugt worden ist, kann i. A. davon ausgegangen werden, dass sie für die weiteren Prozess-Schritte des Ablauf-Pfads verfügbar ist. Wenn trotzdem Input einer gerade erzeugten Ressource explizit notiert wird, wie beim Schritt "Einkaufstermin feststellen", so wird damit die Notwendigkeit der Verfügbarkeit der Ressource dokumentiert. Es gilt nämlich, dass ein Schritt nur ausführbar ist, wenn alle seine Inputs verfügbar sind — es sei denn, die übliche Pfeileigenschaft "muss" wird in "optional" abgeändert, vgl. dazu Abbildung 7. Neben den eigentlichen Wirkungen eines Prozess-Schrittes, die sich aus seiner Benennung und ggf. auch aus seinen Ressourcen-Beziehungen bestimmen, hat er auch modell-logische Effekte, nämlich die Postulierung von Tatsachen, insbesondere wenn es die Aufgabe des Prozess-Schrittes ist, etwas festzustellen oder zu prüfen. Auf solche Tatsachen wird im weiteren Prozess-Verlauf mit Symbolen des Typs "Verzweigung" (zwei Ausgänge) bzw. "Guard" (ein Ausgang) Bezug genommen: Die magentafarbenen Rauten sind normalerweise mit der Frage nach Zutreffen eines Sachverhalts beschriftet. In der Abbildung 2 sorgen die ersten beiden Verzweigungen für bedingte Ausführung von Prozess-Schritten, die dritte dient zur Feststellung, ob die Einkäufe-Schleife ein weiteres Mal zu durchlaufen ist. Im Gegensatz zum Anfangsteil wird im zweiten Diagramm des Festmenü-Prozesses mittels sehr starker Parallelisierung ein sehr hohe Prozessflexibilität modelliert. Je nachdem, wie viele Personen für die Rolle "Koch" zum jeweiligen Zeitpunkt eingesetzt werden können, sind Arbeiten parallel durchführbar: Mit zwei Köchinnen sind am Vortag Vor- und Nachspeise, mit vier Leuten am Festtag die Appetithappen und die drei Teile des Hauptgangs parallel zubereitbar. Weniger Leute bedeutet weniger Parallelarbeit und also mehr Durchgänge durch die Zubereitung-Schleife, also stärkere Sequentialisierung. Der wohlbekannte Trade-off zwischen Personaleinsatz und Projektdauer wird in einer solchen Prozess-Struktur leicht erkenn- und vermittelbar. Am Personal- (oder Maschinen ) Einsatz wird auch der fundamentale Unterschied zwischen alternativen und parallelen Pfaden deutlich: Für Bedarfsabschätzung nach oben ist bei Alternativen das Maximum des Bedarfs an Personal (oder Maschinen), bei Parallelen die Summe der Bedarfe zu betrachten! Dieser fundamentale Unterschied ist ein wichtiger Grund für die deutliche Unterscheidung von Verzweigung und Parallelisierung in Collinor-GPM-Diagrammen. 2.2 Modellierungs-MethodikHinweise auf Abgrenzungen und Benennungen und sonstige Basisregeln des methodischen Modellierens mit Collinor-GPM finden sich schon im vorstehen Abschnitt (und ausführlich und umfassend im Anwenderhandbuch). Hier werden dagegen vor allem übergeordnete Aspekte dargestellt.
Mit dem Begriff "Funktionslinie" wird eine übliche Aufbaustruktur von Unternehmen und Organisationen verallgemeinert, wo die Geschäftstätigkeit arbeitsteilig in verschiedenen Bereichen (Abteilungen, Geschäftsbereiche, Org-Einheiten i.A.) erbracht wird. Ein charakteristisches Merkmal solcher Organisationsstrukturen ist, dass die jeweiligen Linien auf bestimmte Funktionen spezialisiert sind und die Fachleute bei den Geschäftstätigkeiten linien-übergreifend kooperieren.  Abbildung 4: Funktonslinien-Beispiel: Projektmanagement-Prozess Strukturell wesentlich für jegliche Funktionslinien-Modellierung ist, dass die Funktionslinien als Endlos-Schleifen modelliert sind, die Konnektoren am Anfang der Funktionslinien-Pfade also tatsächlich Schleifeneinstiegspunkte sind. (Konkret heißt das im Beispiel, dass – aus Sicht des Projektmanagements, wohlgemerkt! – der Vertrieb so lange nichts tut, bis eine Kundenanfrage entgegen genommen und bearbeitet werden kann; danach kommt wieder der Wartezustand.) Die Endlosschleifen haben auch zur Folge, dass es in diesem Prozessdiagramm keinen Ende-Konnektor gibt. Unter normalen Umständen endet ein solcher Prozess nie, es sei denn, das Unternehmen gibt das betreffende Geschäftsfeld auf oder ändert seine Organisation und Abläufe durchgreifend. Wenn nun also die der Funktion entsprechende fachliche Arbeit in den Funktionslinien parallel geleistet wird, stellt sich natürlich das Problem der Koordination von Tätigkeiten – in der Realität wie im Modell! In der Realität erfolgt die Koordination durch Kommunikation zwischen den in verschiedenen Funktionslinien angeordneten Prozessbeteiligten. Im Modell wird die Interaktion durch Senden und Empfangen von Informations-Ressourcen verschiedener Kategorien dargestellt. Im Beispiel der Abbildung 4 sind besonders Ressourcen der Kategorie "Schnittstelle" bemerkenswert: Schnittstellen in diesem speziellen Sinne sind gewissermaßen Transportbehälter für die Übermittlung von Dokumenten oder Dateien, wobei die Schnittstelle oft genauso heißt wie die übermittelte Ressource. Allerdings hat eine Schnittstelle – im Gegensatz zu "gewöhnlichen" Informations-Ressourcen – per Konvention die Eigenschaft, nur einmal gelesen werden zu können; diese Konvention ist wichtig, damit die Koordination richtig funktioniert. Im Beispiel sind die gezeigten Schnittstellen bidirektional, d.h. dass die Informations-Ressource vom Empfänger wieder an den ursprünglichen Sender zurück geschickt wird. (Schnittstellen-Ressourcen heißen so, weil sie (meistens koordinierende oder steuernde) Schnittstellen zwischen Funktionslinien modellieren.) Austausch von Information, nämlich Durchführungsmeldung (über Aufwand, Ergebnis, Status etc.) vom Fachbereich ans Management und – idealisiert! – Projektplan- Änderungs-Mitteilung vom Management an den Fachbereich, dient im Beispiel auch dazu, die beiden parallelen Schleifen, die "Controlling Loop" auf Projektmanagement- Seite und die "Doing Loop" auf Fachbereich-Seite, zu synchronisieren, aber nur soweit, wie es tatsächlich notwendig ist. Im naiven Ansatz eines gemeinsamen Ablaufpfads von Projektdurchführungs- und Projektleitungs-Schritten ist man dagegen gezwungen, genau vorzuschreiben, nach welchen Durchführungs- welche Leitungs-Schritte zu folgen haben und umgekehrt; häufig verführt eine einpfadige Modellierung auch noch dazu, Schritte zur Meldungserstellung und auswertung im Modell zu unterschlagen, die ja für ein (ordentliches) Projekt durchaus erfolgsrelevant sind. Funktionsablauf-orientierte Modellierung ist hier als Methodik ausführlicher dargestellt, weil sie wichtig ist, aber in Literatur und Vertriebsbroschüren oft vernachlässigt wird. Sie ist allerdings kein Allheilmittel und nicht immer und überall angemessen, wie andere Beispiele dieses Papiers zeigen. 2.3 Interaktions-ModellierungIn der herkömmlichen Geschäftsprozessmodellierung wird die Kommunikation zwischen den am Prozess beteiligten Menschen und Systemen meistens weitgehend oder völlig vernachlässigt. Erfahrungen bei der Erhebung von Ist-Prozessen haben aber gezeigt, dass eine wirklichkeitsgetreue Modellierung ganz stark von der Erfassung der Kommunikationswege profitiert. Deshalb ist Collinor-GPM auch technisch und methodisch für die Modellierung der Kommunikation, die Interaktions-Modellierung, eingerichtet. Abbildung 5: Prozessmodell mit Kommunikationswegen Ein Beispiel für Interaktionsmodellierung wurde schon anhand des Diagramms in Abbildung 4 vorgestellt, allerdings eines, wo allein die dynamischen Kommunikationsaspekte wiedergegeben werden. Strukturelle Kommunikationsaspekte sind dagegen schön aus dem Beispiel in Abbildung 5 und Abbildung 6 zu sehen. Abbildung 5 zeigt ein Vorgehensmodell für Organisation und Durchführung von Software-Anwendertests (Blackbox-Tests). Im Diagramm werden außer dem Ablauf-Fluss der Testabwicklung auch Informationsflüsse gezeigt, die sich im Umfeld abspielen. Dabei ist u.a. bemerkenswert, dass die explizit modellierte "Akzeptanztest"-Schleife eine Schleife außerhalb der Testabwicklung induziert, die durch Senden einer "Neu-Anforderung Testobjekt" – siehe Tätigkeit "akzeptables Testobjekt anfordern" – bei der Org-Einheit "Entwicklung" ebendies veranlasst; die spezielle Kategorie "Sync Message" besagt, dass die Meldung höchstens einmal konsumiert (gelesen, gehört etc.) werden kann. (Vgl. die Kategorie "Schnittstelle" oben im Projektmanagement-Beispiel.)  Abbildung 6: Kommunikations- und Tätigkeitsübersicht Abbildung 6 zeigt die Organisations- und Kommunikationsstruktur des genannten Vorgehensmodells. Das Diagramm ist aus dem der Abbildung 5 durch Kopieren hervorgegangen, die Ressourcen-Symbole wurden gelöscht (und damit auch die entsprechenden Beziehungspfeile), ebenso die rein ablaufbezogenen Symbole und Pfeile. Die verbliebenen Elemente wurden neu angeordnet und mit den beschrifteten Beziehungen ergänzt, die die Kommunikations- und Interaktionsbeziehungen zwischen den beteiligten Rollen zusammenfassen. Aus dem Diagramm der Abbildung 6 ist nun leicht erkennbar, welche Tätigkeiten die einzelnen Rollen durchführen und welche Informationen über welche Kanäle zwischen den Rollen ausgetauscht werden. Hier zeigt sich also der Weg, wie ein Prozessmodell in eine UML-Use-Case-Struktur und ein Informationsflussmodell (verallgemeinertes UML Collaboration Diagram) überführt werden kann. Mit anderen Worten, eine eventuelle Automatisierung des Vorgehensmodells, d.h. Unterstützung des modellierten Prozesses durch IT-Komponenten, ist durch die methodische Modellierung mit Collinor-GPM schon weitgehend spezifiziert: Ein Diagramm wie Abbildung 6 gibt die Architektur vor, die Abläufe innerhalb der Architekturblöcke werden gemäß Abbildung 5 vorgegeben; daraus ist insbesondere auch die für den Erfolg jeglicher IT-Unterstützung von Prozessen entscheidende Frage der System-Schnittstellen klärbar: Je genauer Interaktion analysiert und im Prozess-Modell wiedergegeben wird, desto sicherer kann man sein, dass alle System-Schnittstellen korrekt berücksichtigt werden! (Verfeinerung dieses Ansatzes führt zur GP-basierten System- und objektorientierten Programm- Spezifikation.) 3 Übergang zum ProjektOperative Prozesse können (im Gegensatz zu dispositiven, Management-Prozessen) in Projekte überführt werden. Für den Übergang vom Geschäftsprozessmodell zum vollständigen Projektplan sind strukturelle Umformungen und zusätzliche Informationen vonnöten. Letztere müssen vom Modell-Designer bereit gestellt werden. Damit dies geschehen kann, gibt es in Collinor-GPM die sog. Attributierung, d.h. es sind für die verschiedenen Symboltypen spezifische Felder vorgesehen, in die die Zusatzangaben eingetragen werden können. Zusätzlich werden struktur-bezogene Angaben benötigt, z.B. um Schleifenbereiche mittels sogenannter Grenzkonnektoren eindeutig zu demarkieren. Im Anwenderhandbuch zu Collinor-GPM werden die Strukturanforderungen und die Attribut-Felder im einzelnen erläutert. Hier, im vorliegenden Papier, können nur Beispiele genannt werden.Für Prozess-Schritte (auch Tätigkeiten genannt) gibt es z.B. Attribute für Zeitdauer- und Bearbeitungszeit-Angaben (mittlere, minimale und maximale) und Angaben zu Voraussetzungen und Aktionen. Die Aktionsangaben sind für die Ablaufsteuerung des Projekts besonders interessant; sie haben die Form von möglichen "Variablen-Besetzungen", d.h. es werden Variablen einer Ablaufstruktur benannt und ihnen Wertealternativen und ggf. Werte zugeordnet. Für das Verständnis dieser Zuordnungen kann man sich vorstellen, dass bei einer Simulation des Prozesses bestimmte zulässige Variablenzuweisungen erfolgen, wenn der Prozess-Schritt in der Simulation ausgeführt wird. Auf solche Variablen wird dann z.B. durch die Attributierung von Verzweigungen Bezug genommen. D.h. dass dasjenige, was durch Symbolbeschriftung im Diagramm mehr oder weniger intuitiv ausgedrückt wird, durch die Variablen-Besetzung in einem Prozess-Schritt und die Variablen-Abfrage in einer direkt oder später nachfolgenden Verzweigung (oder Guard) formal exakt umgesetzt wird. Variablen, die auf diese Weise (oder, mittels Attributierung des Start-Konnektors, als Prozess-Variablen) definiert sind, werden beim Übergang zum Projekt in die Projekt-Vorlage und daraus in den Projektplan übernommen. Dort haben sie dann die Funktion von Schaltern, die Einfügen von Vorgängen in den Projektplan veranlassen oder unterbinden oder Modifizieren von Vorgangsdaten bewirken. Vgl. dazu die Umsetzung des o.g. Festmenü-Beispiels in Abbildung 8, worin man ersehen kann, dass von der (im Bild noch unbestimmten) Variablen "Einkaufstermin" die beiden mit Durchkreuzung markierten Vorgänge "haltbare Zutaten einkaufen" bzw. "frische Zutaten einkaufen" abhängen und dass als mögliche Werte "haltbar" und "frisch" (außer den Standardwerten) zur Auswahl anstehen, wie aus dem überlagernden Fenster (rechts im Bild) erkennbar ist. Ein Symbol-Attribut, das nicht nur für die Projekt-Überführung interessant ist, wurde oben schon gelegentlich erwähnt, nämlich das Kategorie-Attribut beim Symboltyp Ressource. Weil dieses Attribut unabhängig von Projektgenerierung eine wichtige Rolle spielt, wird sein Wert im Kopf des Ressourcen-Symbols gezeigt. Die möglichen Kategorie-Arten sind (wie einige andere Attribute auch) in einer Auswahl-Liste vorgegeben. Diese Listen können in der Prozessverwaltung von Collinor IRP erweitert werden.  Abbildung 7: Collinor-GPM—Attributierung Außer Symbolen können auch die Ablauf- und Beziehungspfeile attributiert werden. Abbildung 7 zeigt einen Snapshot mit dem Diagramm für einen Subprozess des Prozesses von Abbildung 1. Wie der Snapshot zeigt, wurde der Ablaufpfeil von Tätigkeit "umgestellte Portion für Test aufbereiten" zum Parallel-Join selektiert. Im Fußteil des gezeigten Fensters sind die Felder und Radio-Buttons für Ablaufpfeile zu sehen, z.B. rechts unten die Auswahl-Alternativen "Muss" und "Optional", die etwa bei einem Parallel-Join angeben, ob alle Pfade "angekommen" sein müssen, damit der Ablauf nach der Zusammenführungsstelle fortgesetzt werden kann, oder nicht.. Rechts oben im Fußbereich kann für den "Ablauftyp" aus einer Auswahlliste ein Wert gewählt werden, der die Abhängigkeitsbeziehung zwischen Vorgängen im Projektplan bestimmt; im Beispiel wird die voreingestellte Ende-Anfang-Beziehung gezeigt, die besagt, dass der Nachfolger-Vorgang beginnt, wenn der Vorgänger-Vorgang beendet ist. Vorgänge im Projektplan ergeben sich aus Prozess-Schritten im Prozessmodell. Wie das Beispiel weiter zeigt, kann beim Ablaufpfeil auch schon angegeben werden, welche Übergangszeit für Zeitplanung im Projekt berücksichtigt werden soll. Ein Ziel der Attributierung im Prozessmodell ist das "Single source"-Prinzip, das hier nicht nur bedeutet, Angaben an einer einzigen Stelle zusammen zu fassen, sondern auch, die Angaben da zu machen, wo die Informationen zuerst verfügbar werden.  Abbildung 8: Collinor IRP – Projektportal / Variablen-Bestimmung Als Beispiel eines Übergangs vom Prozessmodell zum Projekt wird das eingangs diskutierte Prozessmodell der Festmenü-Bereitung noch einmal herangezogen. Abbildung 8 zeigt einen Zustand der Planung des erzeugten Projekts, wo die Variablen aus der Attributierung noch keine bestimmten Werte haben. Deshalb sind die von Variablen abhängigen Vorgänge der Phase "Einkäufe" und der Phase "Zubereitung" mittels der roten Durchkreuzung als "nicht realisiert" markiert. In dem kleinen Fenster, das einen (leeren) Teil des Gantt-Diagramms überlagert, ist die Liste aller definierten Variablen zu sehen ; für die erste, "Einkaufstermin", ist – wie bereits oben erwähnt – die Auswahlliste der möglichen Werte aufgeklappt. Ein wichtiger Aspekt der Überführung in Projekte von Prozessmodellen mit Verzweigungen oder Guards ist, dass im Projektplan zwar Vorgänge für die in alternativen oder optionalen Ablaufpfaden liegenden Prozess-Schritte angelegt, aber in ihrer relativen Dauer und in ihren Abhängigkeiten (z.B. parallel vs. sequentiell) nicht von vorn herein entschieden werden können, wenn die den Projektverlauf steuernden Variablen erst im Verlauf der Projektdurchführung bestimmbar sind. Auch deshalb hat Collinor IRP die Fähigkeit des "dynamischen Projektplans", d.h. ein partiell geplantes Projekt bereits zu starten und die Planung während der Durchführung anzupassen und schließlich zu vervollständigen.  Abbildung 9: Projekt Festmenü-Bereitung: Stand vor Beginn der Phase Zubereitung Abschließend sei ein Blick auf den Stand des Festmenü-Projekts vor Beginn der Phase "Zubereitung" geworfen, siehe Abbildung 9. Aus dem Gantt-Diagramm ist zu ersehen, dass der Termin für den Einkauf der haltbaren Zutaten (sinnvollerweise!) vor dem für die frischen lag und dementsprechend die Einkäufe-Schleife zweimal durchlaufen wurde. (Dass der Einkauf der haltbaren Zutaten eine so viel längere Zeitdauer hat, liegt daran, dass unser Koch am Dienstag, dem 11.02.03, um 17 Uhr Feierabend machte und den Einkauf am Folgetag ab 8 Uhr fortsetzen musste!) Des weiteren ist aus dem Diagramm ersichtlich, dass zum gezeigten (damals!) aktuellen Zeitpunkt, 14 Uhr am 12.02.03, offensichtlich noch nicht klar war, ob der Koch die Zubereitung nun alleine machen muss. (Die Länge der "nicht realisierten", d.h. rot durchkreuzten, Vorgänge ergibt sich aus Mindestannahmen, bei denen insbesondere auch Tageswechsel berücksichtigt werden; daraus wird der erkennbare Unterschied zwischen Zubereitung der Vor- und Nachspeise und des Hauptgerichts klar.) 4 Anhang: GPM-Diagramm-Elemente selbsterklärt Abbildung 10: Überblicksdiagramm der Symbole und Pfeile  Abbildung 11: Ergänzung zum Überblicksdiagramm der Abbildung 10 In den beiden vorstehenden Abbildungen werden die für Geschäftsprozessmodellierung (GPM) zum Zweck der Dokumentation und Kommunikation wesentlichen Symbole und Beziehungen gewissermaßen "durch sich selbst" erläutert. Für die GPM zum Zweck der Projektgenerierung sind in Collinor-GPM neben der Attributierung zusätzliche Symbole und Beziehungen vorgesehen, die hier nicht gezeigt werden. (Sie werden natürlich im Anwenderhandbuch ausführlich dargestellt.) Hinweis: Um "ankommende" und "abgehende" Pfeile ("fette" Ablauf- und "normale" Beziehungspfeile) eindeutig unterscheiden zu können, wird bei Prozess-Schritt-, Subprozess- und Ressourcen-Symbolen automatisch dafür gesorgt, dass einfach gerichtete Pfeile immer an der Symbol-Oberkante ankommen (d.h. dort den Pfeilkopf haben) und an der Symbol-Unterkante abgehen. Doppelt gerichtete Pfeile laufen demnach immer von Oberkante zu Oberkante. (Diese Layout-Eigenschaft hängt mit der Modellierungs-Empfehlung zusammen, wo immer es geht, Abläufe von oben nach unten anzuordnen.) |
||||
© COLLINOR SOFTWARE GMBH
