Model-Based Business Engineering, Blog by Dr. Juergen Pitschke, +49 351 30935193 Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!g

Model-Based Business Engineering - Eine Positionierung

download button Autor: Dr. Juergen Pitschke, BCS-Dr. Juergen Pitschke

Was verstehen wir unter Model-Based Business Engineering? Das Dokument gibt eine Grundlage für unsere folgenden Diskussionen.

Sie können das Dokument im PDF-Format herunterladen oder hier direkt lesen. Kommentare sind ausdrücklich erwünscht. Bitte beachten Sie die Copyright-Angaben.


1 Model-Based Business Engineering

Modelle sind allgegenwärtig. Sie dienen als Grundlage für die Analyse von Prozessen oder die Umsetzung von IT Systemen. Modelle sind Grundlage für eine Vielzahl von Analysetechniken, Optimierung oder das Einführen von Prozessen oder Systemen. Wie können wir ein gutes Ergebnis erreichen, wenn bereits die Grundlage falsch, unzureichend oder schlicht nicht erfassbar ist? Wie können wir Prozesse oder Unternehmen langfristig und systematisch weiterentwickeln, wenn wir keine Kenntnis über die relevanten Sichten besitzen?

Trotzdem wird die Modellentwicklung oft stiefmütterlich behandelt und belächelt. Fragen wie „Malst Du noch oder managest Du schon?“ werden gestellt und die Notwendigkeit einer professionellen Modellentwicklung nicht gesehen. Das rührt unter anderem aus einem falschen Verständnis des Modellbegriffs und einer fehlenden Methodik. Im White Paper wird dargestellt, was wir unter Modell-Basiertem Business Engineering verstehen. Typische Vorgehensweisen werden in weiteren Beiträgen dargestellt.

Business Modellierung ist nicht Business Management. Ohne Modelle ist ein sinnvolles Management von Prozessen, Entscheidungen und anderen Artefakten nicht möglich.

Auf der anderen Seite des Spektrums finden sich selbsternannte Gurus, die ein einzelnes Konzept oder eine einzelne Notation herausstellen. Diskussionen über einzelne Modellelemente und punktuelle Verbesserungen von Standardnotationen werden mit Vehemenz geführt. Model-Based Business Engineering sieht Standardnotationen als wichtiges Mittel. Welches Konzept und welche Notation jeweils am geeignetsten ist, hängt vom Modellgegenstand, unseren Zielen und den beteiligten Stakeholdern ab. Notationen allein sind keine Hilfe. Ein einzelnes Konzept bringt maximal punktuelle Verbesserung. Business ist vielfältig und braucht immer mehrere Sichten und Konzepte. Eine gute Methodik ist unabdingbar.

Modellieren hat über die Zeit in einigen Bereichen einen negativen Ruf erhalten. Zu teuer, zu wenig zielgerichtet, ohne Beachtung der Stakeholder, unsystematisch, nicht pflegbar sind einige der Vorwürfe. Die Ursache liegt in einer unsystematischen und ungeplanten Vorgehensweise. Wir legen daher großen Wert auf den „Engineering“-Teil in der Definition von Model-Based Business Engineering. Modelle müssen zielgerichtet, geplant und wiederholbar erstellt werden. Die Qualität von Modellen kann beurteilt werden. Wir setzen bewährte Arbeitstechniken ein, lernen von anderen Disziplinen und wenden viele Soft-Skills zur Einbeziehung der verschiedenen Stakeholder an.

2 Model-Based ...

Wir sprechen von Model-Based Business Engineering und nicht von Modell-getriebener Entwicklung. Modelle sind eine Basis für viele Arbeitstechniken im Geschäftsprozessmanagement, sie sind jedoch „nur“ ein (wichtiges) Mittel zum Zweck. Es gibt kein Geschäftsproblem „Wir haben nicht genügend Modelle.“

2.1 Warum entwickeln wir Modelle?

Modelle dienen dazu „Dinge“ zu beschreiben, bevor wir sie erstellen oder ändern. Modelle sind Grundlage für die Beurteilung verschiedener Eigenschaften des Modellgegenstands im Betrieb. Modelle helfen uns Eigenschaften zu messen und zu bewerten. Das zu beschreibende Objekt kann ein System sein oder ein Geschäftsprozess oder eine Business Capability oder eine ganze Organisation. John Zachmans Argument „If you can’t describe it, you can’t build it.” trifft die Situation.

