Die Methode eXperience

eXperience steht für die seit dem Jahre 2000 praktizierte Methode, authentisches Wissen rund um E‑Business und IT‑Management zu vermitteln. Der Kern besteht in der Dokumentation von Praxislösungen nach einem einheitlichen Raster. Unter dem Label „eXperience“ wurden die Fallstudien auf drei Kanälen veröffentlicht:

1. Eine öffentlich zugängliche Fallstudiendatenbank (eXperience-online.ch)
2. Eine jährliches Buch, in dem jeweils ca. 14 Fallstudien publiziert wurden (bis 2009)
3. Jährliche Fachkongresse (eXperience Event und Koblenzer Forum für Business Software), an denen ausgewählte Fallstudien von den Projektverantwortlichen vorgestellt wurden (bis 2009).

In den Jahren 2000 bis 2009 wurden im Gespräch zwischen Hochschulvertretern und Praktikern ein aktuelles Thema für die Fallstudien identifiziert, das anschliessend den Buchtitel bildete. Zu diesem Thema erfolgt zu Beginn des eXperience-Zyklus eine Suche nach Projektverantwortlichen, die bereit sind, die Erfahrungen aus passenden Business-Software-Projekten in mehreren Interviews von Hochschulvertretern dokumentieren zu lassen. Es erfolgte ein öffentlicher Aufruf, ein so genannter „Call for Cases“, gefolgt von der Auswahl der Fallstudien durch die Herausgeber aufgrund ihrer Eignung zur Wissensvermittlung.

Die Fallstudien wurden von unabhängigen Autoren direkt bei den im Projekt beteiligten Vertretern der porträtierten Firmen erhoben. Die Dokumentation erfolgte einheitlich nach der in den folgenden Abschnitten vorgestellten Systematik.

Einheitliches Fallstudienraster

Die eXperience Fallstudien sind alle nach einem einheitlichen Inhaltsraster verfasst (vgl. Abb. 1). Im ersten Kapitel werden zunächst der Hintergrund des Unternehmens, die Branche, die angebotenen Produkte, die Zielgruppe sowie die Unternehmensvision des porträtierten Unternehmens vorgestellt. Dabei werden auch der Stellenwert der Informatik und die Haltung zu E-Business beleuchtet. Im darauf folgenden Kapitel werden die Auslöser für das Projekt sowie die im Kontext der Fallstudie wichtigsten Geschäftspartner vorgestellt. Kapitel drei beschreibt das Ergebnis des vorgestellten Projekts als statische Momentaufnahme und schildert dieses aus der Geschäfts-, Prozess-, Anwendungs- und technischen Sicht. Im folgenden Kapitel werden die dynamischen Aspekte des Projekts vorgestellt: der Weg zum Investitionsentscheid, das Projektmanagement, die Entstehung der Softwareapplikation resp. Einführung von Standardsoftware sowie der Unterhalt des Gesamtsystems.

Im fünften Kapitel erfolgt die Beschreibung der mit der Lösung seit ihrer Einführung gemachten Erfahrungen. Hier wird die Nutzerakzeptanz beleuchtet und die Projektresultate werden den ursprünglichen Zielen gegenübergestellt. Kosten, Nutzen und Rentabilität der Lösung werden reflektiert, so weit die Unternehmen diesbezüglich Angaben gemacht haben. Das Abschlusskapitel geht zusammenfassend auf wichtige Erfolgsfaktoren ein. In einem Rückblick werden die Spezialitäten der Lösung und die spezifischen Aspekte in Bezug auf das Fokusthema des Buchs herausgehoben. Den Abschluss bilden die Lessons Learned der Personen, die an der Erstellung der Fallstudie beteiligt waren.

Abb. 1: Einheitliche Systematik der Fallstudien

Sichtweisen auf die Fallstudien

Jede Geschäftslösung mit Einsatz von Business Software kann aus verschiedenen Sichten betrachtet werden. Um dem Leser die Orientierung in den Fallstudien zu vereinfachen, legen die Autoren für die Beschreibung der Lösung einen einheitlichen Aufbau zugrunde (vgl. Abb. 2). Die Geschäftssicht beschreibt die beteiligten Geschäftspartner mit ihren Rollen und Zielen. Die Prozesssicht beleuchtet die Abläufe im Einzelnen. Die Anwendungssicht beschreibt, wie die Lösung auf die beteiligten Informationssysteme verteilt ist und wie deren Integration erfolgt. Die technische Sicht betrachtet die beteiligten Systemkomponenten und ihre Anordnung im Netzwerk. Die einzelnen Sichten werden in den folgenden Abschnitten einzeln vertieft, wobei auch die Systematik der verwendeten Grafiken vorgestellt wird.

Abb. 2: Vier Perspektiven in den Fallstudien

