In diesem Posting soll es einmal um das “Material” gehen, das wir im Zuge einer Einführung von Infor-LN verändern. Wenn wir eine x-beliebige Anforderung umzusetzen haben, welche konkreten Stellschrauben haben wir?

Was es da so allgemein in der ERP-Projektmanagement-Literatur gibt, ist mir ein bisschen dürftig. Die kommt meistens mit “Parametrieren” und “Customizing” aus, das springt entschieden zu kurz.

Ich unterscheide die folgenden

8 Stellschrauben

Parametrierung

Wir stellen in speziellen Parametersessions Schalter so, dass die Programmabläufe den einen oder anderen Weg gehen. Wir richten parameterähnliche Stammdaten wie Auftragsarten, Ust-Codes, Preismatritzen usw. ein. Gerade im Einrichten dieser parameterähnlichen Stammdaten liegt viel Würze, sie steuern insbesondere, ob die Geschäftsvorfälle jeweils gemäß ihrer Kategorie sauber abgewickelt werden können

Stammdatenmanagement

Wir sorgen dafür, dass “Parameter”, die an einzelnen Stammdatenobjekten hängen, so eingestellt, sind, dass wir die gewünschten funktionalen Ergebnisse erzielen: Bestellsystem am Artikelstamm, Preisliste im Kunden etc. Dies ist deutlich aufwendiger als die Parametrierung, weil wir die entsprechenden Daten in der Regel aus einem Alt- oder Vorsystem übernehmen. Das heißt, dass entsprechende Regelwerke für Automatismen im Rahmen der Übernahme entwickelt werden müssen oder die Daten manuell vor- oder nachbereitet werden müssen

Customizing

Wir schrauben an der Oberfläche. Verschieben Felder innerhalb von Masken. Passen interne und externe Formulare an. Hierzu zähle ich auch, datentechnisch leicht erreichbare Informationen auf Masken zu bringen, die im Standard nicht da sind, selbst wenn ich dabei am Quellcode drehen muss.

Personalisierung

Wir schrauben an der Oberfläche, die ein einzelner Anwender sieht. Das ist insofern problematischer als Customizing, weil es nicht so gut skaliert (an drei Arbeitsplätze kann ich mich hinstellen und beim Personalisieren Händchen halten, bei 700 nicht mehr). Hier kann ich aber sehr genau den Arbeitsfluss beeinflussen. Zieh das Feld darüber, schmeiß das raus. Klick nicht hier, sondern nimm dieses Tastaturkürzel. Bau Dir für diesen Anwendungsfall diesen Filter und schnellfiltere dann in dem Feld auf das.

Anpassungsprogrammierung

Hier greifen wir in die bestehende Softwarelogik ein. Und zwar so, dass wir die Verantwortung für die Komponenten, die am von uns veränderten Ablauf dranhängen, fachlich und programmiertechnisch übernehmen müssen. Wir erlauben Dinge, die der Standard nicht erlaubt. Wir rechnen anders, als der Standard rechnen würde. Wir müssen für Anpassungsprogrammierung immer Standard-Sourcecode verändern. Achtung – das heißt nicht zwingend Sourcecodelizenz. Auch massive Änderungen in Report-Skripten können Anpassungsprogrammierungen sein.

Add-On-Entwicklung

Wir programmieren neue Funktionen, schaffen es aber, bestehende Algorithmen und Datenmodelle (konzeptionell) unangetastet zu lassen. Dies sind entweder ganz neue Anwendungen komplett unabhängig von im Standard vorhandener Funktionalität (beispielsweise eine Software für die Verwaltung des Wochenmenüs der Kantine). Oder es sind Funktionen, die “auf dem Standard draufhocken” und ihn fernsteuern: Wann immer ich einem Anwender sagen könnte: “Ja, was der Standard tut, langt nicht. Aber wenn Du – nachdem dieses Standardprogramm gelaufen ist und dann für den Auswahlbereich jenes – nach folgenden Regeln immer das machst und dann das und dann das, dann hast Du genau das, was Du willst”, dann kann ich das auch durch ein Addon gut wegautomatisieren. Oder ich verbiete bestimmte Aktionen, die der Standard zulassen würde. Neue Datenfelder in einer Standardtabelle sind für mich übrigens auch Addons, keine Anpassungsprogrammierungen.