Das Beschreiben des zu erstellenden Gegenstandes gibt uns die Gelegenheit darüber nachzudenken und zu entscheiden, welche Eigenschaften es haben soll. Das Modell enthält daher nicht nur die eigentliche Information über den jeweiligen Modell-Gegenstand, sondern auch Informationen zu getroffenen Designentscheidungen, Wissensquellen und anderen relevanten Informationen.

Wenn Modelle die Grundlage der Definition und der Umsetzung von Geschäftsprozessen oder anderen organisatorischen Aspekten sind, so sind sie vor allem Grundlage für die Pflege und Weiterentwicklung dieser Objekte über einen längeren Zeitraum. Das bedingt, das unsere Modelle ebenfalls über einen längeren Zeitraum gepflegt werden müssen, um sie mit der gelebten Realität in Übereinstimmung zu halten. Gelingt das nicht, so ist der Aufwand für die Erstellung nicht gerechtfertigt.

2.2 Was ist ein Modell?

Manchmal behaupten Kunden oder Workshop-Teilnehmer, das sie (bisher) keine Modelle nutzen. Ich bin überzeugt, dass das falsch ist. Was die Teilnehmer meinen, ist, dass sie keine formalen Modelle nutzen. Für mich sind Modelle sehr vielfältig in Form und Inhalt.

Ein Modell ist eine abstrakte Darstellung von Eigenschaften des uns interessierenden Gegenstandes. Welche Eigenschaften uns interessieren, hängt vom Modell-Gegenstand ab, aber noch stärker von dem zu lösenden Problem und den Stakeholdern.

Modelle beschreiben einzelne Eigenschaften des Modellgegenstandes, z.B. den Ablauf eines Geschäftsprozesses. Modelle stellen komplexe Zusammenhänge zwischen Modellelementen dar, wie z.B. das Modell einer Business Capability, das die einzelnen Aspekte der Capability im Kontext darstellt.

Modelle kommen in verschiedenen Darstellungsformen. Nicht alle Modelle sind formale Modelle. Nicht alle Modelle sind visuelle Modelle. Eine Tabelle oder eine textuelle Beschreibung kann ein Modell sein. Es ist wichtig, bewährte und erfolgreiche Darstellungsformen einer Organisation zu bewahren und weiterzuentwickeln. Bestehende Beschreibungsmittel sollen mit neuen, formalen Notationen kombiniert werden.

2.3 Modelle darstellen

2.3.1 Formale Notationen

Denken wir an formale Darstellungsformen, so denken wir häufig zuerst an die Standard-Notationen der Object Managment Group (OMG) wie Business Process Model and Notation (BPMN) oder Decision Model and Notation (DMN). Visuelle Modellierungsnotationen sind heute die bevorzugte Darstellungsform. Für diese Notationen existieren eine Vielzahl von Modellierungswerkzeugen.

Formale Notationen haben den Vorteil neben der Notation ein Austauschformat zu definieren. Das gestattet den Austausch von Modellen zwischen Modellierungswerkzeugen, aber auch zwischen Modellierungswerkzeug und anderen Umgebungen, z.B. für Auswertungen oder Simulation.

Visuelle Modelle lassen sich leichter erfassen. Ein Modell ist aber mehr als ein Bild. Neben den Informationen, die visualisiert werden, werden für die einzelnen Modell-Elemente weitere Informationen erfasst und im Modell-Repository gespeichert. Die durch den Standard definierten Eigenschaften werden durch eigene Attribute ergänzt, um die für unsere Vorhaben notwendigen Informationen zu erfassen. Die bildliche Darstellung zeigt eine besondere Eigenschaft des uns interessierenden Gegenstandes. Sie ist zugleich eine Navigationshilfe, um wichtige andere Informationen zu den einzelnen Elementen leicht zu finden.

Die Beschreibung der Modell-Elemente enthält mehr Informationen als die Definition der Eigenschaften des eigentlichen Modellgegenstandes (primärer Modellinhalt). Daneben müssen Informationen wie Designentscheidungen, Annahmen, Randbedingungen oder Wissensquellen erfasst werden (sekundärer Modellinhalt).

2.3.2 Informelle Darstellungsformen

Neben den Standardnotationen gibt es viele informelle Beschreibungsmittel. Einerseits sind diese oft leichter zu benutzen. Andererseits fehlt meist die Unterstützung durch ein Werkzeug.
Beispiele für eine informelle Darstellung sind das „North Star“-Konzept der Process Renewal Group oder der „Business Model Canvas“ von Osterwalder.

Informelle Darstellungen finden sich häufig auf höheren Abstraktionsstufen unserer Modelle.

