Systemwechsel als Organisationsfrage
Warum ein neues System ein Problem oft nicht löst, auch wenn die Technik einwandfrei läuft.
Ein neues System wird eingeführt, mit der Hoffnung, dass danach vieles einfacher wird. Ein paar Monate oder sogar Jahre später sind die Prozesse zwar in neuer Software abgebildet, die eigentliche Frustration im Betrieb ist aber noch da. Das ist kein Zeichen für eine falsche Software-Wahl. Es ist ein Zeichen dafür, dass die eigentliche Ursache nie geklärt wurde.
Das Muster hinter der Entscheidung
Ein System wird oft zum Sammelpunkt für Frust, der eigentlich woanders herkommt. Unklare Verantwortlichkeiten, Prozesse, die niemand verbindlich einfordert, Schnittstellen zwischen Abteilungen, die nie sauber definiert wurden. All das lässt sich nur schwer benennen, ein neues System dagegen ist konkret, budgetierbar und lässt sich beschliessen. Also wird investiert, in der Annahme, dass die Technologie das Problem mitlöst.
Was ein Systemwechsel sichtbar macht, aber nicht löst
Ein Systemwechsel macht bestehende Probleme sichtbar. Er löst sie aber nicht von selbst. Wenn zwei Abteilungen sich vorher schon nicht einig waren, wer für einen Prozessschritt zuständig ist, klärt eine neue Software diese Frage nicht automatisch, sie zwingt höchstens dazu, sie endlich zu beantworten, oft mitten in der Einführung, unter Zeitdruck und ohne die nötige Sorgfalt. Das Ergebnis ist ein System, das technisch funktioniert, aber die eigentliche Frage nur verschoben statt geklärt hat.
Wie wir das in der Praxis angehen
Deshalb steht am Anfang eines Systemprojekts bei uns nicht die Anbieterauswahl, sondern eine Ist-Analyse. Wir gehen Problemen nach, nicht Symptomen, und klären, welche Anforderungen tatsächlich dahinterstehen, bevor der Markt evaluiert wird. Erst danach folgt die strukturierte Evaluation, mit Nutzwertanalyse und einer Begleitung, die bis zum Go-Live oder zur Übergabe in den Betrieb reicht. Diese Reihenfolge ist bewusst so gewählt. Eine Anbieterauswahl ohne geklärte Ausgangslage führt fast immer zu einem System, das die alten Fragen einfach mitnimmt.
Typische Situationen
Das zeigt sich regelmässig bei Projekten, in denen ein ERP-System eingeführt oder ein Payroll-Prozess ausgelagert wird, ebenso bei IT- und Prozesslandschaften, die über mehrere Gesellschaften verteilt sind und historisch gewachsen, statt bewusst gestaltet wurden. In all diesen Fällen ist die Software am Ende ein Werkzeug. Die eigentliche Arbeit liegt davor, in der Klärung, was das System eigentlich leisten soll, und wessen Verantwortung was ist.
Was das für Ihr nächstes Systemprojekt heisst
Bevor eine Anbieterliste erstellt wird, lohnt sich die Frage, welches Problem das neue System tatsächlich lösen soll, und ob es wirklich ein Technologieproblem ist. Oft zeigt sich erst in dieser Klärung, was ein neues System leisten muss, damit es nicht dasselbe Ergebnis bringt wie das alte.