Branchenspezifische  Standardsoftware – was ist das? (Teil 2)

Fortsetzung von Teil 1: Branchenspezifische  Standardsoftware – was ist das? (Teil 1)

Was sind die möglichen Bestandteile einer branchenspezifischen Standardsoftware?

Oftmals wird auch zwischen den Standard- oder Kernmodulen und Erweiterungs-modulen unterschieden. Die Kernmodule sind direkt auf das Business des Kunden ausgerichtet, während die Erweiterungsmodule entweder sehr hochwertige Ergänzungen bieten oder aber, andere Produkte beim Kunden mehr oder weniger gut ersetzen können. Manche Erweiterungsmodule werden nur deshalb gekauft, weil die Schnittstelle direkt integriert ist, obwohl ein anderes „standalone“ betriebenes Produkt vielleicht viel besser wäre. Zu unterscheiden ist zwischen integrierten Modulen, die nur zusammen mit den Kernmodulen arbeiten und Modulen, welche auch als eigenständiges Produkt vertrieben werden können.

Reicht dies immer noch nicht aus, um den Kunden zu überzeugen, dann geht es eine Stufe weiter. Große Softwaresuiten erlauben auf Skriptsprachen basierende eigenständige Erweiterungen anzuflanschen, ohne an den Sourcecode gehen zu müssen.

In der obigen Grafik sieht man, dass der Ring dicker geworden ist. Er soll die zusätzliche Möglichkeit verdeutlichen.

Standardsoftware gegen Individualsoftware

Hast Du den Beitrag bisher aufmerksam verfolgt, dann hast Du bestimmt gemerkt, dass wir uns mehr und mehr hin zur individuellen Software bewegt haben. Genau hier gilt es aufzupassen, um sich langfristig viel Ärger zu ersparen.

Bei der Anpassung der zuvor beschriebenen Produkte unterscheide ich nach:

• Customizing
  • Parametrisierung
  • Konfiguration
• Programmierung
  • Erweiterungsprogrammierung
  • Anpassungsprogrammmierung

Customizing

Hierunter verstehe ich bei einer branchenspezifischen Standardsoftware alle Maßnahmen, die mehr oder weniger ohne spezielle Programmierkenntnisse zum aufsetzen des Tools notwendig sind. Das Ziel der Anpassung ist die Transformation von der gelieferten Musterlösung hin zu dem vom Kunden gewünschten Soll-Zustand. Der Quellcode der Anwendung ist dabei tabu. Das Customizing kann in zwei Teilschritten, der Parametrisierung und der Konfiguration erfolgen.

Parametrisierung

Ich verstehe unter der Parametrisierung die Anpassung des Leistungsumfangs eines Tools durch „an- und ausschalten“ von einzelnen Modulen und Komponenten. Die Parametrisierung umfasst die Modul-, Profil- und Anwenderverwaltung.

Konfiguration

Die Konfiguration folgt auf die Parametrisierung und befasst sich mit der Gestaltung des User-Interfaces. Es geht darum Menüs, Ordner, Seiten, Bereiche und Felder den Erfordernissen des Kunden anzupassen. Dies wird immer an der Oberfläche der Anwendung geschehen und nicht mit Änderungen des Quellcodes einhergehen. Beispiele sind die farbliche Gestaltung, die Positionierung von Feldern, die Umbenennung einzelner Felder etc.  

Programmierung

Bei der Programmierung unterscheide ich in Erweiterungsprogrammierung und Änderungsprogrammierung. Die Änderungsprogrammierung ist für mich der einschneidende Punkt hin zur Indiviualsoftware. An diesem Punkt kommt nicht selten die Frage auf: Hätten wir die Lösung nicht direkt selbst programmieren lassen sollen?

Bei der Erweiterungsprogrammierung handelt es sich eher um die Erstellung eines kundenspezifischen Moduls, welches über hoffentlich vorhandene Schnittstellen an das Standardtool angeflanscht werden kann. Die Pflege dieser kundenspezifischen Weiterentwicklung wird immer zu lasten des Kunden gehen. Es sei denn, der Anbieter würde sich mit Einverständnis des Kunden dazu entschließen, das Ergebnis mit in seine Produktpalette aufzunehmen. Die Erwartungshaltung der Kunden ist in dieser Hinsicht oft sehr hoch, wird aber meist nicht erfüllt werden (können).

In der obigen Grafik habe ich eine Schnittstelle (grünes Rechteck) eingebaut, welche eine externe Software mit der Standardlösung verbinden soll. Rechts habe ich eine Anpassungsentwicklung eingebaut (rotes Dreieck). In diesem Fall würde ein Modul den spezifischen Wünschen des Kunden angepasst.

Warum muss ich hier aufpassen?

Bei der Erstellung der Anpassungen und Erweiterungen ist es wichtig, dass der Code, unabhängig davon, wer die Wartung bezahlt, möglichst dicht an der Standardlösung bleibt. Am besten wäre natürlich die Verwendung von programeigenen Skripten. Ansonsten sollte man aber zumindest darauf achten, dass die Grundsprache die gleiche ist.

Die Intervalle für Updates und Upgrades sind meist gar nicht so lange. Bei einer Standardsoftware schließen Sie oft auch Anpassungen an neue Betriebssysteme oder Basisprogramme mit ein. Für den normalen Anwender in aller Regel ganz unbemerkt. Viele Systeme greifen als Applikationslösung auch auf Standarddatenbanken wie MS SQL oder Oracle zurück. Ändert sich hier etwas, dann kann das auch Auswirkungen auf die Applikation haben.

Anpassungen der Applikation sind normalerweise über die Wartung abgedeckt. Hast Du nun aber eigene Module entwickeln, oder gar Anpassungen am Quellcode machen lassen, dann gehen die vorzunehmenden Wartungsarbeiten alleine zu Deinen Lasten. Daher kann diese starke Individualisierung sehr schnell zum Boomerang für Dich werden. Je weiter weg vom Standard, umso gefährlicher für Dich. Ich hab schon einige Klienten gesehen, die nach 2 bis 3 Jahren reumütig wieder zurück auf die Standardapplikation migriert sind.

Ist die Erstellung einer Individualsoftware dann nicht doch besser?

Hier mal wieder ein ganz klares JEIN! Bevor man diese Frage beantworten kann, muss man eine ganze Menge an Variablen ins Kalkül ziehen. Mögliche Variablen können die Anzahl der Nutzer, die Variabilität des Businessmodells, die vorhandenen Ressourcen etc. sein. Wie oft habe ich es schon gesehen, dass kaum war die Software in Betrieb, wurden umfangreiche Änderungen vorgenommen, da die Planung falsch war oder sich das Geschäftsmodell geändert hatte. Anpassungen einer branchenspezifischen Standardsoftware sind in diesen Fällen meist einfacher zu lösen.

Schau Dir bitte die Reihe Softwareeinführung hier im Blog an. Sie hat mehrere Teile und startet mit folgendem Beitrag: Softwareeinführung – 1 – Prozessstart – Ressourcen. Dort sensibilisiere ich auf die Untiefen bei der Einführung von Softwarelösungen.