Wie bei formalen Modellen ist der visuelle Teil des Modells allein wenig aussagekräftig und wird durch textuelle Beschreibungen vervollständigt.

2.3.3 Sprache

In allen Modellformen spielt Sprache eine große Rolle. Modelle dienen der Kommunikation zwischen Menschen. Modelle entstehen aus Sprache und müssen in Sprache zurück übertragbar sein. Für die bildlichen Elemente unserer Modelle definieren wir daher Namenskonventionen für die Benennung. Bei der Beschreibung der einzelnen Elemente sind neben definierten Eigenschaften immer auch textuelle Elemente enthalten. Die Beschreibung der sekundären Inhalte erfolgt in der Regel ebenfalls sprachlich.

Sprache kann sehr vielfältig sein. Um Missverständnisse zu vermeiden, werden für die textuelle Beschreibung daher oft Vorgaben gemacht. Wir legen fest, welche Informationen enthalten sein sollen, und wie die Beschreibung gestaltet sein soll – z.B. als Tabelle. Hier schließt sich der Kreis: Bewährte Beschreibungsformen werden mit neuen Darstellungsmitteln kombiniert.

Manche Inhalte werden ausschließlich textuell dargestellt. Ein Beispiel ist das RuleSpeak®-Konzept von Ron Ross zur Darstellung von Geschäftsregeln.

2.4 Modell und Modell-Ausgabe

Ein häufiger Fehler bei der Erstellung von Modellen ist die Gleichsetzung von Modell und Modell-Ausgabe. Dieses Missverständnis wird durch moderne web-basierte Modellierungswerkzeuge verstärkt. Die Tatsache, das jeder die Modelle im Intranet zugreifen kann, entbindet uns nicht von der Erstellung nutzerspezifischer Sichten. Modelle und Modell-Ausgaben haben unterschiedliche Ziele und Zielgruppen.

ModellModell-Ausgabe
Modellierer ist Haupt-Stakeholder Verschiedene Stakeholder: Management, Qualitätsbeauftragte, Operator, Bearbeiter
Soll gut pflegbar sein Soll gut verständlich sein; soll der Nutzererfahrung entsprechen
Soll langfristig pflegbar sein Soll an wechselnde Anforderungen anpassbar sein
Fokus auf einzelne Sichten Fokus auf Kombination verschiedener Sichten
Soll konsistent sein Verschiedene Formate gewünscht: HTML, PDF, MS Word
Soll einfach auswertbar Relevante Information soll einfach auffindbar sein

Tabelle 1: Modell vs. Modellausgabe - unterschiedliche Anforderungen

Modell-Ausgaben adressieren in Inhalt und Struktur unsere Stakeholder. Oft verhindert die gewünschte Struktur eine leichte Pflegbarkeit. Verschiedene Stakeholder wollen unterschiedliche Inhalte sehen und wünschen unterschiedliche Strukturen. Wir benötigen unterschiedliche Ausgaben, sowohl in Form als auch Inhalt. TOGAF definiert hierfür das Konzept von View und Viewpoint. Die verschiedenen Ausgaben müssen aus unseren Modellen erzeugbar sein. Sie bestimmen nicht, wie unser Modell selbst strukturiert wird.

Die Struktur unserer Modelle und unseres Modell-Repositories soll eine leichte Pflegbarkeit und eine langfristige Nutzbarkeit sichern. Die gewünschten Ausgaben sollen einfach aus den Modellen erzeugbar sein. Die Struktur unserer Modelle muss die Modell-Governance unterstützen. Fragen wie Zugriffsrechte und Zusammenarbeit spielen eine wichtige Rolle bei der Organisation unserer Modelle.

Die Modellausgaben bestimmen, welche Inhalte in unserem Modell enthalten sein müssen. Die Frage nach den Stakeholdern und deren Sichten steht daher am Beginn eines Modellierungsprojektes.

2.5 Inhalte, Verständnis und Darstellungsformen

2.5.1 Was gehört zu einem Modell? Primäre und sekundäre Modellinhalte

Ein Modell soll die interessierenden Sichten auf den Modellgegenstand abbilden. Bei einem Geschäftsprozess interessiert uns zum Beispiel oft der Ablauf der Aktivitäten und die Details zur einzelnen Aktivität. Darüber hinaus sind aber weitere Informationen über den Gegenstand von Interesse und notwendig, z.B. Wie ist der Prozess abgegrenzt? Welche Annahmen haben wir getroffen bezüglich vorhandener Informationen oder vorgelagerter Prozesse? Diese Aspekte – Inhalt, Annahmen, Randbedingungen - fassen wir als primären Modellinhalt zusammen.

