X

Achtung

Aktuell sind wir aufgrund von Internetproblemen unseres Providers nur eingeschränkt erreichbar. Wir bitten dies zu entschuldigen.

  • Von A nach B - Eine Case Study

Von A nach B

Das AAA-Projekt

Die erfolgreiche mittelständische und frei erfundene Firma "Allgemeine Asphaltfräsen AG" (kurz "AAA") kommt im Zuge der jährlichen Unternehmensentwicklungskonferenz zum Entschluss, die betagte selbstgestrickte IT Lösung zu erneuern. Der IT-Leiter (Herr Hagen) wird beauftragt und präsentiert bald einen Vorschlag, welcher die Zustimmung der Geschäftsführung findet: Wir halten uns an den Marktführer. Die Beweggründe sind nachvollziehbar:

Die Sehnsucht nach dem "Silver Bullet": Ich kauf mir mit dem System des Marktführers reibungslose, standort- und zeitunabhängige Zusammenarbeit zwischen Kunden, Partnern und Mitarbeitern.

Die Lizenzkosten sind zwar beträchtlich, der auf DVDs medientechnisch ausgefeilt präsentierte Funktionsumfang lässt jedoch keine Wünsche offen. In einem Workshop werden die wichtigsten Geschäftsvorfälle durchgespielt wobei auch Anwender mit einbezogen werden. Es stellt sich dabei heraus, dass aufgrund unterschiedlicher Interpretationen des Begriffs "Variantenstückliste" doch eine funktionale Differenz besteht, welche kleine Anpassungen nach sich zieht. Unverständlicherweise soll der Aufwand dafür 50 TEUR betragen, während der Programmierer des Altsystems sowas früher nebenher auf Zuruf erledigt hat. Die Frage, ob die Wertschöpfungs-Prozesse oder die Software anzupassen sind, stellt sich nicht, weil jene die Basis des Markterfolges bilden. Also spezifiziert ein Consultant die Softwareanpassung minutiös mittels UML und das Projekt wird gestartet.

Zwei Monate später: Die angepasste Version wird installiert, getestet, scheint zu funktionieren. Dann passieren aber seltsame Dinge: Material wird mehrfach abgebucht, die Projektkalkulation zeigt unplausible Zahlen, Anzahlungen reduzieren nicht den Betrag der Abschlußrechnung, der Server reagiert bisweilen minutenlang nicht mehr. Es muss ein Experte aus der Basis-Entwicklung eingeflogen werden (3000 Euro pro Tag), der schnell herausfindet, was passiert ist: offshore Juniorprogrammierer (80 Euro pro Tag) haben am System vorbei getrickst, Code von anderen Kundenprojekten kopiert und unsachgemäß angepasst, zentrale Verbuchungsschnittstellen nicht versorgt. Der Marktführer bessert nach und nach weiteren zwei Monaten fallen die Tests erfreulicher aus, alle UML-Diagramme sind abgehakt.

Vor der Datenübernahme sollen vorab die ersten Anwenderschulungen stattfinden. Der in Change-Management erfahrene Referent führt die Anwender ins neue System ein. Da die Vorgaben zur Zufriedenheit von Herrn Hagen umgesetzt waren, rechnet er mit guter Akzeptanz. Die Probleme fangen an, als Frau Wind einen Ordner holt und darum bittet, einen aktuellen typischen Vorgang am neuen System durchzuspielen. Es sind vielschichtige Probleme: manche Schritte sind nur umständlich, andere in der falschen Reihenfolge, Auswertungen fehlen, Informationen für die Vorgangsbearbeitung fehlen, verschiedene Spielarten sind überhaupt nicht abgebildet, andere widersprüchlich. Die anderen Sachbearbeiter decken weitere Defizite auf, eine Krisensitzung wird einberufen. Eine Woche lang werden alle Probleme gesammelt und kategorisiert nach Wichtigkeit und Häufigkeit des Auftretens. Die Ausbeute: 14 mal A (Showstopper bei >= 80% der Geschäftsvorfälle), 56 mal B (Showstopper bei >= 10% der Geschäftsvorfälle). Der Echtstart ist in weite Ferne gerückt, weitere geschätzte Anpassungskosten in Höhe von 100 TEUR fallen an. Wer ist schuld?

