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.
Wir verwenden Cookies, um Ihnen ein besseres Nutzererlebnis zu bieten.