Inhaltsverzeichnis

9. Aktueller Stand 

9.1. Weitere umgesetzte Prozesse

9.1.1. Weiterentwicklung Marketingmodul Schritt 1

9.1.2. Dashboard Zusammenarbeit Teams und Vertrieb

9.1.3. Management der Urlaubs- und Krankheitstage

9.1.4. Kundenstammdaten

9.1.5. Automatische Domainabrechnung mit Cloudflare-API

9.2. Prozesse in Arbeit und nächste Prozesse

9.2.1. Automatische USt.IDNr. Abfrage beim Bundeszentralregister

9.2.2. Verbesserungen CRM Modul

9.2.3. Abrechnung und Pflege der Wartungsverträge

9.2.4. Bewerbermanagement

9.2.5. Pflege restliche Verträge (außer Wartungsverträge)

9.2.6. Ticketsystem

9.2.7. E-Mail Kampagnen und Newsletter

9.2.8. Fuhrparkmanagement

9.2.9. Projektmanagement

9.2.10. Eventmanagement

9.2.11. Buchhaltung

9.2.12. Einkauf / Disposition

9.2.13. Kundenportal

1. Die Ausgangslage

Bei uns war es zwischen 2017 und Anfang 2018 genauso, wie bei vielen anderen Unternehmen auch. Durch das stetige Wachstum und die Fokussierung auf unsere Kunden und die Technik hatten wir nach und nach immer mehr Insellösungen für einzelne Prozesse. Klar, man braucht von Anfang an eine Software um Rechnungen zu schreiben und für die Buchhaltung. Die gibt es haufenweise fertig am Markt. Ein Wechsel der Software ist häufig mit enormen Aufwänden verbunden, deshalb vermeidet man das später meistens. Dann hat man noch eine Telefonanlage, verwendet auch mal Word für Angebote und Konzepte. Anfangs mit 5 Mitarbeitern und wenn der Chef immer noch selbst in die Angebotserstellung involviert oder nur eine Person für die Angebote zuständig ist, braucht man vielleicht auch noch keine ERP-Lösung. Die meisten Ansprechpartner hat man ja schließlich im Kopf, Telefonnummern in der Telefonanlage und die E-Mail Adressen in Outlook gespeichert. 

Doch irgendwann wächst man als Unternehmen aus den Kinderschuhen heraus und es kommt die Zeit, in der der Vorstand immer mehr Aufgaben abgeben muss, wenn man weiter wächst. Es kommen immer mehr Kunden und einzelne Ansprechpartner dazu und der letzte Kontakt ist dann auch schon länger her. Dann kommt auch die Zeit, in der man von den bisherigen Insellösungen abkommt und sich aus verschiedenen Gründen eine einheitliche Lösung wünscht, um wieder effizienter arbeiten zu können.

Was waren die Auswirkungen bei uns konkret?

1.1. Keine günstige ERP Lösung im Portfolio

• Gerade KMUs brauchen noch keine individuelle Lösung oder eine branchenspezifische Software, sondern erst mal ein Programm mit dem sie ihre Daten pflegen und die kaufmännischen Standardprozesse abbilden können
• So eine Lösung hatten wir bislang nicht im Programm, wurden aber häufig von unseren Bestandskunden danach gefragt

1.2. Stammdatenpflege

• Keine einheitliche Pflege der Stammdaten
• Recherche nach Kontaktdaten von Ansprechpartnern war umständlich und zeitaufwändig
• Ansprechpartner teilweise überhaupt nicht im Vertrieb bekannt
• Aktuelle Kunden waren überhaupt nicht im Vertrieb bekannt
• Keine aktuellen Daten von Kunden und Leads

1.3. Vertrieb anfangs: Excel-Liste und Outlook-Termine

• Arbeiten mit Excel-Listen und Outlook Terminen im Vertrieb
• Umständliches und zeitaufwändiges Arbeiten
• Kein gleichzeitiger Zugriff möglich
• Kein Überblick vom Vertrieb über aktuelle Projekte
• Kein Überblick über aktuelle Tätigkeiten im Vertrieb
• Kein automatisiertes Reporting möglich
• Stand: Mitte 2016 – Anfang 2018

1.4. Vertrieb später: Odoo Community Edition

• Arbeiten mit Odoo Community im Vertrieb
• Prozesse waren gut ausgereift
• UI allerdings nicht sehr modern
• Strategische Ausrichtung in Richtung der teuren Enterprise Variante
  • Viele Funktionen waren in der Community Edition nicht vorhanden oder wurden nach und nach raus genommen
  • Community Edition war nicht updatefähig
• Stand: Anfang 2018 – Ende 2019

1.5. Kein Kundenportal

• Langfristiges Ziel der Vereinfachung und weiteren Digitalisierung von Fakturierungsprozessen mit bisheriger Software nicht möglich
• Anrufe der Kunden bei allen Fragen zu Rechnungen
• Manuelles Nachschicken von Rechnungen
• Kein Überprüfen der Stammdaten durch Kunden selbst

1.6. Keine Dashboards

• Keinen Überblick des Vorstands, welche Chancen noch in der Pipeline sind
• Steuerung des Vertriebs quasi unmöglich für Vorstand / Vertriebsleitung
• Forecast schwierig zu berechnen durch unterschiedliche Datenquellen

1.7. Vertragsverwaltung

• Keine einheitliche Vertragsverwaltung
• In Google GSuite geschrieben und dann in doppelt in physischen und digitalen Ordnern abgelegt
• Kein Überblick über Stundensätze und vereinbarte Details
• Zeitaufwändiges Heraussuchen der Unterlagen bei Bedarf

1.8. DSGVO

• Viel Aufwand im Rahmen der DSGVO und BDSG-neu
• Pflege der Daten an viel zu vielen Stellen
• Löschen der Daten an viel zu vielen Stellen
• Aufwändige Dokumentation

1.9. Insellösungen

• Viel zu viele Insellösungen
• Viel Open Source im Einsatz
  • Viele günstige/kostenlose Tools sind in Summe auch teuer in Wartung und Pflege
  • Pflege ist vor Allem aufwändig, wenn jedes Team ein anderes Tool nutzt
  • Keine Skalierungs- und Synergieeffekte
• Keine einheitliche Ticketverwaltung, sondern jedes Team eigene Lösung
• Fakturierung und Buchhaltung über Lexware
  • Selbst programmierte Schnittstelle zur Zeiterfassung hat funktioniert aber war aufwändig
  • Prozesse wie automatisierte Rechnungen über Wartungsverträge schwierig zu lösen
  • Wenig Clients, oft am Limit
• Daten der Mitarbeiter über mehrere Systeme verwaltet
  • Zeiterfassung
  • Lexware
  • Dateien in Ordnern
• Projekte über mehrere Systeme verwaltet
  • Zeiterfassung
  • Lexware
  • Asana
• Veraltete Zeiterfassung
  • Access Tool das vor 15 Jahren mal programmiert wurde
  • Bedienung nicht mehr zeitgemäß
  • nicht anwenderfreundlich
  • Teams haben sich schon eigene Frontends programmiert
  • Bonusberechnung zeitaufwändig und umständlich
• Eigenes Tool für ToDo Management
  • Asana
  • Nicht jeder hat einen Zugang
• Mehrere Chatsysteme
  • Teilweise Ticketsysteme
  • Teilweise über Mail
  • Privates oder Kommunikation zu Firmenevents, gemeinsame Mittagspause etc. über Telegram
  • Projekte und Vertrieb über MS Teams
  • stellt sich immer wieder die Frage wo wer was geschrieben hat

2. Die Anforderungen

Der Anstoß zu einer nötigen Verbesserung kam ursprünglich aus dem Vertrieb. Dort sind viele der Probleme zusammengelaufen. Doch was genau waren eigentlich unsere Anforderungen und wie sind wir da hin gekommen?

2.1. Der Weg zu den Anforderungen

Vorstand Arnulf Koch hatte 2016 schon einmal 16 CRM und ERP Systeme ermittelt und anhand der wichtigsten (Ausschluss-) Kriterien vorsortiert und ausgemustert. Wichtig dabei war ihm z.B. eine Einschätzung was die Zukunftsfähigkeit angeht oder ob die Software echtes Open Source. So wurden z.B. 6 Lösungen wieder aus der Matrix eliminiert.

• WECLAPP CRM
• CAS PIA
• openCRX
• OpenZ
• INTARS LITE
• Zurmo
• OROCRM
• XRMS CRM

Irgendwie kam dann aber wieder der Alltag dazwischen und hat ihn und uns wieder davon abgehalten, diese Recherche dieser Stelle fortzusetzen.

2.1.1. Erster Versuch: Odoo Community Edition

Im Herbst 2017 wurden unsere Excel Listen und Outlook Termine langsam aber sicher wirklich unübersichtlich und nicht mehr auswertbar. Es war uns damals wirklich eilig.

Als wir das Thema dann wieder aufgegriffen haben, haben wir uns einige kostenlose CRM Systeme – Alternativen zu SAP –  noch mal grob bewertet.

Dabei haben wir uns recht schnell für die Odoo Community Edition entschieden, diese dann Ende 2017 aufgesetzt und eingeführt. Das war zumindest schon einmal eine Verbesserung in einigen Punkten, z.B.:

• Stammdatenpflege an einer Stelle möglich
• Zugriff auf alle Stammdaten im Vertrieb, zumindest die, welche entsprechend gepflegt wurden
• Übersichtliches Festhalten von anstehenden und erledigten Aufgaben im Vertrieb
• Minimalstes Reporting möglich, allerdings nicht ausreichend und flexibel genug für uns

Dann haben wir durch die Arbeit mit Odoo Community Edition auch recht schnell die Nachteile dieser Lösung bemerkt:

• Abhängigkeit von Lizenzen
• Keine Schnittstellen zu anderen Systemen möglich
• Erfasste Daten konnten nicht (automatisiert) exportiert werden
• Keine Updatefähigkeit auf neuere Versionen
• Viele für uns erst mit der Zeit wichtige Funktionen (v.A. Updatefähigkeit) waren nur mit der Odoo Enterprise möglich, z.B.
  • Anwendung auf mobilen Endgeräten
  • Helpdesk
  • Abonnements
  • Marketing-Automatisierung

Ein knappes Jahr später haben wir die Odoo Enterprise Variante für uns evaluiert und grob berechnet. Bei der Odoo Preiskalkulation zahlt man jeweils pro Modul und es skaliert dann zusätzlich noch pro Benutzer. Dabei mussten wir für die benötigten Module und alle notwendigen Benutzer (zu dem Zeitpunkt 23) also über 9.000€ jährlich veranschlagen. Das ist natürlich schon eine enorme Summe, vor allem wenn man langfristig kalkuliert. Dazu kommt dann noch die Feststellung, dass man dennoch irgendwie unflexibel ist und sich in den Prozessen komplett nach Odoo richten muss. Außerdem war in den nächsten Jahren ein mögliches Wachstum noch gar nicht mit bemessen.

