Open Business: Unser Weg zu ERPNext
Auch in der K&K Software AG nutzen wir erfolgreich ERPNext. Lesen Sie in diesem Blogpost, wie wir zu dem System kamen, welche Hürden wir bei der Einrichtung nehmen mussten, und was wir daraus für unsere Arbeit mitnehmen.
Bis wir unser System hatten, waren viele Meetings nötig. Foto: K&K Software.
Bei der K&K Software AG lieben wir Open Source. Das ist nicht erst seit gestern so; schon seit vielen Jahren setzen wir auf offene Lösungen für unser Unternehmen. Einzelne Open Source-Lösungen zu nutzen ist aber immer noch etwas anderes, als einen wirklich großen Schritt zu unternehmen. Seit einiger Zeit haben wir unser ganzes Unternehmensmanagement auf eine offene Plattform verlagert.
So ein Umbau bringt viele Vorteile mit, ist aber auch alles andere als einfach. Der folgende Blogpost basiert auf einem Vortrag, der schon im Oktober vergangenen Jahres im Zuge der Würzburg Web Week gehalten wurde, sowie auf einem gemeinsamen Unternehmensfrühstück zum Thema Open Source und Business vor Ort in Gerolzhofen im März 2023.
Erfahren Sie, welche Entscheidungen wir auf dem Weg zu einer offenen ERP-Lösung treffen mussten, wie wir die angegangen sind und warum ERPNext das richtige System für uns ist. Lernen Sie außerdem, wie wir mit unserer ersten Iteration gecrasht sind, welche Lehren wir daraus gezogen haben, und wie wir unser System daraufhin umgebaut haben.
Unser Weg zum ERP
Wenn eine Firma wächst, dann ist es manchmal nötig, alte Zöpfe abzuschneiden. Das gilt ganz besonders für Unternehmensprozesse. In einem Wachstumsprozess versucht man, Lösungen für Probleme zu finden, sobald sie auftauchen. Das sorgt dann dafür, dass man für viele einzelne Teil Insellösungen hat, die sich nie wirklich zu einem großen Ganzen zusammenfügen.
Oft hat man Insellösungen anstatt ein großes Ganzes.
So war es auch bei K&K Software. Ehe wir unsere Unternehmensprozesse in unserem ersten ERP-System einbetteten, arbeiteten wir mit unzähligen Insellösungen. Unsere Angebote haben wir in Word zusammgetippt, Emaillisten individuell in Outlook verwaltet, To-Dos über Asana gemacht, aber gleichzeitig Ticketsysteme gepflegt… zwar gab es hier und dort schon einiges an Open Source, aber Einheitlichkeit war noch kein Begriff.
Die Einarbeitung neuer MitarbeiterInnen wurde dadurch zunehmend schwieriger. Teamarbeit und -austausch verkomplizierten sich. Ebenso das Kunden- und Stammdatenmanagement. Nicht nur in Sachen Übersichtlichkeit und Effizienz – an die DSGVO war in dem Zug kaum zu denken. Langer Rede, kurzer Sinn: Eine einheitliche Lösung musste her. Ein ERP-System.
Es gibt viele gute Gründe für Open Source. Bild: K&K Software.
Unsere Zeit mit Odoo
Da fiel uns ein, dass wir in der Vergangenheit schon einmal CRM-Systeme evaluiert hatten, und uns damals Odoo als Lösung ins Auge fiel. Da die Probleme drängend waren, haben wir das Open Source-System auch kurzerhand bei uns eingeführt – auf den ersten Blick wirkte es ja mit seiner offenen Architektur und seinem relativ hohem Umfang wie geschaffen für uns.
Die Arbeit mit Odoo hatte ihre Vorzüge.
Odoo hatte auch seine Vorzüge: die Kanban-Boards, mit denen wir gerne arbeiten, funktionierten hervorragend. Der Workflows, obwohl auf den ersten Blick gewöhnungsbedürftig, waren nachvollziehbar und anpassbar. Überhaupt: In Sachen alltäglicher Funktionalität ist Odoo alles andere als ein schlechtes ERP-System.
sen Sie hier unseren Vergleich zwischen Odoo und ERPNext.
Der Teufel steckte hier im Detail, oder, genauer gesagt, in der Lizenz. Kostenfrei bekommt man nämlich nur eine sehr abgespeckte Version des ERP-Systems. Zahlreiche Features, die wir eigentlich brauchten, befanden sich hinter Bezahlschranken. Für die Enterprise-Version, die wir eigentlich gebraucht hätten, hätten wir lockere 10.000€/Jahr ausgeben müssen! Das wollten wir nicht mitmachen.
In der Matrix
Unsere Zeit mit Odoo hatte vor allem ein Gutes: Wir waren uns jetzt wirklich sicher, was wir eigentlich brauchen. Nämlich ein wirklich offenes, funktionales ERP-System, mit dem wir unsere Systeme wirklich flexibel anpassen können. Wir haben also unsere MitarbeiterInnen gefragt, welche Alternativen ihnen einfallen, und die dann in eine Matrix eingetragen und nach unseren Anforderungen bewertet – auch eine Eigenentwicklung lag auf dem Tisch, was zwar teuer und aufwendig gewesen wäre, aber wenn man an die Kosten von Odoo Enterprise denkt…
Die Matrix wuchs schnell. Binnen kurzer Zeit hatten wir nicht weniger als 32 Systeme in der Auswahl. Schnell wurde uns klar, dass wir uns alle zwar mal anschauen können, wir aber bei der endgültigen Entscheidung eine engere Auswahl brauchen. Am Ende blieben fünf Lösungen übrig, die wir jeweils für brauchbar erachteten. Wir teilten jeder Lösung einen Paten zu und erstellten unsere letzte Matrix.
Das war auch nötig. Der Entscheidungsprozess zog sich an diesem Punkt schon seit einiger Weile hin. Zum einen wurden die Probleme nicht weniger drängend: Unsere Effizienz als Firma litt inzwischen merkbar darunter, Prozesse nicht effektiv in einem einheitlichen System abbilden zu können. Zum anderen machten sich Gräben in der Firma bemerkbar. Ein ERP-System kann durchaus den Kurs in einer Firma mitbestimmen, und einige MitarbeiterInnen legten sich sehr eindrücklich auf „ihre“ Lösung fest.
Nur eine von vielen Matritzen. Bild: K&K Software.
ERPNext: Der erste Anlauf
Nach einem Open Space, in dem wir nochmal intensiv über die verschiedenen Alternativen – weclapp, Odoo, eine Eigenentwicklung, Axelor und ERPNext – debattierten, tat sich ERPNext als klarer Favorit hervor. Warum wir von ERPNext so begeistert sind, können Sie hier genauer nachlesen.
Bei einem weiterem Meeting einigten wir uns auf eine agile Arbeitsweise mit zusätzlichen Super-Stakeholder, der ein erweitertes Vetorecht hat. Schon bei der Verteilung der Aufgaben machten sich ein paar Risse bemerkbar. Wir hatten zu viele Stakeholder – alle MitarbeiterInnen mit ihren teils sehr speziellen Vorstellungen – ein eher unerfahrenes Devteam und ein unerfahrener Product Owner, sowie ein Technical Lead, der eigentlich anderes zu tun hat.
Trotzdem war nicht alles schlecht. Das dreistufige Stagingsystem, mit dem wir Iterationen von ERPNext anhand von Testsystemen ausprobieren, ehe sie live geschaltet werden, haben wir bis heute beibehalten. Wir haben außerdem viele wichtige Kontakte zur Frappé und zur ERPNext-Community aufgebaut, und mithilfe von Azure DevOps direkt mit der Entwicklung eines regelrechten Berges an Modulen von HR über CRM bis zum Rechtemanagement aufgesetzt.
Der Crash
Anfangs war die Motivation für die Einrichtung von ERPNext hoch. Wir hatten ausreichend Stunden zur Verfügung und konnten sogar ein paar Werkstudenten für die Einrichtung abstellen. Das Problem: die waren irgendwann weg. Die Stunden auch. Zu diesem Zeitpunkt war noch kein Prozess wirklich fertig. Unser Stakeholder-System war zu chaotisch, und wir haben einfach an zu vielen Stellen gleichzeitig angefangen zu bauen.
Weil die Prozesse nie ganz ausgereift waren und zu viel auf einmal und unvollständig ausgerollt wurde, haben unserem MitarbeiterInnen das neue System auch nicht vollständig angenommen; eine generelle Skepsis gegenüber ERPNext machte sich breit, und das ganze Projekt drohte zu scheitern.
Das ganze Projekt drohte zu scheitern.
Wir haben einen Kardinalfehler begangen, vor dem wir sogar unsere Kunden immer wieder warnen. Wir haben zwar Scrum adaptiert, aber ein paar zentrale Elemente ausgelassen, nämlich die Sprints und Iterationen. Unser Stakeholder-System war eine eigene Anpassung, die mehr Probleme verursacht als gelöst hat. Jeder Teil von Scrum existiert aus einem guten Grund. Man kann nicht einfach Teile davon auslassen. Das haben wir jetzt auch mal am eigenen Leib gespürt.
Unser Staging-System hat den Crash überlebt. Bild: K&K Software.
ERPNext: Der zweite Anlauf
Im zweiten Anlauf sollte alles viel besser funktionieren. Dafür haben wir eine Reihe neuer Maßnahmen implementiert. Abgesehen von der Maßgabe, das Scrum-Handbuch jetzt vollständig zu beachten, haben wir zwei große Änderungen an unserem Arbeitsprozess vorgenommen. Zum einen haben wir eine neue Rolle definiert: aus dem Super-Stakeholder wurde der Process Owner. Zum anderen haben wir klare Voraussetzungen dafür definiert, wann ein Modul ausgerollt wird, um Frustration zu minimieren.
Wir haben gelernt, das ganze Scrum-Handbuch zu beachten.
Der Process Owner ist eine Art Super-Stakeholder. Das heißt, er hat weitreichende Kompetenzen für kreativen Input und ein Vetorecht, wenn es um Entscheidungen geht. Im Gegensatz zum Super-Stakeholder ist der Process Owner aber nicht mehr für das ganze System verantwortlich, sondern nur für einen einzelnen Prozess. Auf diese Art konnten wir Kompetenzen bündeln, Überforderung vermeiden, und den Arbeitsprozess straffen.
Module werden erst dann ausgerollt, wenn alle Stammdaten voll eingetragen sind, sie von Early Adoptern getestet wurden, alles von ihnen abgenickt wurde, und ein Report-Dashboard existiert. Damit vermeiden wir Frustration, unfertige Module, oder langwierige Eintragungsarbeiten, ehe ein Modul überhaupt benutzbar wird, und steigen so drastisch die Mitarbeitermotivation und die Adoptionsquote.
Zwei Lehren und ein Erfolg
Aus der Einrichtung von ERPNext und dem gescheiterten Versuch, eine Abkürzung hin zu einem funktionierenden ERP-System zu nehmen, haben wir zwei wichtige Dinge gelernt. Zum einen wurde uns nach dem Desaster mit Odoo nochmal wirklich klar, warum wir so intensiv für wirklich offene Software einstehen. Schlicht alle Optionen zur Hand zu haben ist gerade bei einem so ergebnisoffenen Prozess wie der Einrichtung eines ERP-Systems absolut notwendig.
Man kann nicht einfach Module halbfertig ausrollen. Bild: K&K Software.
Wir haben außerdem gelernt, dass es bei Scrum keine Abkürzungen geben kann. Es ist besser, Dinge gründlich und vollständig zu machen, anstatt Arbeitsschritte auszulassen und dann ein System zu haben, das zwar viele Module beinhaltet, die dann aber nicht vollständig ausreift sind und schließlich gar nicht benutzt werden.
Heute benutzen wir mit großer Begeisterung ERPNext und führen das System mit einigem Erfolg auch bei unseren Kunden ein. Unser manchmal nicht ganz gerader Weg und die Erfahrung eines wirkliches Crashs waren für uns kein Grund aufzugeben, sondern wichtige Lektionen, dank derer wir uns als Unternehmen verbessern konnten, und deren Lehren wir gerne weitergeben.
Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr Informationen