Äußere Einflüsse, die der Markt an ein Unternehmen stellt, stoßen die Türen zu völlig neuen Dimensionen auf. Marktanforderungen und technischer Fortschritt steigern die zu beherrschende Komplexität um Größenordnungen, die vor zehn Jahren noch als unerreichbar galten. Zudem müssen die Anforderungen in immer kürzeren Zyklen umgesetzt und sicher beherrscht werden. Projektvorhaben, die unter diesen äußeren Rahmenbedingungen entstehen, lassen sich mit den traditionellen Methoden nicht mehr abwickeln.
Illustration: Absmeier, Geralt
Traditionelle Methoden entstammen in ihren Grundideen der klassischen Softwareentwicklung und dem zugrundeliegenden, linearen Modell. Hierbei wird das gesamte Vorhaben über die fünf Phasen Setup, Business Blueprint, Realisierung, Go-live und Support umgesetzt. Zentrales Element ist der Business Blueprint, welcher eine vollständige Beschreibung der zu erstellenden Lösung enthält.
In den meisten Unternehmen sind die dazu passenden, klassischen, plangetriebenen Projektmethoden etabliert und gehen konform mit den hierarchischen Organisationsstrukturen. Ein Projekt erhält ein fixiertes Ziel, Kosten und Zeit zur Realisierung werden geschätzt. Je einfacher das Projekt ist, desto höher ist die Wahrscheinlichkeit, dass alles wie geplant umgesetzt wird.
Auswirkungen von Komplexität
Heutige Projekte sind komplexer Natur. Es ist nahezu unmöglich, bereits zu Projektbeginn alle projektrelevanten Phasen und Parameter endgültig und im Detail festzulegen. Die Gefahr ist groß, dass die Projektergebnisse nach der Fertigstellung nicht mehr den dann aktuellen Anforderungen entsprechen. Ein fehlerfreier Business Blueprint als umfassender Bauplan einer Lösung ist immer schwieriger herzustellen.
Ist das Projekt erst einmal in der Realisierung, ermöglichen traditionelle Methoden Änderungen gar nicht beziehungsweise nur sehr eingeschränkt. Projekte, in denen das versucht wird, sehen sich einer Flut von Change Requests einhergehend mit Kosten- und Terminüberschreitungen konfrontiert. Im Ergebnis scheitert das Projekt komplett oder die Lösung spiegelt nicht den aktuellen, benötigten Anforderungsstand, sondern nur den Stand zu Projektbeginn wider.
Weniger Individualentwicklung als vielmehr: Customizing
Eine zusätzliche Komponente ist die wachsende Leistungsfähigkeit von Standardsoftware. Diese kann über Customizing flexibel an Kundensituationen angepasst werden, wodurch die an der Softwareentwicklung ausgerichteten Projektverfahren überholt, weil ineffizient sind. Den Unternehmen steht Software in einem hohen Reifegrad zur Verfügung, mit denen sie die Marktanforderungen effizient abdecken können. Nur im Falle fehlender Standards oder wettbewerbsdifferenzierender Prozesse lassen sich Individualentwicklungen heute noch rechtfertigen.
Im Fokus der Aufgabe steht nun, die Best-Practice-Geschäftsprozesse wesentlich stärker zu berücksichtigen. Die Komplexität dieser Pakete steigt, Auswirkungen von Entscheidungen sind kaum in voller Tragweite abschätzbar. Gerade in der Anfangsphase eines Projekts beziehungsweise eines Projektabschnitts führt diese Situation zu großer Unsicherheit.
Heilsbringer Agil?
Für die Bewältigung komplexer Aufgaben haben die meisten Unternehmen weder passende Methoden ausgearbeitet noch sind die Organisationen auf eine Art von Projekten vorbereitet, die maßgeblich von veränderten äußeren Rahmenbedingungen geprägt sind. In der Folge wird mittels überkommener Methoden versucht, einen Ausgleich für die Unbeherrschbarkeit komplexer Aufgaben zu schaffen. Insbesondere wird ein unverhältnismäßig hoher Aufwand in der Analyse- und Konzeptionsphase betrieben, was dann in einem detailliert ausgearbeiteten Business Blueprint mündet. Dies gilt insbesondere für größere Projekte, wenn diese durch lange Laufzeiten determiniert sind.
Die Projekte scheitern oder verlaufen ineffizient – aber nicht etwa, weil die Methoden fehlerhaft, sondern weil die Methoden bezogen auf die Problemstellung ungeeignet sind.
In vielen Unternehmen ist man sich dessen grundsätzlich bewusst. Aktuell kann man jedoch den Eindruck gewinnen, als würde die Verwendung des Titels »Agil« im Projektauftrag ausreichen, um aller Probleme schnell (sprich: agil) Herr werden zu können.
Was können agile Methoden
Agile Methoden haben ihren Ursprung in der Entwicklung komplexer Software. Kennzeichen agilen Vorgehens ist, dass bei Projektstart nicht exakt beschrieben werden kann, wie die Lösung am Ende aussieht, sondern durch Iteration ein möglichst optimaler Wert für das Unternehmen entsteht. Die Grundparameter klassischen Handelns im Unternehmen werden dabei auf den Kopf gestellt:
Während plangetriebene Projekte (fast) um jeden Preis einen fixen Scope erreichen müssen, sind bei agilen Projekten Zeitleiste und Kosten gegeben. Hier ist die Lösung selbst variabel. Wie kann das funktionieren?
Entwicklung agil: iterativ und beweglich
Agile Softwareentwicklung ist der Oberbegriff für den Einsatz von Agilität (lat. agilis: flink, beweglich) in der Softwareentwicklung. Agile Softwareentwicklung versucht, mit geringem bürokratischen Aufwand, wenigen Regeln und meist einem iterativen Vorgehen auszukommen.
Alle agilen Toolsets basieren auf den nachfolgend beschriebenen Prinzipien:
- Transparenz
Die wesentlichen Aspekte des Prozesses müssen für diejenigen Personen erkennbar sein, die für das Prozessergebnis verantwortlich sind. Transparenz erfordert, dass diese Aspekte durch einen gemeinsamen Standard definiert sind, sodass existierende Probleme und mögliche anstehende Probleme sichtbar gemacht werden und alle Beteiligten das gleiche Verständnis für die Situation entwickeln.
- Überprüfung (Inspection)
Scrum-Anwender müssen ständig die Scrum-Artefakte und den Fortschritt auf dem Weg zur Erreichung des Ziels überprüfen, um unerwünschte Abweichungen zu entdecken. Die Häufigkeit der Überprüfungen sollte in dem Zusammenhang nicht so hoch sein, dass die eigentliche Arbeit dadurch behindert wird.
- Anpassung (Adaptation)
Wenn bei einer Überprüfung festgestellt wird, dass ein oder mehrere Aspekte des Prozesses außerhalb akzeptabler Grenzen liegen und das Produktergebnis dadurch ebenfalls nicht zu akzeptieren sein wird, muss so schnell wie möglich eine Anpassung des Prozesses oder des Arbeitsgegenstandes vorgenommen werden, um weitere Abweichungen zu minimieren.
SCRUM
Scrum wird seit den frühen 1990er Jahren als Prozessframework bei der Umsetzung komplexer Produktentwicklungen verwendet. Scrum ist weder ein Prozess noch eine Technik zur Erstellung von Produkten, es ist vielmehr als Framework zu verstehen, innerhalb dessen verschiedene Prozesse und Techniken zum Einsatz gebracht werden können. Scrum macht die relative Wirksamkeit Ihres Produktmanagements und Entwicklungsvorgehens sichtbar, sodass Schritte zur Verbesserung eingeleitet werden können.
Die Werte agiler Softwareentwicklung bilden das Fundament. Im Februar 2001 wurden diese Werte als Agiles Manifest formuliert (nach Schwaber, Sutherland):
- Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
- Funktionierende Software ist wichtiger als umfassende Dokumentation.
- Zusammenarbeit mit dem Kunden ist wichtiger als die ursprünglich formulierten Leistungsbeschreibungen.
- Eingehen auf Veränderungen ist wichtiger als Festhalten an einem Plan.
Leicht zu erlernen – schwer zu meistern
In diesem Zusammenhang lässt sich die agile Methode Scrum als Gegenentwurf zur Befehls- und Kontroll-Organisation verstehen. Stattdessen baut Scrum auf hoch qualifizierte, interdisziplinär besetzte Teams, welche bei der Umsetzung ihrer Ziele autark sind. Dadurch bekommen die Teams den nötigen Freiraum, um ihr Wissens- und Kreativitätspotenzial in Eigenregie zur Entfaltung zu bringen.
Daraus ergibt sich, dass Scrum zwar leichtgewichtig und damit auch leicht zu erlernen ist, aber durch die hohen Freiheitsgrade extrem schwer zu meistern ist.
Model-based Design als Symbiose zweier Welten
Per se stellen weder klassische noch agile Methoden die Lösung für die meisten Projekte dar.
Die Methode, Kundenanforderungen über User Stories zu ermitteln, ist bei komplexeren Aufgabenstellungen – wie der Einführung einer ERP-Software – nicht mehr zielführend anwendbar.
Hier sind methodenbasierte Verfahren als kombinierter Ansatz wesentlich besser geeignet. Vor diesem Hintergrund entstand das »Model-based Design« als agiles, iteratives Methodenset. Das Verfahren unterstützt die Erstellung und Analyse der Anforderungen und schafft die Basis für die Entwicklung der zukünftigen Lösung.
Model-based Design ist ein neuer Methodenansatz in der Softwareentwicklung und -implementierung mit dem Ziel, sehr rasch und in frühen Projektphasen einen gesicherten Erkenntnisstand bezüglich der Eignung eines Lösungsansatzes zu erhalten. Probleme und Änderungswünsche werden frühzeitig identifiziert und sind innerhalb der Realisierung mit weniger Aufwand zu beheben, als es nach Fertigstellung des Projekts möglich ist.
Kernstück Modell
Ein »Modell« steht für ein Abbild des Zielsystems, welches alle kritischen Prozesse beinhaltet. Die Prozesslandschaft des Modells ist bezogen auf die unternehmenskritischen Prozesse vollständig aber noch nicht detailliert.
Dieses Vorgehen kann den klassischen Business Blueprint in großen Teilen ersetzen sowie die Folgeschritte der Implementierung erheblich beschleunigen und sicherer gestalten.
Mehrstufige Analyse der Anforderungen
Zur Anwendung kommt ein mehrstufiger, systematischer Analyse- und Designansatz, mit dem die Anforderungen gesammelt und verprobt werden.
Im Analyseworkshop wird ein gemeinsames Verständnis für das anstehende Projekt und die zu lösende Aufgabe im Team hergestellt. Häufig trifft man auf die Situation, dass das Kundenteam sich im Analyseworkshop erstmalig gemeinsam um eine Lösung bemüht. Es werden gemeinsame Absprachen zu Anforderungen getroffen. Input zu Architektur, Design, Fit-/Gap-Analysen sowie Kundenanforderungen wird verifiziert und gemeinsam verabschiedet.
Ziel ist es, eine möglichst klare Vorstellung von der Aufgabenstellung zu bekommen. Die Freiheitsgrade – oder umgekehrt: die Genauigkeit der Beschreibung – können sehr stark variieren. Oft ist der Kunde nicht in der Lage, die Herausforderung adäquat zu beschreiben. Zusätzlich ist häufig nur das gewünschte Ergebnis bekannt, während der Weg dorthin noch völlig im Dunkeln liegt.
Der Workshop behandelt betriebswirtschaftliche Prozesse und Zusammenhänge jedoch keine (IT-) Funktionalitäten. Über die Definition des Zielmodells wird gemeinsam festgelegt, was die Tauglichkeit der zu erstellenden Lösung bestimmt: Als Projektrandbedingungen werden alle äußeren Einflussgrößen gesammelt, die das Solution Design beeinflussen können. Sie lassen sich aus Vorgaben des Managements und den Einflüssen aus der Geschäftsstrategie ableiten. Die Festlegung dieser Randbedingungen ist überaus wichtig, denn sie definieren mit dem Kunden gemeinsam den Korridor für die Lösung, in der Regel die Prozess- und Budgetgrenzen sowie zeitliche Restriktionen.
Ausrichtung an der Betriebswirtschaft
Im weiteren Verlauf der Analyse werden die betriebswirtschaftlichen Anforderungen erarbeitet. Dies sind die Festlegungen zum Prozessdesign, zum zugehörigen Informationsfluss sowie alle Informationen zur Prozesslenkung. Dabei wird das Sollsystem auf betriebswirtschaftlicher Ebene modelliert. Aktuell gültige betriebswirtschaftliche Anforderungen fließen mit den zukünftigen Anforderungen zusammen. Best Practices wie beispielsweise die Umsetzung von Lean-Strategien werden ebenfalls in das Solldesign eingearbeitet. Es ist gut möglich, bereits hier die existierenden »Pain Points« gegen das entstehende Sollkonzept zu verproben.
Sobald mittels dieser Methode ein gültiges Modell den Kern des Business Blueprint bildet, werden die darauffolgenden Projektphasen über Realisierung und Go-live bis zur Betreuung klassisch durchlaufen.
Herausforderungen für Unternehmen
Für Unternehmen bedeutet dies, dem Implementierungsteam wesentlich mehr Vertrauen entgegenzubringen als in klassischen Projekten. Agiles Vorgehen fordert auch eine stärkere Beteiligung der Unternehmensleitung am Projekt und dessen Fortschritten. Kleinere agile Schritte, die den Fortschritt anhand geeigneter Modelle dokumentieren, schaffen im Gegenzug die vom Management benötigte Sicherheit und das Vertrauen.
Die große Leistung, die dafür erbracht werden muss, ist die Akzeptanz der flexiblen Handhabung einer »theoriebasierten Entwicklung« in der oben beschriebenen methodenfeindlichen Umgebung hierarchischer Organisationen.
Als zweite Konsequenz aus obiger Betrachtung ist die »lernende Organisation« als Teil der Werkzeugkiste zu akzeptieren. Moderne, lernende Organisationen entwickeln die Fertigkeit, eigene Fehler als Erkenntnismittel zu nutzen. Das Problem wird damit die Quelle der Lösung.
Was kann aus bisheriger Erfahrung als Erfolgsfaktor angesehen werden?
Die Praxis lehrt uns, dass aus Fehlern nicht nur gelernt werden kann, sondern durch Fehlerbewältigung auch die Kompetenz im Umgang mit neuen, unerwarteten Problemen und Situationen gefördert wird. Fehler sind somit Ausgangsbasis für Kreativität und Innovation.
Fehlertolerantes Vorgehen als Teil der Firmenkultur
Natürlich bedeutet das im Umkehrschluss nicht, dass Fehler zu provozieren wären. Jedoch ist die Konzentration auf Fehlervermeidung mittel- und langfristig nicht zielführend, weil immer Fehler auftreten werden. Aus Fehlern zu lernen ist keine neue Theorie. Viele Organisationen lassen Fehler trotzdem nicht zu und sanktionieren diese. Moderne Methoden erfordern ein Umdenken im Umgang mit Fehlern.
Agilität ist keine Religion: Agile Methoden nicht für jedes Projekt verwenden
Agile Methoden wurden zur Schaffung von komplexen Produkten geschaffen, basieren auf einem iterativen Modell und folgen den Grundsätzen Transparenz, Überprüfung und Anpassung. Damit verbietet sich eigentlich der Einsatz von agilen Methoden für Themen, deren Komplexität eindeutig beherrscht wird und klar beschrieben ist. Es gilt also nicht, dass ab sofort alle, die »Agile« anwenden als Evangelisten gelten und alle anderen als Ketzer abgestempelt werden.
Readiness herstellen: Die Organisation auf »Agile« vorbereiten
Die agilen Methoden sind folglich kein Allheilmittel für alle anstehenden Probleme. Sie helfen, komplexe Probleme zu strukturieren und in handhabbaren Dosen abzuarbeiten. Team und Umfeld müssen damit zurechtkommen, dass eine Lösung nicht ad hoc existiert, sondern erst durch Entwicklung entsteht. Hier ist lösungsorientiertes Vorgehen ein unbedingtes Muss, die Basis für den Erfolg bildet ein konstruktiver Umgang mit der Veränderung.
Fazit
Agile Methoden lassen sich produktiv und zielführend bei der Einführung von Standardsoftware einsetzen. Dies beginnt mit der Anforderungsanalyse auf Basis betriebswirtschaftlicher Funktionen anstatt auf Basis der bestehenden IT-Transaktionen. Agile Methoden sind allerdings kein Allheilmittel. Sie müssen zur Aufgabenstellung passen und in ein methodisches Umfeld sauber eingepasst werden.
Ein mehrstufiges Design mit dem Fokus auf kritische Prozesse verschafft einen frühen Eindruck, ob die angestrebte Lösung den Erwartungen genügt.
Die modellhafte Abbildung ermöglicht:
- ein frühes Change Management und
- eine hohe Benutzerakzeptanz.
- Sie holt wichtige Entscheidungen in eine frühe Projektphase und
- erlaubt mit vertretbarem Aufwand langfristig Änderungen am Konzept.
Model-based Design ist eine mittlerweile erfolgreich erprobte Methode, mit der komplexe Softwareeinführungen bewältigt werden können.
Gerd Kanzleiter, IT-Management, CONSILIO IT-Solutions GmbH
Ludger Vieth, IT-Management, CONSILIO IT-Solutions GmbH
www.consilio-gmbh.de
Hier folgt eine Auswahl an Fachbeiträgen, Studien, Stories und Statistiken die zu diesem Thema passen. Geben Sie in der »Artikelsuche…« rechts oben Ihre Suchbegriffe ein und lassen sich überraschen, welche weiteren Treffer Sie auf unserer Webseite finden.
Cloud erweist sich als Treiber der Agilität in den IT-Organisationen
Agile Transformation: Agilität auch für »klassische Unternehmen«
Agilität und DevOps erfolgsentscheidend bei der digitalen Transformation
Tiefenanalyse der digitalen DNA: datengetriebene Agilität als Erfolgsfaktor
Neue Methoden für Business Intelligence – Agilität durch Automatisierung des Data Warehouse
Digitale Transformation: So tappen Unternehmen in die Agilitätsfalle