Fachliche Beratung

Jetzt reden wir auf einmal nicht mehr den Anforderungen der fachlichen Seite an die Software. Jetzt sprechen wir über Anforderungen des Business’ an die Fachlichkeit. Wir setzen nicht mehr die Anforderungen der fachlichen Seite in eine funktionierende Softwarelösung um. Sondern wir sehen uns die Softwarelösung an und ändern das fachliche Arbeiten aufgrund von Funktionen in der Software so, dass es dem Business besser hilft als das alte Arbeiten. Wir ändern nicht mehr, wie Leute etwas tun, sondern was Leute tun. Diese Art der Beratung ist im ERP-Projekt in der Regel gut leistbar. Wichtig ist aber, dass das Projekt dazu mandatiert ist – in der Praxis scheitert es häufig daran, dass diese Mandatierung nicht formal und deutlich genug ist und die Key-User darauf bestehen, dass ihre Art zu arbeiten kaum weiter optimierbar ist.

Business Process Reengineering

Man muss es ganz deutlich sagen: Obwohl das Ändern verkrusteter Prozesse eine der Hauptbegründungen ist, warum ERP-Systeme neu eingeführt oder in einem größeren Projekt auf eine deutlich neuere Version gehoben werden, sind ERP-Projekte genau hierzu am wenigsten im Stande. Das liegt zum einen daran, dass die Prozesse in der Regel so schlecht nicht sind, wie sie von Beratungsunternehmen gemacht werden, und dass so viel Verbesserungspotential im Prozess nicht besteht (meist jedoch bei seiner IT-technischen Unterstützung – das ist aber ein gewaltiger Unterschied!). Und zum anderen, dass für eine wirkliche Veränderung von Prozessen in der Regel aufbauorganisatorische Veränderungen, veränderte Arbeitsplatzbeschreibungen etc. notwendig werden. In der Regel ist ein ERP-Projekt aber – auch wenn es anders begründet wird – nicht mandatiert, solche Veränderungen vornehmen zu können.

Auch müssen solche Änderungen, sollen Sie wirklich dauerhaft implementiert werden, mit einem entsprechenden Change-Management begleitet werden, um die auftretenden Widerstände (Mauern der Abteilungsfürsten, Absicherungsverhalten, Ängste um den Arbeitsplatz etc.) zu überwinden. Und ein ERP-Einführungs-Projekt hat in der Regel ein Budget von exakt Null komma Null, um solches Change Management professionell (d.h. bspw. mit entsprechenden Workshops, Unterstützung durch Psychologen, Projektmarketing etc.) zu betreiben. Man kann die Umstellung von ein, zwei Prozessen im ERP-Projekt mit viel Bearbeitung des Lenkungsausschusses vielleicht geregelt bekommen, wenn man deutliche Verbesserungen für das Unternehmen aufzeigen kann. Aber das ist die Ausnahme.

Und die Reihenfolge?

Wie man vielleicht sieht, sind die Punkte so gut es geht in aufsteigender Schwierigkeit bei der konkreten, wirksamen Umsetzung sortiert. Das war jedenfalls meine ursprüngliche Idee. Erst im Nachhinein ist mir aufgefallen, dass das ungefähr umgekehrt korreliert mit der Nähe der Tätigkeiten am konkreten Infor-LN-System selbst. Bei den Parametern ist man extrem nah dran an dem, wie die Software gedacht ist. Beim Business Process Reengineering interessiert konkretes Knowhow in und mit der Software kaum noch.

Und jetzt könnte man trefflich drüber diskutieren, ob eine ERP-Einführung ein IT-Projekt oder ein Organisationsprojekt sein sollte… Da unten gäb’s Platz: