ERP-Tipps

In hohem Maße individualisierbar: eNVenta ERP und Framework Studio



Betriebswirtschaftliche Standardsoftware sollte im besten Fall eine sofort verfügbare Individualsoftware zum Preis eines Standardproduktes sein. Allerdings muss Individualsoftware, wie es der Name sagt, nur die Anforderungen eines Kunden erfüllen. Die Hersteller von Standardsoftware stehen dagegen vor der Herausforderung, vielfältige Funktionalitäten in einer Software so zu verpacken, dass sie für alle Kunden bedienbar bleibt. Zudem muss sie so flexibel sein, dass die Logik auch noch individuell an die Geschäftsprozesse der Unternehmen angepasst werden kann. Die Anpassung wird in der Praxis nicht nur durch den Hersteller vorgenommen, sondern vor allem durch Systemhäuser und Kunden. Der Anpassungsprozess muss deshalb genau definiert sein. Ein neuer Ansatz sorgt hierbei für mehr Flexibilität bei allen Beteiligten.


Standardsoftware muss sich Herausforderungen stellen, von denen Individualsoftware nicht betroffen ist. Das wird gerade bei betriebswirtschaftlicher Standardsoftware deutlich. Geschäftsprozesse sind nicht durch Gesetze festgeschrieben und unterscheiden sich deshalb von Unternehmen zu Unternehmen. Für viele Firmen bedeuten ihre spezifischen Prozesse sogar 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 planmäßigen Auswahl einer neuen Lösung fällt die Entscheidung deshalb auf diejenige Software, welche die Anforderungen bereits in hohem Maße abdeckt, beziehungsweise den geringsten Anpassungsaufwand verursacht. Da sich gesetzliche Rahmenbedingungen 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 Release-Fähigkeit der Lösung.

Die Planung des Customizing und dessen Berücksichtigung in der Architektur ist deshalb essentieller Bestandteil des Entwicklungsprozesses einer 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 programmiert 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. Es 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.

Typen des Änderungsmanagements

Um ein Änderungsmanagement in ein Framework zu integrieren, muss zunächst einmal bestimmt werden, wie dieses aussehen soll. In der Praxis werden hier vor allem drei Vorgehensweisen unterschieden:

Die erste 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 an sich kundenindividuelle Erweiterung wirkt sich auf alle anderen Kunden aus. Der Standard verändert sich fortlaufend, was 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 benötigt. Diese User-Exits 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 mit Branchenlösungen bedienen möchte.

Die dritte 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.

Der letztgenannte Ansatz ist als einziger für das Ä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 Änderungsmanagement ist die Bereitstellung eines Customizing-Mechanismus, ohne das 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 Release-Fä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 ist 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.

Repository basierende Entwicklung


Die Umsetzung der beschriebenen Ebenen-Technik findet sich in der Software Framework Studio. Das Werkzeug ist eine eigenständige Entwicklungsumgebung. Die Ebenen nennen sich hier Packages. Um die Verwaltung für die Klassen zu realisieren, wurde ein datenbankgestützter Ansatz gewählt. Dieser besitzt einige interessante Vorteile, die im folgenden ausgeführt werden.

Im Repository werden alle Klassen in ihrer Struktur abgebildet. Die Editoren erzeugen und manipulieren diese Struktur und das Werkzeug stellt die Konsistenz sicher. Geschäftslogik wird über Editoren in C# programmiert und ebenfalls im Repository gespeichert. Ein Codegenerator erzeugt dann aus dem Repository den Quellcode für das Programm. Dabei wird die komplette Infrastruktur für die Software generiert.

Das stark vereinfachte Datenmodell zum Erfassen einer Klasse in einer Datenbank stellt sich folgendermaßen dar: Eine Klasse besteht aus einem oder mehreren Datensätzen. Diese sind über eine PackageID der Ebene zugeordnet. Um eine Klasse abzuleiten, wird ein zusätzlicher Datensatz angelegt, welcher die Änderungen und Erweiterungen erfasst. Auf Strukturebene ist die Angabe der Basisklasse der Verweis auf einen anderen Datensatz und ist als solcher einfach zu verwalten. Auch eine Versionsverwaltung auf Klassenebene ist leicht umsetzbar. Um eine Klasse in einer neuen Version zu speichern, wird deren Datensatz mit einer inkrementierten Versionsnummer zusätzlich eingefügt. Die Klassen sind mit der aktuellen ClassVersion verschlüsselt. Mit dem Release einer Ebene wird die PackageVersion für die Ebene inkrementiert. Die Version einer Klasse kann damit eindeutig ihrem Release zugeordnet werden.
Durch die Codegenerierung und die strukturelle Erfassung der Klassen ergeben sich noch weitere Möglichkeiten. Framework Studio benutzt beispielweise einen speziellen Klassen-Typ ReportDocumentType. In diese Klasse werden alle Geschäftskomponenten als Property aufgenommen, deren Daten in einem Report ausgegeben werden sollen. Zum Designen der Reports kann anschließend die Struktur der Geschäftskomponenten als XML-Schemadefinition (XSD) exportiert werden. Eine XSD ist selbst nicht vererbbar. Wie bei den normalen Klassen lässt sich aber die im Repository erfasste Struktur durch „Vererbung“ erweitern, also durch einen zusätzlichen Datensatz, welcher die Änderungen gegenüber dem ursprünglichen Datensatz festhält. Damit kann die Schemadefinition in einer anderen Ebene beliebig erweitert werden.
Eine Ebene ist eine Menge an Datensätzen, welche über die PackageID und die PackageVersion verschlüsselt sind. Ein PackageManager fasst die Erweiterungsmenge an Datensätzen zu einem Package zusammen. Dieses kann dabei mit einem Lizenzmechanismus abgesichert werden, wodurch neben einem vollständigen Export auch die Möglichkeit besteht, nur die Struktur der Klassen weiterzugeben. Die Geschäftslogik ist dann beim Zielsystem nur noch als kompiliertes Assembly binär im Repository vorhanden. Um seine fertige Lösung zu erstellen importiert der Kunde dann die gewünschten Packages, bringt sie in eine Hierarchie und lässt sich die Verbindungs- bzw. Kopfklassen generieren. Die Logikklassen der Packages werden unverändert als Assemblies in das Applikationsverzeichnis geschrieben.

