Wer die Wahl hat, sollte wissen, worüber er entscheidet. Mit diesem Blog möchten wir einige Parameter hervorheben, die wir für eine Entscheidung als relevant empfinden.

Die Vergleiche, die wir hier aufzeigen, wurden hauptsächlich zwischen SAP, Navision und Odoo angestellt. Nicht nur, weil Kunden Odoo in die Endauswahl mit besagten Anbietern nehmen und somit automatisch ein Vergleich entsteht, sondern weil wir diese Produkte durch Migrationen von den genannten Kandidaten zu Odoo am besten einschätzen können. Aber natürlich auch, weil alle einen sehr ähnlichen, d.h., einen integrierten, internationalen und generalisierten, Ansatz haben. Keines der Systeme hat sich auf eine Branche, einen Bereich, ein Land oder eine Unternehmensgröße fokussiert.

Nutzungsrechte vs. Community

Ein wesentlicher Unterschied zwischen Odoo und den „klassischen“ Systemen ist das Lizenzmodell. Auch wenn bei Odoo ebenfalls Lizenzen bezahlt werden, sind diese an den Wartungsvertrag und das Enterprise-Paket geknüpft. D.h. wenn ein Kunde darin nicht länger einen Mehrwert sieht, kann der Enterprise-Vertrag entweder gekündigt oder einfach nicht weiter verlängert werden. Damit erlischt zwar die Gewährleistung, d.h. Odoo ist nicht länger verpflichtet, kostenfrei Programmierfehler zu beheben, die Migration der Datenbank muss vom Kunden selbst durchgeführt werden (auch hier gibt es mehrere Ansätze, die vielleicht nicht so komfortabel sind, wie eine Migration, aber es gibt Alternativen) und die Enterprise-Module müssen vom Server entfernt werden. Doch das System selbst und alle Individualisierungen können weiterhin genutzt werden!

Im Gegensatz dazu steht das klassische Lizenzmodell von geschlossenen Systemen (wie z.B. SAP und Navision). Bei diesen Anbietern können lediglich Nutzungsrechte erworben werden, d.h., sobald diese nicht länger gezahlt werden, ist ein weiterer Zugang nicht länger möglich.

Migration und Daten

IT Systeme entwickeln sich heute durch die agilen Ansätze in der Softwareentwicklung deutlich schneller als noch vor 10 Jahren. Aus diesem Grund ist die Frage von Aktualisierungen ein wichtiges Thema für eine Entscheidung geworden. Nicht umsonst hat z.B. Microsoft Windows auf ein sogenanntes „Rolling Release“ umgestellt, das im Grunde keine Versionen mehr kennt (übrigens eine Methodik aus der Open Source Welt).

Doch neue Versionen haben nicht nur ein Problem mit Umstellungen im Front-End, es müssen auch Daten migriert werden. Das Einfachste ist natürlich, seine Lösung vom Hersteller über eine Cloud betreiben zu lassen. Damit ist das Problem inklusive Daten ganz abgegeben.

Wenn allerdings die Hoheit über die eigenen Daten abgegeben wurde und dies auch noch in Kombination damit, dass nur Nutzungsrechte erworben werden können, ist dies für uns persönlich eine unglückliche Fusion. Immerhin entsteht hierdurch in jeder Situation eine totale Abhängigkeit vom Systemanbieter.

Das Gegenmodell ist natürlich der Eigenbetrieb, egal ob auf eigener Hardware oder in einer eigenen Cloud. Hier ist das Angebot, dass Daten im Rahmen eines Wartungsvertrags migriert werden, unvergleichlich und unschlagbar.

Denn bis dato wurde immer von einem „Migrationsprojekt“ gesprochen, was den dahintersteckenden Aufwand und Zeitrahmen erahnen lässt.

Quellcode – Absicherung und Zukunftsgarantie

Neben den sehr undurchsichtigen Lizenzmodellen vieler Hersteller und der Patentsituation, gibt es einen weiteren wesentlichen Grund, warum Open Source in den letzten Jahren weltweit ein Erfolgsmodell geworden ist: Mit der Installation wird auch der Quelltext ausgeliefert. Hier geht es nicht um die Transparenz, sondern um zwei Aspekte, die diese Tatsache möglich macht:

1) Unabhängigkeit

Dadurch, dass der Quellcode mit der Installation vorliegt, ist der Kunde unabhängig vom Anbieter. Solange eine Software keine Nischenlösung ist, sondern eine breite Akzeptanz hat (wie dies bei Odoo der Fall ist), gibt es weitere Wissensträger, die den Support leisten und Individualisierungen durchführen können. Dies sind die global mehr als 1.200 zertifizierten Odoo Partner.

2) Zukunftsgarantie

Da nicht nur von den Anpassungen, sondern auch vom Gesamtsystem der Quellcode verfügbar ist, wird auch die Gemeinschaft der Plattformbenutzer vom Hersteller unabhängig. Sollten sich Entwicklungen abzeichnen, die von der Gemeinschaft in dieser Form nicht länger akzeptiert werden, oder der Hersteller in finanzielle Schwierigkeiten geraten, wird das Projekt unter einem anderen Namen als sogenannte Fork fortgesetzt. Dies hat die Vergangenheit bereits des Öfteren gezeigt.