Abstract

Dieser Artikel soll Entscheidern in Unternehmen deutlich machen, dass ihre Unternehmen sehr rasch auf die wachsenden Fähigkeiten von KI, insbesondere von Chatbots wie ChatGPT reagieren sollten: Unternehmen sollten die bestehenden Möglichkeiten und die Potentiale in ihren strategischen Planungen aufnehmen. Zudem benötigen Mitarbeiter Richtlinien im Umgang mit Chatbots. Der Artikel gibt zudem mit Stand April 2023 einen Ausblick, wie sich kurzfristig die Fähigkeiten von Chatbots verbessern werden. Manche Forscher bezeichnen die  Version GPT-4 bereits als ein System der „künstlichen Allgemeinintelligenz“ (AGI, Artificial General Intelligence).

Verbraucher als Beschleuniger

Doch warum die Analogie zum iPhone? Zum einen wurden Smartphones mit der Veröffentlichung des iPhones zum Alltagsgegenstand. Noch wesentlicher waren die Auswirkungen auf Unternehmen:

• Neue Märkte und Geschäftsmodelle: Schnell entdeckten die Konsumenten, wie Apps ihren Alltag erleichterten. Das wiederum schaffte einen neuen Markt und neue Geschäftsmodelle für App-Entwickler und führte zu zahlreichen Firmengründungen
• Erschließen neuer Vertriebswege und Channels, um Kunden zu erreichen.
• Unternehmen riefen eine „Mobile First Strategie“ aus. Webseiten mussten „responsive“ werden, um auch auf Mobilgeräten optimal dargestellt zu werden.
• Booster der Digitalisierung.

Die eigentliche Beschleunigung der Digitalisierung kam in dem Moment, als ein begeisterter Smartphone-User sich fragte, warum sich nicht auch an seinem Arbeitsplatz alles so einfach über Apps organisieren ließe. Also ging er zu seinem Chef und fragte, warum es denn noch keine Smartphones und Tablets für Mitarbeiter gäbe. Damit könnte man doch die vielen kleineren und größeren Aufgaben mit intuitiven Apps erledigen, anstatt wie bisher mit Papier oder bestenfalls PCs. Außerdem könnte man viel Geld sparen: Es müsse keine teure Software für PCs beschafft und gewartet werden. Apps nutzen die Cloud und brauchen kein unternehmenseigenes Rechenzentrum mit teuren Servern und spezialisierten und raren Administratoren. Und während Schulungen für die meisten Business-Anwendungen obligatorisch, aber auch teuer waren, fragte kaum jemand nach einer Schulung für eine App.

Ähnliche Entwicklung bei ChatBots?

Man braucht nicht viel Fantasie, um sich den Moment vorzustellen, in dem der damalige Mitarbeiter des Monats, der den Anstoß zu Apps für Unternehmensprozesse gab, wieder im Büro seines Chefs steht. Nur dürfte er dieses Mal fragen, warum es eigentlich nicht möglich ist, auf das verteilte Wissen im Unternehmen über einen Chatbot-Prompt zuzugreifen und dabei auch gleich mehrere alternative Handlungsempfehlungen als Antwort zu erhalten.

Die Notwendigkeit eines eigenen ChatBots

Auf die Frage, ob sie Seelsorgern empfehlen würde, Predigten von Künstlicher Intelligenz schreiben zu lassen, antwortete die Ratsvorsitzende der Evangelischen Kirche in Deutschland gemäß der Berliner Morgenpost: „Jede gute Idee, jeder kluge theologische Gedanke ist hilfreich. Egal, woher sie kommen. Aber sie müssen durchs eigene Herz gehen.“

Jetzt dürfte es für Gläubige verwirrend werden, wenn der evangelische Pastor in seiner mit ChatGPT erstellten Predigt Gedanken vertritt, die der Auslegung einer anderen Glaubensgemeinschaft folgt. Ohne dieses Beispiel vertiefen oder bewerten zu wollen: Es zeigt die Notwendigkeit, dass ein Chatbot manchmal bei Antworten ausschließlich auf Informationen des eigenen Unternehmens zurückgreifen darf.

