Wie die IT so tickt – oder die Frage, warum weniger mehr ist
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.
Wir verwenden Cookies, um Ihnen ein besseres Nutzererlebnis zu bieten.