In den letzten 3 Monaten sind wir als Feuerwehr zu einigen Odoo Projekten gerufen worden. Dabei haben wir die Erfahrung gemacht, dass es drei ganz typische Fehler gibt, die zum Scheitern solcher Projekte führen. Wir wollen Sie Ihnen hier kurz vorstellen, damit Ihnen nicht genau das gleiche passiert:

Hände weg von oberflächlichen Lösungen

Typisch für jede Open Source Software ist, dass der Quelltext mitgeliefert wird. Das verführt. Vor allem dazu, an einer Funktion herumzubasteln, wenn sie nicht genau das tut, was man sich vorstellt. So lange, bis das Problem gelöst scheint. Und schon ist alles geritzt. Super Sache. Aber leider der völlig falsche Ansatz.

Was man dabei schlichtweg übersieht, ist die Komplexität der Software. Neben den beiden sichtbaren Ebenen, nennen wir sie Ansicht und Programmierung, gibt es nämlich noch das nicht gleich erkennbare, eigentliche Herzstück des Ganzen: die Prozess Engine bzw. die Backend Ebene. Hier findet der wirkliche Workflow statt, die Prozessabläufe, die Kommunikation zwischen den einzelnen Modulen, etc. Die Schnittstellen dieser drei Ebenen sind die Zahnräder, die ineinander greifen müssen, damit alles reibungslos läuft. Ändert man also etwas nur auf der Programmierungsebene, weil man ja auf den Quelltext zugreifen kann und ihn versteht, übersieht man dabei die Prozess Engine und berücksichtigt sie folglich nicht im Workflow. Jede solche Modifizierung führt dazu, dass die entsprechende Funktion ihren eigentlichen Zweck nicht mehr erfüllt, was wiederum weitreichende Folgen für die damit verbundenen unter- und nebengelagerten Funktionen hat. Eine Zeitlang mag dieses Konstrukt laufen, aber irgendwann kommt der Moment, an dem die Sandburg zusammenbricht und sich dies wie bei den berühmten Dominosteinen durch das System fortpflanzt.

So weit, so schlecht. Aber das Ganze lässt sich noch potenzieren. Wenn man nämlich merkt, dass die ursprüngliche Funktion doch gebraucht wird. Da sie aber zweckentfremdet wurde, muss ein Stellvertreter her. Mit anderen Worten, es muss neu entwickelt werden, was eigentlich bereits vorhanden ist. Es folgt der Tragödie nächster Teil. Der Stellvertreter mag zunächst seine Funktion erfüllen, aber die Neuprogrammierung integriert sich ebenfalls nicht in die Gesamtstruktur. Alle Prozesse, die davon abhängig sind, können nicht mehr genutzt werden, sind aus dem Flow genommen. Die Folge sind Probleme an allen Ecken und Enden.

Dieser Fehler passiert am häufigsten und ist von allen der Schlimmste. Denn letztendlich ist er nicht zu reparieren. Da hilft dann nur ein kompletter Neuanfang!

Stellen Sie die richtigen Fragen

Den zweiten grundlegenden Fehler haben wir schon das eine oder andere Mal erwähnt. Dennoch erscheint er uns so wichtig, dass er auch bei dieser Auflistung nicht fehlen darf.

Der Erfolg des ERP Projekts hängt zunächst einmal ab von der Person, die der Implementierungspartner zum Kunden schickt. So viel schon mal vorweg, ein Entwickler sollte es nicht sein. Denn das Problem ergibt sich häufig, wenn IT und Business aufeinander treffen. Mehr muss eigentlich dazu nicht gesagt werden.

Die Lösung ist ein Analyst mit betriebswirtschaftlichem Know-how, der die betriebswirtschaftlichen Prozesse erkennen und abbilden kann, dem Kunden auf Augenhöhe begegnet und diesen gegebenenfalls auch von falschen Vorstellungen abbringt. Bei openfellas ist es dann Sache des Software-Architekten, aus den Informationen des Analysten das richtige Konstrukt zu formulieren und dafür die richtigen Komponenten auszuwählen. Er macht die Komplexität des unternehmensspezifischen Workflows für den Programmierer und Entwickler handhabbar und minimiert damit das Risiko von Fehlentwicklungen. Nicht zuletzt trifft er die grundlegenden Entscheidungen darüber, wie diese Puzzleteile am Ende des Tages zusammengesetzt werden.

Genauso wichtig ist die Person, die auf Seiten des Kunden mit dem Projekt betraut ist. Häufig ist dem oder den Verantwortlichen selbst nicht klar, warum und wofür die ERP Lösung eigentlich eingesetzt werden soll und welche Schritte dafür notwendig sind. Die Komplexität der Unternehmensabläufe muss im Softwaredesign abgebildet sein. Daher ist die Analyse des Geschäftsprozesses von fundamentaler Wichtigkeit. Und dabei hilft auch nur absolute Ehrlichkeit. Wenn das Spielfeld nicht richtig und vor allem nicht vollständig abgesteckt ist, wird bereits hier der Grundstein gelegt für spätere Diskussionen, von denen man nicht wissen kann, wie sie am Ende ausgehen. Im schlimmsten Fall enden sie vor Gericht und kosten richtig viel Geld, für beide Seiten.

Ein weiterer Knackpunkt ist, so selbstverständlich es sein mag, die richtige Verständigung. Auch wenn beide Parteien die gleiche Sprache sprechen, hat jede ein anderes Verständnis der einzelnen Wörter oder Begriffe und von deren Bedeutung. Der eine sagt das und sein Gegenüber versteht dies und baut darauf seine Analyse auf – mit dem entsprechenden Ergebnis. Daher sollte also von vornherein geklärt werden, ob beide Seiten unter einem bestimmten Begriff auch dasselbe verstehen. Nur so ist gewährleistet, dass am Ende auch das passiert, was passieren soll. Denn werden wichtige Parameter übersehen, stürzt irgendwann alles zusammen wie ein Kartenhaus.

Reden Sie nicht aneinander vorbei

Auch der dritte Fehler, den man bei der Implementierung von Odoo oder jeder anderen ERP Software begehen kann, hat etwas mit Kommunikation zu tun. Dieses Mal bezogen auf die erste Begegnung des Kunden mit Odoo. Gerade bei einer Ersteinführung kommt der Expertise des Analysten eine wesentliche Bedeutung zu. Der Kunde fängt sprichwörtlich bei Null an. Er kann also nicht einschätzen, was sich hinter den einzelnen Masken verbirgt und hat keine Ahnung von der Odoo-spezifischen Nomenklatur. Damit kann er auch nicht die richtigen Fragen stellen und weiß nicht, was die Antworten auf seine Fragen eigentlich bedeuten.

Während also der Kunde keine visuelle Vorstellung von dem hat, was sich hinter den einzelnen Funktionen verbirgt, ist auf der anderen Seite der Partner naturgemäß ein wenig betriebsblind. Er, der sich souverän in seiner Software auskennt, überspringt bei der Erklärung möglicherweise den einen oder anderen Punkt, weil er für ihn selbstverständlich ist. Es ist also extrem wichtig, dass sich Kunde und Partner hier auf Augenhöhe begegnen.

Wie überall helfen auch in diesem Fall nur Erfahrungswerte, um die richtigen Fragen und Rückfragen stellen oder die Probleme eingrenzen zu können. Das hat etwas von einem Koch, der ein neues Gericht ausprobiert und nur aus Erfahrung weiß, welche Zutaten wie miteinander harmonieren. Allerdings mit dem großen Unterschied, dass ein Fehler im Software-Design um einige Potenzen teurer ist.

Ist sich der Implementierungspartner dieser drei fundamentalen Knackpunkte bewusst und baut entsprechend vor, sollte eigentlich nichts mehr schiefgehen. Falls doch, sind es meist Fehler im Handwerk und somit normales Geschäftsrisiko, das der Partner zu tragen hat.