Warum haben wir nicht SAP getestet?

2.1.2. Ein Schritt zurück: Grundlegende Überlegungen

Anfang 2019 war unsere Überlegung dann die folgende: 

Wenn wir uns eine Software selbst individuell entwickeln, haben sich die Kosten wahrscheinlich in wenigen Jahren wieder amortisiert. Genau das ist ja als IT-Dienstleister mit Schwerpunkt auf individueller Softwareentwicklung unser Spezialgebiet. Zusätzlich hätten wir dann den Vorteil, dass wir die Lösung immer weiter anpassen und als fertiges und anpassbares Produkt verkaufen können. Das wäre bei einer Investition in dieser Größenordnung dann auch eine Voraussetzung gewesen. 

Wir haben uns dann mit dem Vorstand und den Mitarbeitern, die an weiteren Verwaltungsprozessen außer dem Vertrieb beteiligt sind zusammengesetzt. In einigen Meetings und einzelnen Überlegungen im November 2018 haben wir die Probleme und Anforderungen in Bereiche und Aspekte aufgeteilt und diese in einer ersten Excel Tabelle festgehalten:

Zuerst haben wir uns überlegt, welche Bereiche oder Funktionen alles abgebildet werden könnten oder sollten. Dann haben wir uns für die Bereiche einzelne Aspekte bzw. Userstorys bzw. erste Akzeptanzkriterien überlegt. Anschließend haben wir die Bereiche gewichtet (von 1-10). Von vielen Mitarbeitern kamen zusätzlich zu Odoo, das nach wie vor im Rennen war noch weitere Vorschläge für ERP-Lösungen. Diese hat dann jeweils ein Mitarbeiter in unserer Matrix pro Bereich / Funktion bewertet. Das war quasi der Pate der Software.

Die betrachteten und (von 1-10) gewichteten Bereiche waren folgende:

• Hersteller- und Self-Support (4)
• Pipeline / ToDo Verwaltung (5)
• ERP-Funktionen (6)
• Oberfläche / Basisfunktionen (8)
• Kosten jährlich (Hosting / Lizenzen) (6)
• Kosten bzw. Risiko Kommerzialität (4)
• Kosten bzw. Aufwand für Grundanpassung, Schnittstellen (5)
• Kommunikation (2)
• Helpdesk / Ticketsystem (7)
• Elementare CRM-Funktionen (8)
• Controlling (5)
• Vertragsverwaltung (8)
• Marketing (9)
• Zukünftige Erweiterbarkeit (6)
• Schnittstellen (7)
• Datenselektion und Workflows (8)
• Administration (3)
• Projektverwaltung (4)
• Zukunftsfähigkeit (6)
• Veräußerbarkeit (10)

Am Ende hatten wir dann Ergebnisse für folgende Lösungen:

• Axelor (gesamt: 917,5 Punkte)
• Odoo Enterprise (gesamt: 858,5 Punkte)
• MS Dynamics 365 CRM (gesamt: 810 Punkte)
• Odoo Community (gesamt: 734,5 Punkte)
• FlarePoint (Laravel CRM) (gesamt: 426 Punkte)

Wir haben uns aufgrund der Ergebnisse dann Odoo Enterprise nochmal genauer durchgerechnet. Axelor und MS Dynamics 365 CRM haben wir uns nochmal näher angesehen und einzelne Mitarbeiter haben die wichtigsten Bereiche getestet.

2.1.3. Bewertung Odoo Enterprise Edition

Zu der erweiterten Odoo Version “Odoo Enterprise Edition” konnten wir ja recht gut Rückschlüsse aus der Basis Version “Odoo Community Edition” ziehen. Die Basis-Funktionen waren uns also schon bekannt und wir wussten, wie sich die Software “anfühlt”. Die Marke Odoo ist nicht ganz unbekannt und als offizieller Partner gibt es auch Vertriebsunterstützung. Daher gibt es aber auch schon viele Odoo-Partner. 

Der mögliche Funktionsumfang und die Anzahl der zukaufbaren Apps sind zwar sehr überzeugend, aber leider hat Odoo einfach keine schöne und moderne Benutzeroberfläche. Die Logiken waren zudem im Vergleich zu anderen CRM Lösungen nicht so gut durchdacht. Zusätzlich fiel noch der dafür dann zu hohe Gesamtpreis stark ins Gewicht.

Unser Fazit:

• Zu hoher Preis, insbesondere zu hohe laufende Kosten durch Lizenzmodell und Kosten pro User
• Dafür zu altbackene Oberfläche
• Zu wenig durchdachte und praxisbezogene Logiken
• Mitarbeiter hatten sich schon daran gewöhnt
• Viele fertige Module, guter Name, man könnte Consulting und Einrichtung als Dienstleistung anbieten
• Blieb im Rennen

2.1.4. Bewertung Axelor

Für das französische Open-Source Produkt “Axelor” hatten wir Anfang 2019 für 2 Monate eine kostenlose Demoversion zu unserer freien Verfügung. Diese war binnen weniger Minuten installiert. Eine echte Installation ohne Docker wäre aber vermutlich aufwändiger. 

Axelor hat eine sehr moderne und übersichtliche Oberfläche und reagiert auch spürbar schneller und direkter als z.B. Odoo.

Formulare und Business-Prozesse konnte man mit wenig Aufwand und ohne große Programmierkenntnisse und direkt über die Oberfläche für sich anpassen, aber die ist nicht so gut wie in Odoo und einige Logiken sind auch absolut fix und nicht änderbar. Die Logiken waren meist sogar recht ähnlich zu Odoo. 

Wir haben mehrfach mit Mitarbeitern bei Axelor gesprochen und uns Logiken und Prozesse erklären lassen. Zusätzlich haben wir einige weitere Firmen befragt, die die Software im Einsatz hatten und uns hier weiteres Feedback eingeholt.

Bei Recherchen im Internet haben wir auch festgestellt, dass Axelor noch recht am Anfang der Entwicklungen stand.

Ein Nachteil für uns war, dass es das System nicht in deutscher Sprache gibt. Auf Nachfrage bei Axelor selbst haben wir aber erfahren, dass das wohl noch geplant sei.

Unser Fazit: 

• Gute Lösung mit der man sehr schnell arbeiten kann, ohne viel einrichten zu müssen
• Leider nicht sehr flexibel
• Sehr schönes und modernes UI (User Interface, also Benutzeroberfläche) und UX (User Experience, also Benutzererfahrung) 
• Blieb daher erst mal weiterhin im Rennen

2.1.5. Bewertung MS Dynamics 365 CRM

Dynamics 365 CRM war Anfang 2019 zuerst noch unser Favorit. Nicht zuletzt weil wir bei K&K auch einige Microsoft-Fanboys haben. Deshalb haben wir es im Frühjahr 2019 auch sehr intensiv getestet und versucht es für uns entsprechend einzurichten. Leider sind wir (trotz dass wir ja wirklich vom Fach und sehr IT-affin sind) hier immer wieder an Grenzen gestoßen. Dynamics ist zwar extrem komplex und anpassbar. Leider muss man dadurch aber auch zunächst extrem viel einrichten und anpassen. Es lässt sich praktisch nichts “out-of-the-box” verwenden. Manche wichtigen Module und Funktionen sind zunächst sehr versteckt, dass man sie suchen muss. Eine große Hürde war schon der Daten-Import. Wir hatten eine Excel-Liste mit Kunden Stammdaten, die wir gerne im System gehabt hätten. Nachdem wir selbst nicht weiter gekommen sind, haben wir Kontakt zum Microsoft Support aufgenommen. Zunächst sind wir zu einem deutschen Dienstleister gekommen. Der konnte uns aber leider nicht weiterhelfen und hat uns an einen Dienstleister aus der Schweiz weitergeleitet. Nachdem uns auch dieser den Fehler nicht finden konnte, wurden wir an den Support in England verwiesen und von dort aus zum Support nach Indien. Mit diesem haben wir mehrfach Videos aufgenommen, woran der Import immer scheitert – leider nach vielen virtuellen Meetings und unter Einbeziehung einiger indischer Kollegen am Ende wieder gescheitert.

Unser Fazit: 

• Unendlich anpassbar und bietet sehr viele Möglichkeiten
• Sehr aufwändig bis man es mal verwenden kann
• Support war nicht wirklich eine Hilfe
• Daher haben wir MS Dynamics 365 CRM wieder aus dem Rennen geworfen, denn: wenn es am einfachen Import schon scheitert, wie sieht denn dann der Support bei wirklich komplexen Problemen aus?

2.2. Die endgültigen Anforderungen

Wir hatten durch das viele ausprobieren und testen der verschiedenen Lösungen aber einen großen Vorteil: Uns wurde klar, was wir wirklich brauchen und wollen. Es hat sich herausgestellt, dass die erste Matrix dadurch nicht mehr gepasst hat. Mitte 2019 haben wir die Lösungen, die bis dahin durchgefallen sind rausgeworfen und noch mal eine neue Matrix erstellt mit unseren eigentlichen Anforderungen und allen Erkenntnissen, worauf es bei einer guten Lösung in dem Bereich eigentlich wirklich ankommt.

Funktionen:

• CRM-Funktionalitäten (Verwalten von ToDos, offene Chancen etc.)
• ERP-Funktionalitäten (Verwalten von allen möglichen Stammdaten)
• Abbildbarkeit von komplexen Kundenhierarchien
• Vertragsmanagement
• Helpdesk / Ticketsystem / Zeiterfassung
• Kundenportal
• Projektverwaltung
• Fakturierung, v.A. Automatisierungen
• Buchhaltung
• Kommunikation (Chatsystem, Kommentare etc.)
• Zeiterfassung
• Marketing-Kampagnen, Newsletter, Serienmails
• Verwaltungsprozesse wie z.B. Fuhrparkverwaltung
• Automatisierte Dashboards / Controlling / Reporting
• Kanban Boards mit intelligenten Suchfiltern und Sortierungen
• Einbindung fremder (Web-)Module
• Aufwand für Schnittstellen
• HR- bzw. Mitarbeiterverwaltung inkl. Bewerbermanagement, Urlaubsplanung und Krankheitsverwaltung
• Einfache und schnelle Imports, inkl. Konvertierung der bisherigen Daten

3. Die Entscheidungsfindung

Man kann noch so lange den Markt beobachten, recherchieren, immer wieder die Entscheidung vertagen und verschieben – irgendwann muss man mal “Nägel mit Köpfen” machen, wie man bei uns in Franken so schön sagt.

Dazu ist es bei so einer langfristigen und weitreichenden Entscheidung natürlich nötig, auch mal etwas mehr Zeit zu investieren und dafür lieber konsequent darüber zu bleiben, sich für etwas zu entscheiden und dann auch durchzuziehen.

