Murmel Murmel… ERP?

Was machen Berater und Programmierer?

Außerhalb von Beratern und (interessierten) Projektleitern ist es sehr schwer, meinen Job zu erklären. Für was braucht man bei einer ERP Integration überhaupt einen Berater, und warum ist es einfach so viel Besser, wenn Berater und Entwickler ein und die gleiche Person sind? Wieso gibt es so viel Reibungsverluste und Missverständnisse, wenn zu viele Personen in der Übertragungskette involviert (beteiligt) sind? Nun… Stellen wir uns einfach mal vor, wie ein Prozess in klassischen Projekten, z.B. SAP Projekten, abgebildet wird.

Arbeitsteilung in ERP Projekten

Ein Berater (Consultant) interviewt einen Mitarbeiter über, sagen wir mal, die Auftragserfassung. Und will/muss mehr über die Preisfindung erfahren.
Der Mitarbeiter wird oft nicht absolut 100% der Preisfindung erklären können. Und der Interviewer / Berater / Consultant weiß ja nicht, nach was er fragen soll: Er ist ja selbst ein fremder in dieser Firma. Es entsteht hier also praktisch immer eine Lücke, ein Delta, zwischen abgefragten und dokumentierten Abläufen, und der Realität. Diese Lücken entstehen natürlich nicht nur bei der Preisfindung, sondern auch bei den Freigabeprozessen, bei der Vertreterabrechnung, bei der Bestandsreservierung und und und…

Typischerweise führt der ERP-Seitige Projektleiter (Consultant, Berater) schon aus Zeit- und Kostengründen nicht alle Interviews selbst. Er hat also unterstützende Mitarbeiter, welche Teile der Prozesse auf die gleiche Weise (Interview, Dokumentation) durchführen. Jeder einzelne Mitarbeiter hat eine gewisse eigene Arbeitsweise, Frageweise und natürlich auch ein eigenes Verständnis für die von den Mitarbeitern erklärten Prozesse (Arbeitsabläufe). Und selbst die Mitarbeiter haben hier schon einen Einfluss auf die Detailtiefe der vom jeweiligen Mitarbeiter im Interview beschriebenen Abläufe und zugehörigen Hintergründe.

Ablaufdokumentationen Pflichtenheft Lastenheft

Nun hat der Interviever / Berater eine Ablaufdokumentation für 1 bis n Prozesse. Teilweise selbst erstellt, teilweise aus Zuarbeiten erhalten. Diese verschiedenen Dokumentationen werden nun (in der Regel) vom EPR-Projektleiter (Berater/Consultant, egal ob für Navision / Business Central, SAP, Baan, Great Plains, AS/400 (AS400) oder was auch immer) zusammen geschrieben. Wenn diese:r Projektleiter:in gut ist, fallen ihm/ihr dabei Diskrepanzen auf, welche nachgefragt werden. Auf der anderen Seite werden aber auch Interpretationen und Missverständnisse der Aufzeichnungen die Qualität der Aufnahmen verschlechtern. Hier findet also schon das 3. Mal (1.: Wiedergabe der Prozesse durch Mitarbeiter. 2.: Verständnis und Dokumentation der beschriebenen Prozesse/Arbeitsabläufe) eine qualitative Veränderung (meist: eine Verschlechterung) der Prozessdokumentation statt.

Diese Ablaufdokumentation wird -hoffentlich- noch einmal mit dem Kunden durchgesprochen. Oft jedoch wird diese nun einfach dem Kunden (meist gegen Geld) übergeben, und der Kunde kann nun „Ja“ oder „Nein“ sagen. Meist sagt der Kunde „Ja“, weil er mit der -nun dokumeniterten- Komplexität der Abläufe in seinem eigenen Unternehmen überfordert ist. Eine Rückkopplung (Feedback) mit den Mitarbeitern findet in der Regel nicht statt. Dafür kann es viele Gründe geben:

Feedback beim Kunden

• Das verstehen die doch eh nicht. Eine recht arrogante, leider aber auch oft richtige Einschätzung.
• Da stehen zu viele verschiedene Interna drin, das dürfen wir in dieser Gesamtheit nicht allen Mitarbeitern übergeben. Durchaus verständlich und oft auch korrekte, aber leider kontraproduktive (schädliche) Einschätzung.
• Das kostet zu viel Zeit/Geld, wenn wir das jetzt alles noch einmal durchkauen. Dies ist mit sicherheit die am meisten genutzte Argumentation (Begründung).
• Wird schon stimmen, das sind doch die Fachleute. Hier stecken sehr viel Hochachtung und Hoffnung drin… leider meist unbegründet. Die „Fachleute“ haben leider keine Erfahrung mit den Abläufen, sie plappern (in der Regel) nur die Mitarbeiter des Kunden nach… so gut sie es halt verstanden haben.

Medienbruch auf dem Weg zum Entwickler Programmierer