Durch den Repository basierenden Entwicklungsansatz arbeiten alle Editoren mit einer Datenstruktur, nicht mit Quellcode. Die Entwicklung ist deshalb zum größten Teil deklarativ. Nur die Geschäftslogik wird in Code-Editoren geschrieben. Diese wiederum beschränkt sich in der Regel auf Operationen, welche Daten in ein Geschäftsdatenmodell editieren.
Die Codegenerierung erzeugt aus der Repository-Struktur die Programm-Infrastruktur und setzt in die Methoden-Rümpfe die in den Quellcode-Editoren geschriebene Geschäftslogik ein. Die Geschäftslogik ist von der Infrastruktur strikt getrennt.

Framework Studio in der ERP-Praxis

Die webbasierten Anwendungen, die mit Framework Studio entwickelt werden, verwenden zur Darstellung einen Java und einen Windows Forms Viewer. In allen Tabellen mit Datenbankbezug stehen automatisch Sortier- und Filterfunktionen zur Verfügung. Beide stellen das vom Application Server gelieferte XML wie ein Browser dar.

ERP-Systeme oder andere Framework-Studio-Anwendungen lassen sich auf verschiedenen Betriebssystemen wie Windows, Linux oder Apple betreiben. Damit eNVenta ERP auch im mobilen Umfeld eingesetzt werden kann, ist es unerlässlich auch Smart Clients wie PDAs zu unterstützen. Für diesen Zweck wird eine ASP-Variante anhand eines Ajax-Konzeptes angeboten. Dabei ist von Vorteil, dass die Anwendung für den neuen Client nicht neu geschrieben werden muss, da im Hintergrund weiterhin, wie bei den anderen Clients, dasselbe XML mit dem Application Server ausgetauscht wird.
Framework Studio ermöglicht es, Forms und Workflows individuell an die Kundenbedürfnisse anzupassen. Bestehende Forms lassen sich erweitern oder austauschen und neue Forms in die Anwendung integrieren. Die Formulare sind jedoch nur der sichtbare Teil der Anwendung. Der weitaus größere und somit auch interessantere befindet sich in den Components. Dort finden die eigentlichen Berechnungen und Überprüfungen statt. Auch diese Components können an die Kundenwünsche angepasst werden.

Auch die Definition neuer Properties ist möglich. Diese Properties können als Datengrundlage sogar eine neue Spalte der bereits verwendeten Datenbank-Tabelle benutzen, die auch anpassbar ist. Die neuen Properties lassen sich auch an Form Controls und speziell an Grid Columns binden und sie können auch in anderen Components wiederverwendet werden.

Per Mausklick lassen sich mehrsprachige Datenbankfelder schnell und komfortabel mit Framework Studio anlegen. Sie werden automatisch im Hintergrund verwaltet. So ist es möglich, in allen Bereichen der Anwendung die Texte mehrsprachig zu hinterlegen. Das zeitaufwändige manuelle Erzeugen und Pflegen von Sprachtabellen entfällt. Durch die Unterstützung des Unicode-Standards können auch Sprachen verwendet werden, deren Zeichen nicht im ASCII-Standard berücksichtigt sind. Doch ein Software-Hersteller kann beim Schreiben der Anwendung unmöglich alle Sprachen berücksichtigen. Aus diesem Grund gibt es ein Tool, das alle in der Anwendung hinterlegten Texte in eine Datei exportiert, die dann problemlos übersetzt werden kann und anschließend einfach wieder importiert wird. Die Anwendung versteht die neue Sprache. Werden zu einem späteren Zeitpunkt Änderungen in der Übersetzung gewünscht, wird dieser Vorgang einfach wiederholt. Dann werden nur die geänderten Übersetzungen aktualisiert.

Das größte Entwicklungsprojekt mit Framework Studio ist die ERP-Software eNVenta ERP der Firma Nissen & Velten. Sie stand im Jahr 2001 vor der Herausforderung ihre bestehende ERP-Software auf Basis von .NET-Technologie komplett neu zu entwickeln. Framework Studio entstand als Antwort auf diese Herausforderung. Dementsprechend nutzt eNVenta ERP das Package-Konzept von Framework Studio. Die Klassen werden über die Packages hinweg vererbt und sind dann beispielsweise für länder-, branchen-, partner- oder kundenspezifische Erweiterungen reserviert. Die Packages können unabhängig von einander ausgetauscht werden. Die fertige Lösung setzt sich ebenfalls aus einer Reihe von Packages zusammen. Ihre Anzahl und ihre Hierarchie sind variabel.

Mit dem Unternehmen verbundene Systemhäuser entwickeln auf der Basislösung aufbauende Erweiterungen und Branchenlösungen. Dabei greifen sie auf die in der Basislösung implementierte Klassenbibliothek zu, um die Software um neue Dialoge, Logik und Funktionalität zu erweitern. Die Entwicklung kann unabhängig vom Hersteller erfolgen. Die Kunden können aus dem Pool von Packages die für sie relevanten Erweiterungen auswählen. So sind im Rahmen von ERP-Projekten schon fünf oder sechs dieser Packages für einen Kunden entwickelt und installiert worden. Diese Erweiterungen laufen in der Praxis konfliktfrei zusammen.