3.1. Laufende Recherche

Deshalb hat unser Vorstand Arnulf Koch auch im Frühjahr 2019 noch mal sehr viel Zeit investiert. Auf Grundlage seiner Matrix von 2017 haben wir eine neue Matrix mit besser formulierten Kriterien erstellt und insgesamt 32 CRM und ERP Lösungen identifiziert. 

Dabei sind wir auch letztendlich auch auf ERPNext gestoßen.

Wichtige Kriterien waren uns hier u.A.:

• Kurzeinschätzung
• Sitz des Kernteams
• URL
• Schwerpunkt
• Technik
• Contributers-Graph
• Github contributors
• Github commits
• Github Anzahl von Committer 
• Github Star
• Google Treffer
• Google Treffer … development
• Google Trends
• YouTube-Treffer
• YouTube-Treffer … development
• Capterra-Reviews
• Freie Module
• Verfügbare Unternehmen und Freelancer
• Datenschutz
• Lizenz
• Look & Feel

Anhand dieser und weiterer Kriterien haben wir konsequent nach und nach 26 Lösungen wieder ausgeschlossen.

3.2. Letzte Evaluierungsphase

Im August 2019 haben bei uns auch zwei neue Informatik-Werkstudenten angefangen. Diese haben sich für uns 4 bzw. 6 Wochen lang mit den einzelnen Programmen beschäftigt und jede Lösung evaluiert, die aktuell noch im Rennen war:

• Eigenentwicklung mit .NET oder Laravel (vertriebsfähig)
• Odoo Enterprise
• Axelor
• ERPNext
• Status Quo (Weiterentwicklung, nicht vertriebsfähig)
• Weclapp (durch Veto gegen Ausschluss vom Vertrieb)

3.2.1. Bewertung Weclapp

Gegen den Ausschluss von Weclapp hat damals der Vertrieb ausdrückliches Veto eingelegt. Toll fanden wir die Regionalität, zumindest ein Teil der Entwickler sitzt in Kitzingen quasi vor unserer Haustüre, der Rest in Marburg bzw. Frankfurt. Weclapp hat eine sehr schöne und sehr moderne Oberfläche, für den Vertrieb die modernste in der obenstehenden Liste. Die Logiken waren sehr eingängig, der Aufbau der Oberfläche logisch und hat zu den Logiken gepasst. Die geeigneten Branchen haben auch zu uns gepasst, es gab eine Erweiterung für den Dienstleistungsbereich und auch schon Referenzen im Bereich IT-Beratung und Systemhaus. Zudem ist Weclapp einfach eine Komplettlösung. Der Fokus lag von Anfang an auf CRM mit Kontaktmanagement, Kundenakte, Aufgaben & Kalender, E-Mail-Automatisierung, Chancen & Kampagnen. Ganz besonders hat uns die Telefonanbindung gefallen. Nach und nach hat Weclapp viele wichtige Module hinzugefügt, wie z.B. Projektmanagement, Angebot & Auftrag, Faktura, Zeiterfassung, einen Formulardesigner, Finanzbuchhaltung & Banking.

Nachteilig war, dass es wieder kein Open Source und für ein Lizenzmodell einer relativ jungen und kleinen Firma sogar recht teuer war. Eine Art Partnermodell war bei Weclapp nicht vorgesehen. Wir konnten uns also in Zukunft nicht in irgendeiner Form beteiligen oder es weiter vertreiben.

Unser Fazit: 

• • Alles in allem die schönste und modernste UI 
  • Insgesamt im Funktionsumfang nahezu perfekt
  • Logiken im Detail auch nahezu perfekt umgesetzt
  • Kein Open Source
  • Kein Partnermodell möglich
  • Daher wurde Weclapp nicht gestrichen (oder wieder aufgenommen) und doch 6 statt des ursprünglichen Ziels von 5 näher zu bewertenden Lösungen in der Matrix belassen

3.3. Neutrale Bewertung nach Punktesystem

Durch die beiden Werkstudenten (die aktuell beide übrigens immernoch bei uns arbeiten – danke Meike und Dietmar ;)) hatten wir den großen Vorteil, noch mal eine außenstehende und neutrale Bewertung zu haben. Bis dahin waren die Meinungen und Standpunkte vieler Mitarbeiter auch schon ein kleines bisschen “festgefahren”.

Beide haben alle Lösungen anhand unserer Matrix eingehend nach einem 10-Punkte System bewertet und kommentiert:

Dazu haben Sie sich jede Lösung einzeln vorgenommen. Sie haben die Anforderungen Punkt für Punkt abgearbeitet und jede einzelne Anforderung für sich getrennt bewertet und kommentiert. Für Fragen standen damals die jeweiligen Ansprechpartner der Bereiche bzw. unser Vorstand Arnulf Koch bereit.

3.4. Gewichtung der Anforderungen

Währenddessen hat ein kleines Team aus Vorstand, Vertrieb und Projektmanagement die einzelnen Anforderungen gemeinsam gewichtet. Dank GSuite bzw. Google Tabelle konnten wir mit mehreren Mitarbeitern gleichzeitig an der Tabelle arbeiten.

Dabei war der höchste Wert +10, was vor Allem z.B. folgende Anforderungen bekommen haben:

• UI (=User Interface)
• Zusammenfassung der Haupt-Vorteile
• Subjektive Argumente
• CRM Funktionalitäten
• Stammdatenpflege

Die Werte konnten für wenige Anforderungen (genau 3) aber auch ins Negative gehen, z.B. für:

• Zusammenfassung der Haupt-Nachteile
• Neben-Nachteile
• Subjektive Bedenken

Alle weiteren Anforderungen lagen irgendwo dazwischen. 

Bei der Gewichtung haben wir darauf geachtet, dass die Punkte dann ausgeglichen und fair verteilt sind. Um besonders essenziellen Punkten noch mal ein besonderes Gewicht geben zu können, haben wir auch die Haupt- und Nebennach- und -vorteile zusätzlich mit aufgenommen und bewertet.

3.5. Festlegen eines fixen Enddatums

Zu Beginn der Evaluierungsphase haben wir schon ein Enddatum festgelegt, zu dem wir mit der Evaluierung fertig sein wollen, um diese Phase nicht zu sehr in die Länge ziehen zu lassen und uns nicht zu sehr in Details zu verlieren. 6 Wochen waren für uns angemessen und im Nachhinein betrachtet auch eine gute Entscheidung. 

Zum Zieltermin sollte die Matrix für alle Systeme und alle Anforderungen vollständig nach dem Punktesystem bewertet und kommentiert sein. Alle Anforderungen sollten zudem alle gewichtet sein.

Der Zieltermin war dann eine Open Space Veranstaltung. Dazu haben wir bereits im Vorfeld eine Umfrage mit einigen Terminvorschlägen und eine Abfrage, wer interesse hätte herumgeschickt. So konnten sich die interessierten Mitarbeiter die Termine rechtzeitig blocken.

4. Die Entscheidung

Irgendwann muss man sich mal endgültig entscheiden. Zu lange Überlegungen hin und her führen nur zu Unklarheiten und binden unnötig Kapazitäten der Mitarbeiter. Außerdem haben sich gerade die betroffenen Mitarbeiter endlich eine Lösung gewünscht. 

Anhand unserer Matrix waren wir zudem auch gut strukturiert und sehr gut vorbereitet.

4.1. Das Problem bei Entscheidungen

Eine Entscheidung für ein und gegen andere Systeme ist nie leicht:

• Langfristige Unternehmensstrategie ist schwierig absehbar und planbar
• Mitarbeiter haben unterschiedliche Präferenzen entwickelt, könnten bei Entscheidung dagegen blockieren
• eine perfekte und fertige Lösung gibt es nicht, irgendwo muss man immer Kompromisse eingehen
• Generell gilt es, die Mitarbeiter mit abzuholen, damit sie mit möglichst viel Motivation ran gehen
• Bei Einbezug von vielen Leuten ist es dagegen schwierig zu einer Einigung und Entscheidung zu kommen
• Wie vermittelt man Leuten, die sich nicht so ausgiebig damit befasst haben und auch nicht die Anwender von kaufmännischen Prozessen sind in aller Kürze die Inhalte von vielen Monaten Recherchearbeit?

Zum Zieltermin hatten wir also einen Open Space für alle Mitarbeiter einberufen. An diesem Abend wurde Pizza und Salate für alle bestellt, die sich angemeldet hatten (und wie immer noch ein “bisschen” mehr).

4.2. Das Format: Ein Open Space

Die Teilnahme an dem Meeting war freiwillig für alle Mitarbeiter. Jeder, der sich dafür interessierte, war herzlich willkommen und eingeladen, sich zu dem Thema einzubringen oder auch nur interessiert zuzuhören. 

Buffet

Es wurde Pizza und Salate bestellt, es gab kostenlose Getränke und auch ein paar süße und salzige Naschereien für später waren vorbereitet.

Teilnahme

Der Termin wurde ja bereits im Vorfeld abgefragt. Da es sich viele Mitarbeiter durch die rechtzeitige Ankündigung terminlich freihalten konnten, haben auch sehr viele Mitarbeiter teilgenommen. Die Quote der Teilnehmenden lag bei uns über 80%!! Daran war auch ersichtlich, wie wichtig und dringend das Thema für viele Mitarbeiter zwischenzeitlich war.

Ablauf

Aus dem grundsätzlich offenen Thema hat sich aus unserem Open Space heraus folgender Ablauf ergeben:

1. Vorstellung des Themas und Erläuterung der Gründe für ein CRM bzw. ERP System durch Vorstand Arnulf Koch
2. Vorstellung der einzelnen Kriterien
3. Vorstellung der einzelnen Lösungen durch diejenigen Mitarbeiter, die das System anhand der Matrix evaluiert haben
4. Bildung von Gruppen, die sich in einer kleineren Gruppe die einzelnen Lösungen noch mal anschauen konnten – jeder die Lösungen, die er interessant fand
5. Ausschluss der Weiterentwicklung des Status Quo
6. Evaluierung und Verdichtung der wichtigsten Kriterien aus der Matrix in einer Präsentation
7. Abstimmung jedes Teilnehmers über eine Lösung
8. Gemeinsames Brainstorming Projektmanagement und Festhalten in der Präsentation, Festhalten der Zusagen zu einzelnen Rollen innerhalb des Projektes
9. Gemeinsames Brainstorming über konkretes weiteres Vorgehen
10. Gemeinsames Brainstorming über Umsetzungsstrategien

Festgehalten wurde der Ablauf und die darin teilweise in Gruppen festgelegten Details in einer Präsentation:

4.3. Die Gründe für ERPNext

Die Gründe, die für uns für ERPNext gesprochen haben waren letztendlich folgende:

