Suche

Ausweg aus der Sackgasse der Systemwartung

„Das alte ERP System tut ja noch“.


„Wir haben jetzt eine neue Schnittstelle programmiert, die Übertragung der Rechnungen aus dem Warenwirtschaftssystem zum Datev funktioniert jetzt automatisch“.


„Wenn wir ein ERP System haben, dann wollen wir es im eigenen Haus laufen haben“.


„Wir wollen unser ERP selbst anpassen, um es auf unsere eigenen Daten, Prozesse und Bildschirme optimal anzupassen“


Schnell finden wir uns womöglich in der einen oder anderen Aussage wieder, die man immer wieder hört. Sie spiegeln Autonomie und Wirtschaftlichkeit vor. Wenn ich mein Warenwirtschaftssystem auf den Rechnern meiner Firma betreibe, dann kann ich es auch umprogrammieren (lassen), so dass es den Anforderungen meiner Prozesse ideal entspricht. So denkt man oft am Anfang. Manchmal ist es ein bewusster Prozess, manchmal eine unwillkürliche Entwicklung über viele Jahre hinweg. Manche gehen sogar so weit ein OpenSource System zu betreiben, so dass sie es programmatisch erweitern können.


Gleichzeitig gibt es aber auch diese Probleme:

* Wie genau funktioniert das Geflecht aus Altsystemen denn eigentlich?

* Was ist mit der Dokumentation der Sonderentwicklung?

* Wer wartet diese Systeme dauerhaft?

* Wie viel Kosten müssen noch investiert werden, um alles am Laufen zu behalten?

* Was, wenn der einzige der die Sonderentwicklungen kennt, nicht mehr zur Verfügung steht?


Theoretisch lassen sich diese Probleme durch Disziplin in den Griff bekommen. Es gibt jedoch zwei technische Besonderheiten, die - wie Naturgesetze - dem Ziel einer reibungslos laufenden IT entgegenstehen.


Punkt 1 ist das Eingreifen der Sonderentwicklung in die gekaufte/angeschaffte Software.

Beispielsweise möchte man ein zusätzliches Feld auf dem Bildschirm nutzen, das eine besondere Bestellnummer darstellt, die es im Standard der gekauften Software nicht gibt. Und das ist noch ein sehr einfacher Fall. Dazu müssen verschiedene Teile der Standardsoftware angepasst, das heißt verändert, werden. Solche Änderungen der Standardsoftware nennt man auch Modifikationen. Modifikationen zeichnen sich dadurch aus, dass die Standardsoftware nicht mehr wie ausgeliefert ist, sondern abgeändert wurde.


Nun ergibt sich ein Problem. Das Problem besteht darin, dass die Standardsoftware als neues Release mit neuen und verbesserten Funktionen zur Verfügung steht, die man gerne nutzen möchte - und oft auch nutzen muss, weil gesetzliche Vorgaben es so verlangen. Nun ist es aber nicht möglich, das neue Release einfach zu verwenden und zu aktualisieren, weil dadurch die Modifikation - die eigene Sonderentwicklung - zerstört werden würde. In anderen Worten müsste die Sonderentwicklung nach dem Releasewechsel erneut wiederholt werden - zumindest in Teilen. Und das geht nur in sehr einfachen Fällen. In der Realität sind diese Projekte oft langlaufende und teure Projekte mit hohem Risikopotenzial.


Der Punkt 2 ist der, dass Sonderentwicklungen auf die Strukturen des Standard zurückgreifen. Sagen wir die zusätzliche kundenspezifische Bestellnummer wird ermittelt, indem Datum und Standardbestellnummer zusammengefügt werden. Dazu muss die Sonderentwicklung die Standardbestellnummer auslesen. Nun kann es vorkommen, dass in einem neuen Release der Zugriff auf die Standardbestellnummer nicht genau so zur Verfügung steht, wie in dem vorigen Release. In anderen Worten: Die Schnittstelle ist nicht stabil. Das ist ein weiterer Grund, warum nach einem Upgrade Sonderentwicklungen oft nicht mehr funktionieren.


Und beides ist wie ein Naturgesetz.


Ohne zu wissen begibt man sich also mit Sonderentwicklungen von selbstinstallierter Standardsoftware auf ein Minenfeld, das zugleich eine Art Sackgasse darstellt. Warum? Wegen all dieser Risiken verzichtet man oft darauf, einen Releasewechsel vorzunehmen. Das ist aber auch nur eine augenblickliche Lösung, weil auf die Dauer die gesetzlichen Anforderungen nicht mehr mit der alten Software abgedeckt werden können, die sich aufgrund neuer gesetzlicher Regelungen ergeben. Außerdem profitiert man nicht von neuen Funktionalitäten des Anbieters der Standardsoftware. Man sitzt fest. Vielleicht stellt der Anbieter sogar irgendwann die Wartung/Fehlerbehebung für das alte Release ein. Und schon sitzt man fest.


Und dabei hat noch nicht einmal jemand etwas falsch gemacht. Es ergibt sich als logische Folge der Modifikation/Sonderentwicklung bezogen auf Standardsoftware, die im eigenen Haus installiert ist. Es ist in diesem Modell unvermeidlich.


Aus diesem Grund wird Cloud ERP Software immer beliebter, weil sie die Lösung für diese Art Probleme ist. Die Software läuft in unserem Fall im Rechenzentrum von SAP. Was auch bedeutet, dass SAP sicherstellt, dass 4x im Jahr das aktuellste Release eingespielt wird - für die Nutzer vollautomatisch. Dadurch werden neueste gesetzliche Anforderungen abgedeckt und zusätzliche Funktionalitäten geliefert.


Und was ist mit den Sonderentwicklungen?


Das Ziel ist immer zuerst, die Prozesse des Standard maximal für die Anwenderfirma auszunutzen. Wenn dann immer noch etwas fehlt, gibt es definierte Mechanismen mit deren Hilfe Erweiterungen so kontrolliert erfolgen, dass damit die Fähigkeit für neue Releases nicht beeinträchtigt wird. Hier spreche ich von SAP Business ByDesign- da steht der Name für das Programm. Felderweiterungen beispielsweise müssen gar nicht programmiert werden, sondern werden nur konfiguriert. Sonstige Erweiterungen können sich an definierten stabilen Andockpunkten mit dem Standard verbinden. Das ist wie bei einer Eisenbahn, bei der man an den vorher bekannten Bahnhöfen ein- und aussteigen kann. Dazu muss man nicht extra die Gleise umlegen oder querfeldein fahren. Nun hat SAP Business ByDesign besonders viele solcher Bahnhöfe.


Und das ist der Ausweg aus der Sackgasse der Systemwartung.

Work Smart Not Hard

0 Ansichten
Partnerschaft
Wer wir sind
SOCIAL

bydesign@adapro.eu

Tel: 0621/5953-130

Donnersbergweg 1

67059 Ludwigshafen

  • xing-icon
  • LinkedIn Social Icon

© 2020 by AdaPro GmbH