Implementierungsansatz von openfellas

Die Krux an der IT! – Oder die Frage, warum weniger mehr ist.

Im Endeffekt gibt es wohl nur zwei grundlegende Ansätze für die Implementierung einer Software-Lösung. Dabei ist es egal, ob es sich um ein ERP System oder etwas anderes handelt, wenn es nicht gerade eine Office Paket-, Buchhaltungssoftware- oder eine andere „Out of the box“-Lösung ist.

Variante 1

hat alles, kann alles, macht alles, verfügt über jede Menge Funktionen, alle Features sind aufeinander abgestimmt. Beispiele hierfür sind Branchenlösungen oder natürlich die Programme klassischer Softwarehersteller für CRM, ERP oder eCommerce. Diese Lösungen sind über viele Jahre gewachsen, am Reißbrett und/oder mit den Kundenanforderungen. Die Präsentationen sind überwältigend. Stellt man eine Frage, bewegt sich auch gleich die Maus auf dem Bildschirm, und Bildschirmabfolgen werden als Antwort gezeigt.

Ein Traum!

Doch was spricht dafür bzw. gibt es überhaupt etwas, das dagegen sprechen könnte?

Ein absolutes Pro ist natürlich, dass eine solche Lösung allein schon in der Vorführung Sicherheit gibt. Auch die Aussage, dass alles zu 90% aus dem Standard gelöst werden kann, ist doch genau das, was der Kunde hören will.

Daraus ergibt sich aber sofort die Frage: Wenn bei neuen Versionen der Hersteller für „den Standard“ zuständig ist und der Kunde selbst für die Anpassung, dann liegt wohl nahe, dass der Standard so viel wie möglich an Funktionen abdecken sollte. Somit müssten auch die Gesamtbetriebskosten günstiger sein. Oder nicht?

Doch was ist der Preis dafür? Die erste Frage, die ich mir immer stelle, wenn im Standard 90% abgedeckt sind: warum sind dann die notwendigen Budgets nicht auch 90% niedriger? Natürlich sind die Lizenzen ein wesentlicher Faktor, doch das „Konfigurations- und Beratungspaket“ müsste eigentlich deutlich niedriger sein. Oder nicht?

Die Antwort auf diese Fragen liegt wohl im Kern der Sache:

• A) Diese „Rund-um-sorglos-Pakete“ sollen gegen alles gewappnet sein. Das hat zur Folge, dass die hohe Anzahl an Features ein sehr hohes Maß an Abhängigkeiten bringt. Was wiederum heißt, muss irgendetwas geändert werden, ist es unmöglich, dies auf einen kleinen Baustein zu beschränken. Eine kleine Veränderung löst grundsätzlich eine Kette an Anpassungen aus, mit den Konsequenzen eines höheren Budgets, einer längeren Projektlaufzeit und des Risikos, alles bei einem Versions-Upgrade neu bewerten zu müssen.

Und zu guter Letzt bedeutet dies, dass es nur wenige Leute gibt, die die Konsequenzen eines Umbaus tatsächlich abschätzen können. Jemand sagte einmal zu mir, allein bei SAP gäbe es vielleicht 100 Leute, die dazu in der Lage seien. Er selbst habe eine Menge Einhunderterste getroffen.

• B) Heißt das aber auch, dass schnelle Entwicklungen seitens des Herstellers nicht möglich sind? Denn hier müssen neue Versionen ebenfalls alle Komponenten bedenken und in einem neuen Kontext einplanen und integrieren. Sicherlich wird dies ebenfalls ein Grund sein, warum die Technologien eingesessener Hersteller im Kern den Verdacht erwecken, veraltet zu sein? Denn wer geht schon das Risiko ein, hier eine Neuentwicklung zu riskieren?

• C) Schlussendlich darf man natürlich nicht vergessen, dass Komplexität auch in der täglichen Nutzung ihren Preis hat. Sie erfordert ein hohes Maß an ständiger Schulung, nicht nur zur Projekteinführung. Wie man sich einfach denken kann, ist die Bereinigung von entstandenen Fehleingaben ebenfalls nicht so einfach zu revidieren.

“Bedenke gut, was du dir wünschst, es könnte wahr werden.”

Jetzt kann man natürlich sagen, dass es genau das ist, was man will. Hohe Abhängigkeiten gewährleisten eine hohe Datenqualität. Und wenn das System nicht auf einen zukommen kann, dann kommt man halt zum System, immerhin ist es ja auch das Ziel, einen standardisierten Prozess zu leben.

Doch das kann nur jemand sagen, der sich der Konsequenzen dieses Wunsches nicht bewusst ist! Abgesehen davon, dass jeder mit ein paar Jahren in der IT weiß, dass der Traum der Datenqualität sehr schnell zum Alptraum wird. Wo ist, kaufmännisch betrachtet, die Individualität, die ein wesentlicher Bestandteil des USP (Unique Selling Point) eines Unternehmens ist? Wenn die IT alles einebnet, wo lebt man dann den Unterschied oder die Abgrenzung?

