Brauche ich wirklich neue Software? Meistens sitzt das Problem woanders

Irgendwas läuft im Betrieb nicht rund, und schnell steht der Gedanke im Raum, dass eine neue Software das Thema lösen wird. Wenn ich mir aber anschaue, woran Digitalisierungsprojekte tatsächlich hängen bleiben, sitzt das Problem fast nie dort, wo der Kunde es vermutet, und eine neue Software allein hätte es selten gelöst.

Das Problem sitzt fast nie da, wo du es vermutest. Trotzdem wird zur Lösung meistens eine neue Software gekauft.

In diesem Artikel liest du, warum es bei diesen Projekten fast nie an der Technik liegt, an welchen zwei Stellen sie wirklich scheitern und in welcher Reihenfolge du vorgehst, damit sich der Kauf am Ende auch lohnt.

Was es kostet, einfach eine Software draufzusetzen

Bevor wir zu den Gründen kommen, lohnt der Blick darauf, was passiert, wenn du diese Frage überspringst und einfach kaufst. Eine neue Plattform löst kein Chaos, das darunter liegt, sondern hebt es nur auf eine teurere Ebene. Sind die Daten vorher unsauber, sind sie es im neuen System auch, nur dass du jetzt Lizenzkosten, Einführungsaufwand und die Erwartung deiner Leute mitbezahlst, dass endlich alles besser wird. Wenn dann nach ein paar Monaten klar wird, dass sich an der eigentlichen Baustelle nichts geändert hat, kostet das nicht nur Geld. Es kostet vor allem Vertrauen, und genau dieses Vertrauen ist beim nächsten Anlauf der teuerste Posten.

Es liegt fast nie an der Technik

Damit sind wir bei der eigentlichen Frage. Wenn ein Projekt scheitert, ist selten das Tool schuld, sondern fast immer einer von zwei Punkten, die im Eifer der Toolsuche untergehen. Der erste hat mit deinen Leuten zu tun, der zweite mit dem Fundament, auf dem die ganze Software überhaupt stehen soll. Schauen wir uns beide der Reihe nach an.

Der erste Grund ist, dass der Change nicht mitgedacht wird. Neue Tools bedeuten neue Abläufe, und neue Abläufe bedeuten, dass deine Leute sich umstellen müssen. Nicht jeder ist am Anfang begeistert davon, und das ist völlig normal. Wer dann eine Projektdauer von sechs oder zwölf Monaten ansetzt und glaubt, danach läuft alles rund, plant am Menschen vorbei. Realistisch heißt zu fragen, wo ihr in einem, drei und fünf Jahren stehen wollt, was technisch wann fertig sein soll und wann sich das Unternehmen wirklich an die neuen Prozesse gewöhnt hat. Die Technik ist meistens in Monaten umgesetzt, aber bis sich neue Gewohnheiten im Unternehmen etabliert haben, vergehen Jahre.

Die falsche Baustelle, und was Stammdaten damit zu tun haben

Der zweite Grund führt uns direkt zu einem Beispiel aus der Praxis. Ein Kunde wollte ein neues ERP einführen, also das zentrale System, in dem ein Betrieb seine Kunden, Artikel, Aufträge und Zahlen an einer Stelle führt. Im Gespräch kam dann heraus, dass das eigentliche Problem gar nicht die fehlende Software war. Die Stammdaten waren nicht pflegbar, die Tabellen unstrukturiert, die IDs passten nicht zusammen.

Stammdaten sind die festen Grunddaten, die überall im Betrieb gebraucht werden, etwa Name, Adresse und Kundennummer. Eine ID ist dabei die eindeutige Nummer, an der zwei Systeme erkennen, dass es sich um denselben Kunden handelt. Ändert sich in einem System ein Vor- oder Nachname und im anderen nicht, lassen sich die Datensätze hinterher nicht mehr zusammenführen, weil gar nicht mehr erkennbar ist, dass sie zusammengehören. Ein neues System oben drauf hätte dieses Chaos nicht gelöst, sondern nur auf eine teurere Plattform verlagert. Wie ein ERP sauber aufgesetzt wird und was es vorher braucht, zeigen wir auf unserer Seite zu ERP-Systemen.

Die richtige Reihenfolge: erst aufräumen, dann aufrüsten

Daraus ergibt sich fast von allein, in welcher Reihenfolge du vorgehst. Deshalb geht es bei mir im ersten Schritt nie um die Software, sondern um die Frage, wo es gerade wirklich weh tut und ob das Problem da sitzt, wo der Kunde es vermutet. Erst danach wird gebaut.

Zuerst ziehst du die Datenbasis glatt, machst die Stammdaten also sauber, strukturiert und eindeutig. Im zweiten Schritt sorgst du dafür, dass diese gepflegten Daten von allein in alle Systeme laufen, statt sie an jeder Ecke neu zu tippen. Genau dafür sorgen Schnittstellen, also feste Verbindungen, über die zwei Programme automatisch dieselben Daten austauschen. Erst im dritten Schritt kommt das große neue System, denn jetzt steht es auf einem Fundament, das trägt. Wie so eine Verbindung zwischen deinen Programmen entsteht, liest du auf unserer Seite zur Schnittstellen-Entwicklung.

Erst fragen, wo es wirklich weh tut

Wenn du eine Sache aus diesem Artikel mitnimmst, dann diese: Bevor du über eine neue Software nachdenkst, frag dich, wo es im Betrieb wirklich weh tut und ob das Problem tatsächlich da sitzt, wo du es vermutest. Oft ist die Antwort eine andere als gedacht, und sie spart dir ein teures Projekt, das am eigentlichen Schmerz vorbeigeht. Dann reden wir über Software. Wenn du sehen willst, wie andere Betriebe diesen Schritt gehen, schau in unseren Blog und trag dich für den Newsletter ein, dann bekommst du neue Artikel direkt ins Postfach.