Außerdem müssen Unternehmen die Zusicherung haben, dass das, was der Chatbot lernt, auch nur Benutzern im eigenen Unternehmen zugänglich gemacht wird. Firmen wie OpenAI/Microsoft dürfte das längst bewusst sein. Schließlich wäre der Erfolg einer Public Cloud wie Microsoft Azure kaum denkbar gewesen, wenn die Daten, die Unternehmen in dieser Cloud verarbeiten, öffentlich verfügbar wären. Ähnlich muss auch der Chatbot einen unternehmensinternen und abgesicherten Modus ermöglichen.

Gedanken, die durchs Herz gehen müssen

Zum Zeitpunkt der Erstellung dieses Artikels, Ende April 2023, stellt die Verwendung von ChatGPT eine wesentliche Anforderung an  Benutzer: Sie müssen „Herz und Verstand“ gebrauchen können. Warum? Allzu häufig neigt der Chatbot zu „Halluzinationen“. So bezeichnet man eine überzeugend richtig klingende Antwort einer KI, die tatsächlich aber falsch ist. Warum das so ist, erklärt ChatGPT selbst, wenn man „es“ fragt, wie „es“ funktioniert:

Vereinfachend gesagt: Bei seinen Antworten hat ChatGPT gut und glaubhaft geraten.

Daraus folgt, dass Anwender die Fähigkeit brauchen, wahr von unwahr zu unterscheiden. Auch wenn wir in den vergangenen Jahren aufgrund der Zunahme von Fake-News ausreichend Möglichkeiten hatten, das zu trainieren, so bleibt beim Ausbau dieser Fähigkeit noch einiges zu tun. Entsprechende Skills werden auch im beruflichen Umfeld immer wichtiger werden.

Ausblick

Auf die Frage, wie es funktioniert, antwortet ChatGPT im Nachsatz:

Um diese starke Aussage zu stützen, dokumentieren die Autoren auf 155 Seiten unter anderem, aufgrund welcher konkreten Anfrage GPT-4 welches verblüffende Ergebnis lieferte.

Als Beispiel, dass laut der Autoren „GPT-4 mehr gesunden Menschenverstand zeigt als frühere Modelle“, wurde dieser Prompt verglichen:

„Hier haben wir ein Buch, 9 Eier, einen Laptop, eine Flasche und einen Nagel. Bitte sag mir, wie man sie stabil aufeinanderstapelt.“

Die Antwort von ChatGPT auf der Basis GPT-3.5 führt noch zu einem Schmunzeln:

• Platziere die Flasche auf einer flachen Oberfläche.
• Balanciere vorsichtig den Nagel auf der Flasche.
• Lege die Eier auf den Nagel und achte darauf, dass sie ausbalanciert sind und nicht zur Seite kippen.
• Platziere den Laptop auf den Eiern, achte wieder darauf, dass er ausbalanciert ist und nicht zur Seite kippt.
• Lege schließlich das Buch auf den Laptop

Dieser Stapel ist möglicherweise nicht sehr stabil, daher ist es wichtig, vorsichtig damit umzugehen. Alternativ könntest du versuchen, die Objekte in einer anderen Reihenfolge zu stapeln oder einige der Objekte als Stützen für andere zu verwenden, um einen stabileren Stapel zu schaffen.

Verblüffend dann die Antwort von GPT-4:

Eine mögliche Art, die Objekte stabil übereinander zu stapeln, ist:

• Lege das Buch flach auf eine ebene Fläche wie einen Tisch oder den Boden. Das Buch wird als Basis des Stapels dienen und eine große und stabile Unterstützung bieten.
• Ordne die 9 Eier auf dem Buch in einem 3 mal 3 Quadrat an, wobei du etwas Platz zwischen ihnen lässt. Die Eier bilden eine zweite Schicht und verteilen das Gewicht gleichmäßig. Stelle sicher, dass die Eier nicht gebrochen oder beschädigt sind, und behandle sie vorsichtig, um ein Fallen zu vermeiden.
• Platziere das Laptop auf den Eiern, mit dem Bildschirm nach unten und der Tastatur nach oben. Der Laptop wird passgenau innerhalb der Begrenzungen des Buches und der Eier sitzen, und seine flache und starre Oberfläche wird eine stabile Plattform für die nächste Schicht bieten. Stelle sicher, dass der Laptop geschlossen und ausgeschaltet ist, und drücke keine Tasten oder Knöpfe.
• Platziere die Flasche auf dem Laptop, mit dem Deckel nach oben und dem Boden nach unten. Die Flasche wird dem Stapel etwas Höhe und Balance verleihen, und ihre zylindrische Form wird die Kontaktfläche mit dem Laptop reduzieren. Stelle sicher, dass die Flasche leer und geschlossen ist, und schüttle oder kippe sie nicht.
• Platziere den Nagel auf dem Flaschendeckel, mit der spitzen Seite nach oben und der flachen Seite nach unten. Der Nagel wird das letzte und kleinste Objekt im Stapel sein, und seine scharfe Spitze wird verhindern, dass er vom Flaschenhals rollt oder rutscht. Stelle sicher, dass der Nagel sauber und gerade ist, und berühre oder bewege ihn nicht.

Die Autoren gehen so weit zu sagen, dass GPT-4 bereits eine „frühe, aber immer noch unvollständige Version einer AGI“ sei. AGI steht für „Artificial General Intelligence“ (zu deutsch: künstliches Allgemeinsystem). Es bezeichnet eine KI, die in der Lage ist, eine Vielzahl von intellektuellen Aufgaben zu lösen, die normalerweise von einem menschlichen Verstand bewältigt werden können. Im Gegensatz zu einer spezialisierten künstlichen Intelligenz, die darauf ausgelegt ist, eine bestimmte Aufgabe zu erfüllen, soll eine AGI in der Lage sein, verschiedene komplexe Aufgaben zu bewältigen, ohne dass eine spezifische Programmierung oder Anpassung erforderlich ist.

Zum Zeitpunkt der Veröffentlichung dieses Artikels war GPT-4 bereits für zahlenden Anwender von „ChatGPT Plus“ verfügbar.

The genie is out of the bottle: Was bedeutet das für Unternehmer?

Klar, es gibt Unternehmen, die ganz offensichtlich den iPhone-Moment ignoriert haben. Der war im Jahr 2007. Doch über 15 Jahre danach gibt beispielsweise noch Versicherungsunternehmen, bei denen Kunden vergeblich nach einer Möglichkeit suchen, über ihr Smartphone oder Tablet eine Schadensabwicklung anzustoßen. Dass Versicherer, die mit der Digitalisierung nicht mehr in den Kinderschuhen stecken, eine höhere Kundenzufriedenheit erreichen, liegt auf der Hand. Außerdem dürften sie durch die Digitalisierung Kosten sparen. Dadurch haben sie den Spielraum, einen Teil der Einsparungen zu nutzen, um über günstigere Prämien mehr Neukunden zu gewinnen.

So wie das Definieren und Umsetzen einer Digitalisierungsstrategie Unternehmen fit für die Zukunft gemacht hat, so wird es jetzt auch bei der Berücksichtigung von Chatbots und ganz allgemein von AI in der Unternehmensstrategie sein. Außerdem braucht es unternehmensinterne Richtlinien, wie Mitarbeiter diese Tools nutzen. Viel Zeit bleibt Unternehmen nicht. Auch wenn manche den Impuls verspüren, ChatGPT zu verbieten, so gleicht das dem Versuch, den Geist schnell wieder zurück in die Flasche zu drücken.

Über den Autor

Sie wollen auf meine Erfahrung zurückgreifen?

Dann freue ich mich auf Ihren Kontakt.

You will find this article in english below.

Organisationen: Traditionell vs. agil

In Verbindung mit der digitalen Transformation liest man häufig auch von der Notwendigkeit einer Transformation der eigenen Organisation. Ziel ist eine agile Organisation.

Was ist darunter zu verstehen? Was unterscheidet traditionelle Organisationsformen und Methoden von agilen? Wie unterscheidet sich die Arbeit insbesondere bei der Produktentwicklung und einführung, z. B. für eine Software? Wie unterscheidet sich im Fall von Software der spätere IT-Betrieb?

In diesem Artikel möchte ich auf diese Fragen eingehen und die Stärken und Schwächen beleuchten, aber auch die Herausforderungen, die sich nach meiner Erfahrung durch agile Methoden für Organisationen ergeben.

