Schlüssel zum Verständnis von AMADEE 3.0 und der Methodik

1) Prozesse werden in AMADEE 3.0 angelegt, nicht frei gezeichnet.

AMADEE 3.0 kennt kein freies Zeichnen von Geschäftsprozessen. Alle Modellobjekte werden einzeln angelegt - entweder im Szenario-Explorer oder im Diagramm. Das Anordnen der Symbole übernimmt AMADEE 3.0 automatisch. Die Symbole sind daher immer korrekt im Modell dargestellt.

2) Die Änderung eines Modellobjekts wirkt sich automatisch auf alle betroffenen Diagramme aus.

Wenn Sie an einer Stelle ein Modellobjekt verändern, sorgt AMADEE 3.0 automatisch dafür, dass sich die Änderung auf das gesamte Szenario auswirkt. Beispielsweise ändern Sie die Bezeichnung einer Organisationseinheit. Alle Diagramme, in denen diese Organisationseinheit abgebildet ist, übernehmen automatisch die neue Bezeichnung. Dies hält die Prozessdokumentation konsistent und aktuell.

3) Services sind der Dreh- und Angelpunkt für die Geschäftsprozessmodellierung mit AMADEE 3.0.

Services werden als Bausteine der Wertschöpfung eines Unternehmens verstanden. Sie stellen eine Kunden-Lieferanten-Beziehung dar, die durch den Austausch von Nachrichten charakterisiert ist. Die Service-Beziehung kann sowohl intern zwischen Abteilungen als auch zu anderen Unternehmen bestehen. Dieses Konzept wird im Ansatz von AMADEE als Service-Paradigma bezeichnet. Es geht über die Prozessdarstellung mittels herkömmlicher Flussdiagramme hinaus. Weiterhin ermöglicht das Service-Paradigma die Ableitung von Kriterien für die Prozessgüte. Schwachstellen im Service können automatisch von AMADEE 3.0 aufgedeckt werden.

1) Die AMADEE Methodik kennt Services und Aufgaben, keine Aktivitäten.

Häufig wird in der Prozessmodellierung von Aktivitäten oder Tätigkeiten gesprochen. Beispiele sind "mit Kunden telefonieren" oder "Besprechung abhalten". Für ein Unternehmen sind jedoch nicht die Aktivitäten relevant, sondern die daraus resultierenden Ergebnisse.

Die zuvor genannten Beispiele lassen sich ebenso ergebnisorientiert formulieren. Sie lauten dann beispielsweise "Kundenproblem lösen" oder "Maßnahmen definieren". Die Ergebnisorientierung in der Geschäftsprozessmodellierung wird über Services und Aufgaben umgesetzt. Während Services direkte Leistungen für andere sind, stellen Aufgaben Leistungen "für sich selbst" dar. Aufgaben können indirekt in Services für andere Organisationseinheiten einfließen.

2) Die wertschöpfende Leistung eines Services vollzieht sich auf einem Geschäftsobjekt.

Services produzieren ein Ergebnis, das sich immer auf ein Geschäftsobjekt bezieht. Ein Geschäftsobjekt ist ein relevanter materieller oder immaterieller Gegenstand der Geschäftswelt, z.B. Ware, Produkt, Kunde, Lieferant, Mitarbeiter, Software oder Bericht. Ein Service kann bspw. ein Geschäftsobjekt herstellen, verändern, prüfen, transportieren oder veräußern. Geschäftsobjekte geben Anhaltspunkte, welche Services zu einem End-to-End-Prozess gehören und welche IT-Systeme eingesetzt werden. Beispielsweise werden Services mit dem Geschäftsobjekt "Kunde" dem Vertriebs- bzw. Kundenmanagementprozess zuzuordnen sein und durch ein CRM-System unterstützt.

3) Das Geschäftsobjekt eines Services bleibt während der Ausführung dasselbe.

