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.

Modularer Aufbau

Der Kern vieler klassischer Systeme ist noch monolithisch. Das verwundert nicht, da ERP Lösungen auf einem komplexen Datenmodell aufbauen und somit Funktionen aufeinander abgestimmt werden müssen. Das wiederum hat zur Folge, dass man diese Systeme nicht einfach in einzelne Teile trennen und somit modularisieren kann – auf dieses Problem sind wir bereits in zwei unserer früheren Blogartikel eingegangen:

https://openfellas.com/de/2020/03/wie-die-it-so-tickt/

https://openfellas.com/de/2018/11/implementierungsansatz-von-openfellas/

Odoo hingegen ist von Anfang an modular aufgebaut und erlaubt damit, eine gemeinsam besprochene Basis einzuführen. Sobald man das System effizient und erfolgreich in der Nutzung hat, kann es weiter ausgerollt werden.

Ein weiterer Vorteil ist, dass Anpassungen ebenfalls als Module gekapselt werden können. Somit ist eine Migration einfacher. Dies bedeutet aber auch, dass die Komplexität des Systems ebenfalls in einzelnen Schritten erhöht werden kann.

Modulbreite vs. Funktionstiefe

Innerhalb eines Unternehmens ist es oft sehr schwer, eine klare Linie zu ziehen und festzulegen, so dass ein bestimmter Bereich nur auf bestimmte Informationen angewiesen ist und der (oder die) andere(n) Bereich(e) nur auf eine definierte Menge an Daten. Dazwischen ist ein Austausch nicht notwendig. Das ist allein schon deshalb nicht möglich, da am Ende des Tages so oder so alles in der Buchhaltung landet, als Erlöse oder Kosten, und hier ein Strich gezogen werden muss (oder wird).

Der Vorteil an einem vollumfänglichen integrierten System ist der, dass hier die Daten nicht nur von Modul zu Modul weitergegeben werden können, sondern dass es zu keinen Doppelterfassungen kommt. Doch dazu muss es ein System erst einmal schaffen, eine Basis für eine vollständige Integration zu legen.

Wenn man sich die Vielzahl der Module anschaut, so ist klar: wenn nicht hiermit, womit sonst?

Der Preis dafür ist natürlich, dass es viele, viele kleine Funktionen nicht geben kann, die in einigen klassischen Systemen geschaffen wurden, da dies

1. a) in einem modularen System, in dem das Set an installierten Erweiterungen vielzählig sein kann, kaum möglich ist und

2. b) dem minimalistischen Ansatz widerspricht.

Da die Kunst so oder so die ist, ein System nicht nur so erfolgreich einzuführen, dass auch jeder vorgesehene Mitarbeiter ein darin arbeitender Benutzer ist, sondern auch die Prozesse so zu gestalten, das sie deutlich effizienter und fehlerfrei laufen, sagt einem schon die reine Vernunft, dass dies nur mit einem „weniger ist mehr“-Ansatz umsetzbar ist, denn Funktionen und Automatisierungen lassen sich einfacher hinzufügen als wegnehmen oder umbauen.

Lokalisierung und Buchhaltung

Die Buchhaltung von Odoo ist GoDB-konform und in Deutschland trotz ausstehender Zertifizierung voll einsetzbar. Eine Zertifizierung schützt übrigens nicht vor einer Fehlbenutzung und spricht eine Geschäftsführung nicht von der Verantwortung frei.

Es gibt für jedes europäische Land eine Lokalisierung im Odoo ERP System, die nicht nur die üblichen Steuern und Kontenpläne installiert, sondern auch die allgemeinen Finanzberichte auf die gesetzlichen Mindestvorgaben anpasst und erweitert. Dabei werden auch zusätzliche Funktionen installiert, wie z.B. in Italien die Übermittlung von Rechnungen per EDI.

Odoo unterstützt einen Mehrwährungsbetrieb. Die Kernfunktionen liegen jedoch in der Buchhaltung. Die notwendigen Funktionen für eine vollständige Unterstützung sind:

1. Umrechnungskurse zwischen den Währungen können manuell gepflegt, jedoch auch automatisch täglich, monatlich oder jährlich mit der EZB abgeglichen werden

2. pro Mandant kann eine Hauptwährung festgelegt werden

3. Im Buchungssatz kann eine zum Mandanten abweichende Währung angegeben werden, so dass die dann verbuchten Beträge in dieser Währung interpretiert werden. Zum Zeitpunkt der Verbuchung werden in nicht sichtbaren Feldern die Beträge in die Standardwährung des Mandanten zum dann gültigen Umrechnungskurs errechnet und dort hinterlegt.

4. Alle Statistiken sind auf Basis der Standardwährung aufgebaut

openfellas Module

Im Laufe der vergangenen 10 Jahre hat openfellas eine Vielzahl an Modulen entwickelt, die im Rahmen von Projekten als Basis zur Umsetzung von Anforderungen oder zur Steigerung der Prozesseffizienz genutzt werden können. Hier handelt es sich um Automatisierungen oder Hintergrundberechnungen, die sich bewährt haben.

Beispiele können sein:

• EDI Anbindungen an Lieferanten

• EDI Anbindungen an Logistiker

• Erweiterung zur Abbildung von komplexen Einkaufskonditionen

• Exchange Connector

• Datev Anbindung

• Shopware Connector

Odoo Gold Partner

Seit 3 Jahren hat Odoo die Bedingungen für eine Odoo Gold Partnerschaft deutlich strenger gestaltet, was recht viel Bewegung in die Partnerschaft gebracht hat.

Als Odoo Gold Partner müssen jährlich 150 neue Benutzer angemeldet werden. Auf der anderen Seite muss jedoch eine Verbleibquote von 80% erreicht werden, d.h. 80% der Kunden bzw. der Enterprise-Benutzer müssen pro Jahr verlängert werden.

Darüber hinaus müssen 3 feste Mitarbeiter eines Partners für die jeweils aktuelle Version zertifiziert sein, um die Kategorisierung halten zu können. Dabei werden dem Kandidaten innerhalb der Zertifizierung 80 zufällige Fragen gestellt, die sich alle auf aktuell im Standard befindliche Module beziehen. 70% davon müssen richtig beantwortet werden.

Dies zeigt, dass Odoo auch innerhalb der Partnerlandschaft auf eine qualifizierte Beratung Wert legt, so dass Risiken für Fehlimplementierungen minimiert werden und damit das Image eines stabilen Systems erhalten bleibt. Die Vorgaben sind ähneln denen von SAP und Microsoft.

Dies heißt auch, dass man hier unbedingt Gleiches mit Gleichem vergleichen sollte. Denn die Wahl des Partners ist womöglich wichtiger als die des Systems.