Sagt der Kunde „Ja“, so wird das entstandene Pamphlet (dickes Buch, Broschüre) einem oder mehreren Programmieren übergeben. Und hier findet nun in der Regel wirklich der größte Medienbruch statt. Der oder die Programmierer haben meist nicht die Interviews geführt und auch nicht die urpsrungsnotizen zu Gesicht bekommen. Sie wissen nur das, was Sie nun in diesem Pflichtenheft/Lastenheft vorfinden. Und dazu haben Sie einen Zeit- und Kostendruck im Nacken. „Schaff das in 6 Wochen, sonst gehen wir in’s Minus!“ ist eine gern getätigte Äußerung. Also machen sich die Programmierer an’s Werk, um die von ihnen aus dem Pflichtenheft/Lastenheft vorgefunden Anforderungen in Bits und Bytes umzusetzen. Und diese Programmierer/Entwickler haben immer öfter zwar einen Programmierer-Background (Hintergrund), aber in den allermeisten Fällen keinerlei kaufmännischen Kenntnisse.

Nun kommen wir wieder zurück zu Navision / Business Central. Der oben beschriebene Ablauf ist universell, und betrifft nahezu alle ERP-Installationen oder sogar die meisten EDV/IT Projekte ganz allgemein. Der nun folgende Teil ist mehr spezifisch für ERP-Integrationen, oft Ablösungen von Altsystemem wie AS400, SNI Quattro Pro Comet, JD Edwards, Baan und so viel mehr.

Problem im Spezialfall ERP/Warenwirtschaft

ERP-Systeme, oft in irgendeiner Weise mit einer Finanzbuchhaltung integriert (verbunden), decken sehr viele Teilaspekte einer Unternehmensführung (ERP = Enterprise Ressource planning, Unternehmen Ressourcen Planung) ab. So z.B. die bereits genannte Finanzbuchhaltung, Bestandsführung, Beschaffung (Einkauf), Angebotswesen (oft verbunden mit dem Kundenmanagement, CRM (Customer Relation ship management, Kundenbeziehungsverwaltung)), Preisfindung, Vertreterabrechnungen, Preisberechnungen, Deckungsbeitragsermittlung, Prozess-Management (Betriebsablauf Steuerung) mit Prüfungen, Plausibilitätskontrollen, Sperren, Zugriffsrechten und so viel mehr.

Diese Details sind klassischen Programmierern oft fremd, zumindest in einer nutzbaren Detailtiefe. Programmierer denken in Klassen, Objekten, Exceptions, Deklarationen, Funktionen. Nicht in Beständen, Bilanzen, und Salden.

Soll und Haben

Diese Programmierer stürzen sich nun z.B. auf eine -im Prinzip- fertige Warenwirtschaft wie Navision oder Business Central, und baut mit seinem Programmiererwissen nun alles so ein, wie er die Dokumentationen der Berater / Consultants versteht. Er (Sie) wird teilweise vorhandene Funktionen erneut erstellen, einfach weil er sie nicht kennt. Er (Sie) wird vorhandene Funktionen modifizieren, und dabei hin und wieder auch beschädigen. Und Er (Sie) hat wenig Hintergrund über die echte Verwendung der von ihm geforderten Funktionen – und weniger über die möglichweise auftretenden Fehlbedienungen und Fehleingaben.

Und der erste grobe Test findet natürlich mit Eingaben statt, die „Sinn“ machen. Viel wichtiger sind aber die Tests eben mit „Unsinnigen“ Daten!

Die so erstellten Programme/Anpassungen werden nun den Kunden übergeben – Manchmal von dem Consultant oder Berater, manchmal vom Programmierer. Hier kommen jetzt zum ersten Mal wieder die Anwender in’s Spiel.

Entwickler / Programmierer und Berater bzw. Consultant in einer Person

Erinnern Sie sich noch an die Eingangsfrage? Warum ist es besser, wenn Programmierer / Entwickler und Consultant bzw. Berater eine Person sind? Ganz viele der obigen Schleifen fallen schlicht weg. Dies verkürzt bereits enorm den Aufwand zur Erfassung/Verständnis/Umsetzung der Anforderungen. Jedoch noch viel wichtiger: Bei Unklarheiten während der Implementierung (Umsetzung) kann er direkt sich an den verantwortlichen Mitarbeiter wenden, um Rückfragen zu stellen. Umgekehrt kann auch bei der Prüfung der Mitarbeiter sich direkt mit weiteren Defintionen, Änderungen, Vergessenen Details an den bereits bekannten Navision oder Business Central Entwickler / Programmierer wenden, um vorher vergessene Spezifikationen nachzureichen.

Verstehen an einem praktischen Beispiel

Diese Feedbackschleifen, Try and Test and Error, sind sehr wichtige Ausprägungen der agilen Entwicklung. Und die ist für die allermeisten Menschen noch viel schwieriger zu verstehen als die uralte, oben beschriebene Arbeitsweise. Wer hier etwas tiefer einsteigen möchte:
Sehen Sie sich einfach einmal dieses Video hier an. Es geht um eine -völlig ERP fremde- Entwicklung einer Murmel-Musik-Maschine. Interessant in diesem Video ist aber etwas gänzlich anderes: Wie viele Details gibt es in einem Projekt zu betrachten, wie viele nachträgliche Anpassungen und Feinheiten gilt es zu berücksichtigen? Und wie werden diese am besten erkannt und behoben oder verbessert? Welche Schönheiten (Ja! Software kann „Schön“ sein!) kann man durch Nacharbeiten noch entdecken und einarbeiten? Wie Detailverliebt kann man sein? Lassen Sie das Video einfach mal auf sich wirken…