Traditionelle Modelle

Wasserfallmodell

Abbildung 1 Schema des Wasserfallmodells nach Paul Hoadley, Paul Smith und Shmuel Csaba Otto Traian, CC BY-SA 3.0

An der Abarbeitung einer Phase sind häufig, ähnlich wie bei Gewerken bei einem Hausbau, spezialisierte Mitarbeiter beteiligt:

• bei den Beschreibungen der Anforderungen, häufig in Form eines Lastenhefts, Mitarbeiter und spätere Anwender aus den betroffenen operativen Bereichen ggf. unterstützt durch Arbeitskreise und Berater,
• im Entwurf IT-Architekten, die zumeist ein Pflichtenheft und einen Architekturentwurf erstellen, auf dessen Basis häufig ein Festpreisangebot abgegeben und Werkvertrag mit dem implementierenden Dienstleister geschlossen wird,
• in der Implementation Entwickler, die die Lösung auf Basis des Pflichtenhefts und ggf. ergänzenden Informationen der IT-Architekten programmieren,
• in der Überprüfung Tester des implementierenden Dienstleisters mit nachfolgenden Integrations- und Abnahmetests durch den Auftraggeber, an dem dann die Mitarbeiter beteiligt sind, die die Anforderungen beschrieben haben. 

Übergreifend koordiniert werden diese Phasen und Mitarbeiter durch einen Projektleiter. Erfolgt die Implementation durch Entwickler des eigenen Unternehmens, so sind die Mitarbeiter häufig in einer Matrix organisiert und temporär dem Projektleiter fachlich zugeordnet. 

Klassischer IT-Betrieb

Der klassische IT-Betrieb folgt häufig den Grundsätzen von ITIL. ITIL ist eine Sammlung von Best-Practice-Ansätzen und beschreibt Prozesse, Funktionen und Rollen zum Betrieb von IT-Infrastruktur.

Im klassischen IT-Betrieb hat der zuverlässige und störungsfreie Betrieb die oberste Priorität. Viele Organisationen setzen dabei ITIL dahingehend um, dass die Entwicklung und der IT-Betrieb organisatorisch und disziplinarisch voneinander getrennt sind. Neue Softwarereleases werden in geplanten Zyklen nach eigenen Tests durch Mitarbeiter des IT-Betriebs in produktiven Umgebungen bereitgestellt. Je nach Organisation wird monatlich oder einmal im Quartal ein neues Release bereitgestellt. In Abstimmung mit dem oder den Projektleitern wird festgelegt, welche Funktionen (Features) in ein Release aufgenommen werden. Die Erstellung des Release folgt zumeist dem Wasserfallmodell.

Agile Modelle 

Scrum / Kanban 

Scrum, als Beispiel für ein verbreitetes agiles Framework, kennt ebenfalls die Tätigkeiten der Anforderungsdefinition, des Entwurfes, der Implementation und der Überprüfung. Allerdings durchläuft nicht das gesamte zu erstellende Gewerk einmal diese Phasen wie im Wasserfallmodell in einem Stück, sondern die Anforderungen werden in mehreren Schritten, sogenannten Sprints, realisiert. Das zu entwickelnde Werk oder die zu erstellende Softwarelösung wird als Produkt betrachtet. Hierbei übernimmt der „Product Owner“ sowohl fachliche als auch budgetäre Verantwortung.

Scrum folgt einem empirischen Ansatz mit den Säulen Transparenz, Überprüfung (Inspect) und Anpassung (Adapt). Das, was man durch regelmäßige Überprüfungen lernt, fließt in Form von Anpassungen in die weitere Produktentwicklung ein. Bei der Überprüfung wird ausdrücklich das Feedback von Kunden berücksichtigt, um das Produkt tatsächlich an den aktuellen Anforderungen des Marktes auszurichten. Außerdem stützt sich Scrum auf die Grundsätze von Lean Thinking, wozu das „Pull-Prinzip“ gehört und das Ziel, Verschwendung zu vermeiden. Der Scrum-Guide ist hier verfügbar.