1. Framework Frappe
1. Dieses haben wir als sehr gut und sehr flexibel bewertet
2. Lässt sich auch ohne ERPNext für andere Anwendungen verwenden
3. Technisch gut umgesetzt
2. Technik und API
1. Datenschutz durch sehr gutes und flexibles Rechtemanagement sichergestellt
2. Es gibt eine Smartphone App für Android und iOS, läuft flüssig
3. REST API vorhanden, funktioniert auch sehr gut
4. Import und Export über API z.B. als Excel Datei oder CSV problemlos möglich
3. Open Source Lizenz und Community
1. Große und wachsende Community
2. Lebendiges Projekt mit regelmäßigen Updates
3. Commitment der Entwickler zu dauerhaftem und echtem Open Source
4. Vernetzung
1. Anwender in Deutschland gut vernetzt über Telegram Gruppe
2. Regelmäßige Konferenzen zu ERPNext, welche gut besucht sind
3. Mitarbeiter von Frappe und ERPNext sind sehr bemüht und gut erreichbar
5. UI (User Interface = Benutzeroberfläche)
1. Modern, aber nicht so bunt und viel schlichter als z.B. Axelor oder Weclapp 1
2. Es gibt andere Themes für die UI auf Github (z.B. Blue Theme oder Dark Mode)
6. Nutzbarer Grundumfang 2
1. Es sind schon viele Module verwendbar
2. Durch die große Flexibilität muss auch erst noch viel angepasst werden
7. Blocker
1. Technische Spezialisierung der Mitarbeiter bisher mehr auf andere Sprachen
2. Es hat sich aber niemand offen gegen ERPNext ausgesprochen
3. Commitment einiger, Python zu lernen
8. Zeitpunkt Einführung
1. Durch notwendige Anpassungen länger als bei Systemen, die nicht angepasst werden müssen (weil auch nicht so flexibel)
2. Aber kürzer als bei Eigenentwicklung
9. Motivation Mitarbeiter
1. Wäre bei Eigenentwicklung natürlich größer gewesen
2. Durch Open Source Strategie, hinter der auch viele Mitarbeiter stehen war die Motivation doch relativ groß
10. Kosten
1. Überschaubar durch Open Source und keine Lizenzkosten
2. Umsetzung durch Werkstudenten, die Zeit haben, sich in die Technik einzuarbeiten und auch schon Kenntnisse aus Uni / FH mitbringen
3. Realistische Chance, dieses Produkt auch mal als Dienstleistung für Kunden anzubieten 

Was unseren Vorstand von ERPNext überzeugt hat erfahren Sie hier: https://erp-beratung.team/ 

Nachträgliche Anmerkungen:

1 UI hat sich mit Version 13 wieder komplett geändert und ist jetzt noch viel moderner und flexibler geworden

2 Im Nachhinein hat sich herausgestellt, dass viel mehr Prozesse ohne Anpassungen verwendbar waren als anfangs gedacht

Lesen Sie mehr über Version 13 in ERPNext unter https://erpnext.com/version-13

5. Der Prozess

Wie haben wir dann den Entwicklungs- und Einführungsprozess gestaltet? Wer hat welche Rollen übernommen? Wie war der Ablauf?

5.1. Rollen

Im Open Space Meeting hatte sich ja ergeben, dass wir durch unsere guten Erfahrungen, die wir bislang mit agiler Softwareentwicklung gemacht hatten auch dieses interne Projekt agil umsetzen möchten.

Es hat sich herausgestellt, dass es Mitarbeiter aus allen Teams gab, die ein sogenanntes “berechtigtes Interesse” an der Lösung hatten. Das waren also unsere Stakeholder. Die Stakeholder haben grundsätzlich nur Anforderungen, also z.B. “Wir müssen unsere Tickets in einem System pflegen können”, haben aber erst mal keinen Anspruch auf eine hohe Priorität der Anforderung. Der Product Owner kann und soll auch mal “nein” zu einer Anforderung sagen.

Deshalb sollte es zusätzlich noch einen “Super-Stakeholder” geben, unseren Vorstand Arnulf Koch. Er hatte ein Veto-Recht, konnte also den Product Owner bei inhaltlichen und den Technischen Lead bei Design-Entscheidungen jederzeit überstimmen.

Die Anforderungen der Stakeholder mussten von jemandem zusammengetragen, auf Sinnhaftigkeit und Umsetzbarkeit geprüft und priorisiert werden. Das macht in einem agilen Prozess der Product Owner. In einem klassischen Projektmanagement wäre das der Projektleiter. Für diese Aufgabe hat sich Laura Köpl bereit erklärt. Sie war dafür zuständig, aus den Anforderungen der Stakeholder konkrete Userstorys zu schreiben und diese zu priorisieren. Dafür war es auch notwendig, sich in die Prozesse hineinzudenken und so an die bestehenden Logiken in ERPNext anzupassen, dass es für die Stakeholder passt.

Umsetzen sollte das Projekt ein Dev-Team aus den beiden Werkstudenten (Informatik-Studium) in Vollzeit Meike Nedwidek und Dietmar Fischer, sowie drei weiteren erfahrenen Entwicklern mit weniger Kapazität, da alle bereits in Kundenprojekten gebunden waren. 

Zudem sollte es einen Technischen Lead / Coach geben, der die technische Umsetzung überwacht, entsprechende Vorgaben macht, die Effizienz im Projekt sicherstellt und zentraler Ansprechpartner und Entscheider für die technische Umsetzung ist. Zudem hat der Technische Lead auch die Verantwortung für die Architektur und wie das System gehostet wird etc. Diese Aufgabe hat unser langjähriger Mitarbeiter Bernhard Sirlinger übernommen.

Da wir noch viele weitere erfahrene und hochqualifizierte Entwickler haben und viele auch gerne einen Beitrag leisten wollten, wurden noch Technische Berater festgelegt. Diese sollten z.B. den technischen Lead beraten, Konzepte auf Schwachstellen abklopfen und ggfs. bei Bedarf Umsetzungsunterstützung leisten. Das waren bei uns Thomas Leiber und Pascal Herbert, da die beiden ebenfalls auf eine langjährige Erfahrung in vielen verschiedenen Kundenprojekten zurückgreifen können.

5.2. Vorgaben

Von unserem Vorstand und Super-Stakeholder haben wir natürlich auch ein paar Vorgaben bekommen, z.B. bzgl. der Kapazitäten. Das war auch notwendig, da wir alle so motiviert waren, dass wir am liebsten unsere komplette Arbeitszeit nur noch in dieses eine Projekt gesteckt hätten. Doch der Alltag und vor Allem Kundenprojekte durften natürlich auch nicht zu kurz kommen. 

Das waren z.B.:

• Kapazität Product Owner: 4-10h / Woche
• Kapazität Technischer Lead: 4-10h / Woche
• Kapazität Technische Berater: jeweils 2-4 h / Woche
• Kapazität Dev-Team gesamt: 70-100h / Woche, davon Meike und Dietmar je 30-40h und der Rest aufgeteilt auf unsere 3 weiteren Vollzeit-Entwickler

Außerdem hat unser Super-Stakeholder auch die ersten umzusetzenden Module vorgegeben:

1. Redaktionsplan Contenterstellung für das Marketing
2. CRM mit den MVP (Minimal Viable Product) Funktionen und den Umzug der Daten aus unserer jetzt abzulösenden Odoo Community Edition
3. Schnittstelle zu unserer Eigenentwicklung “kkProjekt” für die Zeiterfassung und Projektverwaltung mit Kunden, Projekten und Mitarbeitern
4. Umsetzung der eigentlichen Userstorys und damit der Anforderungen der Stakeholder und bei Core-Änderungen Einreichung dieser als Pull-Requests bei ERPNext

5.3. Wissensaufbau

Zunächst mussten sich vor Allem unsere Werkstudenten in die nötigen Techniken einarbeiten, Wissen über Python vertiefen, sich in das Frappe Framework einarbeiten, wie in ERPNext Customizing funktioniert. Auch unser Technischer Lead hat sein Wissen noch mal vertieft.

Unser Product Owner (PO) Laura Köpl hat diese Zeit inhaltlich genutzt, da auch inhaltlich viel vorbereitet werden musste:

1. In grundlegende ERPNext Prozesse und Logiken einarbeiten
2. Konkrete Anforderungen der Stakeholder aufnehmen
3. Userstorys vorbereiten

Dazu haben wir uns auch mit anderen Nutzern vernetzt (z.B. über die Telegram-Gruppe ERPNext German Chapter etc.), befreundete Unternehmen (ggfs. per Onlinemeeting) besucht, die es produktiv im Einsatz haben und gemeinsam an einer ERPNext Konferenz / Usertreffen in Wiesbaden am 05.11.2019 teilgenommen.

Dazu haben wir uns am 13. November 2019 noch mit zwei Mitarbeitern von ERPNext bzw. Frappe zu einem ganztägigen Austausch bei uns im Haus getroffen. Dazu haben wir auch einige Anforderungen für den deutschen Markt zusammengestellt, welche uns bis dahin aufgefallen sind.

Lesen Sie mehr in unserem Blogbeitrag zu diesem Treffen: https://erp-beratung.team/erpnext-meeting/

Parallel zu diesen Vorbereitungen hat unser Dev-Team die Struktur aufgesetzt:

1. Dev-System (Spielwiese zum Experimentieren und Testen)
2. Staging-System (Releases vom Dev-System mit Daten vom Produktivsystem)
3. Produktiv-System als Live System mit den echten Daten

Außerdem wurde ein Projekt in unserer Quellcodeverwaltung, dem Microsoft Team Foundation Server (TFS) angelegt. Mittlerweile wurde der TFS von Microsoft umbenannt in Azure DevOps (ADO).

6. Die Entwicklung

Nach der sehr aufregenden Anfangszeit, in der wir uns alle erst mal in ERPNext und in die für unsere Rolle jeweils notwendigen Techniken eingearbeitet hatten, uns vernetzt und viele User und Entwickler kennengelernt und auf der ERPNext Konferenz in Wiesbaden waren, haben wir uns voll motiviert in die Arbeit gestürzt und sind auch nach und nach ein perfekt aufeinander eingespieltes Team geworden.

6.1. Product Owner (PO)

Laura Köpl hatte als Product Owner (PO) während der Einarbeitung schon mit den Stakeholdern gesprochen und die ersten Anforderungen aufgenommen. Zusätzlich hat sie selbst schon mit dem CRM Modul gearbeitet und nach und nach festgestellt, wo noch Anpassungen nötig waren.

Damit waren alle Voraussetzungen für den richtigen Start in die Entwicklung gegeben. Der PO hat also alle Anforderungen als Userstorys in Azure DevOps formuliert. Der Status der einzelnen Storys wurde über eine Art Kanban Board im ADO verwaltet. Hier hatten wir uns folgende Spalten eingerichtet:

