Zusammenfassung
In Theorie und Praxis etabliert sich zunehmend die Prozeßorientierung als zentrales Gestaltungsprinzip von Unternehmensstrukturen. Aktuelle Studien belegen die hohe Bedeutung der Prozeßgestaltung insbesondere in der Praxis [vgl. Bullinger 95, S. 9 ff.]. Eine Vielzahl von (modisch angehauchten1) Konzepten und Vorgehensmodellen zur Prozeßgestaltung wie Business Process Redesign [vgl. Davenport 90], Core Process Redesign [vgl. Kaplan 91], Business Process Improvement [vgl. Harrington 91] und Business (Process) Reengineering [vgl. Hammer 93, Hammer 95a] wurden in jüngerer Vergangenheit hierzu entwickelt und prägen die aktuelle Diskussion um die Umsetzung der Prozeßorientierung.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Preview
Unable to display preview. Download preview PDF.
Referenzen
Mertens erhebt den Vorwurf der modischen Überhöhung [vgl. Mertens 95b, S. 37 f.].
Beispielsweise läßt sich der zeitlich-logische Ablauf des Prozesses Reisekosten abrechnen in Form eines Referenzmodells abbilden. Bei der Unterstützung dieses Prozesses mit einem Workflow-Management-System werden zusätzliche Aufgaben erforderlich (z.B. Einscannen der Reiseanträge), manuelle Aufgaben entfallen (z.B. Berechnen der Tagessätze), oder die zeitlich-logische Anordnung der Aufgaben ändert sich (z.B. Paralle-lisierung der Prüfungen des Reisekostenbudgets und der Tagessätze).
Anstelle eines lauffähigen Programms wird lediglich ein Programmgerippe bereitgestellt, das um spezifische Daten zu konkretisieren ist (z.B. Variablen-, Feld- und Dateinamen). Andere Bezeichnungen für diese Methode sind Schablonentechnik und „Fill-in-the-blanks“-Methode [vgl. Endres 88, S. 89].
Vgl. z.B. Studie der CSC Index Inc. [vgl. o.V. 94].
„... perhaps the most commonly made error in reengineering is to spend far too much time analyzing existing processes“ [Hammer 95b, S. 17].
Die Forschung hat auf diese Entwicklung bisher nur unzureichend reagiert und kann noch keine tauglichen Konzepte zur Modellierung von unternehmensindividuellen Prozeßmodellen und deren möglichst friktionsfreien Überführung auf Standardsoftware anbieten.
In der Literatur findet sich eine Reihe semantisch ähnlicher Begriffe. Von Hansen wird der Begriff des Process Engineering verwendet [vgl. Hansen 94, S. VIII]. Er impliziert die Anwendung von ingenieurwissenschaftlichen Methoden und Prinzipien zur Prozeßgestaltung. Österle verwendet den Begriff Prozeßentwicklung und versteht hierunter „die einmalige und grundsätzliche Neugestaltung des Prozesses in Form eines Projektes (Prozeßentwurf) als auch die permanente Weiterentwicklung eines Prozesses durch die Prozeßbeteiligten selbst“ [Österle 95, S. 56].
Diese Unterscheidung spiegelt sich auch im Aufbau dieser Arbeit wider. Während Teil A das Rahmenkonzept zur „(Prozeß-) Modellierung“ von Prozeßbausteinen vorstellt, beschäftigt sich Teil D mit der „Prozeßgestaltung“ auf Basis von Prozeßbausteinen.
Eine ausführliche Diskussion des Geschäftsprozeßbegriffes und dessen Merkmale findet sich u.a. bei [Schuderer 95, S. 52–62, Bea 95, S. 278–282, Kruse 96, S. 21–27].
In der Literatur findet sich eine synonyme Verwendung der Begriffe „Aufgabe“ und „Funktion“ [vgl. Priemer 95, S. 225, Kruse 96, S. 23].
Abweichend hierzu definiert Keller eine Aufgabe als „durch physische und geistige Aktivitäten zu verwirklichende Soll-Leistung“ [Keller 92, S. 8].
Diese Definition lehnt sich an Crowston an, der Ressourcen („resources“) definiert als „everything used or affected by activities“ [Crowston 94, S. 10].
Die Anzahl der Ausprägungen kann sich erhöhen, wenn zwischen Modellentwickler und Modellverwender, zwischen mehreren Zeiträumen der Originalrepräsentation oder mehreren Zwecksetzungen unterschieden wird.
Der Begriff Referenz bedeutet „Empfehlung“ [vgl. Kluge 89, S. 588]. Er stellt damit auf einen Tatbestand mit Vorbildfunktion ab.
In dieser Arbeit werden unter Best Practices Prozeßlösungen und Prozeßmuster verstanden, die hinsichtlich definierter Prozeßmetriken etablierten Prozeßlösungen und Prozeßmustern überlegen sind.
(Modell-) Customizing bedeutet im Rahmen dieser Arbeit das Anpassen der RPB an die unternehmensindividuellen Anforderungen [vgl. Scheer 95, S. 289].
Modellierungsmethoden zur Prozeßmodellierung müssen auf die Bedürfhisse der Modell Verwender ausgerichtet sein. Scheer kritisiert, daß ein Teil der existierenden Methoden nicht den Bedürfhissen der Zielgruppe entspricht [vgl. Scheer 95, S. 427].
Mertens kritisiert die hohe Komplexität im Rahmen der Unternehmensmodellierung. „Es wird Zeit, daß wir Komplexitätsuntersuchungen zur Modellierung anstellen“ [Mertens 95b, S. 41].
Eine vergleichende Darstellung der Prozeßmodellierungsmethoden findet sich bei Fahrwinkel [Fahrwinkel 95, S. 19–62].
Die Problematik vieler Modellierungsmethoden besteht darin, daß sie nicht angeben, welchen Realitätsausschnitt sie abbilden und für welche Modellintentionen und Modellempfänger sie geeignet sind.
Jedoch trotz der Euphorie, die der objektorientierten Anwendungsentwicklung bisher entgegengebracht wurde, hat sie bis dato die in sie gesetzten Hoffnungen noch nicht erfüllt [vgl. Küffmar 94, S. 15].
Ausgewählte objektorientierte Modellierungsmethoden zur Anwendungsentwicklung: • Object-Oriented Analysis (OOA) von P. Coad und E. Yourdon [vgl. Coad 91] • Object-Oriented Design (OOD) von G. Booch [vgl. Booch 91] • Object modeling technique (OMT) von J. Rumbaugh [vgl. Rumbaugh 93]
Scheer führt dies darauf zurück, „daß die objektorientierten Methoden im wesentlichen aus einer Abstrahierung der in den objektorientierten Programmiersprachen enthaltenen Konstrukte entstanden sind. Das heißt, Basis für die Entwicklung waren existierende Programmiersprachen und nicht die Betriebswirtschaft des Unternehmens.“ [Scheer 96, S. 38].
Für die einzelnen Komponenten der Prozeßlösung (z.B. Anwendungssystem) werden hierbei eigene Objekte mit Attributen definiert, die über einen Verweis den Geschäftsprozessen zugeordnet werden.
Bekanntester Vertreter ist hierbei das SAP R/3-Referenzmodell, das die Funktionalität des integrierten Softwarepaketes R/3 der SAP AG abbildet [vgl. Keller 94a, S. 6–18, Keller 94b, S. 48–51, Meinhardt 95, S. 489 ff.].
Branchenreferenzmodelle der IDS Prof. Scheer existieren aktuell für die Branchen Anlagenbau, KFZ-Zu-lieferer, Konsumgüterindustrie, Maschinenbau, Papierindustrie, Möbelindustrie, Versorgungsunternehmen und Handelsunternehmen.
Die folgenden Ausführungen beziehen sich auf [IDS Prof. Scheer 95] und [Aichele 94, S. 253–258].
Weitere Modelltypen der IDS Prof. Scheer-Referenzmodelle für die Daten-, Funktions- und Organisationssicht: • Funktionssicht: Für die Darstellung der Funktionen auf der Übersichts- und Detailebene kommen Funktionsbäume zum Einsatz, die die Funktionen der jeweiligen Ebene beinhalten. • Datensicht: Auf der Übersichtsebene werden Clustermodelle zur Verfügung gestellt, in denen Datencluster mit hoher Abstraktion aufgezahlt werden, ohne daß hierbei Datenbeziehungen modelliert sind. Auf der Detailebene erfolgt eine Konkretisierung der Datencluster durch Entity-Relationship-Diagramme. Die in den Entity-Relationship-Diagrammen aufgezeigten Entity-Typen werden durch Attributzuordnungsdiagramme verfeinert, in denen die zugehörigen Attribute vermerkt werden. • Organisationssicht: Zur Abbildung der Aufbauorganisation werden Organigramme verwendet, die die beteiligten Organisationseinheiten auf hohem Abstraktionsniveau aufzeigen.
CIM-OSA: Computer Integrated Manufacturing Open System Architecture
CAPRE: Computer Aided Process Reengineering
Extend ist ein Warenzeichen der Firma Imagine That, Inc., San Jose, California.
Für die Datenmodellierung hingegen existieren bereits Konzepte zur Ablage und Anpassung von Datenmodellen an unternehmensspezifische Anforderungen [vgl. Hars 94].
Vgl. hierzu [Balzert 82, S. 27 ff.].
Modellierungsmethoden zur Prozeßmodellierung müssen auf die Bedürfhisse der Modell Verwender ausgerichtet sein. Scheer kritisiert, daß ein Teil der existierenden Methoden nicht den Bedürfhissen der Zielgruppe entspricht [vgl. Scheer 95, S. 427].
Mertens kritisiert die hohe Komplexität im Rahmen der Unternehmensmodellierung. „Es wird Zeit, daß wir Komplexitätsuntersuchungen zur Modellierung anstellen“ [Mertens 95b, S. 41].
Eine vergleichende Darstellung der Prozeßmodellierungsmethoden findet sich bei Fahrwinkel [Fahrwinkel 95, S. 19–62].
Die Problematik vieler Modellierungsmethoden besteht darin, daß sie nicht angeben, welchen Realitätsausschnitt sie abbilden und für welche Modellintentionen und Modellempfänger sie geeignet sind.
Jedoch trotz der Euphorie, die der objektorientierten Anwendungsentwicklung bisher entgegengebracht wurde, hat sie bis dato die in sie gesetzten Hoffnungen noch nicht erfüllt [vgl. Küffmar 94, S. 15].
Ausgewählte objektorientierte Modellierungsmethoden zur Anwendungsentwicklung: • Object-Oriented Analysis (OOA) von P. Coad und E. Yourdon [vgl. Coad 91] • Object-Oriented Design (OOD) von G. Booch [vgl. Booch 91] • Object modeling technique (OMT) von J. Rumbaugh [vgl. Rumbaugh 93]
Scheer führt dies darauf zurück, „daß die objektorientierten Methoden im wesentlichen aus einer Abstrahierung der in den objektorientierten Programmiersprachen enthaltenen Konstrukte entstanden sind. Das heißt, Basis für die Entwicklung waren existierende Programmiersprachen und nicht die Betriebswirtschaft des Unternehmens.“ [Scheer 96, S. 38].
Für die einzelnen Komponenten der Prozeßlösung (z.B. Anwendungssystem) werden hierbei eigene Objekte mit Attributen definiert, die über einen Verweis den Geschäftsprozessen zugeordnet werden.
Bekanntester Vertreter ist hierbei das SAP R/3-Referenzmodell, das die Funktionalität des integrierten Softwarepaketes R/3 der SAP AG abbildet [vgl. Keller 94a, S. 6–18, Keller 94b, S. 48–51, Meinhardt 95, S. 489 ff.].
Branchenreferenzmodelle der IDS Prof. Scheer existieren aktuell für die Branchen Anlagenbau, KFZ-Zu-lieferer, Konsumgüterindustrie, Maschinenbau, Papierindustrie, Möbelindustrie, Versorgungsunternehmen und Handelsunternehmen.
Die folgenden Ausführungen beziehen sich auf [IDS Prof. Scheer 95] und [Aichele 94, S. 253–258].
Weitere Modelltypen der IDS Prof. Scheer-Referenzmodelle für die Daten-, Funktions- und Organisationssicht: • Funktionssicht: Für die Darstellung der Funktionen auf der Übersichts- und Detailebene kommen Funktionsbäume zum Einsatz, die die Funktionen der jeweiligen Ebene beinhalten. • Datensicht: Auf der Übersichtsebene werden Clustermodelle zur Verfügung gestellt, in denen Datencluster mit hoher Abstraktion aufgezahlt werden, ohne daß hierbei Datenbeziehungen modelliert sind. Auf der Detailebene erfolgt eine Konkretisierung der Datencluster durch Entity-Relationship-Diagramme. Die in den Entity-Relationship-Diagrammen aufgezeigten Entity-Typen werden durch Attributzuordnungsdiagramme verfeinert, in denen die zugehörigen Attribute vermerkt werden. • Organisationssicht: Zur Abbildung der Aufbauorganisation werden Organigramme verwendet, die die beteiligten Organisationseinheiten auf hohem Abstraktionsniveau aufzeigen.
CIM-OSA: Computer Integrated Manufacturing Open System Architecture
CAPRE: Computer Aided Process Reengineering
Extend ist ein Warenzeichen der Firma Imagine That, Inc., San Jose, California.
Für die Datenmodellierung hingegen existieren bereits Konzepte zur Ablage und Anpassung von Datenmodellen an unternehmensspezifische Anforderungen [vgl. Hars 94].
Vgl. hierzu [Balzert 82, S. 27 ff.].
Vgl. Kap. 8.1.
Im Unterschied zur objektorientierten Anwendungsentwicklung, bei denen einem Objekt (z.B. Auftrag) verschiedene Methoden zugeordnet werden (z.B. Auftrag erfassen, Auftrag stornieren), verfügt ein RPB über lediglich eine Aufgabe (z.B. Auftrag erfassen). Ein weiterer Unterschied besteht darin, daß bei einem Objekt in der objektorientierten Anwendungsentwicklung die Daten im Mittelpunkt stehen, die in der RPB-Modellierung lediglich eine Teilmenge der RPB-Prozeßlösungsattribute darstellen. Eine Gleichsetzung von Methoden und Aufgabe einerseits und Daten und Ressourcen (bzw. Prozeßlösung) andererseits ist damit nicht möglich.
Bestehenden objektorientierten Ansätzen zur Prozeßmodellierung liegt ein anderes Objektverständnis zugrunde. Beispielsweise Fahrwinkel definiert in ihrem objektorientierten Ansatz zur Prozeßmodellierung und analyse (OMEGA) eine Vielzahl unterschiedlicher Objekte, in denen die für die Beschreibung eines Geschäftsprozesses notwendigen Informationen festgehalten werden (Materialobjekt, IT-Informationsobjekt, Papierinformationsobjekt, mündliches Informationsobjekt etc.) [vgl. Fahrwinkel 95, S. 70 ff.]. Diese Objekte bilden eigenständige Objekthierarchien und werden wiederum durch eine Reihe von Attributen beschrieben. Ein Papierinformationsobjekt enthält beispielsweise die Attribute Beschreibung, Name, speichernder Papierspeicher, Papierinformationsbestandteile etc. [vgl. Fahrwinkel 95, S. 84]. Die Verknüpfung zu den Geschäftsprozessen erfolgt über Verweise [vgl. Fahrwinkel 95, S. 83]. Die Beschreibung der verschiedenen Objekte mit mehreren Attributen und der Aufbau von Objekthierarchien für die Vielzahl unterschiedlicher Objekte erfordert einen hohen Modellierungsaufwand. Im Gegensatz hierzu modelliert das RPB-Konzept für die verschiedenen Ressourcen eines RPB keine eigenständigen Objekte mit Attributen und baut hierfür keine Objekthierarchien auf, sondern bildet die Ressourcen als Attribute direkt beim RPB ab.
Ansätze zur Übertragung der Spezialisierung auf Geschäftsprozesse sind in der Literatur nur vereinzelt zu finden. Bertram wendet die Spezialisierung auf „abstrakte Abläufe“ (z.B. „Partner schließt Vertrag ab’) an und entwickelt hieraus konkretere Abläufe (z.B. „Eintritt eines Mitarbeiters“) [vgl. Bertram 96, S. 89 f.]. Die Spezialisierung erfolgt, indem abstrakte Funktionen durch konkrete Funktionen (manuell) ersetzt, zusätzlich erforderliche Funktionen aufgenommen und die Ablaufbedingungen angepaßt werden. Zudem wendet er Ablaufschablonen“, die Abläufe völlig losgelöst von fachlichen Inhalten beschreiben (z.B. „Prüfung nach dem 6-Augen-Prinzip“), auf Geschäftsprozesse (z.B. „Schadensregulierung in Versicherungen“) an, wobei hier nach Bertram ein „Einsetzen“ und keine „Spezialisierung“ vorliegt [vgl. Bertram 96, S. 93 f.].
Die Koordinationstheorie definieren sie „... as a body of principles about how activities can be coordinated, that is, about how actors can work together“ [Malone 91, S. 3]. Die erarbeiteten Ergebnisse stellen jedoch keine abgeschlossene Theorie dar. „We use the term theory, however, in part to signify a provocative goal for this interdisciplinary enterprise, and we hope that the various studies reviewed will serve as steps along the path toward an emerging theory of coordination.“ [Malone 94, S. 88].
Einige wichtige Bereiche, in denen für Koordinationsprobleme Lösungen entwickelt werden, sind: • Informatik: Im Bereich der Informatik wurden z.B. die Allokation von Speicherplatz und Zuordnung von Tasks zu Prozessoren erforscht. • Organisationstheorie: Die Organisationstheorie befaßt sich mit der Frage der optimalen Aufteilung von Aktivitäten auf Mitarbeiter und der Koordination dieser Aktivitäten. • Biologie: In der Verhaltensforschung von Menschen und Tieren konnten interessante Forschungsergebnisse erzielt werden, indem Fragestellungen wie z.B. „Wie koordiniert das menschliche Gehirn die Vielzahl von parallelen Aktivitäten und Bewegungen?“ oder „Wie koordiniert sich das Gruppenverhalten von Honigbienen?“ untersucht wurden.
Dieser Aspekt ist in dem neuen Paradigma der Organisationsentwicklung, der „Organizational Intelligence“, wiederzufinden. Organisationale Prozeßintelligenz wird von Matsuda „als interaktiver, aggregierender und koordinierender Komplex der menschlichen Intelligenz und der maschinellen Intelligenz einer Organisation“ definiert [vgl. Matsuda 93, S. 13].
Vgl. Definition der Begriffe Ressourcen und Aufgabe in Kap. 1.4.2.
RPB-Bibliothek „Banken“ [Gamstätter 95], RPB-Bibliothek „Auftrag abwickeln“ [Glunde 96].
Die Pfeile verdeutlichen die Verwendungsmöglichkeiten der verschiedenen RPB-Bibliotheken. Die generische RPB-Bibliothek kann beispielsweise zum Aufbau einer geschäftsprozeßtypspezifischen RPB-Bibliothek genutzt werden.
Eine Domäne stellt einen Ausschnitt aus der realen Welt dar, der sich durch spezifische Eigenschaften auszeichnet. Sie beinhaltet spezifisches Wissen und Fakten über diesen Realitätsausschnitt [vgl. Küffrnar 94, S. 25]. Unter domänenspezifischen RPB werden im Rahmen dieser Arbeit geschäftsprozeßtyp-, branchen- und IV-/IT-spezifische RPB verstanden.
Eine generische RPB-Bibliothek wird im Teil C, Kap. 3, vorgestellt.
In Kap. C, Kap. 2, wird die geschäftsprozeßtypspezifische RPB-Bibliothek „Auftrag abwickeln“ aufgezeigt.
Einzelne Branchen weisen teilweise eine hohe Heterogenität auf. Große Unterschiede bestehen beispielsweise innerhalb der Branche Handel zwischen den Geschäftsprozessen im Einzelhandel, Großhandel und Versandhandel.
In der Literatur findet sich eine Vielzahl unterschiedlicher geschäfisprozeßtyp-/funktionalorientierter Typologien, die auf Industrieunternehmen ausgerichtet sind und damit die Anforderung nach Allgemeingültigkeit nicht erfüllen: Geschäftsprozeßtyp-/funktionalorientierte Typologien: Scheer unterscheidet zwischen Logistikprozessen (Beschaffungslogistik, Produktionslogistik, Vertriebslogistik, Personallogistik), Leistungsgestaltungsprozessen (Marketing, Konstruktion, Arbeitsplanung, Qualitätssicherung) und Informations- und Koordinationsprozessen (Rechnungswesen und Informationsmanagement) [vgl. Scheer 94, S. 85 ff.]. Krüger differenziert zwischen Operativen Prozessen (Marketing, Forschung und Entwicklung, Beschaffung/Eingangslogistik, Produktion, Vertrieb/Ausgangslogistik, Kundendienst), Unterstützungsprozessen (Organisation/ Informationsverarbeitung, Personalwirtschaft, Finanzen und Rechnungswesen, Controlling) und Planungs-, Steuerungs-, Kontrollprozessen [vgl. Krüger 93, S. 183 ff. und 211 ff.]..
Die Darstellung des RPB „Info, über Produktspektrum bereitstellen“ in EPK-Form erfolgt in Abb. 8–4.
Rights and permissions
Copyright information
© 1997 Springer Fachmedien Wiesbaden
About this chapter
Cite this chapter
Lang, K. (1997). Rahmenkonzept zur Modellierung von Referenzprozeßbausteinen. In: Gestaltung von Geschäftsprozessen mit Referenzprozeßbausteinen. Gabler Edition Wissenschaft. Deutscher Universitätsverlag, Wiesbaden. https://doi.org/10.1007/978-3-663-08526-3_1
Download citation
DOI: https://doi.org/10.1007/978-3-663-08526-3_1
Publisher Name: Deutscher Universitätsverlag, Wiesbaden
Print ISBN: 978-3-8244-6540-8
Online ISBN: 978-3-663-08526-3
eBook Packages: Springer Book Archive