Das Produkt wird gemeinschaftlich von einem Scrum-Team realisiert. Zum Scrum-Team gehört der Product Owner, das Entwicklerteam und ein „Scrum Master“.

Der Scrum Master ist kein klassischer Projektmanager, sondern eher ein „Facilitator“ für das Scrum-Team. Seine Hauptaufgabe besteht darin, sicherzustellen, dass das Scrum-Team das Scrum-Framework und den empirischen Ansatz korrekt versteht und erfolgreich anwendet. Insbesondere fördert er das Team in der Fähigkeit zur Selbstorganisation. Er hält dem Team auch „den Rücken frei“, indem er dort, wo Engpässe oder Hindernisse (Impediments) entstehen, sich Team-intern und -extern eine Lösung fördert.

Das Entwicklerteam besteht aus Architekten, Entwicklern und Testern. Das Team verfügt über alle erforderlichen Fähigkeiten und Mittel (Ausstattung, Werkzeuge), um das Produkt realisieren zu können.

Zu Beginn der Produktentwickler erstellt der Product Owner gemeinsam mit den Anforderern (Stakeholdern) das sogenannte Product Backlog, eine grobe Liste der Anforderungen. Der Product Owner kommunizierte auch mit Stakeholdern, die nicht nur fachliche Anforderungen an das Produkt haben, sondern in jeglicher Hinsicht Einfluss auf das Produkt nehmen (z. B. Datenschutz, IT-Security, Rechtsabteilung).

Nachdem das Produkt Backlog durch den Product Owner priorisiert wurde, kann die eigentliche Umsetzung beginnen. Das Produkt wird nun schrittweise in sogenannten „Sprints“ realisiert, wie in Abbildung 2 gezeigt. Ein Sprint dauert zwischen zwei und vier Wochen. Danach beginn der Zyklus von Neuem. Inzwischen wurden weitere Anforderungen beschrieben und im Product Backlog priorisiert. Der empirische Ansatz ermöglicht es nun, flexibler (agiler) als im klassischen Wasserfallmodell noch während der Produktentwicklung Anpassungen vorzunehmen, um ein marktgerechtes Produkt entstehen zu lassen.

Ein Sprint ist vergleichbar mit einem Teilprojekt. Zu Beginn eines Sprints plant das Scrum-Team gemeinsam den Umfang des kommenden Sprints. Der Product Owner bringt dazu den Vorschlag für ein Sprint-Ziel ein. Das Entwicklerteam wählt aus dem Product Backlog zum Sprint-Ziel passende Einträge und übernimmt diese in das vom Entwicklerteam gemeinsam verantwortete Sprint Backlog. Nach dem gemeinsamen „Commitment“ des Entwicklerteams zum Sprint-Ziel und dem geplanten Sprint Backlog, beginnt die Realisierung.  

Typisch für Scrum ist, dass sich das Entwicklerteam täglich zu einem kurzen, maximal 15-minütigem Meeting trifft, in dem es die Arbeit für den aktuellen Tag abstimmt und eventuelle Hindernisse anspricht.

Am Ende jedes Sprints steht ein betriebsbereites Produktinkrement zur Verfügung, das die geplanten Anforderungen erfüllt. Das Scrum-Team präsentiert dieses Produktinkrement während des sogenannten Sprint-Reviews den Stakeholdern. Während dieses Meetings gibt der Product Owner außerdem einen Überblick über die gesetzten Prioritäten und die Zielsetzungen für den kommenden Sprint. Die Sprint-Review dient somit nicht nur als bloße Demonstrationsveranstaltung, sondern fungiert als interaktives Arbeitsmeeting für das Scrum-Team und die beteiligten Stakeholdern. Idealerweise nehmen daran auch Kunden teil. Die Sprint Review setzt also die empirischen Säulen von Scrum Transparenz, Überprüfung und Anpassung um.

Um die Zusammenarbeit des Scrum-Teams zu verbessern, trifft sich dieses unter Anleitung des Scrum-Masters am Ende des Sprints (Sprint Retrospektive, Lessons learned). Auch dieses Meeting dient zur Überprüfung und hat Anpassung zum Ziel.

