Releasefähigkeit von ERP-Systemen als Qualitätsmerkmal (2/3)

Releasefähigkeit_von_ERP-Systemen

Dass eine ERP-Lösung releasefähig sein muss, ist allen bewusst. Nur so kann sie aktualisiert und an neue Anforderungen angepasst werden. Aber wie kann die Releasefähigkeit überhaupt ermittelt, bewertet und verglichen werden?

Im ersten Teil des Beitrags bin ich auf die Bedeutung der Releasefähigkeit von ERP-Systemen im Allgemeinen sowie in Zusammenhang mit kundenspezifischen Anpassungen eingegangen. In diesem Teil geht es um die Frage der konkreten Bewertung.

Einflussfaktoren auf die Releasefähigkeit

ERP-System-Kontextdiagramm

ERP-Systemkontext

Die Releasefähigkeit eines ERP-Systems wird meist entweder bei einer ERP-Evaluation oder bei einer Bewertung der bestehenden Installation beurteilt. In beiden Fällen ist es wichtig sich zu vergegenwärtigen, dass die Releasefähigkeit nicht alleine von der gelieferten Software abhängt. Zur Beurteilung der Releasefähigkeit einer ERP-Lösung genügt es daher nicht, die ERP-Software isoliert zu betrachten. Wichtig ist, die Releasefähigkeit in dem jeweils gegebenen Systemkontext zu beurteilen. In Bezug auf die Releasefähigkeit sind insbesondere folgende Faktoren relevant:

  • Stakeholder des Releases
  • ERP-Software: das gelieferte ERP-Release
  • Bereitstellungsprozess des ERP-Anbieters
  • Inbetriebnahmeprozess (Deployment) beim Kunden
  • Integration in die Systemumgebung des Kunden

Stakeholder

Stakeholder sind die Gruppen von Personen innerhalb oder ausserhalb einer Organisation, die von einem Releasewechsel betroffen sind oder einen Beitrag dazu leisten. Interne Stakeholder sind meist:

  • Anwenderinnen und Anwender
  • Das Adminsitratorenteam
  • Die für den Betrieb zuständige IT-Abteilung
  • Die Eigentümer der Organisation

Zu den Stakholder ausserhalb der Organisation gehören zum Beispiel:

  • Kunden (mit oder ohne Systemanbindung)
  • Lieferanten, die an das System angebunden sind
  • Dienstleister und Informationsempfänger wie z. B. Banken, Versicherungen
  • Der Lieferant des Releases
  • evtl. normative oder gesetzgebende Instanzen

Die Interessen der Stakeholder können unterschiedlich sein. Anwenderinnen und Anwender wünschen sich laufend schnelle Inbetriebnahmen um durch die neuen Funktionen Entlastung zu erhalten. Das Administratorenteam möchte dagegen ausgiebig testen um den zuverlässigen Betrieb der Lösung sicherstellen zu können. Die IT-Abteilung möchte möglichst selten neue Releases einspielen müssen. Auch innerhalb einer Gruppe müssen die Interessen nicht homogen verteilt sein.

Viele Stakeholder mit unterschiedlichen Interessen wirken sich negativ auf die Releasefähigkeit aus. Je besser die Übereinstimmung der Interessen, desto höher ist die Releasefähigkeit.

ERP-Software

Von allen Faktoren, die die Releasefähigkeit beeinflussen, ist die ERP-Software derjenige, der am meisten vom ERP-Hersteller abhängt. Hierbei spielen sowohl die Konzeption als auch die Umsetzung im Detail eine Rolle. Hängt die vom Anbieter ausgelieferte ERP-Software von verschiedenen anderen Softwaresystemen ab, müssen die Abhängigkeiten sicher getestet werden. Unter Umständen sind jedoch auch Updates der anderen Systeme notwendig. Ein Releasewechsel in einem ERP-System kann eine Reihe weiterer Updates nach sich ziehen. Insbesondere der Planungsaufwand wird dadurch erheblich erhöht.

Ein weiterer Punkt ist die Releasestrategie für die ERP-Lösung. Hierzu gibt es unterschiedliche Konzepte: Manche Anbieter stellen jährlich ein Release zur Verfügung, das installiert werden muss. Andere stellen Ihre ERP-Releases je nach anstehenden Entwicklungen gemäss einer Roadmap bereit. Kunden entscheiden pro Release, ob der Nutzen den Aufwand für einen Releasewechsel rechtfertigt. Weitere Varianten sind möglich.