Daneben benötigen wir weitere Informationen, die sich nicht vordergründig auf den Modellgegenstand selbst beziehen, sondern aus dem Modellierungs- und Designprozess resultieren. Das sind zum Beispiel Wissensquellen. Diese lassen uns nachvollziehen, woher Wissen und Informationen über unseren Modellierungsgegenstand stammen. Für Pflege und Governance der Modelle ist das eine essenzielle Information. Während des Erstellungsprozesses treffen wir Designentscheidungen: Wie ist der Prozess abgegrenzt? Wie soll der Ablauf des Prozesses gestaltet sein? Welche Rolle ist für bestimmte Aktivitäten verantwortlich? Auch diese Information ist für Pflege und Governance unerlässlich. Dabei geht es nicht nur um das Ergebnis der Entscheidungen, sondern zuerst um die Gründe für unsere Entscheidung. Projektspezifisch können weitere Informationen über unseren Modellierungsprozess wichtig sein. Informationen über Wissensquellen, Designentscheidungen und andere Informationen nennen wir sekundären Modellinhalt. Sie sind für das Verständnis der primären Inhalte notwendig. Oft werden diese Informationen in den gewünschten Modell-Ausgaben für unsere Stakeholder benötigt.

ModellInhaltDeutsch

 Abbildung 1: Primäre und sekundäre Modellinhalte

2.5.2 Primäre Modellinhalte organisieren

Um für unsere Modelle Wartbarkeit zu erreichen, müssen wir die Modelle selbst und unser Modell-Repository sinnvoll organisieren. Für die Organisation unserer Business-Modelle folgen wir den Perspektiven des Zachman-Framework for Enterprise Architecture™. Im Rahmen des MBBE stellen wir Inhalte aus den Perspektiven Scope und Business Concepts bereit und entwickeln Anforderungen für die Perspektive System Logic. Tabelle 2 ordnet typische Modellinhalte den Perspektiven des Zachman-Frameworks zu.

PerspektiveInhalte
Scope / Contexts Prozesslandkarte, Capability Map, Vision, Ziele, Zielstellungen, Heat Maps
Business Concepts Geschäftsprozessmodelle, Entscheidungsmodelle, Business Requirements
System Logic Anforderungen für IT- und Technologie-Unterstützung
Technology Physics  
Tool Components  
Operations Instances  

Tabelle 2: Perspektiven des Zachman-Frameworks und typische Inhalte im MBBE (Beispiele)

2.5.3 Sekundäre Modellinhalte

Wie in Abschnitt 2.5.1 dargestellt, wird der Wert eines Modells nicht ausschließlich in der Beschreibung des interessierenden Gegenstands gesehen, sondern in den Designentscheidungen, Randbedingungen und Vorgaben die wir bei der Entwicklung der Capabilities und Prozesse getroffen haben.

In jedem Fall gehören für uns Annahmen, Randbedingungen, Wissensquellen und Designentscheidungen zwingend zu einem guten Modell. Weitere Informationen können selbstverständlich für das jeweilige Unternehmen relevant sein.

Diese Informationen werden meist in den Standardnotationen wie BPMN nicht berücksichtigt. Der Standard Decision Model and Notation (DMN) kennt das Element „Knowledge Source”, welches explizit dargestellt wird und damit auch einer Auswertung (Auswirkungsanalyse) zugänglich ist.

Wo uns ein solches Element nicht zur Verfügung steht, müssen wir eigene Regelungen treffen. Das ist auch eine Toolfrage: Welche Möglichkeiten haben wir in dem von uns gewählten Werkzeug für die Beschreibung und Auswertung solcher Informationen.

Wie Entscheidungen getroffen werden und mit welcher Begründung ist zentrales Element des Business Process Management. In unseren Modelle halten wir die Entscheidungen und die dazu führenden Gründe fest und machen sie so nachvollziehbar und auswertbar.

3 ... Business ...

3.1 Business – Was ist Gegenstand unseres Interesses?

Gegenstand unseres Interesses ist das Unternehmen. Ein gutes IT-System oder ein guter Geschäftsprozess sichern noch keine erfolgreiche Organisation.

Der Zweck unserer Modelle ist die Entwicklung von „Business Capabilities“.