Zur Steuerung der Aufgaben des Teams wird Scrum häufig mit Kanban kombiniert. Dieser ursprünglich aus der Automobilfertigung stammende Ansatz wurde auf die Softwareentwicklung übertragen. Die einzelnen Aufgaben werden dabei auf Kanban-Karten notiert und durchlaufen die Softwareproduktion. Als einzelne Produktionsbereiche gelten dabei zumeist Design, Test-Preparation, Development, Test und Deployment. Die Produktion erfolgt typisch für Kanban nach dem Pull-Prinzip. Nachfolgende Produktionsbereiche fordern bei freien Kapazitäten beim vorausgehenden Produktionsbereich neue Aufgaben an. Ein Prinzip von Kanban ist, den Fluss der Arbeit zu visualisieren. So ist auf dem Kanban-Board erkennbar, wie vielen Aufgaben in welchem Produktionsbereich stecken (WiP/Work in Progress). So werden Engpässe in einzelnen Bereichen leichter erkennbar, wodurch der Prozess der Realisierung der Features optimiert werden kann. 

Neben Features werden auch Bugs auf Kanban-Karten notiert und durchlaufen ebenso den gesamten Prozess.

Continuous Integration, Continuous Delivery und DevOps

Auf der Basis von agilen Methoden wie Scrum und Extreme Programming haben sich Konzepte etabliert, die eine kurzfristige und doch hohen Qualitätsansprüchen genügende Bereitstellung von Software ermöglichen. Das Konzept der Continuous Integration beschreibt Prozesse, Grundsätze und Anforderungen an Werkzeuge, um fortlaufend und mit einem hohen Automatisierungsgrad qualitativ hochwertige Software zu erstellen. Automatisiert meint dabei nicht, dass die Programmierung selbst automatisiert erfolgt. Diese Tätigkeit obliegt nach wie vor Entwicklern. Die Continuous Integration automatisiert jedoch den Prozess, der aus dem Quellcode eine neue Programmversion des Softwareprodukts baut (Software Build).

Ein wesentliches Element sind dabei automatisierte Tests, sogenannte Unittests. Als Grundlage für einen Unittest dienen Business Cases, die durch den jeweiligen Fachbereich beschrieben werden. Ein Business Case beschreibt einen konkreten Geschäftsvorfall, beispielsweise: 

Der Mitarbeiter Müller aus der Niederlassung 0815 erfasst am 15.01.2016 für die Sendung 4711 eine Retoure an den Versender aufgrund einer Annahmeverweigerung durch den Empfänger. Erwartet wird dabei, dass der Mitarbeiter durch die Software einen Fehlerhinweis erhält, da in der Datenbank bereits dokumentiert ist, dass die Zustellung der Sendung am 14.01.2016 erfolgte. 

Der Entwickler verwendet den Business Case, um ein kleines Testprogramm zu schreiben. Dieses ruft die Softwarefunktion oder Methode (z. B. eine API-Funktion) auf, die durch den Test überprüft werden soll und durch den beschriebenen Business Case genutzt wird. Dabei nutzt er die konkreten Informationen aus dem Business Case als Parameter für den Funktionsaufruf. Da der Business Case auch das erwartete Ergebnis definiert, kann das Testprogramm dieses mit der tatsächlichen Rückgabe der getesteten Funktion vergleichen. Stimmen erwartetes und tatsächliches Ergebnis überein, so ist der Test erfolgreich, andernfalls fehlerhaft. 

Während der automatischen Erstellung eines Software Builds werden alle Unittests durchlaufen. Nur wenn alle Unittests erfolgreich abgeschlossen werden konnten, steht eine neue ausführbare Programmversion zur Verfügung.

Das Konzept der Continuous Delivery führt den Prozess der Continuous Integration fort und beschreibt Techniken und Prozesse, wie neue Programmversionen in kurzen Zyklen für die stabile produktive Nutzung bereitgestellt werden.