Geschäftssicht (Business Szenario)

In der Geschäftssicht wird die Wertschöpfungskonstellation des vorgestellten Projekts behandelt. Sie stellt damit den für das Verständnis des Projekts relevanten Ausschnitt aus dem Geschäftsmodell dar. Es wird gezeigt, welche Partner welchen Anteil an der Leistung erbringen. Dabei werden deren Beziehungen und die Anliegen der Beteiligten vorgestellt. Es soll verständlich werden, warum die Parteien auf die vorgestellte Weise zusammenarbeiten und welche Ziele sie verfolgen

Abb. 3: Business Szenario: Rollen und Arbeitsteilung an Beispiel Kauf einer Maschine

Die Übersicht über das Projekt wird mit einem Business Szenario vorgestellt, wie es exemplarisch in Abb. 3 dargestellt ist. Darin werden die in dem zu diskutierenden Kontext relevanten Ausschnitte eines Marktschemas, einer Supply Chain, der Zusammenarbeit in einem Konzern oder auch nur der fachbereichsübergreifenden Zusammenarbeit in einem Unternehmen abgebildet. Das Business Szenario zeigt die Beteiligten in ihren Rollen, die im Kontext wichtigsten Prozesse sowie die Austauschbeziehungen zwischen diesen Prozessen.

Prozesssicht

Nachdem das Business Szenario die einzelnen Geschäftsprozesse in ihrem Kontext eingeordnet hat, werden ausgewählte Prozesse in der Prozesssicht vertieft behandelt. Bei grafischen Abbildungen wird auf die Methode der erweiterten Ereignisgesteuerten Prozesskette EPK zurückgegriffen. Diese wurde am Institut für Wirtschaftsinformatik der Universität des Saarlandes entwickelt [Keller et al. 1992] und wird in diesem Buch in einer vereinfachten Form verwendet.

Die erweiterte Ereignisgesteuerte Prozesskette zeichnet sich dadurch aus, dass sie auf relativ übersichtliche und verständliche Weise mehrere Sichten auf den Prozess miteinander verbindet. Vier davon sind für die Beschreibung des Fachkonzepts für Informationssysteme erforderlich: die Datensicht, die Funktionssicht, die Organisationssicht und die Steuerungssicht. Die Modellelemente zeigt Abb. 4.

Abb. 4: Modellelemente der erweiterten Ereignisgesteuerten Prozesskette (eEPK)

Die Ereignisgesteuerte Prozesskette nimmt Zustände eines Prozesses in die Abbildung der Aufgabenkette mit auf. Zustände werden als Ereignisse dargestellt, wobei ein Ereignis das Eingetretensein eines bestimmten Faktums bedeutet. Dieses Faktum kann als Information in einem Informationsverarbeitungssystem gespeichert werden. Das oder die Ereignisse, die einen Prozess auslösen, können dementsprechend bestimmte Ausprägungen (Werte) von Daten sein. Z.B. kann das Sinken eines Artikellagerbestands auf einen bestimmten Wert das Ereignis „Mindestlagerbestand ist unterschritten“ auslösen und einen Bestellprozess anstossen. Auch innerhalb eines Prozesses wird jede einzelne Aufgabe durch ein oder mehrere Ereignisse ausgelöst. Eine Aufgabe beinhaltet eine oder mehrere Tätigkeiten, die an einem Prozessobjekt verrichtet werden und dieses vom Eingangszustand in den Ausgangszustand überführen. Der Ausgangszustand wird als neues Ereignis aufgefasst und mit dem verarbeiteten Prozessobjekt kann eine Daten-Variable einen neuen Wert annehmen. Eine Aufgabe „Bestellung durchführen“ würde z.B. dazu führen, dass ein Prozessobjekt „Bestellung“ erzeugt würde und nach vollständiger Erfüllung der Aufgabe den Zustand „Bestellung ist erfolgt“ einnehmen würde. Ereignisse können also einzelne Aufgaben oder ganze Prozesse auslösen. Diese wiederum resultieren in einem neuen Ereignis.

Die Identifikation der Zustände als Eingangs-, Ausgangs- oder Zwischenereignis erleichtert die Aufteilung grosser Hauptprozesse in sinnvolle Teilprozesse. Zustände sind geeignet für die Beschreibungen von Prozessübergängen (Schnittstellen), wie sie beim Wechsel der Verantwortung von einem Bereich zu einem anderen oder bei der Integration zweier Informationssysteme auftreten.

Die Erweiterung der Basiselemente der Ereignisgesteuerten Prozesskette besteht in der Assoziation zusätzlicher Erläuterungen, z.B. Input-/Output-Vorgänge, betroffene Informationsobjekte und Angaben zu Organisation und Informationssystemen.