• New (gedacht als Brainstorming-Liste für den PO und für alle Storys die noch nicht fertig oder noch nicht priorisiert sind)
• Approved (für alle fertigen und priorisierten Storys)
• Work in Progress (für alle durch die Entwickler committeten Storys)
• Testing (für alle fertig umgesetzten Storys, die gerade getestet werden)
• Done (für alle umgesetzten und getesteten Storys, die im Review Meeting durch den PO abgenommen wurden)

Der PO hat also in der Spalte New alle Anforderungen gesammelt, daraus fertige Userstorys erstellt und sie in die Spalte Approved verschoben, sobald sie fertig formuliert waren und dort entsprechend priorisiert. New war also die Spielwiese des PO.

6.2. Dev-Team

Die Entwickler in unserem Dev-Team haben sich dann nach und nach immer die oberste und damit die Story mit der höchsten Priorität zugewiesen (=sich committet), in die Spalte Work in Progress verschoben und umgesetzt. 

Bei inhaltlichen Fragen zu den Storys oder während der Umsetzung haben sich die Entwickler immer direkt an den PO gewandt. Nur in Ausnahmefällen direkt an einen Stakeholder bzw. unseren Super-Stakeholder. 

Technische Fragen wurden meist direkt mit dem Technischen Lead besprochen. 

Sobald der Entwickler seine Story fertig umgesetzt hatte, wurde sie in die Spalte Testing verschoben und immer konsequent durch einen anderen Entwickler getestet.

Immer wenn mehr als 10 Storys fertig getestet waren, haben wir ein Review Meeting angesetzt. Darin haben die Entwickler ihre umgesetzten Storys dem PO vorgestellt. Sofern alle Akzeptanzkriterien erfüllt waren, hat dieser die Story abgenommen und auf Done verschoben.

6.3. Module

Welche Module haben wir anfangs umgesetzt, wo haben wir Anpassungen für uns gemacht?

6.3.1. HR: Verwaltung der Mitarbeiter

Das HR Modul in ERPNext ist sehr komplex. Es lassen sich viele verschiedene Prozesse damit abbilden, z.B. die Zeiterfassung, Urlaubsverwaltung, Offene Stellen und Bewerber, Onboarding, Gehaltsabrechnungen, Aus- und Weiterbildung der Mitarbeiter, Bewertung und Feedback, Schichtverwaltung, Ressourcenplanung, Teams, Abteilungen und viele weitere. Grundlage für alles und für alle weiteren Prozesse ist aber zunächst die reine Verwaltung der Mitarbeiter. Theoretisch können auch einfach nur die Namen und ggfs. User angelegt werden. Wir haben uns jedoch dafür entschieden, jeden Mitarbeiter gleich komplett mit allen Daten anzulegen. Ein deutlicher Mehrwert sind oft die kleinen Dinge: viele haben sich gefreut, dass wir jetzt einen Notfallkontakt hinterlegen können. An solche Kleinigkeiten haben wir früher gar nicht gedacht.

6.3.2. Marketing Modul

Zunächst haben wir begonnen, ein bereits fertig entwickeltes Marketing Modul der befreundeten Firma Seibert Media bei uns zu implementieren. Zunächst haben wir es so übernommen, wie es bei Seibert im Einsatz war und nur wenige Daten angepasst. Es war auch als erstes Lernprojekt für unsere Werkstudenten gedacht, um das Framework Frappe und seine Möglichkeiten besser kennenzulernen. Im Laufe der Zeit und während es auch schon im Einsatz war, haben wir daran noch Anpassungen gemacht, z.B. Felder gestrichen, umsortiert oder neue Felder hinzugefügt.

Unsere Theresa Baumann durfte sich nach Fertigstellung des Moduls als erste Mitarbeiterin, die nicht an der Entwicklung beteiligt war in ERPNext einloggen, um das Modul zu testen. Lesen Sie mehr darüber in unserem Beitrag: https://erp-beratung.team/premiere-im-erpnext-system/

6.3.3. CRM Modul

Außerdem haben wir Anpassungen am CRM gemacht. 

Wir haben die Verkaufsphasen unseres Vertriebstrichters implementiert, sodass wir ein Kanban Board danach bauen können. 

Außerdem haben wir uns die Wiedervorlagen angepasst. Darin können wir jetzt z.B. unterschiedliche Aufgabentypen (Anrufen, E-Mail schicken, Angebot erstellen, nachfassen, Vorstellungstermin etc.) angeben, um dann später danach auswerten zu können. Es gibt auch eine farbige Markierung der Wiedervorlagen: Abgelaufene Wiedervorlagen werden nun rot angezeigt, heute fällige orange und die welche in der Zukunft liegen grün.

6.3.4. Kampagnen

Auch die Kampagnen haben wir uns angesehen. In einem späteren Schritt wollen wir unterschiedliche Kampagnen starten können, z.B. alle Geschäftsführer von Kunden anschreiben, wenn ihr Server veraltet ist oder Lizenzen verlängert werden müssen, um dies nicht mehr manuell machen zu müssen und uns so Arbeit zu sparen. Das ist unser großes Ziel mit den Kampagnen.

Zuerst wollten wir allerdings einfach unsere bestehenden Excellisten in ERPNext importieren können. Dazu war es in einem ersten Schritt wichtig, dass wir Kunden, Leads und Kontakte zu einer Kampagne hinzufügen können. So etwas geht zwar schon von Grund auf in ERPNext, wird aber nicht im Lead und Kunden angezeigt. Daher haben wir uns ein neues Doctype für die Kampagnen gebaut. Diese werden jetzt direkt im entsprechenden Doctype angezeigt und können darin auch direkt hinzugefügt werden.

Dann haben wir uns ein Script geschrieben, welches prüft, ob es den Lead, Kunde oder Kontakt schon gibt. Falls ja, hat es ihn zur Kampagne hinzugefügt. Falls nicht wurde er komplett neu angelegt.

6.3.5. Vertragsmanagement

In ERPNext kann man von Grund auf schon unterschiedliche Verträge verwalten:

Mit Abonnement-Plänen können wir z.B. unsere unterschiedlichen Arten von Wartungsverträgen erfassen und pflegen. Für jeden einzelnen Kunden legt man dann aus dem Abonnement-Plan ein Abonnement an. 

Sehr individuelle Verträge wie z.B. Rahmenverträge können über “Verträge” im CRM Modul gepflegt werden. Es kann ein Gruppen-Typ ausgewählt werden (z.B. Mitarbeiter, Lieferant oder Kunde), wir können kennzeichnen, ob der Vertrag bereits unterschrieben wurde und wir können ihn mit einer speziellen Referenz verknüpfen.

6.3.6. Rechtemanagement

Wir haben uns intensiv mit dem Rechtemanagement in ERPNext auseinandergesetzt. Es gibt bereits sehr viele mit Rechten vorbelegte Rollen. Rechte können in verschiedenen Stufen bzw. für verschiedene Ebenen vergeben werden. Zusätzlich könnte man Rollenprofile anlegen, was wir als kleinerer mittelständischer Betrieb aber noch nicht gebraucht haben. Wir haben zunächst einmal jedem Mitarbeiter nur die recht eingeschränkte Rolle “Mitarbeiter” zugewiesen und dem ERPNext Team die Rolle “Systemmanager”, welche quasi Vollzugriff aufs System hat. Daraufhin mussten wir aber immer wieder mal Rechte anpassen, da wir immer wieder das Problem gemeldet bekommen haben, dass jemand Rechte benötigt, die er nicht hat. Deshalb hat unsere PO nach einigen Prozessen alle Rechte angepasst. Sie ist dabei immer vom Prozess ausgegangen und nicht vom Mitarbeiter, hat also überlegt, welche Doctypes zu einem Prozess gehören und welche Mitarbeiter auf diese Doctypes welchen Zugriff brauchen. Daraufhin haben wir beschlossen, dass das Rechtemanagement immer zum jeweiligen Prozess gehört und der Product Owner zusammen mit dem Prozess Owner dieses für den Prozess festlegen muss, bevor der Prozess eingeführt wird.

6.4. Fazit

So haben wir anfangs in vielen verschiedenen Bereichen und Modulen in ERPNext Anpassungen gemacht und dadurch auch viel gelernt. Jeder hat sich gut in seine Rolle eingefunden, wir haben alle voneinander gelernt und sind zu einem richtigen gut aufeinander eingespielten Team zusammengewachsen.

Im Januar 2020 haben wir außerdem ein Meeting mit allen interessierten Mitarbeitern durchgeführt. Lesen Sie mehr dazu in unserem eigenen Beitrag darüber: https://erp-beratung.team/status-erpnext-bei-kk-software-ag/

7. Der Crash

Erfahrene Scrum-Master, Product Owner oder Entwickler haben beim Lesen des letzten Kapitels vielleicht schon die Fehler bemerkt.

7.1. Beobachtung

Im Frühjahr 2020 waren die Praktikumsphasen unserer beiden Werkstudenten um. Beide wollten an dem Projekt weiterarbeiten, konnten allerdings nur noch eine begrenzte Stundenanzahl leisten. Bis dahin hatten wir allerdings keinen einzigen Prozess richtig fertig. An allen Stellen gab es noch Verbesserungspotenzial. 

Dazu kam, dass umgesetzte Storys selten von den tatsächlichen Anwendern getestet wurden. Für das Team waren einige Prozesse fertig, da alle dem PO kommunizierten Anforderungen umgesetzt waren. Dennoch wurden viele Prozesse nicht wirklich verwendet. Die Anwender blieben z.B. irgendwie doch bei ihren alten Tools. Wie es eben im Tagesgeschäft meistens so läuft. Realistisch ist es selten einfach, ein neues Tool einzuführen, da geht es uns in der IT genauso wie in anderen Branchen auch. 

Die Unzufriedenheit wuchs in allen Bereichen:

Das gesamte ERPNext-Team war unzufrieden, weil die Prozesse nicht angenommen wurden. Außerdem hatte sich unser Super-Stakeholder ein bisschen viel eingemischt. 

Unsere Product Ownerin war unzufrieden, weil keine genauen Anforderungen von den Anwendern kamen und es sehr aufwändig war, sich in die Prozesse der einzelnen Bereiche hineinzudenken, wenn man im Tagesgeschäft nichts damit zu tun hat. 

Die Anwender waren unzufrieden, da die Prozesse in den gewohnten Tools doch irgendwie für sie durchdachter waren und man sich sehr umgewöhnen musste. 

Und nicht zuletzt unser Vorstand und Super-Stakeholder, der unzufrieden war, weil jetzt schon so viel Zeit in ERPNext geflossen war und doch noch keine richtigen Ergebnisse zu sehen waren.

7.2. Identifizierung