Zur Umsetzung von Continuous Delivery beschreibt der DevOps-Ansatz eine entsprechende Philosophie und einen organisatorischen Rahmen. Der Kern liegt darin, wie die Zusammenarbeit zwischen den Entwicklern (Dev) und dem IT-Betrieb (Ops) verbessert werden kann. In klassischen Organisationen sind diese beiden Abteilungen voneinander getrennt und verfolgen kollidierende Ziele: die Entwickler möchten möglichst kurzfristig und häufig neue Programmversionen an den Endanwender ausliefern, um Bugfixes und neue Funktionen bereitzustellen; der IT-Betrieb möchte möglichst selten Änderungen an der produktiven Umgebung, da jede Änderung das potentielle Risiko trägt, den IT-Betrieb zu stören. Der DevOps-Ansatz fördert dabei eine Kultur, die die Zusammenarbeit zum Nutzen des Endanwenders verbessert, ohne Risiken für den stabilen IT-Betrieb zu erhöhen. Das Softwarearchitekturmodell der Microservices legt dabei eine technische Grundlage, um auftretende Fehler und Störungen im Betrieb zu begrenzen und optimal zu behandeln. 

Vergleich der Modelle 

Welches Vorgehensmodell für welches Projekt besonders geeignet ist, um zuverlässig und kosteneffizient die Projektziele zu erreichen, hängt insbesondere von der Komplexität des Projekts ab und der an dem Projekt beteiligten Persönlichkeiten. 

Der Komplexitätsforscher Ralph Douglas Stacey hat für zunehmende Komplexität zwei Treiber identifiziert: Uneinigkeit und Unsicherheit. Übertragen auf ein IT-Projekt bedeutet das, dass wenn Einigkeit zu Vorgehen, Ressourcen und Budget besteht und man genau weiß, was man möchte und keine offenen Punkte bestehen, das Projekt als einfach eingestuft werden kann. In Projekten, in denen Uneinigkeit und Unsicherheit höher ist, steigt die Komplexität bis hin zu chaotisch, wobei chaotisch in diesem Fall nicht negativ zu deuten ist. Welche Komplexität ein Projekt besitzt, wird durch das Projekt selbst, seine Rahmenbedingungen und die Beteiligten bestimmt. Eine hohe Komplexität lässt sich nicht immer vermeiden. Die Unsicherheit wird häufig dadurch getrieben, indem zwar eine Vision von dem finalen Produkt existiert, aber der konkrete Weg zur Realisierung unklar ist und mitunter auch experimentell vorgegangen werden muss. Der Umfang oder die Dauer des Projekts gilt nach diesem Modell nicht als Treiber für Komplexität. Demnach kann der Bau einer großen Anlage, der mehrere Monate in Anspruch nimmt, als kompliziert eingestuft werden, sofern die Faktoren Uneinigkeit und Unsicherheit gering sind.

Das Wasserfallmodell ist insbesondere für Projekte geeignet, die den Komplexitätsgrad einfach oder kompliziert haben, agile Methoden für komplex und chaotisch.

Die Erfahrungen mit agilen Methoden haben gezeigt, dass sich damit kurze bis sehr kurze Produktzyklen mit einer dennoch hohen Qualität realisieren lassen. Sie empfehlen sich, wenn nicht im Detail frühzeitig geplant werden kann, wie das zu erstellende Produkt final aussehen soll (hohe Unsicherheit). Dies wird auch durch den Vergleich der Wertschöpfungskurven der beiden Modelle deutlich (Abbildung 4).

Die graue Linie gibt den Verlauf bei einem klassischen Vorgehensmodell wieder, die orange bei einem agilen Vorgehen. Aufgrund der häufigen Iterationen z. B. in Form von Sprints, entsteht bei der Anwendung von agilen Methoden bereits früh ein erstes Produktinkrement, z. B. in Form eines Klick-Dummys. Die Iterationen ermöglichen es auch, für jede Iteration/jeden Sprint die Anforderungen nachzujustieren. Bei Abschluss des Projekts erhält man so ein Produkt, das den Anforderungen entspricht, die erst zuletzt festgeschrieben wurden. So können praktische Erfahrungen berücksichtigt werden, die während des Projektverlaufs gewonnen wurden. In der Grafik entspricht daher das Produkt den Anforderungen, die zum Zeitpunkt tx definiert wurden.

Klassische Vorgehensmodelle beginnen mit einer längeren Analyse- und Planungsphase. Dazu werden früh im Projekt, in der Grafik zum Zeitpunkt t1, die Anforderungen festgeschrieben, z. B. in Form eines Pflichtenhefts. Entsprechend entspricht das fertige Produkt am Ende des Projekts den Anforderungen zum Zeitpunkt t1. 

