(Entwurf, wird fortgesetzt)
Die Älteren unter uns erinnern sich an Schlagzeilen über krachend scheiternde Großprojekte für die Einführung einer Unternehmenssoftware. Solche Schlagzeilen liest man inzwischen seltener. Woran liegt das? Hier meine Erkenntnisse auf der Basis eigener Erfahrungen:
1. Make vs. Buy
Treiber für Großprojekte sind oft die Ablösung einer sehr alten Kernprozess Software oder der Unterstützungsbedarf für neue Kernprozesse. Da gibt es 40 Jahre alte Kernsysteme, die im Unternehmen oder der Behörde selbst entwickelt wurden. Und der letzte, der den umdokumentierten Code noch kennt und versteht, geht bald in den Ruhestand. Wenn die IT einer Leitung unterstellt ist, die von IT und Software nicht allzu viel besteht, sucht man hier vorzugsweise nach einer anpassbaren Kauflösung. Das gilt auch für den Neubedarf einer Software, wenn die Organisation neue Geschäftsprozesse einführt.
Das Problem mit Kauflösungen ist, man muss sie bei der Implementierung anpassen. Denn kein Unternehmen will seine Kernprozesse vollständig an eine Out-of-the-box Lösung eines Anbieters anpassen. Wenn der Kernprozess wettbewerbsrelevant ist würde das Unternehmen damit Wettbewerbsvorteile verspielen.
Anpassen heißt im besten Fall: Konfiguration. Was mit der Anpassung von Eingabemasken anfing, dreht sich heute um die Gestaltung ganzer Abläufe und die Nutzbarkeit bestehender Datenstrukturen. Aber schon hier braucht man geschultes Personal, das sich mit dem zu konfigurierenden Produkt wirklich auskennt. Ich habe in meiner frühen Zeit als IT-Berater erlebt, dass IT-Unternehmen nur ungern vorab in die Ausbildung ihrer Spezialisten investierte, sondern erst tat, wenn das Projekt wirklich beauftragt war.
=> Risiko Nr. 1: Ungeschultes Personal für das Customizing von Standardsoftware.
Reicht die Anpassbarkeit über die Konfiguration nicht aus, kommt die Frage nach der Umprogrammierung: Gibt es Mittel, den Code des Produktes selbst zu ändern um zu einer individuellen Lösung zu kommen? Auch solche Wege gibt es heute, aber man übernimmt hier sehr viel Selbstverantwortung. Man riskiert z. B. aus der automatisierten Wartung des Systems herauszufallen und Aktualisierungen künftig selbst mit eigenem Knowhow und Aufwand bewerkstelligen zu müssen.
=> Risiko Nr. 2: Unterschätzung des mittel- und langfristigen Risikos einer Codeanpassung
Wenn man sich diese Risiken klar macht, kommt die Entwicklung einer eigenen Anwendung im Haus vielleicht doch in Betracht und ist zu bewerten. Der Vorteil, wenn man es hinbekommt, ist natürlich, dass sich das Softwareprodukt an die Anforderungen der eigenen Prozesse anpasst und anpassbar bleibt. Amazon ist ein sehr gutes Beispiel für ein digitales Unternehmen, dass seine Software von Anfang selbst entwickelt hat (bzw. entwickeln ließ). Prozesse sind dort im hohen Maße nicht nur digitalisiert sondern auch automatisiert. Und genau daraus zieht das Unternehmen große Wettbewerbsvorteile. Das Risiko besteht natürlich darin, dass sich das Unternehmen auf sich selbst verlassen muss und entsprechend qualifiziertes Personal braucht.
=> Risiko Nr. 3: Eigenentwicklung erfordert langfristige Selbstverpflichtung und Verfügbarkeit von sehr guten Spezialisten. Und ein IT-Verständnis im Top-Management.
Anmerkung: Jeff Bezos hat meines Wissens nie mit seiner Ahnungslosigkeit in Sachen IT kokettiert.
Fazit: Eine Kauflösung empfiehlt sich aus meiner Sicht um so mehr, je standardisierter und je weniger wettbewerbsrelevant der Prozess ist. Zumindest muss man in der Lage sein, solche Prozesse aus dem Gesamtgefüge herauszulösen, so dass man diese entsprechend abdecken kann. Produktentwicklung ist m. E. ein Beispiel, das sich schwer mit Standardprodukten umsetzen lässt.
2. Methodiken
Was sich zwischen 2000 und 2010 dramatisch verbessert hat, sind m. E. die Methoden. Disziplinen wie Anforderungsmanagement, Architekturmanagement, agile Entwicklung haben Struktur in das Chaos gebracht. Es hat auch das Anforderungsprofil an die Projektmitglieder weit aufgefächert.
Lastenhefte waren früher nur für Eingeweihte lesbar. Und sie waren ein Absicherungsdokument für den Auftraggeber. Das einzige Qualitätsmerkmal das sie fast immer erfüllten, war das der Vollständigkeit. Alles was wichtig war, stand irgendwo. Aber basierte auf tausend unausgesprochenen Annahmen und nicht immer in dem Kapitel, wo man es vermutet hätte. Schon wenn der Auftragnehmer die Auswertung (die "Exegese") des Lasterhaftes auf mehrere Mitarbeiter, seine Spezialisten, verteilte, bestand das Risiko, etwas wichtiges zu übersehen.
Ich glaube ähnlich verhielt es sich mit Pflichtenheften des Auftragnehmers. Hier versuchte sich dieser gegenüber dem Kunden abzusichern. Wir werden Ihre Anforderungen so und so umsetzen. (Wenn Sie etwas daran stört, sagen Sie es. Schweigen ist Zustimmung.)
Heute gehen wir anders, aber ganz anders an diese Disziplin heran. Heute entwickeln wir auf beiden Seiten erstmal ein Gesamtverständnis vom Produkt und seinem Zweck. Wozu willst Du etwas tun können? Um was zu erreichen? Aha, darauf willst Du hinaus. Aber da haben wir eine viel schlankere Lösung, als Du zuerst vorgeschlagen hast. Gut, dass wir vorher darüber gesprochen haben.
Der Autor des Lasterhaftes ist heute eher ein System oder Produkt Owner. Der Autor des Pflichtenheftes tendenziell ein Architekt.
Architekturmanagement ist die zweite, heute gängige Disziplin. Die Beschreibung der Produktstruktur ist der Realitätscheck für das Projekt. Welche Anforderungen werden mit welchen Produktkomponenten umgesetzt? Kaufen wir diese oder entwickeln wir sie selbst? In welcher Reihenfolge (Releases) kann das Produkt entstehen? Wie kann eine erste Version aussehen und welche Benutzergruppe wird sie bedienen?
Owner und Architekt müssen hierfür in einem ständigen Dialog sein und am besten teilen sie sich das selbe Büro (wenn wir mal wieder im Büro sind). Und dieses Büro braucht Wände, auf denen man zeichnen kann. Unsere Sprache besteht aus Worten und Diagrammen. Ich habe mit genau dieser Konstellation allerbeste Erfahrungen gemacht: "Kollege, wenn wir jetzt noch dies und das können wollen, was brauchen wir dazu?". Schon während der Kollege antwortete griffen wir beide nach einem Stift und schritten zur Wand. Und erweiterten unsere Produktskizze. Das war das erste Mal in meinem Leben, wo ich dachte: Genau so muss der Job eines Ingenieurs ablaufen. Ein kreativer Prozess aus sich ergänzenden Spezialisten mit dem Gesamtverständnis für das Spiel.
Und wenn wir uns dann über das Was, Wozu und Wie einig sind, dann können wir unsere Epics und Stories in die Implementierung geben.
Und auch hier gibt es dramatische Verbesserungen zu früher: die iterative Entwicklung mit regelmäßigen Anforderungsklärungen, Reviews und Tests. Nicht den einen großen Knall am Ende des Projektes. Scrum, Scaled Agile sind Methoden, die für meine Begriffe genau so viel Wert geschaffen haben wie manches Unternehmen.
Dieser regelmäßige Austausch zwischen Fachbereichssicht und Entwicklerteam sichert das Projekt ständig ab. Man kann dann bei der Bergbesteigung dann eigentlich nicht tiefer zurückfallen, als der Ankerpflock des letzten Releases.
Dieser regelmäßige Umgang miteinander bewirkt auch ein wachsendes Vertrauen. Und wachsendes Vertrauen öffnet die Kommunikation und reichert das Wissen über Was und Wie auf beiden Seiten an. So entsteht ein Gesamtteam, das sich mit dem Produkt und mit sich als Team identifiziert.
Es erfordert auf beiden Seiten aber auch die Bereitschaft, der anderen Seite zuzuhören und zu lernen. Entwickler empfinden den hohen Kommunikations- bzw. Meetinganteil manchmal als störend und hemmend. Aber nach einiger Zeit empfinden es meistens alle als nützlich.
Und umgekehrt: Ich kenne Prozessmenschen die sich ganz bewusst (um nicht zu sagen "selbstbewusst") von der IT abgrenzen und ein Verständnis von Delegation gegenüber der IT haben. Nein, auch der Fachbereich, der von einem Prozess und somit einem System abhängt, muss hier ein Verständnis über Möglichkeiten und Restriktionen und Zusammenhänge aufbauen. Jedenfalls im Groben.
3. Projektpersonal
Das ist der Grund, warum Softwareprojekte heute nicht nur Logiker brauchen. Sondern auch sprachlich begabte Leute. Begriffsbildung, Kontextvermittlung, die Unterscheidung zwischen Zweck und Mitteln - also eine bewusste Verwendung von Sprache und Bildern ist sehr wichtig. Hierzu gehört auch die Fähigkeit des Zuhörens. Und ich kann versichern: Hierzu hilft es auf Dauer ungemein, nicht nur Fachliteratur zu lesen, sondern auch andere Literaturgattungen. Das gleiche gilt für das gehörte Wort. Ich bin mit einer Germanistin verheiratet und ich habe unzählige Diskussionen über die Verwendung von Sprache und Begriffen ("Kommunikation?!") hinter mir ;-).
Neben der Sprache braucht es Verantwortungsbereitschaft und den Willen zum Mitdenken. Mein Verständnis der Owner - Rolle ist aus dem Produktmanagement abgeleitet. Ein 360° Blick auf das Produkt. Von allem muss ein Owner so viel verstehen, dass der die Implementierungsoptionen mitentscheiden und tragen kann. Das Team muss ihm Optionen mit Vor- und Nachteilen, auch technischen, anbieten. Ein Owner muss dann entscheiden können. Die Entscheidungen werden nie perfekt sein, das sind sie auf einem Markt nie. Die eigene Vorgehensweise muss auch immer Raum für Korrekturen lassen, bei denen man vielleicht mal Zeit verliert, aber nie das ganze Produkt.