Wir mussten also evaluieren, woher die Probleme kamen. Dazu haben wir uns im ERPNext Team unsere Scrum Masterin des A-Teams (Theresa Baumann) quasi “ausgeliehen” und mit ihr eine Retrospektive durchgeführt.

Daher werden wir hier nicht auf die Details eingehen. Doch ein paar Dinge waren auch außerhalb der Retrospektive schon klar und werden erfahrenen Projektmanagern sowieso auffallen:

• Wir haben Scrum nicht richtig angewendet:

• Kein Scrum-Master
• Keine feste Sprintlänge
• Keine Planning Meetings
• Keine Refinement Meetings
• Erste Retrospektive erst nach einigen Monaten
• Kein Schätzen von Userstorys
• Userstorys sind zu lange und umfangreich

• Wir haben zu chaotisch an zu vielen Prozessen gleichzeitig gearbeitet:

• Super Stakeholder hatte zu viele Ideen gleichzeitig
• Zu viele Meetings zu zu vielen Ideen mit dem Super Stakeholder
• PO hat zu selten “nein” gesagt
• Einen Prozess nach dem anderen umsetzen

• Wir haben die Anwender zu wenig einbezogen:

• Keine Verantwortlichkeiten für die Prozesseinführung in ERPNext 
• Kein konsequentes Testen
• Keine Verantwortung für Eingabe von Daten festgelegt

Wir haben daher in der Retrospektive im Team eine kleine Maßnahmenliste erarbeitet (die im Scrum auch kommuniziert werden darf):

1. Für Meetings Agenda vorbereiten 
2. Wolfgang Lutz ist ab sofort “Schätzmeister”
3. Nächste Retro in 1-2 Monaten
4. Die Rolle des Super Stakeholders hat sich nicht bewährt, entweder dann PO oder nur normaler Stakeholder → Scrum Master leitet Gespräch ein
5. Timeboxen für Meetings einführen

8. Die Lösung

Unsere Scrum Masterin hat sich daraufhin mit unserem Vorstand und Super Stakeholder zusammengesetzt und ihm gegenüber die Ergebnisse aus der Retrospektive und die Wünsche des Teams kommuniziert. Daraus hat sich im Juni 2020 ein Committment und neue Zielvorgaben von unserem Vorstand ergeben.

8.1. Ein neuer Ansatz

Die Übereinkunft aus einer Präsentation des Vorstands und darauffolgenden gemeinsamen Gesprächen waren folgende:

• Iterationen / Sprints einführen

• Storys konsequent abschätzen

• Es wird nur noch ein Prozess gleichzeitig umgesetzt

• Für jeden Prozess verantwortliche Personen und Stakeholder suchen und benennen

• Es gibt eine Definition, wann ein Prozess fertig umgesetzt ist (auch im MVP)

Um diese Ziele zu erreichen, haben wir uns eine Matrix in Excel bzw. Google Tabellen gebaut:

Diese war in 7 Bereiche aufgeteilt:

8.2. Ergebnis

Wir hatten ja bereits nach unserer Retrospektive begonnen, Scrum auch richtig umzusetzen und uns nicht nur die angenehmen Teile im Scrum herauszupicken. Dies hatte schon mal zur Folge, dass unser PO die Komplexität der einzelnen Storys viel besser einschätzen konnte. Daraufhin wurden die Storys schon deutlich kürzer und überschaubarer, was insgesamt zu einer höheren Zufriedenheit der Entwickler geführt hat.

Durch die Einführung der Iterationen / Sprints konnte unsere Product Ownerin auch viel bessere Aussagen gegenüber den Stakeholdern und dem Vorstand treffen, was sie wiederum schon um einiges zufriedener gemacht hat.

Unsere Product Ownerin hat anschließend einzelne Unternehmensprozesse und Module bzw. Prozesse in ERPNext selbst identifiziert und in die Prozess-Matrix eingetragen. Dann hat sie mit allen Mitarbeitern gesprochen, um herauszufinden, wer sich bereit erklärt, die Verantwortung für die Akzeptanzkriterien und die Einführung sowie das Testing der einzelnen Prozesse zu übernehmen.

Dabei waren wir uns alle einig, dass ein Prozess nicht in ERPNext umgesetzt wird, wenn sich niemand findet, der diese Aufgabe übernimmt. 

Einen großen Anteil hat unsere PO natürlich auch selbst übernommen, vor Allem in den Bereichen, in denen sie auch im Tagesgeschäft verantwortlich ist, z.B. im CRM, Stammdaten, Kampagnen, Newsletter oder Vertragsverwaltung.

Außerdem wurden natürlich auch die bereits fertiggestellten oder angefangenen Prozesse aufgelistet, um zu identifizieren, ob diese umgesetzt waren und um die Einführung voranzutreiben.

Nun haben wir tatsächlich viele Prozess Owner gefunden, einen zu jedem wichtigen Prozess. Außerdem hat sich dieser Prozess Owner mit Unterstützung der Product Ownerin noch ein paar Stakeholder gesucht. Das macht z.B. Sinn beim Ticketsystem: wenn hier jemand aus dem TeamX den Prozess Owner übernimmt, werden sonst die Anforderungen aus dem Systemhaus nicht berücksichtigt und umgekehrt.

So haben sich dann die ersten Prozess Owner mit Unterstützung unserer PO in den Default Prozess eingearbeitet, die genauen Anforderungen bzw. Akzeptanzkriterien evaluiert und dementsprechend die Prozess-Matrix ausgefüllt, oft gemeinsam mit unserer PO. Diese hat also viel mehr Input durch die Stakeholder insgesamt bekommen und so konnte sie auch wiederum viel mehr Zeit in das Schreiben der Userstorys investieren. Dadurch stieg sowohl nochmals die Zufriedenheit im Team als auch bei unserer PO um ein Vielfaches.

9. Aktueller Stand

Wo stehen wir aktuell? Wie weit sind wir mit der internen Einführung gekommen?

Diese Liste halten wir laufend aktuell. Eingeführte Prozesse rutschen dann nach oben zu den “Weiteren umgesetzten Prozessen” und neu hinzugekommene anstehende Prozesse werden wir unten mit aufführen.

Zusätzlich zu Prozessen stehen aber auch immer mal technische Arbeiten an, wie z.B. die Migration auf eine neue Version (aktuell von 12 auf 13). Zusätzlich haben wir jetzt mittlerweile schon mit Kundenprojekten gestartet. Deshalb werden wir mit unserer internen Einführung manchmal leider nicht so schnell vorankommen, wie wir es uns vielleicht wünschen würden.

9.1. Weitere umgesetzte Prozesse

Mittlerweile führen wir ja die Prozessliste, in der die Prozesse ganz klar priorisiert sind. Wir haben gelernt, wie wichtig es ist, einen Prozess nach dem anderen einzuführen (“Getting things done”).

9.1.1. Weiterentwicklung Marketingmodul Schritt 1

Ganz agil haben wir das bereits eingeführte Marketingmodul nach dem Anwenderfeedback noch mal angepasst. So kann nun z.B. der Wert eines Beitrages anhand des Typs und des Themas berechnet werden. Doch nicht benötigte Felder wurden entfernt und dynamische Felder eingefügt, welche nur unter bestimmten Bedingungen auftauchen, z.B. wenn in einem anderen Feld ein bestimmter Wert ausgewählt wurde. Zudem wurden Abschnitte umsortiert und insgesamt das komplette Doctype übersichtlicher gestaltet.

9.1.2. Dashboard Zusammenarbeit Teams und Vertrieb

Eines unserer Umsetzungsteams kam mit dem Wunsch nach einer Lösung auf uns zu. Hintergrund war, dass es in diesem Team sehr viele kleinere Kunden und Projekte gibt. Daher verliert das Team häufig den Überblick, welche Chancen jetzt noch offen sind und wie da der aktuelle Status ist. Außerdem würde das Team gerne bei einzelnen Chancen erst ein Veto einlegen, wenn es z.B. vor der Kontaktaufnahme noch Klärungsbedarf gibt.

Wir haben also ein Dashboard gebaut, mit dem das Team sich mit vielen verschiedenen Möglichkeiten seine Chancen filtern und anzeigen lassen kann. Vieles davon wäre in ERPNext zwar auch gegangen, aber so können wir z.B. Leads und Chancen auf einer Seite anzeigen.

9.1.3. Management der Urlaubs- und Krankheitstage

Ein wichtiges Anliegen unseres Vorstandes war auch, dass wir die Urlaubs- und Krankheitstage aller Mitarbeiter einheitlich verwalten können. Bislang hatten wir Urlaube über Termine genehmigt und diese wurden dann von unserer Verwaltung in einem Urlaubskalender gepflegt. Eine Umstellung auf ERPNext hatte auch den Vorteil, dass wir so endlich einen Prozess eingeführt hatten, den alle Mitarbeiter nutzen würden. 

Nun können unsere Mitarbeiter in ERPNext ihren aktuellen Urlaubsanspruch sehen, Urlaub eintragen und die Urlaubsgenehmiger können den Urlaub genehmigen. Dazu gibt es verschiedene Urlaubstypen, z.B. Erholungsurlaub oder Sonderurlaub. Zusätzlich kann unsere Verwaltung darin über einen entsprechenden Urlaubstype auch Krankheitstage pflegen sowie unsere Azubis ihre Berufsschultage.

Auch zu diesem Prozess haben wir Dashboards in Redash umgesetzt: Ein nicht öffentliches mit allen Urlaubstypen für den Vorstand und weitere Urlaubsgenehmiger, sowie ein unternehmensöffentliches für alle Mitarbeiter, in dem man nur Abwesendheitszeiten sieht, um DSGVO-konform zu sein.

9.1.4. Kundenstammdaten

Wichtig war uns auch, unsere teamspezifischen Kundenstammdaten einheitlich pflegen zu können. Viele Felder sind in ERPNext ja schon gegeben. Diese sind aber meist eher allgemein und weniger branchenspezifisch. Es können aber ganz leicht neue Felder, dynamische Felder, Dropdown-Felder oder auch Tabellen hinzugefügt werden. Außerdem können einklappbare oder nicht einklappbare Bereiche hinzugefügt werden. 

Da für alle unsere Teams unterschiedliche spezifische Daten wichtig sind, hat also jedes Team einen eigenen einklappbaren Bereich im Kunden bekommen (siehe unten Bespiele der Umsetzungsteams, aber auch für die Verwaltung gab es neue Bereiche). Außerdem wurden nicht benötigte Felder entfernt und das komplette Doctype durch die neue Aufteilung übersichtlicher gestaltet.

Oben: Daten für unser TeamX (verwendetes CMS und Hosting)

Unten: Daten für unser A-Team (v.A. bzgl. agilem Projektmanagement)

Unten: Daten für unser Systemhaus (technische Daten zum Netzwerk)

9.1.5. Automatische Domainabrechnung mit Cloudflare-API