Die Vorteile der klassischen Methoden werden häufig in einer vermeintlichen Kostensicherheit gesehen: Da zum Zeitpunkt t1 der Funktionsumfang festgeschrieben wird, kann ein Dienstleister den Aufwand zur Umsetzung schätzen und ist in der Lage ein Festpreis anzubieten. Dieser Festpreis wird jedoch in der Praxis nicht selten überschritten, da zum Zeitpunkt t1 Anforderungen übersehen wurden, noch nicht bekannt waren oder erst durch den Fortschritt der Zeit im Projekt hinzukamen. Diese Änderungen erhöhen dann in Form von Projektnachträgen die Kosten. 

Kostensicherheit kann in agilen Projekten durch den „Design-to-Budget“-Ansatz sichergestellt werden. Vor jeder Iteration/jedem Sprint definiert der Product Owner ein Budget und stimmt mit dem Team/dem Dienstleister ab, welche Features in diesem Rahmen realisiert werden können. Dies fördert eine Kosten-Nutzen-Abwägung einzelner Funktionen und berücksichtigt das Pareto-Prinzip. Dieses besagt, dass 80 % des Ergebnisses mit 20 % des Gesamtaufwands erreicht werden, wohingegen die verbleibenden 20 % der Ergebnisse 80 % der Kosten verschlingen. Durch eine zielgerichtete Kosten-Nutzen-Abwägung wird häufig deutlich, dass nicht immer eine 100 %-Lösung erforderlich ist, die alle Anforderungen berücksichtigt. Das trägt direkt dazu bei, dass ein Produkt früher verfügbar ist und zu geringeren Kosten. Dabei ist nicht ausgeschlossen, dass zu einem späteren Zeitpunkt weitere Anforderungen umgesetzt werden, die dann jedoch die Erfahrungen berücksichtigen können, die durch die zwischenzeitliche Nutzung des Produkts gewonnen wurden.

Eine Herausforderung in der Anwendung von agilen Methoden besteht jedoch in dem höheren erforderlichen Reifegrad der beteiligten Personen und Organisationen. So hat bei Scrum das Team eine höhere Freiheit in der Umsetzung aber damit auch eine höhere Verantwortung. Außerdem organisiert sich das Team selbst. Beides setzt voraus, dass die Teammitglieder hierzu bereit sind. 

Außerdem erfordert Scrum auch von dem Auftraggeber/dem Investor eine höhere Risikobereitschaft, da nicht vor Start eines Projekts exakt definiert ist, zu welchen Kosten und in welcher Zeit das Produkt erstellt werden kann. 

Fazit 

Grundsätzlich besteht nicht in jedem Projekt die Pflicht, dieses nach agilen Methoden zu bearbeiten. Aufgabenstellungen, die den Komplexitätsgrad einfach bis kompliziert haben, können erfolgreich mit einer klassischen Planung und Durchführung gelöst werden.

Die digitale Transformation stellt Organisationen vor Herausforderungen – bietet aber auch die Chance, neben neuen Technologien einen Wandel der Unternehmenskultur hin zu einer agilen Organisation zu vollziehen. Die meisten externen IT-Dienstleister und einige unternehmensinterne IT-Abteilungen arbeiten bereits mit agilen Methoden. Das vollständige Potential können agile Methoden jedoch nur entfalten, wenn der gesamte Prozess zur Entwicklung und Einführung eines neuen Produkts agile Methoden nutzt – nicht nur der Teil, der durch die IT bearbeitet wird. 

Dabei lassen sich Organisationen nicht per Schalter auf agil umstellen – dies ist ein Reifeprozess. Mitarbeiter und Manager benötigen Zeit, um Vertrauen in agile Methoden zu fassen und Praxis und Sicherheit in der Anwendung zu gewinnen. In diesem Prozess können sie zumindest anfänglich durch einen externen Berater unterstützt werden, der in der Anwendung agiler Methoden erfahren ist.

Sie wollen auf meine Erfahrung zurückgreifen? 

Dann freue ich mich auf Ihren Kontakt.