Standardsoftware muss sich Problemen stellen, von denen Individualsoftware nicht betroffen ist. Das wird gerade bei betriebswirtschaftlicher Standardsoftware deutlich. Geschäftsprozesse sind nicht durch Gesetze festgeschrieben, und deshalb unterscheiden sie sich auch von Unternehmen zu Unternehmen. Für viele Firmen bedeuten ihre spezifischen Prozesse einen Wettbewerbsvorteil. Eine zeitgemäße ERP Software passt sich deshalb an die Prozesse im Unternehmen an und nicht umgekehrt. Darüber hinaus sind beispielsweise die Firmengröße, die Kunden, der Standort, die Branche und die Sprache wichtige Faktoren. Bei der Auswahl einer neuen Lösung fällt die rationale Entscheidung deshalb auf die Software, welche bereits alle Anforderungen abdecken kann, beziehungsweise den geringsten Anpassungsaufwand verursacht. Da sich der gesetzliche Rahmen und die Technologie fortlaufend weiterentwickeln, muss das Produkt durch Updates aktuell gehalten werden. Ist das Customizing der Software nicht klar definiert, erzeugt ein Update erheblichen Mehraufwand und gefährdet im schlimmsten Fall die Releasefähigkeit. Eine scheinbar optimale Entscheidung kann sich damit nachträglich als fatal herausstellen.
Die Planung des Customizing und dessen Berücksichtigung in der Architektur ist essentieller Bestandteil des Entwicklungsprozesses der Software. Davon abgesehen benötigt Standardsoftware einen Aufbau wie jede andere Software auch. Zur Entwicklung wird in den meisten Fällen ein Framework, ob selbst geschrieben oder gekauft, genutzt. Dieses bietet Richtlinien, Designvorlagen und eine Infrastruktur, um den Entwicklungsprozess zu optimieren. Vorgehensweisen, welche sich in anderen Projekten bereits bewährt haben, können so wiederverwendet werden. Die Auswahl des Frameworks ist eine strategische Entscheidung, welche die Architektur und den Arbeitsaufwand beim Erstellen der neuen Software bestimmt. Das Framework bildet das Fundament und ist nur sehr schwer zu ersetzen. Ist ein Änderungsmanagement bereits Bestandteil des Frameworks, muss es nicht in der Software implementiert werden. Dies rationalisiert die Entwicklung und stellt einen einheitlichen, durchgängigen Anpassungsmechanismus bereit.
Änderungsmanagement
Um ein Änderungsmanagement in ein Framework zu integrieren, muss zunächst bestimmt werden, wie dieses aussehen soll. In der Praxis werden hauptsächlich vier Methoden unterschieden. Die mit Sicherheit schlechteste ist die, gar kein Änderungsmanagement zu implementieren. Das Programm wird einfach als Open Source weitergegeben, die Systemhäuser beziehungsweise Kunden sind für die Pflege und das Nachziehen von Erweiterungen bei Releases verantwortlich. Als natürliche Reaktion werden die Kunden versuchen, ihren Stand festzufrieren und diesen bei Bedarf eigenständig weiterzuentwickeln. Damit Entkoppeln sie sich von einer Weiterentwicklung des Softwareherstellers und sitzen langfristig auf einer Insel fest. Trotzdem muss man dieser Methode zugute halten, dass sie mit Sicherheit die größte Flexibilität für Anpassungenbietet.
Die zweite Variante besteht darin, alle Erweiterungen im Standard zu verankern. Die gewünschte Funktionalität wird anschließend durch eine komplexe Konfiguration definiert. Alle Erweiterungen müssen hierbei durch den Hersteller vorgenommen werden. Eine kundenindividuelle Erweiterung wirkt sich auch auf alle anderen Kunden aus. Der Standard verändert sich fortlaufend, was schließlich die Softwarequalität beeinflusst. Dabei bläht sich die Software mit jedem hinzugewonnen Kunden bis zu dem Zeitpunkt auf, an dem sie nicht mehr wartbar ist.
Eine weitere Methode ist die Bereitstellung einer Add-in-Schnittstelle, verbunden mit einer API. Der Hersteller bestimmt hierbei die Nützlichkeit durch Aufbau und Umfang der API. Kundenindividuelle Anforderungen können unabhängig vom Hersteller umgesetzt werden und beeinflussen den Standard nicht. Probleme entstehen, wenn bestehende Logik ersetzt werden soll. Zur Übersteuerung werden spezielle, durch den Hersteller vorbereitete, Einstiegspunkte (User-Exits) benötigt. Die Einstiegspunkte können nur durch einen Beteiligten genutzt werden. Entwickeln die Systemhäuser Varianten der Software, müssen sie ihrerseits Einstiegspunkte definieren, um die Software für den Kunden anpassbar zu halten. Auch können verschiedene Varianten nicht zusammengeführt werden, wenn ein Kunde beispielsweise mehrere Marktsegmente bedient.
Die vierte Technik besteht darin, die Software in verschiedenen Ebenen aufzubauen. Die Klassen werden über die Ebenen hinweg vererbt und sind dann beispielsweise für länder-, branchen-, partner- oder kundenspezifische Erweiterungen reserviert. In jeder Ebene kann die Logik im Rahmen der objektorientierten Programmierung überschrieben und erweitert werden. Der Ansatz besitzt die gleiche Flexibilität, als wenn der Kunde direkt den Standard anpassen würde. Allerdings können die Ebenen unabhängig von einander ausgetauscht werden. Damit bleiben Änderungen nach einem Update erhalten. Dieser Ansatz ist als einziger für ein Änderungsmanagement als Teil eines Frameworks nutzbar, da es keine Rolle spielt, welche Funktionalität hinter einer Klasse steckt.
Änderungsmanagement als Teil eines Frameworks
Ziel eines im Framework integrierten Änderungsmanagements ist die Bereitstellung eines Customizing-Mechanismus, ohne dass dies einen Mehraufwand für die Entwicklung bedeutet. Der Mechanismus muss allgemeingültig sein und soll auch die Entwicklung einer API überflüssig machen. Des Weiteren muss auch bei umfassenden Anpassungen die Releasefähigkeit garantiert sein. Die Anpassungen sollen gekapselt erfasst werden können, um nach dem Baukastenprinzip in die Software integrierbar zu sein. Dabei darf es keine Rolle spielen, aus wie vielen Bausteinen die Lösung letztlich besteht. Die Entwicklung der Bausteine soll durch Hersteller, Systemhäuser und Kunden möglich sein und die Flexibilität für die Anpassungen nahezu unbeschränkt. Darauf aufbauend kann ein gut getesteter Standard definiert werden, der nur selten verändert werden muss.
Die Idee geht von einer Ebenen-Technik aus, wie sie aus der Bildbearbeitung schon lange bekannt ist: Die Summe aller Ebenen ergibt das fertige Bild. Übertragen auf einen Softwareentwurf setzt sich die fertige Lösung ebenfalls aus einer Reihe von Ebenen zusammen. Die Anzahl der Ebenen und deren Hierarchie sind variabel. Der Kunde kann die Ebenen nach Bedarf zu seiner Lösung hinzufügen und entfernen, um damit die Funktionalität und Logik zu beeinflussen.
Zur Umsetzung müssen zunächst einmal alle Klassen in ihrer Bedeutung erfasst werden. Zu welcher Ebene gehört die Klasse? Was ist ihre Basisklasse? In welcher Ebene befindet sich die Basisklasse? Die Beziehungen müssen bei einer Änderung in der Ebenen-Hierarchie angepasst werden. Das ist aufgrund der Komplexität ohne einen Verwaltungsmechanismus nicht zu schaffen. Abbildung 1 zeigt einen Ausschnitt der Vererbungskonstellationen, die dabei entstehen können.
Zum einen können die Klassen innerhalb einer Ebene vererbt sein, andererseits über die Ebenen hinweg abgeleitet werden. Wie man an der Klasse Ebene_X_Klasse_2 sieht, kann dadurch auch eine doppelte Beziehung entstehen, was eigentlich eine Mehrfachvererbung erforderlich macht. Diese kann aufgelöst werden, wenn man Basis_Klasse_2 von Ebene_X_Klasse_1 erben lässt. Durch diese "Serialisierung" berücksichtigt die Klasse Ebene_X_Klasse_ 2 auch die Anpassungen, welche an Ebene_X_Klasse_1 und Ebene_1_Klasse_ 1 durchgeführt wurden.
Die Anpassung der Vererbungshierarchie macht es erforderlich, dass eine Klasse im Quellcode vorliegt. Um das zu umgehen, kann man jede Klasse von einer Verbindungsklasse erben lassen. Die Verbindungsklasse enthält keine Logik. Beim Ändern der Ebenen-Hierarchie muss nur die Verbindungsklasse angepasst werden. Damit kann die Logik als kompiliertes Assembly und ihre Verbindungsklasse im Quellcode weitergegeben werden. Diese Vorgehensweise schützt das geistige Eigentum und beugt Missverständnissen bei der Anpassung vor, ohne die Flexibilität einzuschränken. Vererbung ist gut, um eine Klasse funktional zu erweitern. Die neue Klasse kann anschließend durch den Entwickler genutzt werden, um Objekte dieses neuen Typs zu erzeugen. Ziel des Änderungsmanagement ist es aber auch, bestehende Funktionalität anzupassen oder zu übersteuern. Abbildung 2 zeigt dafür die Lösung: Wird eine Kopf-Klasse SalesOrder überall zur Instanziierung verwendet, erweitern die Ableitungen in den Ebenen die Klasse, statt neue Klassen zu erzeugen.
Damit kann die Logik und Funktionalität einer Klasse in jeder Ebene durch Vererbung verändert werden. Die darunter liegenden Ebenen sind davon unabhängig. Natürlich muss bei der Entwicklung viel sensibler mit dem Ändern bestehender Klassen umgegangen werden. Jede öffentliche Klasse ist eine potentielle Basisklasse, und eine Änderung an der Definition von öffentlichen Methoden und Properties ist eine Schnittstellenänderung. Dagegen bleibt einem die Entwicklung einer separaten API erspart.