Der Anbieter hat die UML Diagramme sklavisch exakt umgesetzt, auch die kleinen Fehler, die ein mitdenkender Programmierer automatisch ausgemerzt hätte. Mit 10 TEUR Nachlass ist der Anbieter mehr als aus dem Schneider. Leider sind dem Consultant bei Erstellung der Vorgabe ein paar logische Widersprüche durchgerutscht. Vielleicht ließen die Schilderungen des IT-Leiters auch Interpretationsspielraum. Manche der spezielleren fachlichen Anforderungen waren ihm nicht vertraut. Von den 200 Seiten sind 15 bei genauerer Prüfung zu beanstanden. Nach Schulnoten wäre das immer noch ein "sehr gut".

Herr Hagen - der IT-Leiter - hat Programmierer und Anwender gefragt und auch sein ganzes Wissen eingebracht. Nur wusste er eben auch nicht alles bis ins Detail. Programme werden ständig umgeschrieben, neue Routinen erstellt, alte stillgelegt, Nutzungsschwerpunkte verschieben sich, ohne dass das sich das jedesmal im IT Logbuch niederschlägt oder gar im Gedächtnis haften bleibt. Seine Dokumentation übertrifft aber immer noch jede ISO-Norm. Auch auf dem Weg der Information von den Anwendern zum IT-Leiter trat bereits ein Verlust auf. Selbverständlich anmutende Bearbeitungsdetails bleiben unerwähnt. Die schiere Menge jahrelanger Berufserfahrung kann nicht in wenigen Tagen kommuniziert werden.

Alle zusammen vertrauten insgeheim der großen Standardsoftware. Dort würde schon alles in weiser Voraussicht vorhanden sein. Ungerechterweise haben sich zu allem Überfluss einige Abläufe seit dem Workshop bereits geändert.

Jeder Mitwirkende hat also für sich genommen gute Arbeit geleistet und es wird niemand gefeuert. Aber durch den mehrstufigen Prozess (man spricht auch vom Wasserfall-Modell) verstärkten sich die Abweichungen. Das Ziel selbst bewegte sich fort. Die erste Rückkopplung fand nach Monaten statt. Jetzt sind alle schlauer. Die IT-Leute haben viel über die fachlichen Inhalte gelernt, die Anwender über ungeahnte Möglichkeiten der neuen Software. Hätten sie diese Kenntnis früher gehabt, hätten sie ihre Anforderungen ganz anders formulieren können. Es kommt ein Selbsterkenntnisprozess in Gang. Manches erscheint jetzt suboptimal organisiert. Interessante Ideen für effizienteres Arbeiten entstehen. Das führt dazu, dass manche der ursprünglichen Anpassungen unnötig werden, andere nochmal umformuliert werden und einige neue Konzepte hinzukommen. Um auch diese eleganten neuen Ideen zu implementieren, werden weitere 50 TEUR investiert und der nächste Zyklus (Anforderung, Spezifikation, Implementierung, Test) gestartet. Es folgen noch 3 weitere zu 80, 40 und 20 TEUR bis zum Echtstart, der mit knapp einem Jahr Verspätung erfolgt.

Insgesamt fielen neben den Lizenzkosten 333 TEUR Projektkosten an, davon 283 TEUR ungeplant.

Nachdem sich der Betrieb eingespielt hat, werden die Statistiken eines Screen-Tracking Tools ausgewertet. Von allen aufgerufenen Bildschirmseiten entfallen 20% auf originale Standardfunktionen, 30% auf leicht angepasste und 50% auf umfassend modifizierte bzw. neu erstellte Programmteile.