Bereitstellungsprozess für ERP-Releases

Hierbei geht es darum, die Bereitstellung eines neuen ERP-Releases zu prüfen. Dabei ist die Frage nicht primär, ob der ERP-Anbieter die Software auf CD/DVD oder per Download ausliefert sondern vielmehr, was der ERP-Anbieter anbietet, um einen effizienten Releaswechsel zu ermöglichen. Dazu können Tools für die Bereitstellung und Installation oder die Datenmigration gehören. Ein weiterer wichtiger Punkt ist die Bereitstellung von Dokumentation, die für einen erfolgreichen Releasewechsel benötigt wird. Die Dokumentation sollte nicht nur Installationsanweisungen für die IT enthalten sondern den gesamten Releaseprozess abdecken, von der Ermittlung des Nutzens über die Planung bis hin zur Schulung der Anwenderinnen und Anwender und der Abnahme (siehe unten).

Inbetriebnahmeprozess für ERP-Releases

Um den Prozess der Inbetriebnahme eines ERP-Releases durch die eigene Organisation bieten sich zwei Kenngrössen an: Die Durchlaufzeit und die geleisteten Stunden. Des Weiteren können verschiedene KPIs definiert werden, die qualitative Aspekte berücksichtigen. z. B .:

  • Anzahl Incidents aufgrund Releasewechsel
  • Anzahl durchgeführter Änderungen
  • Kundenzufriedenheit zum Releasewechsel

Der Prozess des Releasewechsel wird im ITIL  Release und Deployment Management gut beschrieben. Die Beschreibung ist als Grundlage für Optimierung in diesem Bereich geeignet. Eine hilfreiches Modell für die Verbesserung des Inbetriebnahmeprozesses ist das Capability Maturity Model Integration (CMMI). Hierbei werden die eigenen Prozesse bezüglich ihrere Reife eingestuft. Die Reife ist im CMMI wie folgt definiert:

  • Initial: Prozesse sind unvorhersehbar, unkontrolliert und reaktiv
  • Managed: Prozesse für Projekte beschrieben, häufig reaktiv
  • Defined: Projekte passen sich unternehmensweit standardisierten Prozessen an
  • Quantitatively Managed: Prozesse werden gemessen und überwacht
  • Optimizing: Fokus auf Optimierung

Ziel ist, die Prozesse in Zusammenhang mit Releasewechseln auf eine hohe Reife zu bringen.

Integration

Um die Integration einer ERP-Lösung zu bewerten, wird häufig die Zahl der Schnittstellen verwendet. Diese Angabe alleine ist jedoch nicht sehr aussagefähig. Eine Schnittstelle kann einfach oder kompliziert sein, je nach Art und Anzahl der übertragenen Parameter. Auch Art und Häufigkeit des Zugriffs kann eine Rolle spielen.

Des Weiteren können verschiedene Applikationen auf einen gemeinsamen Datenbestand zugreifen (z. B. ERP-System und DMS oder Tools, die an ERP-Systeme angebunden sind). Je mehr Anwendungen auf einen gemeinsamen Datenbestand zugreifen, desto komplizierter wird ein Releasewechsel. Spätestens wenn die gemeinsam genutzten Daten für den Releasewechsel migriert werden müssen, wird es anspruchsvoll.

 

Veröffentlicht am 20. August 2015
2 Kommentare

[…] Kunden stehen vor der Herausforderung, dass ERP-Systeme kaum voreinander zu unterscheiden sind (Daher stammt vermutlich auch der Ausdruck „Standardsoftware“). Zwar gibt es teilweise Ausrichtungen auf Industrien, Branchen, Teilbranchen und Kundengrössen, die meisten ERP-Anbieter können mit ihren Lösungen (aus ihrer Sicht) jedoch fast alles. Und so verkaufen Sie auch Ihre ERP-Produkte. Zur Not wird da noch ein Subsystem eingebunden oder dort noch eine Entwicklung vorgenommen, selbstverständlich ohne Einbussen bei der Releasefähigkeit. […]

Kommentar schreiben