Modifikationen für ERP-Software
Standard-ERP: Updatefähig trotz Modifikationen
Auch die ausgereifteste Standardsoftware kann nicht alle individuellen Gegebenheiten und Prozesse eines Unternehmens abdecken. Deshalb muss sie in aller Regel im Rahmen der Einführung angepasst werden.

Allerdings darf sie dadurch ihre Releasefähigeit nicht verlieren. Das heißt: Installiert das Unternehmen eine neue Programmversion des eingesetzten ERP-Systems, sollten die individuellen Modifikationen aus der Vergangenheit selbstverständlich auch dort zur Verfügung stehen. Das lässt sich unter anderem gewährleisten, indem die Software bereits von Haus aus eine hohe Flexibilität mitbringt und individualisierbar ist.
Im ERP-System Oxaion beispielsweise lassen sich die Masken der Benutzeroberfläche frei gestalten. Der Benutzer kann selbst entscheiden, welche Felder er sehen möchte und welche nicht, wo sie auf dem Bildschirm platziert werden und wie sie grafisch aussehen sollen. Da es sich dabei de facto gar nicht um Modifikationen, sondern vielmehr um die konkrete, individuelle Ausgestaltung des Standards handelt, lassen sich diese Anpassungen beim Releasewechsel vollautomatisch übernehmen. Sie stehen in der neuen Version so selbstverständlich zur Verfügung, wie etwa die persönlichen Einstellungen beim Update eines Internetbrowsers.
Ähnlich verhält es sich mit den Prozessabläufen. Die einfachste und eleganteste Möglichkeit bietet hierbei ein integriertes Business Process Management (BPM). Damit lassen sich individuelle Prozesse sehr leicht grafisch modellieren und anschließend auf Knopfdruck in Betrieb nehmen: Die Software legt sie ab und führt sie künftig selbstständig aus.
Da die Prozesse damit nicht fest im ERP-System codiert sind, sondern sich flexibel einstellen lassen, können sie bei einem Releasewechsel problemlos mitgezogen werden. Es genügt, der neuen Version die grafischen Modelle der veränderten Prozessabläufe bekannt zu geben, und sie sind dort eins zu eins lauffähig.
Ebenfalls vollautomatisch kann die Übernahme von individuellen Änderungen an der Datenbank (z.B. zusätzliche Felder oder Typänderungen) erfolgen. Dafür gibt es unterschiedliche Wege; Oxaion beispielsweise arbeitet hier in vielen Bereichen mit dem „Drei-Wege-Vergleich“. Ein speziell entwickeltes Tool prüft hierbei den Auslieferungszustand der installierten Version, den tatsächlichen Zustand der Installation und den Auslieferungszustand des neuen Releases, das eingespielt werden soll. So kann das Werkzeug ermitteln, wo es beim Anwender Anpassungen gab, und die nötigen Schritte zur Übernahme dieser Modifikationen ausführen.
Etwas schwieriger gestaltet sich die Angelegenheit, wenn Änderungen am Programmcode vorgenommen wurden. Um den Releasewechsel auch auf dieser Ebene vollautomatisch zu ermöglichen, wird die ERP-Software mit sogenannten „Extension-Points“ ausgestattet – speziellen Stellen im Code, an denen individuelle Programme andocken können.
Die Einrichtung und Verteilung dieser Punkte erfolgt nach Erfahrung: Sie stehen dort bereit, wo öfter Modifikationen nötig sind. Ein Beispiel dafür ist die Preisfindung. Zwar ist hier der Standard bereits mit den gängigsten Verfahren ausgestattet, die sich flexibel einstellen lassen. Trotzdem haben einige Anwender sehr spezielle, eigene Preisfindungsverfahren. Deren Programmcode lässt sich am entsprechenden Extension-Point hinterlegen und kann dort aufgerufen werden.
Auf diese Weise ist die Modifikation nicht mehr Bestandteil des Sourcecodes, sondern wird in Form eines Zusatzprogramms separiert hinterlegt. Dieses bleibt beim Releasewechsel der ERP-Software unangetastet – und lässt sich auch in der neuen Version am entsprechenden Extension-Point aufrufen.
Oxaion-Kunden haben darüber hinaus die Möglichkeit, jede beliebige Quellcodestelle des ERP-Systems frei anzupassen. Solche Änderungen werden dann von den Releasewechseltools über Drei-Wege-Vergleiche identifiziert und extrahiert. Der extrahierte Code wird über automatisierte „Sourcecode-Manipulationen“ (= „Refactorings“) an die neuen Gegebenheiten angepasst und an den richtigen Positionen im neuen Release eingebunden. Das gelingt häufig automatisch, in vielen Fällen sind aber Eingriffe in Form von Kontrollen oder manueller Programmierung nötig.
Wie hoch der Automationsgrad ist, hängt vom Alter der ERP-Version ab, die abgelöst werden soll. Wurden mehrere Releasezyklen übersprungen, wird sich der Programmcode des Standards in aller Regel sehr verändert haben – entsprechend umfangreicher fallen die manuellen Eingriffe aus. Generell gilt: Je aktueller die Anwender bei ihren Installationen sind, desto einfacher der Releasewechsel.
Bildquelle: © porcorex/iStockphoto
Meistgelesene Artikel
Infor kündigt neue Produkte, Releases und Allianzen an
ERP-Lösungen für IBM Pure Systems
Windows 8
Endlich weniger: Die Windows-Editionen
IBM nennt Preise für Modell 7R2, aber nicht für p24L
Mehr Details zu IBM Power Linux
Nach HP und Microsoft verliert Oracle offenbar den nächsten Großkunden
IBM ersetzt Siebel durch SugarCRM
IBM kündigt „Virtual Pattern Kit“ für Pure Systems an
„Patterns of Expertise“ erstellen
Meistgelesene Interviews
Titelinterview mit Wolfgang M. Roser, Roha Software Support GmbH
„Gutes Output-Management muss einfach sein!“
Titelinterview Andreas Wodtke, Systems & Technology Group der IBM Deutschland
„Server bleiben eine Paradedisziplin für IBM!“
Interview mit Ralph Menten, Menten GmbH
Technische Verfahren wie EDI für eInvoicing-Projekte ratsam
„Gutes Output-Management muss
einfach sein!“
Interview mit Wolfgang M. Roser,
Gründer und Inhaber der Wiener
Roha Software Support GmbH










