Ergänzung für IT-Projektprofis
von Roger T. Burlton, Ronald G. Ross & John A. Zachman1
Der Kontext und die Bedeutung dieser Ergänzungbasiert auf dem Business Agility Manifest.

~~~
A. Echte Unternehmensagilität
1. Echte Unternehmensagilität ergibt sich aus nachhaltiger Geschäftsveränderung –nicht nur aus nachhaltiger Software-Entwicklung.
2. Echte Unternehmensagilität wird nicht nur an der Reaktionsgeschwindigkeit auf
neue oder veränderte Kundenbedürfnisse und Disruptionen im Umfeld desUnternehmens gemessen, sondern auch an der Kohärenz dieser Reaktionen.
3. Echte Unternehmensagilität entsteht erst, wenn alle Silos oder nicht integrierten
Produkt-Pipelines entlang der Wertschöpfungsketten eliminiert werden.

B. Selbstorganisierende Teams
1. Selbstorganisierende Teams sowie andere agile Organisationsmodelle allein
führen nicht zu Unternehmensagilität.
2. Selbstorganisierende Teams sind ein Mittel, kein Ziel. Sie reduzieren nicht den
Bedarf nach Geschäftsstrategie, kohärenter Wertschöpfungskette, Wiederverwendung von Geschäftswissen sowie effektivem Portfolio-Management, sondernerhöhen ihn sogar.

1 Dank an Gladys S.W. Lam für Input zum Inhalt und zur Organisation des Manifests und an Sasha Aganova für dieLeitung der Arbeiten bis zu deren Fertigstellung. Dank an Dr. Jürgen Pitschke für seinen wertvollen Beitrag bei derÜbersetzung des Manifests.
© Business Rule Solutions, LLC. 2017.
1© John A. Zachman, Zachman International. 2017.
© Process Renewal Consulting Group (2015), Inc. 2017.
© Übersetzung: KnowGravity, Inc. 2018.
Die Erlaubnis zur unbegrenzten Vervielfältigung und Verbreitung dieses Dokuments wird unter folgenden
Bedingungen erteilt: (a) Die Urheberrechte und dieser Genehmigungshinweis sind eindeutig enthalten. (b) Das Werk
wird eindeutig seinen drei Autoren zugeschrieben. (c) Kein Teil des Dokuments, einschliesslich Titel, Inhalt,
Urheberrechte und Genehmigungshinweise, wird in irgendeiner Weise verändert, gekürzt oder erweitert.

C. Kundenorientierung
1. Kundenorientierung ist entscheidend – aber nie das einzige Unternehmensziel.
Gewisse Geschäftsprobleme bleiben immer: Kompromisse gegenüber anderenGeschäftszielen, "Total Cost of Ownership", Compliance, inakzeptable Risikenoder untragbare Kosten.
2. Der wahre Geschäftskunde ist der Kunde des Geschäftsprodukts – nicht derEigentümer des Softwareprodukts.
3. Im Unternehmensumfeld sollte "Kunde" immer Kunde des Unternehmens und"Produkt" immer Produkt des Unternehmens bedeuten.
4. Benutzer sind nicht notwendigerweise Kunden; Benutzererfahrung ist nicht
notwendigerweise Kundenerfahrung. Die Kundenerfahrung sollte überwiegen.
5. Ein exzellentes Kundenerlebnis umfasst sämtliche Kontaktpunkte mit demKunden, nicht nur die digitalen.

D. Schnelles Scheitern
1. Teures oder wiederholtes Scheitern, auch wenn schnell, ist dennoch eine
Verschwendung, die es zu vermeiden gilt.
2. Der Wert des schnellen Scheiterns um schnell zu lernen, muss gegenüber anderen
Faktoren abgewogen werden: Auswirkungen auf Geschäftskunden, Kosten fürNacharbeit oder Risikobereitschaft.

E. Kommunikation
1. Sich ausschließlich auf Face-to-Face-Dialoge zu verlassen, um Geschäftswissen zu
vermitteln oder zu erhalten, ist äusserst riskant.
2. Effektive Kommunikation von Geschäftswissen über die Zeit hinweg – seineBewahrung – ist von unschätzbarem Wert. Dies ist weitaus schwieriger, als nur
Kommunikationslücken in Projekten zu schliessen.
3. Eine entscheidende Fähigkeit für Analysten ist die Fähigkeit, in Dialogen das
Geschäftswissen auf Lücken, Konflikte, Unklarheiten und Vollständigkeit zuüberprüfen.

2

F. Wandel
1. Eine unmittelbare Veränderung ist nicht das Ziel. Ziel ist eine durchdachte
Veränderung, die den gewünschten Geschäftseffekt erzielt und unbeabsichtigte
Nebenwirkungen vermeidet.
2. Reibungsloser Wandel ist nicht das Ziel. Ziel ist ein Wandel, der sich verlässlich an
der Geschäftsstrategie, den Grundsätzen sowie den geschäftlichen
Verpflichtungen orientiert.
3. Spezifische oder einmaligen Veränderungen sind nicht das Ziel. Ziel ist ein
skalierbarer, nachhaltiger Wandel.

G. Bestehende Geschäftsfelder
1. An der Qualität von Unternehmenssoftware zu sparen – und damit einetechnische Schuld zu schaffen – hat in Unternehmen, die Veränderungen inbestehenden Geschäftsfeldern anstreben, keinen Platz.
2. In bestehenden Geschäftsfeldern tragen selbstorganisierende SoftwareEntwicklungsteams nur dann zur geschäftlichen Agilität bei, wenn sie auf
explizitem gemeinsamem Geschäftswissen aufbauen und auch dazu beitragen.
3. In bestehenden Geschäftsfeldern ist Time-to-Market direkt von der
Rekonfigurations-Agilität abhängig.

H. Konzeptmodelle
1. Der Fokus eines Konzeptmodells liegt darauf, welche Worte in derKommunikation über das Unternehmen verwendet werden sollen, insbesondere
beim Schreiben und anderen geschäftlichen Kommunikationsformen, sowie wasdiese Worte bedeuten.
2. Die Elemente eines Konzeptmodells repräsentieren nicht die Dinge in der realen
Welt; sie repräsentieren das gemeinsame Verständnis des Unternehmens überdiese Dinge, wie es in Geschäftsdefinitionen zum Ausdruck kommt.
3. Die Zusammenhänge in einem Konzeptmodell beschreiben, wie Konzepte logisch(d.h. strukturell) zueinander in Beziehung stehen.
4. Ein Konzeptmodell wird durch ein strukturiertes Geschäftsvokabular
repräsentiert, das sowohl Substantive als auch Verb-Phrasen enthält.
5. Ein Datenmodell, Klassendiagramm oder Entity Relationship Diagramm ist kein
Konzeptmodell. Ebenso wenig wie ein Prozessmodell, ein Anwendungsfall- oder
Aktivitätsdiagramm.

3

I. Geschäftsregeln
1. Die effektive Formulierung von Geschäftsregeln erfordert ein Konzeptmodell.
2. Ein Geschäft basiert auf vertraglichen Verpflichtungen, die verletzt werden
können, was wiederum zu persönlichen oder geschäftlichen Konsequenzen führen
kann.
3. Sobald Geschäftsregeln prozedural implementiert sind, geht ihre Semantik
verloren, ohne dass sie automatisch wiederhergestellt werden kann. Dieser Verlust
macht den Geschäftszweck unklar und macht eine Wiederverwendung
unmöglich.

J. Software Design und Entwicklung
1. Unternehmensagilität kann nicht allein durch agile Softwarepraktiken erreicht
werden.
2. Die schnelle Erstellung von Software tendiert dazu, die spätere schnelle undkosteneffektive Anpassung von Geschäftswissen zu behindern.
3. User Stories, Use Cases und Software-Prototypen können einen Großteil desGeschäftswissens, das für eine ganzheitliche, effektive und anpassungsfähige
Geschäftslösung erforderlich ist, leicht übersehen.
4. Gewisse Dinge können nicht gegen Prioritäten von Software-Features abgewogen
werden: beispielsweise die Einhaltung vertraglicher Verpflichtungen undZusagen, die Einbettung in die Wertschöpfungskette oder die Wiederverwendungvon explizitem Geschäftswissen.
5. Eine Software-Strategie, die Geschäftswissen nicht erfasst, bewahrt undwiederverwendet, ist für die wissensbasierte Wirtschaft ungeeignet.

4