„Business“ hat viele Facetten. Wir müssen sehr unterschiedliche Stakeholder-Sichten in verschiedenen Abstraktionsstufen adressieren. Bevor wir operative Geschäftsprozesse und Entscheidungen beschreiben, müssen wir auf strategischer Ebene über Vision und Ziele unseres Unternehmens Klarheit gewinnen. Auf operativer Ebene interessieren uns neben dem Ablauf des Prozesses Verantwortlichkeiten, unterstützende IT-Systeme, aber auch andere Inhalte wie z.B. die Topologie eines Lagers. Wir sprechen daher von Business Capabilities, die wir beschreiben wollen. Abbildung 2 zeigt das Burlton Hexagon zur Beschreibung einer prozesszentrierten Business Capability.

BurltonHexagon

Abbildung 2: Burlton Hexagon zur Beschreibung einer Business Process Centric Capability

Wir müssen die verschiedenen Inhalte bestimmen und eine Struktur für die Darstellung und für die Organisation unseres Modell-Repositories festlegen. Wie breits gesagt, nutzen wir das Zachman Framework for Enterprise Architecture als Rahmen für die Organisation der Modellinhalte und deren Verknüpfung untereinander.

3.2 Business und IT – Welche Rolle spielt Technologie im Rahmen des Model-Based Business Engineering?

Business ohne IT oder Technologie allgemein ist heute nicht mehr denkbar. Wir sprechen von der Digitalisierung von Geschäftsprozessen oder dem „Internet of Things“. Beides schließt sowohl die Business-Sicht, als auch technische Lösungen ein.

Die IT muss „Business-aware” sein, genauso wie das Business „Technology-aware” sein muss. IT und Business müssen gemeinsam die Anwendungsmöglichkeiten neuer Technologien für die Lösung von Geschäftsproblemen erkunden und umsetzen.

Im Rahmen des „Model-based Business Engineering“ werden Systembeschreibungen, System-Anforderungen, Zusammenhänge zwischen Systemen und Capabilities dargestellt und berücksichtigt. Insbesondere Anforderungen für Business-IT-Systeme sind Bestandteil unseres Ansatzes. Die eigentliche Entwicklung der Systeme ist dagegen nicht Gegenstand. Hierfür gibt es viele andere modell-basierte Ansätze, wie zum Beispiel das Model-Based Systems Engineering (MBSE). Wir verstehen unseren Ansatz als komplementär dazu.

4 ... Business Engineering – Ergebnisse systematisch erstellen

Wir verstehen Modellieren als ingenieur-technische Leistung. Das heißt:

  • Modellieren kann geplant werden.
  • Die Qualität von Modellen kann beurteilt werden.
  • Modellieren ist nachvollziehbar und wiederholbar.
  • Modelle können langfristig gepflegt und genutzt werden.
  • Designentscheidungen werden begründet getroffen.

Diese Punkte sollten selbstverständlich sein, sind es aber in der Praxis oft nicht. Insbesondere die Forderung nach Nachvollziehbarkeit und Wiederholbarkeit führt zu Diskussionen. Wir erwarten, dass Modelle vergleichbar sind, wenn sie auf Grundlage derselben Informationen entstehen, unabhängig davon, wer in unserem Team diese Modelle erstellt. Das Ergebnis wird nicht identisch sein, da Modellieren eine kreative Tätigkeit ist. Im Modellierungsprozess treffen wir möglicherweise unterschiedliche Designentscheidungen. Auch deshalb ist die Erfassung dieser Informationen über den primären Inhalt hinaus sehr wichtig. Ist das Ergebnis aber komplett unterschiedlich, dann hat Modellieren nicht mit ingenieur-technischem Herangehen zu tun.

4.1 Standard-Notationen, informelle Beschreibungsmittel und Styleguides

Um den genannten Ansprüchen gerecht zu werden, spielen Standard-Notationen eine wichtige Rolle.

In sozialen Netzwerken und auf Konferenzen erleben wir viele Diskussionen über Fehler und Unvollständigkeiten in den Standard-Notationen. Natürlich bieten die Standard-Notationen noch viele Möglichkeiten zur Verbesserung. Sie bilden aber oft eine bessere Basis als proprietäre Notationen. Sie bieten einen Erweiterungsmechanismus, um zusätzliche Beschreibungen zu integrieren und eigene Anforderungen abzudecken. Das definierte Austauschformat gibt die Möglichkeit verschiedene Werkzeuge zu benutzen.