Bevor wir die AAA jetzt zu einem Releasewechsel mit steigenden Lizenzkosten zwingen unter Verlust bzw. Neuimplementierung ihrer Anpassungen, besuchen wir die "Badischen Blechbearbeitungs Betriebe".

Das BBB Projekt

Die erfolgreiche mittelständische und frei erfundene Firma "Badische Blechbearbeitungs Betriebe" (BBB) kommt im Zuge der jährlichen Unternehmensentwicklungskonferenz zum Entschluss, die betagte selbstgestrickte IT Lösung zu erneuern. Der IT-Leiter (Herr Struve), der sich heimlich auf so Veranstaltungen wie LinuxTag, FrosCon, OpenSaar herumgetrieben hat, wird beauftragt und präsentiert bald einen Vorschlag, welcher revolutionär anmutet: Wir lassen uns eine maßgeschneiderte offene Lösung zusammenstellen. Nun ist die Geschäftsführung zwar vertraut mit Maßanzügen, für den Vorschlag von Herrn Struve erwärmt sie sich aber erst nach dessen Argumentation:

Eingedenk ihrer Vorfahren, welche die Badische Revolution starteten, stimmt die Geschäftsführung dem revolutionären Vorschlag zu. Ein Budget von 50 TEUR wird bewilligt und Herr Struve beauftragt, mit einem fähigen Dienstleister das Projekt zu wagen. Dieser ist bald gefunden und verbringt die folgenden Wochen vor Ort im Betrieb.

Statt zu programmieren schaut er den Leuten bei der Arbeit zu, auch in der Produktion und im Lager. Er läuft mit dem Klemmbrett herum, macht sich Notizen, fragt jedem ein Loch in den Bauch, stöbert in der Software, schaut sich die Ablage-Ordner an, macht sich Kopien von allen Druckformularen. Würde auf seinen Laufschuhen nicht "Brooks" stehen, wäre die Geschäftsführung verunsichert. Nach 4 Tagen (800 EUR pro Tag) ist er soweit eingearbeitet, dass er zur Not Urlaubsvertretung machen könnte.

Dann zapft er die Daten an, importiert das Schema ins Meta-Datenmodell seiner Universal Application und lässt Statistik-Auswertungen ablaufen. Das Ergebnis ist eine Relevanz-Abschätzung für die Priorisierung. In den folgenden Tagen werden Datenmodell und Daten bereinigt und konvertiert wo nötig. Dann wird das Meta-Datenmodell strukturiert: Feldgruppen zusammengefaßt, Tabellen erweitert um Infrastruktur-Felder, die vom Altsystem bekannten Funktionen als Buttons vorgesehen.

Schliesslich startet die Universal Application zum ersten Mal mit dem neuen Meta-Datenmodell. Die Bildschirmlayouts konfiguriert das System zunächst automatisch aufgrund der Relevanzinformationen (Felder mit hoher Varianz und hohem Füllgrad sind relevanter als häufig leere Felder oder solche mit überwiegend konstantem Inhalt). Mit etwas Handarbeit im regelbasierten Screen-Designer sind in kurzer Zeit die 20% der wichtigsten Module in ein den Anwendern vertrautes Format gebracht. Nachdem auch noch die zentralen Drucklayouts definiert sind und das Hauptmenu eingerichtet ist, dürfen die Anwender einen ersten Eindruck gewinnen.

Sie sehen ihre Stammdaten und Bewegungsdaten und es sieht ganz ähnlich aus. Suchen, Drucken und Navigieren geht schon. Ausserdem sind über die Universal Application jede Menge Grundfunktionen dazugekommen: Dokumenten-Management, Zuordnungen, Berechtigungssteuerung, Groupware mit Kalender und Akten, Fax/Mail/SMS/Fibu-Schnittstellen, Screen-Designer für benutzerbezogene Oberflächenkonfiguration, mächtige Suchfunktionen, eingebaute Daten- und Funktionsmodellierung, generische Übersichten, Nachschlagefunktionen.