Anwendungssicht (Verteilung und Integration der Systeme)

Die Anwendungssicht betrachtet die beteiligten Informationssysteme und ihre Verteilung auf die im Business Szenario vorgestellten Rollen. Eine Software­anwendung wird dabei als eine logische Einheit im Sinne des Anwenders verstanden. Eine denkbare Verteilung der Anwendung auf mehrere technische Systeme wird in der technischen Sicht behandelt. Das verwendete Schema [Schubert 2003] zeigt die Verteilung der wichtigsten Funktionen und Daten, was für das Verständnis der Verantwortungsbereiche, Abhängigkeiten und damit Risiken der Lösung wichtig ist. Indem für die Systeme die drei Layer Datenhaltung, Geschäftslogik und Benutzerinterface unterschieden werden, lässt sich aufzeigen, auf welcher Ebene die Integration erfolgt.

Das Schema soll mit folgendem Beispielszenario erläutert werden (vgl. Abb. 5): Ein Handelsunternehmen in einem beratungsintensiven B2B-Marktsegment will seine Marktstellung grundsätzlich verbessern. Dies soll durch die Ausweitung des Sortiments, die Erhöhung der Lieferfähigkeit sowie die schnellere und effizientere Bestell- und Auftragsabwicklungsprozesse bei den Kunden und im eigenen Unternehmen erfolgen. Abb. 5 zeigt das für diese Anforderungen entworfene Lösungsszenario, die darin involvierten Anwendungssysteme und deren Integration. Ein E‑Shop soll den Kunden in Zukunft ein komfortables One-Stop-Shopping bieten, er ist aber ausschliesslich via Internet und Browser zugänglich. Neben zahlreichen Zusatzinformationen zu den Produkten sind die kundenindividuellen Preise sowie die aktuelle Artikelverfügbarkeit anzuzeigen. Dies wird erreicht, indem ein zur Produktfamilie des ERP-Systems gehörender E‑Shop (ein E‑Business-Modul) ausgewählt wird, der über eine systeminterne, proprietäre Schnittstelle direkt auf die Applikationslogik des ERP-Systems zugreift. Zur Erhöhung der Lieferverfügbarkeit wird eine Integration mit den Vorlieferanten vereinbart. Mit dreien von ihnen, die insgesamt 80 % des Sortiments abdecken können, wird eine 1:1-Integration auf Stufe der ERP-Systeme eingerichtet. Mit ihrer Hilfe werden Aufträge und Artikelverfügbarkeit mehrmals in der Stunde abgeglichen.

Abb. 5: Anwendungsübersicht mit Unterscheidung der Ebenen: Verteilung der Systeme

Technische Sicht

Die technische Sicht beschreibt die Verteilung der Softwareanwendungen auf Hardwaresysteme, deren Einbindung in ein Netzwerk resp. Verbund von Netzwerken sowie Spezifikationen der Softwaresysteme. Je nach Besonderheit des einzelnen Falls kann sie weitere Aspekte behandeln.

Das folgende Szenario zeigt beispielhaft die Verteilung des Zeit- und Leistungserfassungssystems TimeCollect auf mehrere Netzwerke, Zonen und Systeme (vgl. Abb. 6). TimeCollect ist eine internetbasierte Anwendung zur Erfassung von Arbeitszeiten der Mitarbeitenden und wurde zurzeit- und Leistungserfassung an einer der Vorgängerinstitutionen der Fachhochschule Nordwestschweiz FHNW eingesetzt.

Abb. 6: Beispielgrafik für die Technische Sicht: Netzwerk und Systeme TimeCollect

Die besprochenen Rechnersysteme werden in der Abbildung durch einheitliche grafische Symbole repräsentiert. Die Systeme können in separaten Tabellen mit zusätzlichen Informationen zur Hardware, zur Software (z.B. Betriebssystem) etc. näher bezeichnet werden. Angaben zu Hard- und Softwaremerkmalen der Systeme werden mit der Anzahl der Nutzer, für die die Systeme ausgelegt wurden, kommentiert.

Literaturverzeichnis

Keller, Gerhard; Nüttgens, Markus; Scheer, August-Wilhelm (1992): Semantische Prozessmodellierung auf der Grundlage „Ereignisgesteuerter Prozessketten (EPK)“, in Scheer, August-Wilhelm (Hrsg.): Veröffentlichungen des Instituts für Wirtschaftsinformatik, Heft 89, Saarbrücken, 1992.

Schubert, Petra (2003): E-Business-Integration, in: Schubert, Petra; Wölfle, Ralf; Dettling, Walter (Hrsg.), E-Business-Integration: Fallstudien zur Optimierung elektronischer Geschäftsprozesse, S. 1-21, München, Wien: Hanser Verlag, 2003.