Unabhängig davon lassen alle Standard-Notationen einen großen Freiheitsgrad in der Anwendung, da sehr unterschiedliche Einsatzfälle adressiert werden sollen. Egal ob wir eine Standardnotation einsetzen oder uns für eine eigene Darstellungsform entscheiden, müssen wir in unserem Team eine einheitliche Anwendung sicherstellen. Dazu gehört die Entwicklung eines gemeinsamen Verständnisses der Konzepte, aber auch Vorgaben, wie die Notation zu nutzen ist. Das umfasst einfache Vorgaben, wie Benennungsregeln für Modelle und Modellelemente oder Farbgebung von Elementen. Das können Vorgaben zur Verwendung und Bedeutung bestimmter Modellelemente sein. Das kann die Vorgabe von Prozessmustern sein.

Üblicherweise erfolgt das in einem Styleguide oder Modellierungs-Wiki, das unsere Modellierungsvorgaben für unser Team oder unsere Organisation enthält.

4.2 Arbeitstechniken für die Modellierung

Für die Erstellung von Modellen gibt es eine Vielzahl von Arbeitstechniken, wie Informationen für Modelle erfasst werden, wie diese analysiert und umgesetzt werden.

Dazu gehört die Planung von Modellierungsprojekten. Dazu gehören Arbeitstechniken wie Process Mining, textuelle Analyse, Interviewtechniken, Gestaltung von Workshops oder Facilitation-Techniken.

Die Anwendung solcher Arbeitstechniken ist wichtiger Bestandteil des Model-Based Business Engineering.

In vielen Teilen geht es dabei um die Einbeziehung von Menschen bei der Erhebung, Gestaltung und Umsetzung von Geschäftsprozessen und Business Capabilities.

4.3 Business Engineering ist ein “People Business”

Wir müssen Menschen bei der Gestaltung des Unternehmens einbeziehen. Wir erstellen Modelle nicht als Selbstzweck.

Die entworfenen Prozesse müssen umgesetzt werden. Change Management gehört als herausgehobene Disziplin zum Model-Based Business Engineering. Change Management benötigt unsere Modelle zur Kommunikation über Geschäftsprozesse, Organisation und die geplanten Änderungen.

Die Gestaltung von Modellausgaben erfordert ebenfalls ein gutes Verständnis der Stakeholder, deren Anforderungen, Erwartungen und Erfahrungen.

Diese Aspekte sind mit der Kultur der jeweiligen Organisation verbunden. Die Umsetzung von Prozessen und Capabilities erfordert eine entsprechende Kultur und einen kulturellen Wandel.

4.4 Continues Improvement und Governance für Modelle

Business Engeering ist kein einmaliger Aufwand. Um die Organisation konkurrenzfähig zu halten, müssen Prozesse und Capabilities kontinuierlich verbessert werden. Aufbauend auf unseren Modellen, verfolgen wir zum Beispiel unsere Prozesse und überwachen die KPI im operativen Betrieb. Ausgehend von diesen Erkenntnissen verändern wir Prozesse und die Organisation.

Die ständige Verbesserung von Prozessen und Organisationskontext birgt die Gefahr, das sich Modelle und Realität auseinander entwickeln. Wir müssen daher sicherstellen, das Modelle und Realität unter Berücksichtigung des Modellzwecks in Übereinstimmung gehalten werden. Wir definieren Governance Regeln und Prozesse für die Pflege der Modelle.

 

Literatur/Quellen

Burlton, Roger, Business Process Management: Profiting from Process: Incorporating Internet Strategies, Que, 2001
Zachman, John F., John Zachman, The Zachman Framework For Enterprise Architecture: Primer for Enterprise Engineering and Manufacturing, Zachman International, 2006, Electronic Book
Osterwalder, Alexander, Pigneur, Ives, Business Model Generation: Ein Handbuch für Visionäre, Spielveränderer und Herausforderer, Campus Verlag, 2011
Ross, R., Pitschke, J., RuleSpeak® Satzformen, Business Rules in natürlich sprachlichem Deutsch spezifizieren, Business Rules Solutions, LLC und BCS, Dr. Jürgen Pitschke, Version 1.1, 2009

 

Copyright

Diese Unterlagen können intern frei für nicht-kommerzielle Zwecke benutzt werden. Die kommerzielle Nutzung oder Weiterverbreitung jeglichen Teils dieser Unterlagen ist ohne Zustimmung von Dr. Jürgen Pitschke, BCS - Dr. Juergen Pitschke nicht gestattet. Für Lizenzen und Weiterverwendung sprechen Sie uns bitte an. Kopieren Sie diese Notiz in jede Reproduktion.