Ein buntes Buch in ungewohntem Querformat soll DAS neue Managementbuch sein? Ja, richtig.

Es schließt an das 2010 veröffentlichte Buch „Management 3.0“ an, worin sich Jurgen Apello mit der verändernden Rolle der Führung in agilen Organisationen beschäftigte. Zwei Jahre nach der Veröffentlichung des Folgewerks „Management for Happiness“ im Jahr 2016 erschien nun im Mai 2018 die deutsche Übersetzung im selben farbenfrohen Layout wie die Originalversion.
Scrum.org empfiehlt übrigens beide Werke für alle, die sich für die „Professional Agile Leadership“-Zertifizierung interessieren.

Seit vielen Monaten sind wir jetzt schon für die MID GmbH als Scrum Master und Agile Coaches im Kundeneinsatz. Täglich arbeiten wir unermüdlich mit diversen Organisationen und Teams daran, agile Werte wie Mut, Respekt und Wertschätzung und sinnvolle Vorgehensmodelle zu etablieren und zu verbreiten. Eine spannende Herausforderung, die dauerhafte Selbstreflexion von uns fordert.
Wann beginnen wir selbst, in eingefahrenen Bahnen zu denken?
Wann verlieren wir irgendwann als Teil des Systems unsere unvoreingenommene Perspektive?
Und wie schaffen wir es, trotz eines fordernden Alltags neue Impulse und frische Ideen in unsere Arbeitsumgebung zu tragen und einfach mal "Out of the Box" zu denken?

Neue Vorgehensweisen bei der Produktentwicklung und agile Transformationen in Unternehmen bedingen, dass wir uns auch im klassischen Geschäftsprozessmanagement mit diesen neuen Methoden und Denkweisen auseinandersetzen müssen.

In diesem Kontext hören und lesen wir Dinge wie „Agile Business Process Management (BPM)“, „agile Prozesse“ oder „agile Prozesserhebung“.

Aber was bedeutet all das nun?

Um das zu klären, müssen wir zunächst verstehen, mit welchen Begrifflichkeiten wir hantieren.

Agil oder Agilität ist ein Wertesystem, das ursprünglich zum Entwickeln von Softwareprodukten unter Anwendung von bestimmten Prinzipien entwickelt wurde, das heute auch in der Nicht-IT zum Einsatz kommt.

Ein leichtgewichtiger, agiler Entwicklungsansatz verträgt sich nicht mit einem schwergewichtigen Modellierungsvorgehen. Dieser Meinung sind viele Kunden und Interessenten, mit denen wir sprechen. Sie vertreten daher den Standpunkt, dass man in agilen Projekten nicht modellieren kann.

Als "The Modeling Company" haben wir uns mit diesem Vorurteil, dass Agilität und Modellierung angeblich nicht zusammenpassen, selbstverständlich intensiv auseinandergesetzt. Wir haben uns daher nicht nur damit beschäftigt, warum das Vorurteil häufig genannt wird, sondern auch, ob es so überhaupt zutrifft.

Die kurze Antwort lautet „Nein“.

Mehrfach angekündigt und verschoben, ist das neue Service-Design-Buch von Mark Stickdorn und seinen Co-Autoren Adam Lawrence, Markus Homess und Jakob Schneider nun endlich im Dezember des vergangenen Jahres auf den Markt gekommen. Wie der Titel schon andeutet, wendet sich das Buch an alle, die in Projekten arbeiten oder arbeiten wollen, für die Innovation, Kundenorientierung und Servicequalität elementar sind und die sich deshalb für die Methoden des „Service Design“ und „Design Thinking“ interessieren.

Mark Stickdorn und Jakob Schneider haben bereits 2010 gemeinsam das Buch „This is Service Design Thinking“ herausgegeben, das binnen kurzem zu einem Standardwerk avancierte. Hier hatten sie schon mit vielen Gastautoren zusammengearbeitet, die auch im neuen Werk wieder mit an Bord sind.

Oft zitiert und viel gelobt wird im Kontext von agiler Produktentwicklung das Thema Selbstorganisation. Ein Scrum Team soll selbstorganisiert und eigenverantwortlich arbeiten. Und auch so manchem nichtagilen Team würde eine Portion Selbstorganisation nicht schaden.
Doch was ist das eigentlich – Selbstorganisation?

Der Duden sagt dazu: „Spontane Entstehung, Bildung aus sich selbst heraus, ohne von außen wirkende Faktoren“

Und auf Wikipedia steht zum Thema Selbstorganisation in der Systemtheorie Eingangs: „Selbstorganisation ist das spontane Auftreten neuer, stabiler, effizient erscheinender Strukturen und Verhaltensweisen (Musterbildung) in offenen Systemen.“

Soweit so gut – aber wie schaffen wir es, diese spontanen, stabilen Strukturen in unsere Scrum Teams zu bekommen? Oder vielmehr – wie befähigen wir unsere Teams diese Strukturen selbst(!) zu schaffen?

In Zeiten der vermehrten Digitalisierungs- und Modernisierungswellen innerhalb vieler Unternehmen aber auch außerhalb, entstehen im Zuge dessen oft Unsicherheiten. Was modernisieren wir? Wo setzt man an? Welche Faktoren gibt es zu beachten und bleibt man der ursprünglichen Firmenphilosophie treu?