Es ist ein lauffähiger Prototyp mit Echtdaten entstanden. Daran lassen sich wunderbar Bearbeitungsvorgänge simulieren und besprechen. Die Geschäftsführung hat sich mittlerweile informiert und versetzt Herrn Struve ins Staunen als sie anregt, nun mit dem Feature-Based Programming weiterzumachen. Gemäß der getroffenen Priorisierung werden nun die Buttons und Events mit Leben gefüllt. Dies geschieht in der eingebauten Scripting-Sprache, die Turnaround Zeit zwischen Implementieren und Testen beträgt 1 Sekunde. Nach der Hälfte des Budgets ist der Status quo des Altsystems erreicht.

Herr Hagen, befreundet mit Herrn Struve sowie IT-Leiter bei AAA welche wiederum Kunde von BBB ist, kommt zu Besuch und schaut interessiert zu, weil er auch gerade so ein Projekt laufen hat. Dass das Meta-Datenmodell so eine Art Design-Time-Repository ist, hat er schnell verstanden. Das System-Landscape-Directory sucht er vergeblich. Die vertraute Cluster-Konfiguration mit Prozess-Knoten, Dispatcher und Servern vermisst er ebenfalls. Das ganze System soll auf nur einem Rechner laufen? Wo ist überhaupt die Development-Configuration? Subversion als Change-Management-System läßt er sich noch gefallen. Aber ein sekundenschneller Klick auf "reload Scripts" soll den stundenlangen Deployment-Prozess ersetzen? Der in Change-Management erfahrene Dienstleister führt die Anwender ins neue System ein. Da er das Altsystem ausführlich studiert und nachgebaut hat, rechnet er mit guter Akzeptanz. Die Probleme fangen an, als Frau Herwegh einen Ordner holt und darum bittet, einen aktuellen typischen Vorgang am neuen System duchzuspielen. Da wird ja gar nicht das Kreditlimit geprüft! Der Dienstleister schaut im Datenmodell nach, findet das Feld, fügt in einem geheimnisvollen Eventscript 4 Zeilen ein, klickt auf "reload Scripts" und beim folgenden neu angelegten Auftrag funktioniert die Prüfung. Frau Herwegh ist zufrieden und testet weiter. Herr Hagen weint.

Die nächsten Tage sieht man den Dienstleister immer mit einer zweiten Person vorm Bildschirm sitzen. Funktionen werden getestet, diskutiert und im Dialog verfeinert, sofort wieder getestet usw. Dabei beginnt die Software bereits ein Eigenleben zu entwickeln: Wo schon Verbesserungsvorschläge existieren, wird statt der alten Funktion schon die verbesserte implementiert. Nachdem alle wichtigen Abläufe zur Zufriedenheit funktionieren, werden die Daten nochmal übernommen und der Echtbetrieb gestartet. Im integrierten Projektmanagement sammeln Anwender weitere Wünsche, Ideen und gefundene Bugs. Herr Struve kanalisiert die Topics und leitet sie an den Dienstleister weiter. Dieser beginnt nun die neuen Features zu bauen, die nicht mehr im alten System realisiert worden waren. Sobald eine Idee umgesetzt ist, kommt ein Anwender hinzu und liefert Feedback, der unmittelbar verarbeitet wird. Die Kommunikation erfolgt nicht über UML-Diagramme sondern über die fertige Software. Der Anwender spricht direkt zum Dienstleister, der wiederum zeitnah das Gewünschte präsentiert.

Das Projekt ist von seiner Dynamik her bereits im Wartungsstatus angelangt, als das Budget aufgebraucht ist. Der Programmierer, welcher früher das Altsystem inhouse betreute, ist während des Projekts mit der Scriptsprache vertraut geworden und ins neue System hineingewachsen. Die Übergabe ist nur noch eine Formsache. Kleinere Anpassungen sind für ihn kein Problem. Für größere Vorhaben steht weiterhin der Dienstleister per Remote-Support bereit.