Wir verwalten für unsere Kunden ca. 800 Domains. Diese werden in unterschiedlichen Intervallen abgerechnet, z.B. monatlich, quartalsweise, jährlich oder alle 2 Jahre. Sie sind dazu noch bei verschiedenen Registraren und DNS Providern gelistet, was sowohl die Rechnungsprüfung als auch die Fakturierung aufwändig und kompliziert macht. 

Früher haben wir die Daten der Domains manuell in Listen geführt und bei Cloudware und Schlundtech abgeglichen. 

Mit Hilfe einer Automatisierung sorgen wir heute für eine Entlastung unserer Buchhaltung:

Wir haben uns hierfür ein eigenes Doctype “Domains” erstellt. Hostingverträge unserer Kunden pflegen wir über die Abonnements. Eine Domain ist jeweils mit dem Kunden und dessen Hostingvertrag = Abonnement verknüpft. Vorlagen für die Abonnements werden in den Abonnement-Plänen gepflegt. 

Zuletzt haben wir eine Schnittstelle zu Cloudflare programmiert, um die Domains nicht manuell pflegen zu müssen. Die Schnittstelle ruft täglich alle Daten ab. So werden auch die z.B. gekündigten oder geänderten Domains durch eine entsprechende Kennzeichnung berücksichtigt.

Außerdem gibt es natürlich wie immer ein Dashboard, in welchem wir die Domains mit Handlungsbedarf sowie den richtigen Verknüpfungen einsehen, deren Anteil vergleichen und die Webhosting Rechnungen und Umsätze überwachen können.

Oben: Beispiel Abonnement

Unten: Beispiel Domain

Unten: Beispiel Dashboard Domains mit Handlungsbedarf

9.2. Prozesse in Arbeit und nächste Prozesse

Natürlich haben wir immer schon viele weitere Prozesse in Planung. Zuerst brauchen wir immer einen Stakeholder bzw. Prozess Owner, der die Anforderungen des Prozesses genau kennt und diese Anforderungen an den Product Owner heranträgt. 

Darin steckt oft viel mehr Aufwand. Diese Aufgabe sollte nicht unterschätzt werden, da der “Teufel häufig im Detail liegt”, wie man so schön sagt.

9.2.1. Automatische USt.IDNr. Abfrage beim Bundeszentralregister

Natürlich hat im Zuge des Prozesses zur Stammdatenpflege und der automatisierten Domainabrechnungen auch unsere Buchhaltung einen eigenen Bereich im Kunden bekommen. Zunächst fiel eine Sache gar nicht auf (hier lag der Teufel wirklich im Detail): 

Viele unserer Hosting-Kunden sitzen in einem EG oder Drittland. Für sie müssen wir vor der ersten Rechnungsstellung und dann einmal jährlich manuell die USt.IDNr. beim Bundeszentralregister abfragen. Dazu gibt es z.B. in Lexware einen Button, mit welchem die jeweilige Nummer über die API des Bundeszentralregisters abgefragt werden kann. 

Um den Prozess noch weiter zu vereinfachen und mehr zu automatisieren, werden wir ein Skript schreiben, welches die USt.IDNr. einmal jährlich automatisch beim Bundeszentralregister abfragt und zwar für alle Kunden im EG oder Drittland. Ohne dass jemand in der Buchhaltung daran denken muss.

Die Anforderungen sind mittlerweile definiert und die ersten Userstorys sind geschrieben und umgesetzt. Da dies ein recht kleiner Prozess ist und von ihm die tatsächliche und vollständige Einführung des Domainabrechnungsprozesses abhängt, werden wir ihn zügig umgesetzt haben.

9.2.2. Verbesserungen CRM Modul

Im CRM Modul haben wir ja schon viele Anpassungen gemacht. Es war nach dem Marketing-Modul der zweite Prozess, den wir uns anfangs angepasst hatten. Deshalb ist er auch schon seit Anfang 2020 produktiv im Einsatz und funktioniert auch sehr gut.

Dennoch fehlen uns noch ein paar Kleinigkeiten in ERPNext. Meist sind es kleinere Einstellungen, wie die Anzeige des genauen Datums im Kommentar statt z.B. “vor 2 Monaten”. Zudem soll das Rechtemanagement verfeinert werden. Wichtigen Punkt für die Vertriebsleitung und den Vorstand: Aktuell gibt es noch kein Dashboard für ein Vertriebsreporting. Die Festlegung, dass ein Prozess immer erst fertig ist, wenn es ein Dashboard gibt, haben wir ja erst nach der Einführung des Vertriebsprozesses getroffen.

9.2.3. Angebotserstellung

Sobald das CRM Modul passt wollen wir bald darauf auch unsere Angebote in ERPNext pflegen. Aktuell schreiben wir unsere Angebote noch entweder in Lexware oder in Google Docs. Unsere Angebote sind durch die individuellen Dienstleistungen generell sehr komplex. Außerdem gibt es einige Vorlagen, die wir dann immer speziell für unsere Kunden anpassen. 

Bis auf die Angebotsvorlagen sind wahrscheinlich schon alle Anforderungen in ERPNext enthalten. Für die Vorlagen müssten wir uns also noch ein Konzept überlegen, wie wir diese am besten in ERPNext abbilden können.

Ansonsten müssten noch alle Artikel entsprechend angelegt werden. Zudem ist es auch immer wichtig, mit den einzelnen Teams zu sprechen, welche Anforderungen sie jeweils haben.

Aber auch hier ist es (wie bei allen Prozessen, die mehrere Teams mit unterschiedlichen Anforderungen betreffen) wichtig, Schritt für Schritt vorzugehen. Erst wollen wir die Angebote für ein Team abbilden, dann für das nächste usw.

9.2.4. Abrechnung und Pflege der Wartungsverträge

Nach den Domains wollen wir natürlich auch die Wartungsverträge unserer Kunden in ERPNext pflegen und fakturieren. Mit den Domainabrechnungen haben wir ja quasi schon den Weg geebnet. 

Hauptsächlich müssen wir für die unterschiedlichen Arten der Wartungsverträge und teilweise auch Support-Level Abonnement-Pläne anlegen. Hier werden wir uns allerdings unsere Teams mit ihren verschiedenen Vertrags-Modellen nach und nach vornehmen. Zunächst wird das unser TeamX sein mit ihren Wartungsverträgen für ihre Webseiten. Diese können wir dann auch mit den Domains verknüpfen, was wir beim Domainabrechnungsprozess schon berücksichtigt hatten. Danach werden wir die Wartungsverträge für unsere ERPNext Rechnungen umsetzen. Anschließend kommen noch unser A-Team und unser Systemhaus dran.

Alle Wartungsverträge mit einem festen Betrag pro Intervall werden wir über die Abonnements pflegen. Alle Verträge mit flexiblem Stundenkontingent, welches wir je nach Aufwand abrechnen über die Service Level Agreements.

9.2.5. Pflege restliche Verträge (außer Wartungsverträge)

Auch alle anderen Verträge können über ERPNext verwaltet werden, z.B.:

• Rahmenverträge
• AV-Verträge
• Geheimhaltungsvereinbarungen / NDA’s

Hierfür gibt es im CRM-Modul den Punkt “Vertrag”. Es können auch Vertragsvorlagen erstellt werden. Diese müssen für alle unsere Standardverträge erstellt werden, die nicht über die Abonnement-Pläne oder Service Level Agreements abgebildet werden. Zudem muss noch evaluiert werden, ob uns noch Felder oder sonstige Funktionen fehlen, die noch implementiert werden müssen.

9.2.6. Bewerbermanagement

Wie viele andere Firmen auch bekommen wir oft sehr viele Bewerbungen und pflegen unsere offenen Stellen in vielen verschiedenen Portalen.

Bislang kommen die Bewerbungen über unser eigenes Postfach bewerbung@kk-software.de an. Wir nehmen schon ausschließlich digitale Bewerbungen per Mail an. Im Postfach werden diese dann nach Status in Ordner verschoben, was recht aufwändig ist und leider nicht nachvollzogen werden kann.

ERPNext bietet uns schon fast alle Funktionen, die wir brauchen. Auch Vorlagen für Mails können hinterlegt werden, z.B. für Absagen oder Zusagen zum Vorstellungsgespräch.

Wir können offene Stellen pflegen, Bewerber anlegen, unser Vorstand kann im Vorstellungsgespräch vereinbarte Vertragsinhalte kurz und knapp festhalten und die Personalabteilung im Nachhinein den Arbeitsvertrag erstellen.

Den meisten Aufwand wird die automatische Anbindung an unser Bewerbungspostfach machen. Wir möchten, dass Bewerber automatisch angelegt werden und die Personalabteilung informiert wird, wenn eine neue Bewerbung eingegangen ist. Der Bewerber soll eine automatische Eingangsbestätigung erhalten.

9.2.7. Ticketsystem

Bislang nutzt jedes unserer Teams ein eigenes Ticketsystem. Natürlich sind die verwendeten Lösungen auf den jeweiligen Fachbereich der Teams ausgelegt. 

Wir müssen daher die Tickets einerseits vereinheitlichen. Dann müssen diese automatisch den verschiedenen Teams zugeordnet werden können. Tickets müssen automatisch angelegt werden, wenn der Kunde eine Mail an die jeweilige Adresse schickt. Und nicht zuletzt muss das Ticketsystem mindestens die gleichen Funktionen bei einer ähnlich einfachen Anwendung bieten. 

ERPNext bietet schon ein umfangreiches Ticketsystem. Allerdings müssen wir Schritt für Schritt vorgehen und erst mal ein Team auf ERPNext umstellen. Danach dann das nächste Team und so weiter. Nur so kann die Einführung funktionieren. Vorher muss natürlich evaluiert werden, welche Funktionen wirklich genutzt werden und sinnvoll sind.

9.2.8. E-Mail Kampagnen und Newsletter

Schon lange ist es bei uns ein Thema, Newsletter an unsere Kunden zu schicken. Aktuell können wir zwar Serienmails über Supermailer versenden. Das macht aber dennoch viel manuellen Aufwand, z.B. die relevanten Ansprechpartner herausfiltern. 

Wir würden aber Kunden gerne in Zukunft automatisiert an bestimmte Ereignisse erinnern, z.B. wenn der Server eine gewisse Zeit alt ist, wenn es Updates von Systemen gibt oder wenn ein neuer Mitarbeiter zuständig ist.
Dazu möchten wir nach der Position unserer Kontakte bei unseren Kunden filtern. Manche Informationen sollte z.B. nur der Geschäftsführer bekommen, andere braucht wiederum eher der Vertriebsleiter. So müssen wir nicht alle Ansprechpartner anschreiben, sondern können speziell die kontaktieren, die die Information auch brauchen.

Auch weitere Filter nach Feldern im Kunden werden wir brauchen, z.B. Alter des Servers, Branche des Kunden, Anzahl Clients oder bestimmte eingesetzte Software.