Als erfolgversprechendes Modell hierfür hat sich das St. Galler Konzept seit mehreren Jahrzehnten bewährt. Dieses Konzept berücksichtigt nicht nur die harten Faktoren, sondern auch die nicht minder wichtigen weichen Faktoren einer Firma, die das große Ganze bilden und äußerste Komplexität vermuten lassen.
Autor und Mitbegründer der St. Galler Business School Christian Abegglen hat in seinem Buch das St. Galler Konzept in die Praxis umgesetzt und erklärt äußerst ausführlich und mit höchster Präzision wie man das Modell auf sein Unternehmen übertragen kann. Hierzu hat er dem eigentlichen St. Galler Konzept noch drei Perspektiven hinzugefügt: Zeit, Raum und Mensch.

Was ich nicht weiß, macht mich nicht heiß

Im Blog-Beitrag zu Innovator 14 und den Neuerungen im Bereich der Konfiguration haben wir uns mit der Möglichkeit beschäftigt, wie zusätzliche Stereotyp-Merkmale in nahezu jedem Profil zu einem Stereotyp hinzugefügt werden können.

Doch wie verhält es sich mit ungewünschten, nicht benötigten Eigenschaften (Labels, Spezifikationstexten (F3-Texte)), Verbindungsmöglichkeiten zwischen Modellelementen sowie die Möglichkeit, Elemente generell anlegen zu können? Oftmals ist das Ziel einer eigenen Modellierungsmethodik, die Modellierung zu vereinfachen und nur diejenigen Elemente mit spezifischen Eigenschaften dem Anwender zur Verfügung zu stellen, die tatsächlich im Kontext des Unternehmens bzw. des Projekts benötigt werden.

Bislang hatten Sie diesbezüglich wenige Möglichkeiten, ungewünschte Stereotypen bzw. deren Eigenschaften aus dem Modell zu entfernen. Sie konnten auch hier entweder nur die Konfiguration der Elemente in den definierenden Profilen anpassen (Stichwort: Updateproblematik bei der Verwendung von Migrationsprofilen – siehe Blog-Beitrag Innovator-Konfiguration leicht gemacht) oder sich wieder eigene Profile mitsamt allen benötigten Elementen anlegen (sehr aufwändig und nicht updatebar ohne manuelle Anpassungen).

Mit Innovator 14 gehört auch dies der Vergangenheit an!

In einem Qualitätsmanagementsystem müssen die Kundenanforderungen berücksichtigt werden. Dieser Tatsache trägt bspw. auch die neue Revision der Norm DIN EN ISO 9001 aus dem Jahr 2015 Rechnung, in der der Analyse und Steigerung der Kundenzufriedenheit insgesamt ein viel höheres Gewicht eingeräumt wird, als dies noch in alten Revisionen der Fall war.
 
Oft genug wird der Begriff der "Kundenanforderungen" in diesem Zusammenhang aber nur auf Produkteigenschaften bezogen. Dabei wird vernachlässigt, dass auch die Prozesse des Kunden, angefangen mit der Vorkaufphase über den eigentlichen Kauf und die Nachkaufphase mit Service & Support, und deren Unterstützung durch das Unternehmen die Erfahrungen mit dem Produkt nachhaltig beeinflussen. Anforderungen bestehen also nicht nur in Bezug auf Produkteigenschaften, sondern auch in Bezug auf die Kundenprozesse. Klassische Ansätze des prozessorientierten Qualitätsmanagements wie auch des Business Process Managements im Allgemeinen berücksichtigen diese Erkenntnis oft nur unzureichend, da Geschäftsprozesse als sogenannte Ende-zu-Ende-Prozesse aus Sicht des Unternehmens (aus der Innensicht) spezifiziert werden. Eine systematische Beschreibung, Analyse und Gestaltung der Kontaktpunkte mit dem Kunden oder eine Gestaltung von Geschäftsprozessen basierend auf diesen Kundenprozessen erfolgt dabei jedoch nicht. In diesem Blogbeitrag zeige ich Ihnen ein Vorgehen auf, wie Sie Kundenprozesse beschreiben und darauf basierend Ihre Geschäftsprozesse gestalten können. Damit können Sie die Kundenerfahrung mit Ihren Produkten nachhaltig verbessern.

Im ersten Blog-Beitrag zu Innovator 14 haben wir Ihnen einen ersten Überblick darüber gegeben, welche verbesserten Konfigurationsmöglichkeiten Sie mit dem neuesten Release haben:

• Stereotypeigenschaften in Erweiterungsprofilen definierbar
• Importierte Konfigurationsinhalte ignorieren
• Verweis auf anderes Element

Doch was genau lässt sich unter diesen Punkten verstehen? Was bedeutet es, Stereotypeigenschaften in Erweiterungsprofilen definieren zu können, ohne das Rad neu erfinden zu müssen?

Bis einschließlich Version 13.3 von Innovator waren grundlegende Änderungen eines Stereotyps (Hinzufügen bzw. Wegnehmen von Merkmalen) nur in dem Profil möglich, in dem der Stereotyp definiert ist.

Beispielweise wurde dem Stereotyp <<Anforderung>> ein Merkmal „Geheimhaltungsstufe“ hinzugefügt. Dieses Merkmal musste bisher im ROOT-PROFILE konfiguriert werden.

Abb. 1: Individuelle Merkmale zu Elementen hinzufügen