Framework zur Evaluierung der Erweiterbarkeit cloudbasierter ERP-Systeme
Lesedauer: 10 Minuten
Die Anpassbarkeit cloudbasierter ERP-Systeme ist systembedingt limitiert, da nur auf diese Weise viele Mandanten effizient in einem SaaS-Ansatz bedient werden können. Dennoch müssen Prozesse immer wieder angepasst oder gegebenenfalls lokal ausgeprägt werden. Durch Verlagerung der technischen Kompetenz hin zum SaaS-Provider nimmt die technische Kompetenz in Unternehmen sukzessive ab. Low-Code-Plattformen können eine Option sein, diese Prozessanpassungen über fachliche Anwendungsentwickler (sogenante Citizen Developer) zu ermöglichen. Doch wann lassen sich Prozesse in einem cloudbasierten System gut abbilden, über eine Low-Code-Plattform modifizieren und wann nicht? In diesem Artikel wird ein Framework vorgestellt, das bei der Analyse von potenziell in ERP-Systemen abbildbaren Prozessen mittelständischer Dienstleistungsunternehmen unterstützt. Das Resultat ist die Ermittlung geeigneter Anpassungsoptionen mit anschließender Priorisierung.
In diesem Beitrag lesen Sie:
- wie unter Zuhilfenahme eines Frameworks die Abbildbarkeit von Prozessen und die optimale Reihenfolge der Implementierung ermittelt werden kann
- welche Anpassungsformen es für ein ERP-System geben kann
- welche Anpassungsform des ERP-Systems optimal zur Abbildung eines Prozesses geeignet ist
Das in diesem Artikel beschriebene Framework besteht aus dem Zusammenspiel von Prozessmodellierung, Entscheidungsbaum, Scoring, Feedback von Experten und Priorisierung. Es hat zum Ziel, bei der Entscheidungsfindung von der Ist- über die Sollprozessmodellierung bis hin zur Bewertung der technischen Umsetzbarkeit eines Prozesses und Aufbereitung der Inhalte eine Empfehlung für die optimale Anpassungsmöglichkeit und Reihenfolge der Umsetzung zu geben.
Design und Development
Die Bestandteile des Frameworks [1] lassen sich aus dem „Venn-Diagramm für Innovation“ ableiten. Das abgebildete Venn-Diagramm zeigt, wie eine funktionsübergreifende Denkweise zu Innovation führen kann, welche aus der Schnittstelle von Desirability, Feasibility und Viability resultiert [2].
Die Desirability fokussiert sich auf die Lösung aus Sicht des Nutzers, um nachvollziehen zu können, ob die angestrebte Lösung ein reales Problem des Nutzers behebt oder gewünscht, aber nicht notwendig ist. Behebt die Lösung ein reales Problem, besitzt sie ein besonderes Maß an Bedeutung. Zusammengefasst testet die Desirability, ob die Innovation das tatsächliche Problem des Nutzers löst [3].
Die Feasibility behandelt die Umsetzbarkeit – also ob die Organisation in der Lage ist, eine Lösung für das Problem des Nutzers zu liefern. Das beinhaltet Fragen der technischen Kompetenz, Serviceprozesse und Inhalte, die dabei unterstützen können, den Nutzer mit einem Angebot zufriedenzustellen.
Der Bereich der Viability betrachtet das Business-Modell der Lösung. Damit einher geht die Kontrolle der finanziellen und nicht-finanziellen Kennzahlen. Grundlegend prüft die Viability die Lösung auf ihre Nachhaltigkeit, Beständigkeit und ihr Langzeitwachstum.
Nachdem Prozessabbildungen im ERP oft auf „Business Performance Improvements“ zielen – also bestehende Abläufe effizienter abzubilden oder mindestens zu unterstützen, steht hier die Teilschnittmenge zwischen Feasibility und Viability im Fokus. Deswegen wurde der Auswahlprozess auf diese Schnittmenge ausgelegt: Die technische Umsetzbarkeit (Feasibility) wird mithilfe eines Entscheidungsbaumes evaluiert, während die „Viability“ über ein Scoring-Modell die geschäftlichen Effekte priorisiert.
Vorstellung des Frameworks
Um zu beantworten, wann und wodurch Aufgaben und Prozesse mittels einer Anpassungsstufe abgebildet werden können, wird unter Zuhilfenahme ausgewählter Literaturquellen ein Framework entworfen. Dieses Framework besteht aus vier aufeinander aufbauenden Schritten (vgl. Bild 2): Prozessmodellierung, Entscheidungsbaum, Scoring und Priorisierung.
Im Rahmen einer Prozesserhebung wird zunächst der im Unternehmen vorhandene Ist-Prozess aufgenommen und modelliert. Anschließend wird dieser in einer Soll-Prozessphase auf Optimierungspotenziale hin analysiert; die gewonnenen Erkenntnisse fließen dann in ein Re-Design vom Ist- hin zu einem verbesserten Soll-Prozess ein.
Sobald der Soll-Prozess vorliegt, durchläuft er die Phase des Entscheidungsbaumes. Der Entscheidungsbaum hilft zu prüfen, ob der Prozess in seiner optimierten Form von dem im Unternehmen implementierten ERP-System abgebildet werden kann. Des Weiteren kann hier bereits eine erste Indikation gegeben werden, welche der Anpassungsstufen (Standard-ERP-System, Low- oder High-Code-Ansatz) geeignet sind, um den Prozess abzubilden.
Nachdem durch den Entscheidungsbaum die Abbildbarkeit des Prozesses im ERP-System des Unternehmens bestätigt ist, erfolgt die Bewertung des Prozesses mittels eines Fragebogens. Dieser wird vom Prozessexperten gemeinsam mit einem Business Analysten ausgefüllt. Daraus ergeben sich Werte zur wirtschaftlichen Relevanz des Prozesses und der Komplexität der Prozessverbesserung.
Diese zwei Werte bilden die Grundlage zur Einordnung des Prozesses innerhalb des Scoring-Systems. Aus dem Verhältnis von Benefit und Komplexität wird dann eine Priorisierung abgeleitet und die Reihenfolge der Implementierung der im ERP-System abzubildenden Prozesse empfohlen.
Vorstellung des Entscheidungsbaumes
Dem Scoring-System vorgelagert bestimmt der Entscheidungsbaum, ob der Prozess mit den Anpassungsstufen Standard-ERP-System, Low-Code und High-Code nur unter speziellen Voraussetzungen oder überhaupt nicht abbildbar ist. Die Kriterien sind dabei so angeordnet, dass jene mit dem größten Potential einer Nichterfüllung am Anfang des Entscheidungsbaumes stehen.
Die Abfrage der Kriterien wird mit fortschreitender Tiefe des Entscheidungsbaumes zunehmend detailreicher und betrifft eine kleiner werdende Anzahl von potenziell abbildbaren Prozessen. Die im Entscheidungsbaum (vgl. Bild 3) verwendeten Knoten weisen verschiedene Farben auf, deren Bedeutung in Tabelle 1 genauer erläutert wird.
Anpassungsstufen des ERP-Systems
Der Entscheidungsbaum hat zum Ziel, eine geeignete Anpassungsstufe für einen im ERP-System abzubildenden Prozess zu ermitteln. Im Folgenden werden die einzelnen Stufen benannt und definiert:
1. Standard-ERP-System
Bei dieser Stufe der Einordnung reichen die vordefinierten Funktionen eines normalen ERP-Systems aus, um den Prozess abzubilden.
2. Leichte Modifizierung des ERP-Systems mit Low-Code
Diese Stufe indiziert, dass der Prozess nicht von den Grundfunktionen innerhalb des ERP-Systems abgebildet werden kann. Um den Prozess implementieren zu können, erfordert es den Einsatz von Low-Code. Denkbar ist die Implementierung durch die unternehmenseigenen Citizen Developer.
3. Starke Anpassungen des ERP-Systems (High-Code)
Um den Prozess im ERP-System abbilden zu können, erfordert es eine starke Anpassung bzw. Ergänzung der Software mittels High-Code. Hier ist es hilfreich, einen ERP-Experten und -Programmierer hinzuzuziehen.
4. Nicht abbildbar im ERP-System
Sollte der Prozess auf dieser Stufe eingeordnet werden, ist es mit allen definierten Anpassungsstufen nicht realistisch, den Prozess im ERP-System abzubilden. Hier bietet es sich an, den Prozess den Analysen entsprechend anzupassen, in der Originalform beizubehalten oder mittels einer anderen Lösung zu automatisieren.
Entscheidungsbaum
Nach der Vorstellung des Entscheidungsbaumes, der Erläuterung der Bestandteile und der Definition der Anpassungs-stufen erfolgt nun eine exemplarische Beschreibung der zweiten Ebene.
Innerhalb der zweiten Ebene des Entscheidungsbaumes (vgl. Bild 4, Knoten 2) geht es um die Prüfung, ob der Prozess als Supportprozess oder Kernprozess des Unternehmens definiert ist [4].
Supportprozesse haben die Eigenschaft, dass die Aktivitäten der Prozesse aus Kundensicht nicht direkt wertschöpfend sind, jedoch eine Notwendigkeit der Existenz besteht, um einen Kernprozess ausführen zu können [5, 6]. Zudem besteht die Möglichkeit, dass Support-prozesse in Kernprozesse übergehen. Ein Beispiel hierfür sind Handelsunternehmen.
Diese nehmen im Kernprozess der Zentralregulierung keine logistischen Aufgaben mehr wahr, sondern konzentrieren sich auf Regulierungsaktivitäten, welche im typischen Lagergeschäft Supportprozesse darstellen. Kernprozesse sind unter Berücksichtigung der Unternehmensausrichtung strategisch wichtig und tragen wesentlich zum Geschäftserfolg des Unternehmens bei. Zudem haben sie direkten Kun-denbezug und direkte Kundenauswirkung. Der Kunde ist bereit, für den Output des Prozesses zu bezahlen [7].
Handelt es sich um einen Kernprozess, erfordert dies eine spezielle Prüfung der Abbildbarkeit durch einen Fachexperten (vgl. Bild 4, Knoten 2a). Dieser entscheidet aufgrund des Funktionsumfangs der ERP-Lösung des Unternehmens, ob es möglich ist, den Kernprozess abzubilden. Wird diese Prüfung mit einem negativen Ausgang bewertet, ist der Prozess nicht abbildbar (vgl. Bild 4, Knoten 2b). Ist eine Abbildung möglich, erfolgt eine weitere Prüfung, ob der Prozess nur mit der Anpassungsstufe High-Code abbildbar ist (vgl. Bild 4, Knoten 2c). Sofern es noch andere Möglichkeiten neben High-Code gibt, wird die dritte Ebene des Entscheidungsbaumes angesprochen. Ist nur High-Code als Lösungsmöglichkeit vorhanden, endet der Prozess, da eine Abbildbarkeit im ERP-System durch eine Anpassungsstufe festgestellt wurde (vgl. Bild 4, Knoten 2d). Handelt es sich um einen Supportprozess, wird direkt die dritte Ebene des Entscheidungsbaumes erreicht.
Wenn der abzubildende Prozess alle relevanten Ebenen des Entscheidungsbaumes und die potenziellen Prüfungen auf Abbildbarkeit mit positivem Ausgang durchlaufen hat, ist der Prozess im ERP-System abbildbar.
Scoring
In der Phase des Scorings wird der im ERP-System abzu- bildende Prozess anhand der aufgelisteten Kriterien in Form eines Fragebogens bewertet. Die Gewichtung der Kriterien kann hierbei von Organisation zu Organisation unterschiedlich sein und muss individuell angepasst werden. Die Empfehlung ist hier, die Gewichtung der Kriterien gemeinsam mit den Prozessexperten des Unternehmens und relevanter Fachliteratur zu entwickeln [8, 9, 10]. Die Kriterien sind dabei in vier Bereiche unterteilt, aus denen der Score abgeleitet wird: Grund- informationen, Ist-Prozess,
Prozessvalidierung und Benefits. Der zugewiesene Score bestimmt die entsprechende Anpassungsstufe bzw. Anpassungsstufen und die Priorität der Umsetzung.
Priorisierung
Um die Prozesse priorisieren zu können, werden die ermittelten Scores innerhalb einer Scoring-Matrix verortet, welche aus vier Quadranten besteht: Quick Win, Low-Hanging Fruit, Must-Do-Improvement, Long-Term-Improvement (vgl. Bild 5). Welcher Prozess als nächstes bearbeitet wird, ist im Vorfeld in einer Analyse zu begutachten. In dieser Analyse werden die eingereichten Prozesse anhand zweier Kennzahlen beurteilt. Der Komplexitätsscore gibt an, wie schnell eine Automatisierung für den Prozess umzusetzen ist. Faktoren wie standardisierter Ablauf, dokumentierter Prozess, wenige Ausnahmen und regelbasiertes Arbeiten erzielen einen Komplexitäts- bzw. Umsetzbarkeitsscore (Y-Achse). Maximal kann ein Komplexitätsscore von 500 Punkten erreicht werden.
Die Benefits (X-Achse) spiegeln den mit der Automatisierung einhergehenden Nutzen wider. Aspekte wie hohe Fehlerquote der manuellen Arbeitsergebnisse erzielen einen hohen Benefit. Maximal können hier 500 Punkte erreicht werden. Anhand dieser beiden Faktoren werden die Projekte in vier Kategorien eingeteilt (Bild 5):
Der Wert der Gewichtung gibt die Priorisierung innerhalb der jeweiligen Kategorien in Prozent vor. Entsprechend hat ein höherer Wert der Gewichtung eine höhere Priorisierung. Er ist ein zusammengesetzter Wert der erreichten Punktzahl, der sich aus dem Komplexitätsscore und den Benefits in Relation zur maximal erreichbaren Punktzahl ergibt.
Basierend auf den Kategorien lassen sich dann für den Prozess konkrete Handlungsempfehlungen ableiten, wann eine Implementierung des Prozesses im ERP-System vorgenommen werden sollte.
Alexander Nitzschke ist Masterstudent im Studiengang Wirtschaftsinformatik und Digitale Transformation an der Universität Potsdam. Darüber hinaus bildet er das PMO beim ERP-Projekt zur Einführung von einer ERP-Lösung im mittelständischen Wirtschaftsprüfungsunternehmen Mazars.
Maik Schmalstich ist Programm-Manager ERP beim Wirtschaftsprüfungsunternehmen Mazars
und hat langjährige Erfahrung im Rechenzentrumsbetrieb, in der Technologie- beratung sowie in der Cloud Advisory digitaler Transformationen. Er begleitet komplexe Transformationsvorhaben mit Schwerpunkt auf Digitalisierung und nachhaltiger Lösungsarchitektur.
Dipl.-Kfm. Marco Ehlert ist seit 5 Jahren Partner bei Mazars und verantwortet den Bereich IT Audit & Advisory. Er hat über 15 Jahre Erfahrung in der Einführung von ERP-Lösungen und begleitet mit seinem Team neben IT-Audits komplexe ERP-Transformationen für mittelständische und Großunternehmen.
Dr.Wolfgang Völl ist seit 2021 Partner bei Mazars in der Service Line Consulting. Er hat mehr als 14 Jahre Erfahrung in der Beratung von Unternehmen verschiedener Branchen und Größen, insbesondere in den Bereichen Accounting, Controlling und Performance Management. Sein Spezialgebiet sind digitale Finanz- und Controlling- transformationen, von der Konzeption, Toolauswahl bis hin zur Implementierung unterschiedlicher Lösungen im SAP- und Non-SAP-Bereich.
Kontakt:
Alexander Nitzschke, B. Sc.
Masterstudent an der Universität Potsdam;
PMO beim Projekt zur Einführung einer ERP-Lösung Mazars,
Alt-Moabit 2, 10557 Berlin
E-Mail:
