Ergänzung für IT-Projektprofis

    von Roger T. Burlton, Ronald G. Ross & 
    John A. Zachman
    1

    Der Kontext und die Bedeutung dieser Ergänzung
    basiert auf dem Business Agility Manifest.

     ~~~

    1. 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 des Unternehmens 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.
    2. 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, Wiederver­wendung von Geschäftswissen sowie effektivem Portfolio-Management, sondern erhöhen ihn sogar.
    3. Kundenorientierung
      1. Kundenorientierung ist entscheidend – aber nie das einzige Unternehmensziel. Gewisse Geschäftsprobleme bleiben immer: Kompromisse gegenüber anderen Geschäftszielen, "Total Cost of Ownership", Compliance, inakzeptable Risiken oder untragbare Kosten.
      2. Der wahre Geschäftskunde ist der Kunde des Geschäftsprodukts – nicht der Eigentü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 dem Kunden, nicht nur die digitalen.
    4. 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ür Nacharbeit oder Risikobereitschaft.
    5. 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 – seine Bewahrung – 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.
    6. 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.
    7. Bestehende Geschäftsfelder
      1. An der Qualität von Unternehmenssoftware zu sparen – und damit eine technische Schuld zu schaffen – hat in Unternehmen, die Veränderungen in bestehenden Geschäftsfeldern anstreben, keinen Platz.
      2. In bestehenden Geschäftsfeldern tragen selbstorganisierende Software-Entwicklungsteams 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.
    8. Konzeptmodelle
      1. Der Fokus eines Konzeptmodells liegt darauf, welche Worte in der Kommunikation über das Unternehmen verwendet werden sollen, insbesondere beim Schreiben und anderen geschäftlichen Kommunikationsformen, sowie was diese 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 über diese 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.
    9. 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.
    10. 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 und kosteneffektive Anpassung von Geschäftswissen zu behindern.
      3. User Stories, Use Cases und Software-Prototypen können einen Großteil des Geschä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 und Zusagen, die Einbettung in die Wertschöpfungskette oder die Wiederverwendung von explizitem Geschäftswissen.
      5. Eine Software-Strategie, die Geschäftswissen nicht erfasst, bewahrt und wiederverwendet, ist für die wissensbasierte Wirtschaft ungeeignet.

     

    German Download Button

     


    Dank an Gladys S.W. Lam für Input zum Inhalt und zur Organisation des Manifests und an Sasha Aganova für die Leitung 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.                                        

    © 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 Genehmigungs­hinweise, wird in irgendeiner Weise verändert, gekürzt oder erweitert.