Wird beispielsweise der Geschäftsprozess zur Durchführung von Projekten modelliert, so ist das entsprechende Geschäftsobjekt das "Projekt". Aufgaben im Rahmen eines Projekts sind die Projektplanung, Kickoff, Durchführung, Abschluss und Nachbereitung. Jede dieser Aufgaben bezieht sich auf genau ein bestimmtes Projekt. Andere Aufgaben im Umfeld des Projektmanagements, die sich nicht auf das einzelne Projekt beziehen, werden in separaten Services abgebildet. Hierzu zählen u.a. Aufgaben des Multi-Projektmanagements oder die Personalbeschaffung. Ruft bspw. ein Controlling-Service aus dem Multi-Projektmanagement den Berichtsservice einzelner Projekte auf, so besteht eine 1:n-Beziehung - mehrere Projektberichte führen zu einem Gesamtbericht. Dieses Beziehungsverhältnis bzw. diese Kardinalität von Service-Aufrufen leitet sich von den zugrunde liegenden Geschäftsobjekten ab.

4) Der Kontrollfluss repräsentiert die Verantwortung für einen Service und kennt keine Verzweigungen.

Die Abfolge von Prozessschritten wird über den Prozessfluss bzw. Kontrollfluss dargestellt. Logische Regeln führen üblicherweise zu Verzweigungen des Prozessflusses. Liegt zum Beispiel das Beschaffungsvolumen über 10.000 Euro, ist eine Zweitunterschrift erforderlich, bei Beträgen darunter nicht. Diese Regel führt bei herkömmlichen Flussdiagrammen zu einer Verzweigung des Prozessflusses, wobei in dem Zweig über 10.000 Euro die Lieferung der Zweitunterschrift dargestellt wird. Die AMADEE Methodik sieht für diesen Fall einen Aufruf des Services "Zweitunterschrift" vor, der nur bei Eintritt der Bedingung "Betrag größer 10.000 Euro" erfolgt. Dadurch wird eine Verzweigung im Kontrollfluss vermieden und das Geschäftsprozessmodell bleibt übersichtlich. Da in der AMADEE Methodik der Kontrollfluss die Verantwortung für einen Service repräsentiert, werden Verzweigungen grundsätzlich unterbunden. Die Verantwortung kann nur wechseln, sich aber nicht teilen.

5) Ein SLA/SLP bezieht sich auf einen einzelnen Service, ein KPI auf alle Services einer Periode.

Werte eines Service Level Agreements (SLA) oder Service-Level-Protokolls (SLP) beziehen sich immer auf einen einzelnen Service (Instanz). Beispielsweise wird mit dem Kunden vereinbart, dass er spätestens in 5 Tagen das Angebot erhält (SLA). In der Regel benötigt das Unternehmen aber nur eine Durchlaufzeit von 2 Tagen für die Erstellung des Angebots (SLP). SLA- und SLP-Werte gelten für einen bestimmten Service. Im Gegensatz dazu ist ein Key Performance Indicator (KPI) eine Kennzahl, die für eine bestimmte Periode berechnet wird. Alle Service-Instanzen dieser Periode fließen in die Berechnung des KPI ein. Die "durchschnittliche Durchlaufzeit für Angebote im Monat Januar" oder die "Anzahl Angebote mit mehr als 10 Tagen Durchlaufzeit im Jahr 2010" sind demnach periodenbezogene Kennzahlen.

6) Die ServiceMap-Vorlage enthält abstrakte und standardisierbare, die ServiceMap auch reale Service-Merkmale.

In der ServiceMap-Vorlage werden u.a. Rollen, Schnittstellen und Service-Vorlagen definiert. Diese Informationen dienen einer allgemeingültigen Beschreibung von Geschäftsprozessen, z.B. in Form von Referenzprozessen. In der ServiceMap sind dagegen die realen Begebenheiten dargestellt. Organisationseinheiten führen Services aus, setzen dabei konkrete Ressourcen ein und übermitteln Nachrichten über bestimmte Medien. Von einer ServiceMap-Vorlage können verschiedene ServiceMaps abgeleitet werden, z.B. weil die Ausführung regional unterschiedlich ist.