Geöffneter Notizblock mit Konzept der richtigen und falschen Strategie auf weißem Holztisch
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.” Sprichwort
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.
Wir verwenden Cookies, um Ihnen ein besseres Nutzererlebnis zu bieten.