Wie die IT so tickt – oder die Frage, warum weniger mehr ist

Die Ausgangssituation

Ob der Vergleich der Wirklichkeit entspricht oder nicht, sei mal dahin gestellt, in der Wahrnehmung wird Odoo offensichtlich gerne mit Microsoft Navision verglichen. Immerhin ist bei nahezu jeder Angebotsphase mindestens ein Navision Partner in der Bieterrunde dabei.

Was uns in Gesprächen immer wieder auffällt, sind Hinweise darauf, dass „die anderen ausgereifter erscheinen, wenn man sich die Systeme im Detail anschaut“. Dies kommt natürlich auch zum Tragen, wenn man Fragenkataloge oder Ausschreibungen bearbeitet bzw. beantwortet, in denen allein nach den Features gefragt wird. Viele Funktionen lassen sich selbstverständlich nachbauen, doch im Odoo Standard sind sie nun mal nicht vorhanden. Daher lautet die Antwort auf die Frage, ob sie denn verfügbar seien zunächst immer „nein“.

Unsere wiederkehrende Argumentation ist, dass der Standard in der Verantwortung des Herstellers liegt, damit langfristig günstiger ist und mehr Sicherheit bietet. Damit sind alle Risiken der Einführung sozusagen im Lizenzpreis inkludiert.

Doch was bedeutet das alles? Gehen wir einfach mal auf die einzelnen Punkte ein:

“Alles im Preis inkludiert”

Es stimmt, die klassischen Systeme wurden über die Jahrzehnte hier und da mit vielen kleinen Features bestückt. Ich muss zugeben, es ist im ersten Moment schon beeindruckend, wenn man sieht, an welch feine Details gedacht wurde. Aber klar, im Lauf der Zeit gab es zahlreiche Wünsche und Feedback – und die entsprechenden Hundertschaften an Programmierern mussten ja irgendwie beschäftigt werden.

Hinzu kommt natürlich, dass der Großteil der Funktionen in der jeweils aktuellen Version nicht als erstes präsentiert wurde und es somit eine Sicherheit gibt oder geben muss, dass die Bugs darin beseitigt sind.

Keine Frage, die Software hat einen beachtlichen Wert. Und das führt zum nächsten Punkt. Denn schaut man auf die Lizenzpreise, so findet man diesen Wert dort natürlich wieder. Dabei ist klar, dass hier gerne ein paar hundert Euro pro Benutzer oder Modul abgerufen werden.

Wenn man also das eine nimmt, muss man wohl auch das andere bezahlen.

Mit Features gewinnt man noch lange keinen Krieg

Dann kommen wir mal zu all den Features. Ich stelle mir die Frage, ob dieser Funktionsumfang – neben der Sicherheit in der Entscheidung für das „richtige System“ – wirklich seinen Mehrwert bringt. Denn in all den Jahren Implementierung und Beratung sind mir mehrere Punkte aufgefallen:

Allgemein

Da ERP Systeme keine Fachanwendungen sind und sich die Effektivität einer solchen Lösung erst dann ergibt, wenn mehrere Bereiche eines Unternehmens integriert wurden, hat jedes zusätzliche Feature auch größere Komplexität zur Folge. Wenn man dabei bedenkt, dass Übergaben der Informationen in die unterschiedlichen Bereiche definiert wurden, bedeutet dies zudem eine Abhängigkeit der verschiedenen Features untereinander. Mit anderen Worten, die Komplexität wird nochmals erhöht.

Dies führt uns gleich zum nächsten Punkt.

Schulungsbedarf

Dass eine entsprechende Funktionsmenge natürlich einen vergleichsweise größeren Schulungsbedarf mit sich führen muss, liegt auf der Hand. Denn mehr Felder, mehr Knöpfe, mehr Meldungen müssen verstanden und bearbeitet werden – und das Wissen dazu muss weitergegeben werden.

Darüber hinaus entstehen oft Sinnzusammenhänge zwischen Feldern und Funktionen, für die der Benutzer ebenfalls Verständnis entwickeln muss, um sie nicht nur richtig, sondern optimal nutzen zu können.

Denn neben der Effizienz kann dies zu einem weiteren Punkt führen, den man versucht zu verhindern:

Mehr Support

Die Abhängigkeit und Komplexität führt zwangsläufig dazu, dass mehr Fehleingaben erfolgen, auch wenn es entsprechende Schulungen gab. Dies kann man dem Benutzer eher nicht vorwerfen, denn es ist ein Zusammenspiel aus Realität und der „richtigen Einschätzung“ des Benutzers. Wäre alles Schwarz oder Weiß, wäre es einfach. Doch oft ist es schwierig, den realen Fall auf die Feldwerte oder Zusammenhänge im System richtig zu abstrahieren, und den Vorfall entsprechend richtig in der Applikation zu hinterlegen.

Und dann wird unweigerlich ein Supportfall ausgelöst, der korrigiert und behoben werden muss.

Fazit soweit

Als Resultat aus dem größeren Funktionsumfang führen allein diese beiden Punkte zu konstanten Mehrkosten. Dabei gehen wir sogar davon aus, dass die Funktionen und deren Sinn entweder nicht alle bekannt oder so spezifisch sind, dass sie für das jeweilige Unternehmen keinen Mehrwert bringen und somit nicht genutzt werden.

Dabei haben wir gerade hierzu folgendes feststellen müssen:

Beratung – das A und O

