Erst der Ablauf, dann die Software

Wir bauen Buchungs-, Dispositions- und Planungssysteme für Betriebe, denen die Standardlösung nicht passt. Angefangen wird damit aber nie: Erst kommen wir für einen Tag in deinen Betrieb und sehen zu, wie gearbeitet wird. Das klingt nach Umweg. Die Forschung zu gescheiterten Softwareeinführungen sagt seit fünfundzwanzig Jahren, dass genau dieser Tag den Unterschied macht.

Woran Softwareeinführungen scheitern

Fast immer an derselben Sache: An der Lücke zwischen dem Ablauf, wie er im Betrieb läuft, und dem Ablauf, den die Software voraussetzt. Die grundlegende Untersuchung dazu stammt von Soh, Kien und Tay-Yap und erschien im Jahr 2000. Sie unterscheidet drei Herkünfte solcher Lücken:

• Der Betrieb selbst. Gewachsene Abläufe, eigene Aufteilung der Arbeit, eigene Art zu führen.
• Die Branche. Was hier üblich ist und in der Software nicht vorgesehen war.
• Das Land. Recht, Steuer, Meldepflichten.

Eine Übersichtsarbeit von 2010 hat alles durchgesehen, was zwischen 1997 und 2009 über gescheiterte Einführungen veröffentlicht wurde, und neun Hauptursachen herausgeschält. Auf Platz eins steht zu viel Anpassung, auf Platz drei zu wenig Verständnis für die Abläufe. Das ist dieselbe Ursache von zwei Seiten.

Der Unterschied, um den es geht

Zwei niederländische Forscher haben 2016 untersucht, wie mittelständische Betriebe mit solchen Lücken umgehen. Von ihnen stammt die Unterscheidung, auf der dieser Grundsatz beruht: Es gibt Lücken, die echt sind, und solche, die nur so aussehen.

Eine Lücke sieht nur so aus, wenn jemand die Software ändern will, der Betrieb sein Ziel aber auch ohne diese Änderung erreicht. Als Gründe nennen die beiden Gewohnheit, Widerwillen gegen Veränderung und schlicht: Man wusste nicht, dass es anders geht.

Ihr Ergebnis ist deutlich. In den untersuchten Betrieben war genau eine Abweichung wirklich zwingend, und die ging auf eine behördliche Vorgabe zurück. Alle anderen kamen aus Wünschen, die man auch hätte fallen lassen können.

Das spricht gegen unser eigenes Geschäft, und es steht hier, weil es stimmt. Die meisten Abweichungen, die ein Betrieb für zwingend hält, sind es nicht. Das heißt nicht, dass nichts gebaut wird. Es heißt, dass weniger Sonderfälle in die Software wandern, und genau das hält sie günstig und später änderbar.

Der umgekehrte Fehler kostet mehr

Daraus folgt nicht, sich immer der Standardsoftware zu beugen. Zwei amerikanische Forscher haben gezeigt: Wird ein Ablauf verbogen, der zum Kern des Geschäfts gehört, passt der Betrieb hinterher schlechter zu seiner eigenen Strategie. Messbar, sowohl bei der Einführung als auch im Betrieb danach.

Es gibt also zwei Fehler, und von außen sehen sie gleich aus:

• Eine Gewohnheit in Software gießen, die man hätte ablegen können.
• Einen Ablauf aufgeben, der der eigentliche Vorsprung des Betriebs war.

In beiden Fällen sagt jemand denselben Satz: „Das machen wir hier anders." Welcher der beiden Fälle vorliegt, merkt man erst, wenn jemand danebensteht und fragt, warum.

Warum ein ganzer Tag

Weil die Frage „warum läuft das so?" beim ersten Mal fast nie beantwortet wird. Die erste Antwort ist „das war schon immer so". Die zweite Antwort, meist eine halbe Stunde später und von jemand anderem, ist die richtige. Darin steckt dann entweder ein Grund, den kein Standardprodukt kennt, oder eine Gewohnheit, die niemand verteidigen würde, wenn man sie einmal ausspricht.

Zur berühmten Zahl

Oft liest man, ein spät gefundener Fehler koste das Hundertfache eines früh gefundenen. Die Richtung stimmt und ist belegt: Boehm und Basili nennen diesen Faktor 2001 für große, kritische Systeme. Der Nachsatz derselben Arbeit wird fast nie mitzitiert. Für kleinere Vorhaben liegt das Verhältnis eher bei fünf zu eins.

Die bekannte Tabelle mit den Werten 1 : 6,5 : 15 : 100 lässt sich außerdem auf gar keine Untersuchung zurückführen. Sie stammt aus einer Fußnote und wurde so lange weitergereicht, bis sie wie ein Messwert aussah.

Fünf zu eins reicht als Begründung völlig. Gegen jedes dieser Verhältnisse ist ein Tag Zusehen die günstigste Stelle im ganzen Projekt.

Was nach dem Tag passiert

Wo eine Abweichung nicht zwingend ist, schlagen wir vor, den Ablauf zu ändern statt zu bauen. Das kostet nichts und bleibt später nicht als Wartungsfall zurück. Gebaut wird für den Rest.

Erstgespräch vereinbaren, 30 Minuten, kostenlos. Oder weiter zu dem, was das Bauen danach kostet.

Quellen

• Soh, C.; Kien, S. S.; Tay-Yap, J. (2000): Cultural Fits and Misfits: Is ERP a Universal Solution? Communications of the ACM 43 (4), S. 47–51. Der Fachbegriff für die hier „Lücke" genannte Sache ist Misfit.
• van Groenendaal, W.; van Beijsterveld, M. (2016): Solving misfits in ERP implementations by SMEs. Information Systems Journal. Unterscheidung zwischen tatsächlichem und nur empfundenem Misfit.
• Momoh, A.; Roy, R.; Shehab, E. (2010): Übersichtsarbeit zu den Ursachen gescheiterter ERP-Einführungen, Literatur von 1997 bis 2009.
• Gattiker, T. F.; Goodhue, D. L. (2002): zur Folge von Prozessanpassungen an Standardsoftware für die strategische Ausrichtung.
• Boehm, B.; Basili, V. (2001): Software Defect Reduction Top 10 List. IEEE Computer 34 (1). Zur Herkunft der abgeleiteten Kostentabelle: Bossavit, L.: The Leprechauns of Software Engineering.