Der Markt im Telekommunikationsumfeld ist derzeit von Übernahmen und Fusionen geprägt. Darüber hinaus müssen in diesem schnelllebigen Geschäft oft übergreifende Geschäftsprozesse zwischen verschiedenen Unternehmen und Organisationen in kürzester Zeit angepasst oder erweitert werden. Hierbei ist der Einsatz von vordefinierten Prozessstrukturen sinnvoll, um diese anspruchsvollen Aufgaben in der verfügbaren Zeit bewältigen zu können. Entsprechende Prozessstrukturen können sowohl das Zusammenlegen der Prozesse unterschiedlicher Telekommunikations-Unternehmen bei einer Fusion unterstützen als auch für den gemeinsamen Entwurf organisationsübergreifender Geschäftsprozesse verwendet werden. Diesbezüglich spielt neben der Integration auf Geschäftsprozessebene insbesondere die technische Integration der erforderlichen Systeme eine zentrale Rolle. Die Herausforderung bei diesen Projekten besteht dann darin, das Wissen und die Erfahrung aller beteiligten Parteien in kürzester Zeit effektiv zu nutzen, um entsprechende Prozesskonsolidierungen oder übergreifende Prozesse aufbauen oder ändern zu können. Hierzu wird eine Unterstützung von kollaborativem Arbeiten von der Anforderungsspezifikation bis hin zur Inbetriebnahme der neuen Prozesse und der dazugehörigen Softwarekomponenten benötigt.
Im europäischen Telekommunikationsmarkt ist „3“ – die Mobilfunkmarke des asiatischen Mischkonzerns Hutchison Whampoa Konzerns mit Headquarter in Hong Kong – derzeit eines der am schnellsten wachsenden Unternehmen. In den letzten Jahren hat das Unternehmen einige Übernahmen und Fusionen in Europa erfolgreich durchgeführt. Weiterhin gab es viele Anpassungen von organisationsübergreifenden Prozessen, beispielsweise durch den Wechsel von Logistikpartnern in der Supply Chain. Bei den Unternehmensfusionen liegen die Herausforderungen im Konsolidieren gegebenenfalls abweichender Geschäftsprozesse und im Zusammenführen verschiedener Implementierungen mit sich jeweils unterscheidenden Systemkomponenten. Bei Änderungen in organisationsübergreifenden Prozessen sind vor allem Änderungen der zu integrierenden Systemkomponenten, der technischen Detailabläufe, der verwendeten Technologien und teilweise auch der organisatorischen Geschäftsprozesse im laufenden Betrieb zu managen. 3 verfolgt hierbei das Konzept einer sogenannten Global Single Instance (GSI), d.h. eines zentralisierten ERP-Systems mit konsolidierten Geschäftsprozessen für jede angeschlossene operative Ländergesellschaft.
Die GSI besteht aus der Oracle E-Business Suite (EBS) und sogenannten Belt-Systemen. Im Rahmen der EBS werden die folgenden Module verwendet:
Bei der hier vorliegenden Lösung auf Basis einer konfigurierbaren Unternehmenssoftware und den dadurch unterstützten Geschäftsprozessen ist inzwischen eine Komplexität erreicht worden, die kaum noch beherrschbar ist.
Ein Ansatz zur Lösung dieser Probleme ist der Einsatz von Modellen, welche die Geschäftsprozesse, Geschäftsobjekte und Funktionen der GSI-Lösung beschreiben, kombiniert mit einer kollaborativen Umgebung zur gemeinsamen Bearbeitung dieser für eine Umsetzung anzupassenden Artefakte. Gerade bei der Verschmelzung von Unternehmen eignet sich der Einsatz von Geschäftsprozessmodellen in besonderem Maße, da die grundlegenden Prozesse durch die globale Lösung vorgegeben sind, und diese dann mit dem jeweils zu integrierenden Unternehmen abgeglichen, abgestimmt und gegebenenfalls erweitert werden können.
Durch eine solche kollaborative Geschäftsprozessmanagement-Umgebung können Fusionen oder organisationsübergreifende Geschäftsprozessimplementierungen von der Anforderungsanalyse bis hin zum Training bzw. der Bereitstellung einer dauerhaften Wissensbasis für die entsprechenden ERP-Prozesse und -Funktionen unterstützt werden und dadurch das Risiko dieser meist umfangreichen Projekte minimiert werden.
Bei 3 wurde ein solches Verfahren für die Umsetzung und Erweiterung von organisationsübergreifenden Geschäftsprozessen im Rahmen verschiedener großer ERP-Projekte angewendet. In diesen Projekten wurden die aktuell in der GSI abgebildeten Geschäftsprozesse initial als Modelle in einem entsprechenden Projekt-Workspace im Repository bereitgestellt und anschließend von allen beteiligten Gruppen gemeinsam bearbeitet. Hierzu mussten einerseits Geschäftsprozesse länderspezifisch für die einzelnen Tochterunternehmen umgesetzt bzw. angepasst werden. Andererseits mussten organisationsübergreifende konzernweite Geschäftsprozesse – z.B. im Rahmen des Konzern-Reportings – realisiert werden.
Nachfolgend wird das verwendete Repository und die Umgebung für die Durchführung solcher Projekte auf Basis der GSI beschrieben. Darauf aufbauend wird die Vorgehensweise beschrieben, mit der Geschäftsprozessumsetzungen bei Fusionen und ERP-Rollouts für eine nachfolgende Implementierung abgestimmt werden können. Hier wird insbesondere auch die für die Umsetzung übergreifender Prozesse erforderliche technische Integration betrachtet. Abschließend werden die Vorteile einer solchen Vorgehensweise in einem kurzen Fazit zusammengefasst.
Geschäftsprozess-Repository der Global Single Instance
Projekte zur Umsetzung organisationsübergreifender Geschäftsprozesse werden bei 3 immer auf Basis der vorgegebenen Referenzprozesse durchgeführt, die den aktuellen Status der globalen Lösung darstellen. Die Grundidee dieser Referenzprozess-Modelle ist eine Beschreibung von Geschäftsprozessen (Beschaffungsprozess, Auftragsprozess etc.), Geschäftsobjekten (Bestellung, Auftrag, Artikel etc.), Funktionen (Bestellerfassung, Bestellgenehmigung etc.) und deren Beziehungen untereinander, um die Möglichkeiten der Geschäftsprozessumsetzung mit existierenden Systemkomponenten der GSI darzustellen und zu vermitteln. Durch die Aufteilung der Geschäftsprozessbeschreibung auf mehrere Schichten mit jeweils unterschiedlichem Detaillierungsgrad wird das Management des operativen Betriebs und der Weiterentwicklung einer solch komplexen Lösung zusätzlich unterstützt. Die Prozessbeschreibungen gehen von allgemein verständlichen betriebswirtschaftlichen Abläufen auf höheren abstrakteren Ebenen aus und konkretisieren diese dann in den unteren Detailschichten in einer durch die GSI-Lösung vorgegebenen Umsetzung. Darüber hinaus werden rund um die Prozessbeschreibungen weitere Modelle bereitgestellt, welche die Einführung der Unternehmenssoftware unterstützen, wie bspw. Geschäftsobjektstrukturen, Organisationstrukturen und konkrete Handlungsanweisungen für die Nutzung des Systems bei bestimmten Geschäftsvorfällen. Weiterhin steht eine Verknüpfung der Geschäftsvorfälle und Abläufe zu entsprechenden Testfällen zur Verfügung, die gegebenenfalls automatisiert ausgeführt werden können. Die Modelle und sonstigen Artefakte im Repository sind miteinander verknüpft, sodass eine umfassende Sicht auf die mit der GSI für die jeweiligen Unternehmensbereiche abgebildeten Geschäftsprozesse erreicht wird. Die Referenzprozesse der GSI sind prinzipiell nach den Kernprozessen des Unternehmens, wie bspw. Order2Cash, Procure2Pay, Work Orders & Manage Stock etc. strukturiert. Abbildung 2 zeigt eine Übersicht der Kernprozesse des eingesetzten GSI-Referenzmodells.
In Abbildung 3 wird der grundlegende Aufbau des GSI-Repositorys dargestellt. Auf der linken Seite wird die verwendete Prozesshierarchie mit den je Ebene verwendeten Typen von Prozessmodelle gezeigt. Ausgehend von den groben Business Services des Procure2Pay-Prozesses, d.h. des übergreifenden Unternehmensprozesses von einer Bedarfsmeldung bis hin zur bezahlten Lieferantenrechnung, werden in den darunterliegenden Ebenen die jeweils entsprechenden Detailabläufe beschrieben. Geschäftsvorfälle werden durch sogenannte Business Use Cases abgebildet, welche Geschäftsvorfälle aus dem Blickwinkel des Fachbereichs beschreiben. Business Use Cases sind den einzelnen Prozessschritten zugeordnet und so auf die Prozesse und Funktionen der GSI abgebildet. Auf der unteren Funktionsebene werden einerseits Standardfunktionen und Detailabläufe der verfügbaren GSI-Komponenten bereitgestellt und andererseits vorgegebene Integrationskomponenten in Form sogenannter Main Integration Processes (MIPs) dokumentiert. Ein MIP beschreibt die technische Prozessausführung bei der Integration beteiligter Systeme. Diese technischen Integrationsprozesse werden im Wesentlichen automatisiert durchgeführt. Interaktion ist hier nur in geringem Maße erforderlich und erfolgt in der Regel durch Administratoren. Bei Prozessen auf Basis von Standard-ERP-Funktionen oder speziellen Telekommunikations-spezifischen Erweiterungen der zugrundeliegenden ERP-Software ist in den meisten Fällen eine Benutzerinteraktion erforderlich. Diese wird im GSI Repository durch entsprechende Handlungsanweisungen, sogenannten User Instructions, dokumentiert. Dies sind Mikroabläufe, welche die Bedienung der GSI beschreiben. Darüber hinaus werden auf dieser Ebene zusätzlich Self-Service-Trainingskomponenten bereitgestellt, die Muster-Aufzeichnungen der Bedienung für den entsprechenden Ablauf bereitstellen und dem Anwender neben der Dokumentation auch die Möglichkeit des interaktiven Übens erlauben.
Darüber hinaus wird die Verknüpfung zum Test Management dargestellt. Diesbezüglich werden die Business Use Cases als logische Test Cases übernommen. Sie stellen eine grundlegende fachlich orientierte Gruppierung der einzelnen physikalischen Test Cases dar. In der Test-Management-Umgebung werden dann auf Basis der Teststrategie die einzelnen physikalischen Test Cases erstellt.
Das GSI-Repository setzt sich insgesamt aus drei Hauptkomponenten zusammen:
Um das Wissen aller Beteiligten (Business, Process Owner und IT) in den Projekten effektiv zu nutzen, wird der Entwurf und die Implementierung der Geschäftsprozesse, unterstützt durch Web-2.0-Funktionen, in einer kollaborativen Umgebung durchgeführt. Hierbei werden die für die Umsetzung der neuen Geschäftsprozesse benötigten Modelle durch Prozessspezialisten und IT im Modellierungswerkzeug und gleichzeitig mit Wikis durch die Key User der Fachbereiche bearbeitet. Dies wird durch Verwendung einer mit dem Geschäftsprozessmodellierungs-Tool über einen bidirektionalen Synchronisationsmechanismus verbundene Wiki-Umgebung ermöglicht. Darüber hinaus werden in die Wikis zusätzlich die zuvor beschriebenen Self-Service-Trainingskomponenten für die Business-Anwender eingebunden. In der IT-Sicht werden die von der IT technisch zu implementierenden Prozesse hinterlegt und mit den fachlichen Geschäftsprozessen verbunden. Dadurch können alle drei Sichten (Business, Prozess und IT) auf einen Geschäftsprozess von den jeweiligen Beteiligten in einer integrierten Form erstellt werden.
Abbildung 5 zeigt den Wiki-Zugriff für den Fachbereich bei dem die Key User in einfacher Weise textuelle Anpassungen über die Wiki-Funktionen durchführen können oder Kommentare zu durchzuführenden Änderungen der Diagramme hinterlegen können, die dann wiederum von den Geschäftsprozessmodellierern verarbeitet werden können. Im zweiten Screenshot von Abbildung 5 wird die Synchronisation zwischen fachlichem Input aus dem Wiki und den durch die Prozessmodellierer durchgeführten Änderungen in den Geschäftsprozessmodellen dargestellt. Hierbei werden Änderungen abgeglichen und es können Konflikte aufgelöst werden, falls Änderungen auf beiden Seiten vorgenommen wurden.
Abstimmung abweichender Geschäftsprozesse
Für die Abstimmung von zukünftigen Geschäftsprozessen bei Unternehmensfusionen und ERP-Rollouts muss nach einem groben Mapping auf Ebene der zu integrierenden Geschäftsvorfälle in Form der Business Use Cases die eigentliche Prozessebene betrachtet werden. Hierbei wird auf Basis des vorgegebenen Ablaufs der GSI zunächst analysiert, ob Änderungen am globalen Prozess durchzuführen sind. Wenn Änderungen oder Erweiterungen bei der Analyse identifiziert werden, dann werden diese im Prozess entsprechend gekennzeichnet. In diesem Zusammenhang bedeuten blaue Aktivitäten in einem Prozess, dass diese durch Standardfunktionalitäten der GSI abgedeckt werden und keine Änderungen an diesen Stellen erforderlich sind. Rote Aktivitäten zeigen an, dass die entsprechenden Prozessschritte entweder neu implementiert oder zumindest Erweiterungen an bestehenden Funktionen vorgenommen werden müssen. Prozessschritte, die eine Schnittstelle zu externen Systemen darstellen, sind zusätzlich mit „Int.“ gekennzeichnet. Sogenannte Extensions, d.h. Zusatzentwicklungen zur verwendeten Standardsoftware, sind hingegen mit „Ext.“ markiert.
Abbildung 6 zeigt einen Beispielprozess zum Anlegen neuer Sales Orders. Im Rahmen der entsprechend vorgegebenen Geschäftsvorfälle müssen einerseits Sales Orders über Schnittstellen kommend von Webshops oder von Händlersystemen importiert werden. Andererseits müssen Sales Orders auch manuell direkt im ERP-System angelegt werden können. Alle erfassten und importierten Sales Orders sollen geprüft und dann bei positiver Prüfung genehmigt werden. Bei den einzelnen Aktivitäten dieser Detailprozesse sind jeweils die durch den Prozessschritt bearbeiteten Geschäftsvorfälle (Business Use Cases), die für die Ausführung bei manuellen Tätigkeiten verantwortlichen Abteilungen und die erforderlichen Systemkomponenten zugeordnet. Zugewiesene Systemkomponenten können entweder ein Modul der Standardsoftware, ein für eine Schnittstelle benötigter Main Integration Process oder eine zu realisierende Extension bei benötigten Zusatzfunktionen sein.
Im dargestellten Beispiel ist im Rahmen eines Projekts sowohl die Integration als auch die Prüfung der Aufträge zu erweitern. Solche Erweiterungen treten in solchen Projekten sehr häufig auf, da sich vorgelagerte Systeme unterscheiden oder andere Vertriebskanäle zu berücksichtigen sind. Auch die bei Sales Orders durchzuführenden Prüfungen sind meist pro Land abweichend.
Zur Abstimmung von Details der Geschäftsprozesse können neben den Detail-Prozessbeschreibungen auf Ebene der User Instructions auch zusätzlich die mit Oracle User Productivity Kit aufgezeichnete jeweilige Handhabung für die Business-Anwender genutzt werden. Hierbei werden die Abläufe bei der Systembedienung für einzelne Geschäftsvorfälle im Rahmen der GSI-Dokumentation mit Oracle UPK aufgezeichnet. Diese können dann in verschiedenen Modi von Anwendern genutzt werden. Dies umfasst bspw. einen Modus See It, der die Systembedienung für einen konkreten Geschäftsvorfall exemplarisch vorführt oder einen Modus Try It, bei dem der Anwender die Behandlung des jeweiligen Geschäftsvorfalls mit den Funktionen der implementierten GSI-Lösung üben kann. Dieses spezielle Anwendungswissen wird bei den Geschäftsprozessmodellen an den entsprechend relevanten Schritten hinterlegt und ebenfalls über die Wiki-Umgebung zur Verfügung gestellt, sodass ein zusammenhängendes Wissensnetz aus Modellen und sonstigen Artefakten entsteht, welches das System umfassend beschreibt.
Abbildung 7 zeigt den See It Mode zur Bedienung der ERP Software. Im dargestellten Beispiel wird dem Benutzer gezeigt, wie ein Lieferant für den Procure2Pay-Prozess im System Schritt für Schritt erfasst wird. Der Benutzer wird durch das System geführt und bekommt für jeden durchzuführenden Schritt Bedienungshilfen in textueller Form innerhalb der Masken angezeigt, wie mit den jeweiligen Feldern und sonstigen Bedienelementen des Systems umzugehen ist. Diese den oben erwähnten Detailabläufen auf Funktionsebene der Geschäftsprozesshierarchie entsprechenden Mikro-Abläufe innerhalb des Systems werden im See It Mode anhand von Beispieldaten durchgeführt. Analog kann ein Benutzer im Try It Mode einen Ablauf dann durch direkte Anwendung trainieren. Bei diesem Modus werden die vom Übenden durchgeführten Eingaben entsprechend hinterlegter Regeln validiert.
Abstimmung der technischen Integration
Zur Abstimmung der technischen Integration ist die Kommunikation der jeweiligen IT-Experten aller beteiligten Parteien auf einem technischen Level erforderlich. Hierbei müssen für einzelne Schritte aus der zuvor behandelten Prozessebene technische Detailabläufe und Datenstrukturen geklärt werden. In Abbildung 8 ist der technische Ablauf zum Transfer und Import von Sales Orders des entsprechenden Main Integration Process (MIP) dargestellt. Der technische Prozess wird ausgehend von der Oracle E-Business Suite gestartet und dann über die Middleware Qorus gesteuert. Es werden verschiedene PL/SQL-Programme entsprechend des dargestellten Prozesses aufgerufen und ausgeführt. Die Daten werden automatisiert über Aufbereitungsschritte und das Laden in Staging Tabellen dann über die Auftragsschnittstelle von Oracle Order Management importiert.
Viele solcher technischen Integrationsprozesse müssen im Rahmen von Unternehmensfusionen oder ERP-Rollouts durch entsprechende IT-Experten geprüft und gegebenenfalls erweitert werden. Oft ist es ausreichend, die einzelnen technischen Komponenten an die Besonderheiten der zu verarbeitenden Datenstrukturen anzupassen. Die dazugehörigen Datenstrukturen sind ebenfalls Bestandteil der GSI-Dokumentation.
Fazit
Durch die kombinierte Nutzung eines Geschäftsprozess-Repositorys mit vorgegebener Prozess- und Funktionsdokumentation, Kollaborationsfunktionen und einer Test-Management-Umgebung wird die notwendige Basis geschaffen, komplexe Projekte bei Unternehmensfusionen und umfangreichen ERP-Rollouts – wie sie beispielsweise im Telekommunikationsumfeld stattfinden – erfolgreich durchzuführen. Das Wissen aller an solchen Projekten beteiligten Parteien kann dadurch in kürzester Zeit zusammengetragen und dokumentiert werden, um so die richtigen Entwurfsentscheidungen für die Umsetzung zu treffen. Vor allem wird jedoch durch das gemeinsame Erarbeiten eines zusammenhängenden Wissensnetzes aus Geschäftsprozessmodellen, Anwendungswissen, technischen Detailabläufen und Testfällen die Komplexität solcher Systeme und Projekte handhabbar.
Weitere Informationen zu Horus finden sie unter http://www.horus.biz/de/
Im europäischen Telekommunikationsmarkt ist „3“ – die Mobilfunkmarke des asiatischen Mischkonzerns Hutchison Whampoa Konzerns mit Headquarter in Hong Kong – derzeit eines der am schnellsten wachsenden Unternehmen. In den letzten Jahren hat das Unternehmen einige Übernahmen und Fusionen in Europa erfolgreich durchgeführt. Weiterhin gab es viele Anpassungen von organisationsübergreifenden Prozessen, beispielsweise durch den Wechsel von Logistikpartnern in der Supply Chain. Bei den Unternehmensfusionen liegen die Herausforderungen im Konsolidieren gegebenenfalls abweichender Geschäftsprozesse und im Zusammenführen verschiedener Implementierungen mit sich jeweils unterscheidenden Systemkomponenten. Bei Änderungen in organisationsübergreifenden Prozessen sind vor allem Änderungen der zu integrierenden Systemkomponenten, der technischen Detailabläufe, der verwendeten Technologien und teilweise auch der organisatorischen Geschäftsprozesse im laufenden Betrieb zu managen. 3 verfolgt hierbei das Konzept einer sogenannten Global Single Instance (GSI), d.h. eines zentralisierten ERP-Systems mit konsolidierten Geschäftsprozessen für jede angeschlossene operative Ländergesellschaft.
Die GSI besteht aus der Oracle E-Business Suite (EBS) und sogenannten Belt-Systemen. Im Rahmen der EBS werden die folgenden Module verwendet:
- Order Management
- Inventory
- Work in Progress
- Purchasing
- iProcurement
- Receivables
- Payables
- Assets
- Cash Management
- General Ledger
Bei der hier vorliegenden Lösung auf Basis einer konfigurierbaren Unternehmenssoftware und den dadurch unterstützten Geschäftsprozessen ist inzwischen eine Komplexität erreicht worden, die kaum noch beherrschbar ist.
Ein Ansatz zur Lösung dieser Probleme ist der Einsatz von Modellen, welche die Geschäftsprozesse, Geschäftsobjekte und Funktionen der GSI-Lösung beschreiben, kombiniert mit einer kollaborativen Umgebung zur gemeinsamen Bearbeitung dieser für eine Umsetzung anzupassenden Artefakte. Gerade bei der Verschmelzung von Unternehmen eignet sich der Einsatz von Geschäftsprozessmodellen in besonderem Maße, da die grundlegenden Prozesse durch die globale Lösung vorgegeben sind, und diese dann mit dem jeweils zu integrierenden Unternehmen abgeglichen, abgestimmt und gegebenenfalls erweitert werden können.
Durch eine solche kollaborative Geschäftsprozessmanagement-Umgebung können Fusionen oder organisationsübergreifende Geschäftsprozessimplementierungen von der Anforderungsanalyse bis hin zum Training bzw. der Bereitstellung einer dauerhaften Wissensbasis für die entsprechenden ERP-Prozesse und -Funktionen unterstützt werden und dadurch das Risiko dieser meist umfangreichen Projekte minimiert werden.
Bei 3 wurde ein solches Verfahren für die Umsetzung und Erweiterung von organisationsübergreifenden Geschäftsprozessen im Rahmen verschiedener großer ERP-Projekte angewendet. In diesen Projekten wurden die aktuell in der GSI abgebildeten Geschäftsprozesse initial als Modelle in einem entsprechenden Projekt-Workspace im Repository bereitgestellt und anschließend von allen beteiligten Gruppen gemeinsam bearbeitet. Hierzu mussten einerseits Geschäftsprozesse länderspezifisch für die einzelnen Tochterunternehmen umgesetzt bzw. angepasst werden. Andererseits mussten organisationsübergreifende konzernweite Geschäftsprozesse – z.B. im Rahmen des Konzern-Reportings – realisiert werden.
Nachfolgend wird das verwendete Repository und die Umgebung für die Durchführung solcher Projekte auf Basis der GSI beschrieben. Darauf aufbauend wird die Vorgehensweise beschrieben, mit der Geschäftsprozessumsetzungen bei Fusionen und ERP-Rollouts für eine nachfolgende Implementierung abgestimmt werden können. Hier wird insbesondere auch die für die Umsetzung übergreifender Prozesse erforderliche technische Integration betrachtet. Abschließend werden die Vorteile einer solchen Vorgehensweise in einem kurzen Fazit zusammengefasst.
Geschäftsprozess-Repository der Global Single Instance
Projekte zur Umsetzung organisationsübergreifender Geschäftsprozesse werden bei 3 immer auf Basis der vorgegebenen Referenzprozesse durchgeführt, die den aktuellen Status der globalen Lösung darstellen. Die Grundidee dieser Referenzprozess-Modelle ist eine Beschreibung von Geschäftsprozessen (Beschaffungsprozess, Auftragsprozess etc.), Geschäftsobjekten (Bestellung, Auftrag, Artikel etc.), Funktionen (Bestellerfassung, Bestellgenehmigung etc.) und deren Beziehungen untereinander, um die Möglichkeiten der Geschäftsprozessumsetzung mit existierenden Systemkomponenten der GSI darzustellen und zu vermitteln. Durch die Aufteilung der Geschäftsprozessbeschreibung auf mehrere Schichten mit jeweils unterschiedlichem Detaillierungsgrad wird das Management des operativen Betriebs und der Weiterentwicklung einer solch komplexen Lösung zusätzlich unterstützt. Die Prozessbeschreibungen gehen von allgemein verständlichen betriebswirtschaftlichen Abläufen auf höheren abstrakteren Ebenen aus und konkretisieren diese dann in den unteren Detailschichten in einer durch die GSI-Lösung vorgegebenen Umsetzung. Darüber hinaus werden rund um die Prozessbeschreibungen weitere Modelle bereitgestellt, welche die Einführung der Unternehmenssoftware unterstützen, wie bspw. Geschäftsobjektstrukturen, Organisationstrukturen und konkrete Handlungsanweisungen für die Nutzung des Systems bei bestimmten Geschäftsvorfällen. Weiterhin steht eine Verknüpfung der Geschäftsvorfälle und Abläufe zu entsprechenden Testfällen zur Verfügung, die gegebenenfalls automatisiert ausgeführt werden können. Die Modelle und sonstigen Artefakte im Repository sind miteinander verknüpft, sodass eine umfassende Sicht auf die mit der GSI für die jeweiligen Unternehmensbereiche abgebildeten Geschäftsprozesse erreicht wird. Die Referenzprozesse der GSI sind prinzipiell nach den Kernprozessen des Unternehmens, wie bspw. Order2Cash, Procure2Pay, Work Orders & Manage Stock etc. strukturiert. Abbildung 2 zeigt eine Übersicht der Kernprozesse des eingesetzten GSI-Referenzmodells.
In Abbildung 3 wird der grundlegende Aufbau des GSI-Repositorys dargestellt. Auf der linken Seite wird die verwendete Prozesshierarchie mit den je Ebene verwendeten Typen von Prozessmodelle gezeigt. Ausgehend von den groben Business Services des Procure2Pay-Prozesses, d.h. des übergreifenden Unternehmensprozesses von einer Bedarfsmeldung bis hin zur bezahlten Lieferantenrechnung, werden in den darunterliegenden Ebenen die jeweils entsprechenden Detailabläufe beschrieben. Geschäftsvorfälle werden durch sogenannte Business Use Cases abgebildet, welche Geschäftsvorfälle aus dem Blickwinkel des Fachbereichs beschreiben. Business Use Cases sind den einzelnen Prozessschritten zugeordnet und so auf die Prozesse und Funktionen der GSI abgebildet. Auf der unteren Funktionsebene werden einerseits Standardfunktionen und Detailabläufe der verfügbaren GSI-Komponenten bereitgestellt und andererseits vorgegebene Integrationskomponenten in Form sogenannter Main Integration Processes (MIPs) dokumentiert. Ein MIP beschreibt die technische Prozessausführung bei der Integration beteiligter Systeme. Diese technischen Integrationsprozesse werden im Wesentlichen automatisiert durchgeführt. Interaktion ist hier nur in geringem Maße erforderlich und erfolgt in der Regel durch Administratoren. Bei Prozessen auf Basis von Standard-ERP-Funktionen oder speziellen Telekommunikations-spezifischen Erweiterungen der zugrundeliegenden ERP-Software ist in den meisten Fällen eine Benutzerinteraktion erforderlich. Diese wird im GSI Repository durch entsprechende Handlungsanweisungen, sogenannten User Instructions, dokumentiert. Dies sind Mikroabläufe, welche die Bedienung der GSI beschreiben. Darüber hinaus werden auf dieser Ebene zusätzlich Self-Service-Trainingskomponenten bereitgestellt, die Muster-Aufzeichnungen der Bedienung für den entsprechenden Ablauf bereitstellen und dem Anwender neben der Dokumentation auch die Möglichkeit des interaktiven Übens erlauben.
Darüber hinaus wird die Verknüpfung zum Test Management dargestellt. Diesbezüglich werden die Business Use Cases als logische Test Cases übernommen. Sie stellen eine grundlegende fachlich orientierte Gruppierung der einzelnen physikalischen Test Cases dar. In der Test-Management-Umgebung werden dann auf Basis der Teststrategie die einzelnen physikalischen Test Cases erstellt.
Das GSI-Repository setzt sich insgesamt aus drei Hauptkomponenten zusammen:
- Horus Business Modeler: Hierarchische Geschäftsprozess- und Geschäftsvorfallbeschreibungen
- Oracle User Productivity Kit: Zusätzliche Self-Service-Trainingskomponenten auf der Funktionsebene der Geschäftsprozesshierarchie
- HP Quality Center: Test Cases, die mit den entsprechenden Geschäftsvorfällen (Business Use Cases) verknüpft sind
Um das Wissen aller Beteiligten (Business, Process Owner und IT) in den Projekten effektiv zu nutzen, wird der Entwurf und die Implementierung der Geschäftsprozesse, unterstützt durch Web-2.0-Funktionen, in einer kollaborativen Umgebung durchgeführt. Hierbei werden die für die Umsetzung der neuen Geschäftsprozesse benötigten Modelle durch Prozessspezialisten und IT im Modellierungswerkzeug und gleichzeitig mit Wikis durch die Key User der Fachbereiche bearbeitet. Dies wird durch Verwendung einer mit dem Geschäftsprozessmodellierungs-Tool über einen bidirektionalen Synchronisationsmechanismus verbundene Wiki-Umgebung ermöglicht. Darüber hinaus werden in die Wikis zusätzlich die zuvor beschriebenen Self-Service-Trainingskomponenten für die Business-Anwender eingebunden. In der IT-Sicht werden die von der IT technisch zu implementierenden Prozesse hinterlegt und mit den fachlichen Geschäftsprozessen verbunden. Dadurch können alle drei Sichten (Business, Prozess und IT) auf einen Geschäftsprozess von den jeweiligen Beteiligten in einer integrierten Form erstellt werden.
Abbildung 5 zeigt den Wiki-Zugriff für den Fachbereich bei dem die Key User in einfacher Weise textuelle Anpassungen über die Wiki-Funktionen durchführen können oder Kommentare zu durchzuführenden Änderungen der Diagramme hinterlegen können, die dann wiederum von den Geschäftsprozessmodellierern verarbeitet werden können. Im zweiten Screenshot von Abbildung 5 wird die Synchronisation zwischen fachlichem Input aus dem Wiki und den durch die Prozessmodellierer durchgeführten Änderungen in den Geschäftsprozessmodellen dargestellt. Hierbei werden Änderungen abgeglichen und es können Konflikte aufgelöst werden, falls Änderungen auf beiden Seiten vorgenommen wurden.
Abstimmung abweichender Geschäftsprozesse
Für die Abstimmung von zukünftigen Geschäftsprozessen bei Unternehmensfusionen und ERP-Rollouts muss nach einem groben Mapping auf Ebene der zu integrierenden Geschäftsvorfälle in Form der Business Use Cases die eigentliche Prozessebene betrachtet werden. Hierbei wird auf Basis des vorgegebenen Ablaufs der GSI zunächst analysiert, ob Änderungen am globalen Prozess durchzuführen sind. Wenn Änderungen oder Erweiterungen bei der Analyse identifiziert werden, dann werden diese im Prozess entsprechend gekennzeichnet. In diesem Zusammenhang bedeuten blaue Aktivitäten in einem Prozess, dass diese durch Standardfunktionalitäten der GSI abgedeckt werden und keine Änderungen an diesen Stellen erforderlich sind. Rote Aktivitäten zeigen an, dass die entsprechenden Prozessschritte entweder neu implementiert oder zumindest Erweiterungen an bestehenden Funktionen vorgenommen werden müssen. Prozessschritte, die eine Schnittstelle zu externen Systemen darstellen, sind zusätzlich mit „Int.“ gekennzeichnet. Sogenannte Extensions, d.h. Zusatzentwicklungen zur verwendeten Standardsoftware, sind hingegen mit „Ext.“ markiert.
Abbildung 6 zeigt einen Beispielprozess zum Anlegen neuer Sales Orders. Im Rahmen der entsprechend vorgegebenen Geschäftsvorfälle müssen einerseits Sales Orders über Schnittstellen kommend von Webshops oder von Händlersystemen importiert werden. Andererseits müssen Sales Orders auch manuell direkt im ERP-System angelegt werden können. Alle erfassten und importierten Sales Orders sollen geprüft und dann bei positiver Prüfung genehmigt werden. Bei den einzelnen Aktivitäten dieser Detailprozesse sind jeweils die durch den Prozessschritt bearbeiteten Geschäftsvorfälle (Business Use Cases), die für die Ausführung bei manuellen Tätigkeiten verantwortlichen Abteilungen und die erforderlichen Systemkomponenten zugeordnet. Zugewiesene Systemkomponenten können entweder ein Modul der Standardsoftware, ein für eine Schnittstelle benötigter Main Integration Process oder eine zu realisierende Extension bei benötigten Zusatzfunktionen sein.
Im dargestellten Beispiel ist im Rahmen eines Projekts sowohl die Integration als auch die Prüfung der Aufträge zu erweitern. Solche Erweiterungen treten in solchen Projekten sehr häufig auf, da sich vorgelagerte Systeme unterscheiden oder andere Vertriebskanäle zu berücksichtigen sind. Auch die bei Sales Orders durchzuführenden Prüfungen sind meist pro Land abweichend.
Zur Abstimmung von Details der Geschäftsprozesse können neben den Detail-Prozessbeschreibungen auf Ebene der User Instructions auch zusätzlich die mit Oracle User Productivity Kit aufgezeichnete jeweilige Handhabung für die Business-Anwender genutzt werden. Hierbei werden die Abläufe bei der Systembedienung für einzelne Geschäftsvorfälle im Rahmen der GSI-Dokumentation mit Oracle UPK aufgezeichnet. Diese können dann in verschiedenen Modi von Anwendern genutzt werden. Dies umfasst bspw. einen Modus See It, der die Systembedienung für einen konkreten Geschäftsvorfall exemplarisch vorführt oder einen Modus Try It, bei dem der Anwender die Behandlung des jeweiligen Geschäftsvorfalls mit den Funktionen der implementierten GSI-Lösung üben kann. Dieses spezielle Anwendungswissen wird bei den Geschäftsprozessmodellen an den entsprechend relevanten Schritten hinterlegt und ebenfalls über die Wiki-Umgebung zur Verfügung gestellt, sodass ein zusammenhängendes Wissensnetz aus Modellen und sonstigen Artefakten entsteht, welches das System umfassend beschreibt.
Abbildung 7 zeigt den See It Mode zur Bedienung der ERP Software. Im dargestellten Beispiel wird dem Benutzer gezeigt, wie ein Lieferant für den Procure2Pay-Prozess im System Schritt für Schritt erfasst wird. Der Benutzer wird durch das System geführt und bekommt für jeden durchzuführenden Schritt Bedienungshilfen in textueller Form innerhalb der Masken angezeigt, wie mit den jeweiligen Feldern und sonstigen Bedienelementen des Systems umzugehen ist. Diese den oben erwähnten Detailabläufen auf Funktionsebene der Geschäftsprozesshierarchie entsprechenden Mikro-Abläufe innerhalb des Systems werden im See It Mode anhand von Beispieldaten durchgeführt. Analog kann ein Benutzer im Try It Mode einen Ablauf dann durch direkte Anwendung trainieren. Bei diesem Modus werden die vom Übenden durchgeführten Eingaben entsprechend hinterlegter Regeln validiert.
Abstimmung der technischen Integration
Zur Abstimmung der technischen Integration ist die Kommunikation der jeweiligen IT-Experten aller beteiligten Parteien auf einem technischen Level erforderlich. Hierbei müssen für einzelne Schritte aus der zuvor behandelten Prozessebene technische Detailabläufe und Datenstrukturen geklärt werden. In Abbildung 8 ist der technische Ablauf zum Transfer und Import von Sales Orders des entsprechenden Main Integration Process (MIP) dargestellt. Der technische Prozess wird ausgehend von der Oracle E-Business Suite gestartet und dann über die Middleware Qorus gesteuert. Es werden verschiedene PL/SQL-Programme entsprechend des dargestellten Prozesses aufgerufen und ausgeführt. Die Daten werden automatisiert über Aufbereitungsschritte und das Laden in Staging Tabellen dann über die Auftragsschnittstelle von Oracle Order Management importiert.
Viele solcher technischen Integrationsprozesse müssen im Rahmen von Unternehmensfusionen oder ERP-Rollouts durch entsprechende IT-Experten geprüft und gegebenenfalls erweitert werden. Oft ist es ausreichend, die einzelnen technischen Komponenten an die Besonderheiten der zu verarbeitenden Datenstrukturen anzupassen. Die dazugehörigen Datenstrukturen sind ebenfalls Bestandteil der GSI-Dokumentation.
Fazit
Durch die kombinierte Nutzung eines Geschäftsprozess-Repositorys mit vorgegebener Prozess- und Funktionsdokumentation, Kollaborationsfunktionen und einer Test-Management-Umgebung wird die notwendige Basis geschaffen, komplexe Projekte bei Unternehmensfusionen und umfangreichen ERP-Rollouts – wie sie beispielsweise im Telekommunikationsumfeld stattfinden – erfolgreich durchzuführen. Das Wissen aller an solchen Projekten beteiligten Parteien kann dadurch in kürzester Zeit zusammengetragen und dokumentiert werden, um so die richtigen Entwurfsentscheidungen für die Umsetzung zu treffen. Vor allem wird jedoch durch das gemeinsame Erarbeiten eines zusammenhängenden Wissensnetzes aus Geschäftsprozessmodellen, Anwendungswissen, technischen Detailabläufen und Testfällen die Komplexität solcher Systeme und Projekte handhabbar.
Weitere Informationen zu Horus finden sie unter http://www.horus.biz/de/