Für diesen Prozess gibt es zwar schon ein kleines Modul in ERPNext. Es müssen allerdings dennoch erst einige Felder und Funktionen implementiert werden, bevor wir es so nutzen können, wie wir möchten, z.B. der automatische Filter und das automatische Hinzufügen zu einer Kampagne. 

Daher ist der Prozess vorerst etwas weiter nach hinten priorisiert.

9.2.9. Fuhrparkmanagement

Da wir mit unseren 3 Fahrzeugen und einem Anhänger keinen richtig großen Fuhrpark haben, hatten wir bisher nie einen großen Fokus auf diesen Prozess gelegt. Einige gesetzliche Bestimmungen müssen natürlich dennoch eingehalten werden, z.B. die regelmäßige Prüfung der Führerscheine der Mitarbeiter, die die Fahrzeuge nutzen. Allerdings ist die manuelle Verwaltung z.B. der Leasingverträge oder die Überwachung von Werkstattterminen der Fahrzeuge immer recht aufwändig. 

ERPNext hat aber für einige Bestandteile des Fuhrparkmanagements schon Funktionalitäten integriert. So kann man bereits ohne Anpassungen schon Fahrzeuge anlegen, Fahrer und Versicherungen hinterlegen, Tankrechnungen zuordnen oder Serviceleistungen überwachen. So kann man sich auch die Kosten zu den einzelnen Fahrzeugen auswerten lassen.

Wir möchten auf dieser Basis noch die deutschen gesetzlichen Bestimmungen implementieren (z.B. Prüfung der Führerscheine) und uns an fällige Termine für HU / AU oder Inspektionen bzw. Reifenwechsel erinnern lassen.

9.2.10. Projektmanagement

Das Projektmanagement ist ein sehr umfangreiches Modul. Hiermit können so viele Prozesse abgebildet werden. 

ERPNext bietet hier schon extrem umfangreiche Features. Es können natürlich Projekte angelegt werden, darunter auch Aufgaben mit verschiedenen zeitlichen Abhängigkeiten oder Abhängigkeiten untereinander. 

Es gibt verschiedene Projekttypen und auch Vorlagen für Projekte können angelegt werden, um gerade bei längeren oder umfangreicheren Projekten nicht alle Aufgaben neu anlegen zu müssen. Dazu kann bei Bedarf auch die Zeiterfassung an das Projektmanagement geknüpft werden. 

Alle Projekte können zusammen als Bericht, als Liste oder in konfigurierbaren Kanban-Boards dargestellt werden. Ein einzelnes Projekt kann man sich zusätzlich noch als Baum, Kalender oder sogar Gantt-Diagramm anzeigen lassen.

Innerhalb der Projekte lassen sich auch sehr viele Dinge pflegen und auswerten, daher hier nur ein kleiner Auszug:

• Grundlegende Informationen wie Status, Typ, Start- und Enddatum, Priorität und zugeordnete Abteilung
• Aufgaben in verschiedenen Ebenen und / oder Abhängigkeiten zueinander
• Anfragen, Ausgaben und Aufwandsabrechnungen
• Kundendaten inkl. Zuordnung zu Kunden, Kundenaufträge, Lieferscheine und Ausgangsrechnungen
• Materialanfragen, Stücklisten und Lagerbuchungen
• Lieferantenaufträge, Kaufbelege und Eingangsrechnungen
• Projektkalkulation, Abrechnung und Berechnung der Marge
• Überwachung von Fortschritten

Wie bei allen Doctypes in ERPNext kann man natürlich auch hier Mitarbeiter zuordnen, Anhänge hinterlegen, Bewertungen und Kommentare hinterlassen oder Schlagworte vergeben. 

In den einzelnen Aufgaben und allen anderen Doctypes lassen sich ebenfalls verschiedene Daten pflegen.

Für die IT-ler: natürlich ist ERPNext keine Quellcodeverwaltung oder Repository wie Gitlab oder Microsoft Azure DevOps. Daher werden wir ERPNext auch nicht dafür verwenden. Zunächst müssen auch erstmal bestimmte Projekte der Verwaltung abgebildet und damit zumindest ein Teil der in einer Vielzahl verwendeten Tools wie Asana, Mirosoft Project, Trello oder Google Docs bzw. Google Tabellen abgelöst werden. Sehr gerne würden wir unsere Veranstaltungen damit planen und so auch besser im Team organisieren. Da uns allerdings die Pandemie unsere Pläne bzgl. Veranstaltungen ein bisschen umgeworfen hat, haben wir den Prozess aktuell auch etwas weiter nach hinten priorisiert. 

Das Projektmanagement ist also ein riesiger Prozess, den wir unbedingt in kleinere Teile aufsplitten müssen. Natürlich sind auch weitere Prozesse denkbar bzw. werden auch ganz sicher kommen. Auch eine Anbindung an weitere Tools in unserem Haus war bereits angedacht und ist noch nicht verworfen. Aber immer Schritt für Schritt 😉

9.2.11. Eventmanagement

Wie bereits beim Projektmanagement beschrieben hängt die Organisation von Veranstaltungen sehr mit dem Projektmanagement zusammen. Die Planung findet aktuell teilweise in Asana oder über Google Docs oder Google Tabellen statt. Dabei gibt es aber keine Vorlagenfunktion. ToDos müssen daher immer wieder neu eingepflegt und zugeordnet werden. Nach der Veranstaltung werden oft die Lessons Learned notiert, aber im nächsten Jahr dann vielleicht nicht mehr beachtet.

Hier möchte ich allerdings noch etwas mehr auf unsere Anforderungen eingehen:

• ToDos für Veranstaltungen inkl. Zuordnung zu Mitarbeitern und Fälligkeitsdatum managen 
• Vorlagen für verschiedene (aber sich wiederholende) Veranstaltungstypen
• Marketing und Verwaltung brauchen einen Überblick über die Veranstaltung und eine einfachere Planung
• Der Vorstand braucht einen Überblick über Status der Planung und Details zur Organisation
• Wir wollen Kunden hinterlegen und Anmeldungen überwachen und pflegen

Natürlich muss für das Eventmanagement erst mal einiges am Projektmanagement angepasst oder erweitert werden. Zunächst wird unser PO Laura aber wie immer prüfen, wie man möglichst nah am eigentlichen System den Prozess abbilden kann, also mit möglichst wenig Anpassungen und damit Umsetzungsaufwand.

9.2.12. Einkauf / Disposition

Aktuell legen wir schon unsere Lieferanten an und pflegen z.B. Adressen und Kontaktdaten. Damit wir aber den Einkauf bzw. unsere Disposition vollständig abbilden können, müssen auch z.B. Eingangsrechnungen und Bestelldaten eingepflegt werden können. 

Zusätzlich ist auch eine Schnittstelle zu unserem IT-Einkaufsmanagementsystem Egis im Gespräch. Über dieses System bestellen wir aktuell z.B. 80-90% unserer Hardware. Aber auch manuell müssten sich Eingangsrechnungen anlegen lassen, hier gibt es ja die unterschiedlichsten Bereiche wie verschiedene Lizenzen, Ersatzteile oder auch Büroausstattung oder Möbel. Dazu muss mit unseren Einkäufern der verschiedenen Teams (vorwiegend Systemhaus und Verwaltung) evaluiert werden, was hierfür alles nötig wird.

Außerdem ist die Pflege von Eingangsrechnungen eine der Grundvoraussetzungen, um unsere Buchhaltung über ERPNext abbilden zu können.

9.2.13. HR Management

Als Voraussetzung für die Buchhaltung müssen natürlich auch die Gehälter unserer Mitarbeiter über ERPNext abgebildet werden. 

Dieser Prozess ist allerdings aktuell noch sehr weit nach hinten priorisiert. ERPNext bietet zwar schon alle nötigen Voraussetzungen und Funktionalitäten wie Personalabrechnung, Gehaltsabrechnung und Boni. Auch Aufwandsabrechnungen und sogar Vorschüsse und zusätzliche Gehälter können schon abgebildet werden. 

Um das HR Management voll und ganz bei uns abbilden zu können, müssen wir unsere selbst entwickelte Zeiterfassung entweder an ERPNext anbinden oder die Zeiterfassung direkt in ERPNext abbilden.

Dennoch haben wir aktuell noch für uns wichtigere Prozesse identifiziert und wir haben über unsere aktuelle Lösung in Lexware und beim Steuerberater auch noch keine mit anderen Prozessen vergleichbare Punkte gefunden, in denen uns ERPNext einen entscheidenden Vorteil oder Arbeitserleichterung bringen könnte. Zudem könnte die Anbindung an die Zeiterfassung recht komplex werden. Daher sind uns die oberen Prozesse erst mal wichtiger.

9.2.14. Buchhaltung

Sobald wir alle Eingangs- und Ausgangsrechnungen sowie die Löhne über ERPNext abgebildet haben, können wir auch die Buchhaltung über ERPNext abbilden. In diesem Moment können wir dann bei uns Lexware komplett ablösen. 

Natürlich ist das einer der wichtigsten Prozesse, die ein Unternehmen hat, wenn nicht der wichtigste überhaupt. Aber er funktioniert aktuell noch gut, so wie er ist. Daher wird die Buchhaltung aktuell noch (fast) nach ganz hinten priorisiert.

9.2.15. Kundenportal

Hin und wieder ist es mal im Gespräch, unseren Kunden ihre Stammdaten, aber auch Dokumente wie Rechnungen und Angebote über ein Portal zur Verfügung zu stellen. 

Was in Lexware schon vorhanden ist, ist ein CMS, also ein Content-Management-System für Webseiten. Auch als Shopsystem lässt es sich verwenden. In Artikeln lässt sich einfach angeben, ob der Artikel auf die Webseite gestellt, also im Shop verkauft werden soll.

Auch ein ausgefeiltes Rechtemanagement, welches auch Zugänge für Kunden berücksichtigt ist bereits integriert.

Nun verkaufen wir ja kaum Hardware, unseren Umsatz erzielen wir hauptsächlich mit meist individuellen IT-Dienstleistungen. Dafür brauchen wir kein Shopsystem. Dennoch könnten wir es uns vorstellen, unseren Kunden Zugang zu unserem ERP System zu gewähren und damit Daten zur Verfügung zu stellen. Nicht zuletzt, da es uns auch Arbeit erspart, wenn wir mal Rechnungen erneut zusenden oder unseren Kunden für Fragen zur Verfügung stehen. Das würden wir natürlich auch weiterhin, aber wenn es unsere Kunden wünschen, würden wir diese Möglichkeit auch gerne zur Verfügung stellen.

Screenshotupdate

Alle Screenshots in diesem Blogpost sind auf Version 13 von ERPNext aktualisiert.

Letzter Stand der Aktualisierung: 06.09.2021