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 zeigt seit fünfundzwanzig Jahren, dass das Verständnis für die Abläufe den Unterschied macht. Dieser Tag ist unsere Antwort darauf.

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. Die meisten Abweichungen, die ein Betrieb für zwingend hält, sind es nicht. Dadurch wandern weniger Sonderfälle in die Software, 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. Gattiker und Goodhue haben 2002 in einer Befragung von 77 Werken gezeigt: Wo Betriebe ihre Abläufe an die Standardsoftware angepasst haben, brachte das keinen messbaren Vorteil. Die gängige Empfehlung, sich den eingebauten Abläufen der Software zu beugen, trägt also nicht von selbst.

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 der Grund für einen Ablauf selten beim ersten Nachfragen auf dem Tisch liegt. Auf „warum läuft das so?" liegt „das war schon immer so" näher als die eigentliche Antwort, und die kennt vielleicht jemand anderes im Betrieb. Ein ganzer Tag lässt Zeit, weiterzufragen. Dahinter 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. Dafür fällt kein Entwicklungsaufwand an. Die Umstellung im Betrieb kann trotzdem Zeit und Abstimmung kosten, bleibt aber nicht als Wartungsfall in der Software. 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 Beijsterveld, J.; van Groenendaal, W. (2016): Solving misfits in ERP implementations by SMEs. Information Systems Journal 26 (4), S. 369–393. Vier Fallstudien; 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): Software-driven changes to business processes: An empirical study of impacts of ERP systems at the local level. International Journal of Production Research 40 (18), S. 4799–4814. Befragung von 77 Werken.
• 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.