Wenn man ein weiteres Resultat aus den Analysen unterschiedlicher Tools, von denen wir auf Odoo migriert haben, ziehen soll, dann ergibt sich der Eindruck, dass die eingesetzte Lösung einen wesentlich geringeren Anteil am Erfolg eines Projektes hat als man vielleicht annehmen könnte. Natürlich darf man die technische Basis nicht vernachlässigen, aus einer Out-of-the-box Lösung kann man keinen individualisierten Ansatz fahren, und aus einem alten Gaul wird kein schnelles Pferd. Doch ab einem gewissen Punkt macht alles danach nur noch wenig Unterschied. Entscheidender ist der menschliche Faktor im Projekt, also die Kenntnisse desjenigen, der die Lösung implementiert, das Einfühlungsvermögen in die Prozesse und das Verständnis über das zu erzielende Ergebnis aus dem Prozess sowie der daraus resultierende „Hingebungsfaktor“.

Kurz gesagt: wie gut und wie umfangreich die Beratung erbracht wird.

Denn nur so wird das Verständnis des Benutzers aufgebaut und ganz besonders der nächste entscheidende Punkt erfüllt:

Die Angst des Benutzers, etwas falsch zu machen

Eine hohe Dichte an Funktionen und eine mit Feldern vielleicht sogar überfrachtete Maske löst bei Benutzern verständlicherweise Berührungsängste oder zumindest Respekt aus.

Auf der Liste der Benutzer ist dies vielleicht der geringste Faktor. Immerhin wird durch Schulungen ja versucht, diesen Respekt einzugrenzen. Es gibt jedoch immer wieder Mitarbeiterwechsel, mit mehr oder weniger Erfahrung im Zusammenhang mit technischen Prozessen oder kaufmännischem Hintergrund. Da diese Systeme jedoch nur von den Eingaben der Benutzer leben und nur damit rechnen können, ist dies in Summe doch ein Faktor, denn man langfristig nicht vernachlässigen sollte.

Je mehr Features, desto weniger Intuivität

Um die nicht technischen Punkte abzuschließen, lässt es sich nicht verhindern, dass mehr Funktionen und die darauf basierende größere Anzahl an Informationsfeldern innerhalb der einzelnen Masken, nicht gerade den Eindruck eines intuitiven Systems vermitteln. Denn nicht umsonst ist hier der Schulungsaufwand deutlich höher. Das beste Beispiel war hier das Feedback eines neuen Mitarbeiters bei einem Kunden, der zu seiner Verwunderung bereits am 2. Tag in der Lage war, einen Auftrag vollständig zu erfassen. Beim vorherigen Arbeitgeber hatte er eine Woche Schulung benötigt und war bei seinem ersten Auftrag dort nicht einmal sicher, ob alles richtig erfasst wurde.

Aber klar, das sind Einzelbeispiele. Am Ende des Tages kann man diesen Effekt durch sehr starke Individualisierung in Odoo auch erreichen. Odoo an sich ist kein Schutz vor diesem Phänomen.

Der technische Hintergrund

Und nun ein paar technische Punkte, die gegen einen umfangreichen Funktionsumfang sprechen, und warum weniger dann doch mehr ist.

Ein Tanker bremst nicht so schnell

Wie im vorherigen Abschnitt beschrieben, ist das Ziel eines jeden ERP Systems, einen Effizienzfaktor durch die Nutzung zu schaffen. Dieser kann nur durch die Übergaben von Informationen an nachgeschaltete Abteilungen gewonnen werden. Und genau diese Übergaben stellen Schnittstellen im System selbst dar, welche Abhängigkeiten voraussetzen, um diese Informationen an die jeweils richtige Stelle im Folgevorgang weitergeben zu können.

Dies wiederum bedeutet, dass das Risiko genau dann beginnt, wenn es zu Anpassungen innerhalb des Ökosystems kommen soll. Denn wenn A und B miteinander verbunden bzw. voneinander abhängig sind und A verschoben wird, muss B ebenfalls berücksichtigt werden. Vielleicht soll A sogar weg, was ist dann mit B, das eine Information erwartet? Solche Fragen stellen sich der Technik, vorausgesetzt der Techniker weiß um die Existenz eines jeden Punktes und versteht, welche Abhängigkeiten sich durch diesen Punkt ergeben.

Und eben an dieser Stelle erklärt sich, warum klassische Systeme zwar einen guten Umfang an integrierten Features anbieten, aber das Budget trotzdem nicht viel geringer ist. Denn der Umbau ist aufwändiger und risikoreicher und bildet somit einmal die X- und einmal die Y-Achse innerhalb einer Kalkulationsmatrix.

Problematischer kann es sogar bei Branchenlösungen werden. Hier wurden viele Vorgaben durch die Branche definiert und integriert, doch ist das Risiko, etwas zu individualisieren oder umzubauen, gerade hier noch größer. Denn jedes Unternehmen hat schließlich seinen eigenen gelebten Prozess, ist im Detail anders gewachsen und arbeitet somit ganz anders. Was den kostspieligen Misserfolg eines Implementierungsversuchs einer Branchenlösung teilweise erklärt.

Fazit

Auch wenn wir von digitalen Einheiten sprechen, bilden diese in Summe ebenfalls eine zu kontrollierende Masse. Damit kann man sagen, das Umbauen risikoreicher ist als Aufbauen.

Und genau dies ist das Prinzip von Odoo. Es bildet eine kaufmännische Basis, von der aus Umbauten garantiert nicht notwendig sind, sondern Aufbauten in Form von: Automatisierungen, weiteren Feldern, weiteren Berechnungen, die dann auf genau die Anforderung angepasst werden (am besten sogar ohne komplexe Konfiguration).

Bleibt die Frage, was bedeutet Migration. Sind Anpassungen wirklich das Hindernis? Dies klären wir in einem separaten Blog.