Und rein technisch betrachtet gibt es einen weiteren wesentlichen Nachteil. Denn das Verhängnisvolle ist, dass der Computer zwar schnell rechnen kann, aber nur in haargenau der Reihenfolge, die vorgegeben ist. Muss man von der Reihenfolge abweichen, oder vielleicht sogar einen Schritt oder zwei weglassen, weil er/sie absolut keinen Sinn macht/machen, gibt es hoffentlich eine Konfiguration, in der dies vorgesehen ist. Wenn nicht, landen wir wieder bei den beschriebenen Punkten.

Vergessen wir außerdem nicht den vorherigen Artikel: von oben bzw. außen betrachtet sieht alles gleich oder ähnlich aus. Viele Fragen wurden vor einem solchen System nie gestellt, da es keinen Computer gab, der das Ergebnis errechnen sollte. Somit gibt es darauf auch keine Antworten.

Variante 2

ist der Ansatz, nur das zu haben, was kaufmännisch absolut notwendig ist und über alle hinweg betrachtet gleich sein MUSS, denn alles andere widerspräche jeder geschäftlichen bzw. unternehmerischen Regel. Alles Weitere, wie die Abgrenzung von Vorfällen durch einen zusätzlichen Status je Vorgang, weitere Felder, Berechnungen, Knöpfe, Ausarbeitung von vorhandenen Formeln, mit anderen Worten die Erstellung des individuellen Maßanzuges, ist Teil der Umsetzung.

Was spricht dagegen und was überhaupt dafür, schließlich bedeutet dies wesentlich mehr Aufwand?

Dagegen spricht natürlich, dass das Risiko zur positiven Entscheidung für eine Einführung sehr hoch erscheint, denn man hat ja im Grunde erst einmal nichts oder nur sehr wenig gesehen. Da eine solche Entscheidung nicht technisch, sondern meist in kaufmännischer Runde getroffen wird, erscheint es riskant; und wer möchte dafür seinen Job aufs Spiel setzen? Dieser Nachteil ist valide und bleibt leider unzweifelhaft und unmissverständlich im Raum.

Auch erscheint es einem logisch, dass der Aufwand jetzt und bei der Einführung von neuen Versionen ebenso groß sein muss. Damit ist die Projektlaufzeit jetzt sehr lang und die Gesamtbetriebskosten erscheinen sehr hoch.

Interessanterweise ist genau dies nicht der Fall. Da es im System weniger Abhängigkeiten gibt, müssen auch weniger Abhängigkeiten berücksichtigt werden. Hinzu kommt, dass zumindest derzeit alles auf aktuellen und neuen Technologien basiert und auf einen aktuell gehaltenen Kern aufbaut. D.h., die benötigten Anpassungen können vergleichsweise schnell und einfach umgesetzt werden. Folglich sind Projektzeiten und Budgets tatsächlich geringer. Gemäß dem Open Source Gedanken „mach es klein, aber mach es effektiv“, ist Odoo als Hersteller selbst in der Lage, sich schnell weiterzuentwickeln. 

Dies ist eindeutig erkennbar, wenn man Google nach TinyERP 4.2, OpenERP 6.0oder Odoo 11fragt und nur die Bildschirme vergleicht, die man sieht. Musste man vor 6 Jahren noch mit einem klobigen, lokalen Client arbeiten, gab es vor 5 Jahren bereits ein Webfront End, vor 4 Jahren nur noch ein Webfront und seit 3 Jahren ein neues Webfront End, das responsive und intuitiv aufgebaut ist. Vor 4 Jahren noch waren es hauptsächlich kleine und mittelständische Unternehmen, die Odoo als Lösung in Betracht gezogen haben, mittlerweile sind es Behörden und Konzerne.

Was spricht also tatsächlich dagegen?

Ein wirkliches Kontra sind die vielen Fragen, die bei einer Einführung gestellt werden, denn wie gesagt, der Computer lässt nur die von Anfang an in Betracht gezogene Toleranz zu. Es reicht nicht zu sagen, dass es Grün ist, man muss auch sagen, welches Grün genau. Sicherlich ist dies in ähnlicher Form mit Variante 1 auch notwendig, allerdings dort hauptsächlich zur Bestimmung der Konfiguration oder zur Absicherung des Implementierers. Bei Odoo ist es eine Definitionsrunde.

Ein weiterer Nachteil ist natürlich – machen wir uns nichts vor – die sich dadurch ergebende Abhängigkeit von demjenigen, der das System aufsetzt, von dessen Kenntnis und Verständnis der Materie. Geht hier etwas schief, sind alle Anpassungen zwar in der eigenen Hand, aber eine Vielzahl an Fragen müssen neu gestellt und beantwortet werden.

Für beide Varianten gilt jedoch:

Das Verständnis der Prozesse und die Fähigkeit, diese korrekt mit den vorhandenen Komponenten in Einklang zu bringen, ist der wesentliche Faktor für die langfristige Konstruktion und Implementierung eines stabilen und Upgrade-fähigen Systems.

Auf die weiteren Details möchte ich im 3. Teil dieser Blogserie eingehen. Darin werde ich zeigen, welche Bausteine für ein Projekt notwendig sein sollten. Darüber hinaus werde ich abgrenzen, wo der allgemeine Trend in der Umsetzung liegt, um auch deutlich zu machen, welches die eigentlichen Kostentreiber sind.

War dieser Artikel hilfreich? 
Dürften wir Sie bitten, uns eine Bewertung zu Ihren Erfahrungen mit openfellas zu hinterlassen?

​​​​​​openfellas bewerten