„Recovery“-Projekte sind Maßnahmen, die Unternehmen bei schwierigen Momenten während einer sich verzögernden Implementierung unterstützen, oder aber bei einer Situation, in der das implementierte System oder Tool nicht den spezifischen Erwartungen entspricht.
Wann erfordert ein Projekt eine Korrektur?
Wir sprechen hier von konkreten Situationen, die bei der Umsetzung eines Projekts aufgetreten sind:
- Fehlende ganzheitliche Sicht auf die gesamte Lösung und Unklarheiten in Bezug auf die Anforderungen (sie sind ungenau oder stehen im Widerspruch zueinander).
- Probleme mit dem Zeitplan (unrealistischer oder übertrieben optimistischer Zeitplan).
- Planung auf der Grundlage fehlender Schlüsselinformationen und -komponenten oder auf der Grundlage falscher Einschätzungen.
- Ressourcenknappheit (übermäßige Belastung der Ressourcen, Unvermögen, Ressourcen effizient einzusetzen, mangelnde Kompetenz auf der Ebene der Ressourcen).
- Unvollständiges oder vollständig fehlendes Risiko- und Bedrohungsmanagement im Zusammenhang mit den Projekten.
Solche Probleme können in zwei Bereichen auftreten: auf der administrativen und auf der inhaltlichen Ebene. Während diejenigen Schwierigkeiten, die mit dem Projektmanagement zu tun haben, in der Regel zu bewältigen sind, stellen diejenigen, die mit der inhaltlichen Ausarbeitung zu tun haben, oft eine sehr große Herausforderung dar. Nehmen wir zum Beispiel die Frage der Internationalisierung eines Projekts, so nimmt die Komplexität dieses Projekts östlich der Oder und südlich der Alpen zu. Die Diversifizierung der Märkte wächst und wenn Unternehmen nicht schon zu Beginn bestimmte Standards setzen, kann es sich herausstellen, dass sie trotz des implementierten Projekts nicht den Geschäftserwartungen des Unternehmens entsprechen und viele Probleme verursachen. – sagt Remigiusz Efinowicz, Executive Director International Sales und Geschäftsführender Gesellschafter von Hicron.
Das Projekt läuft schlecht
Nun stellen wir uns vor, dass sich der Kunde in der Mitte des Projekts befindet, aber alle Indikatoren, einschließlich des KPI, anzeigen, dass sowohl das Budget als auch der Zeitplan überschritten worden sind. Das Projekt wird angehalten. Wir hatten eine solche Situation bei einem unserer Kunden aus der DACH-Region. Der Auftraggeber blieb zusammen mit dem Beratungsunternehmen, dem Hauptauftragnehmer, auf der Ebene der Erstellung von Facility-Management-Konzepten stecken. Die eigentliche Lösung war ineffizient, die Rechnungsprozesse dauerten etwa zwei Wochen. Der Kunde suchte also nach einer Lösung für diese Situation. Das Beratungsunternehmen versuchte zu helfen, aber es fehlten ihm die Kompetenzen, über den typischen ERP-Systemstandard hinauszugehen. Zusammenfassend lässt sich sagen, dass die Lösung zwar implementiert worden war, aber äußerst wirkungslos blieb. Wir wurden daraufhin eingeladen, bei der Lösung dieser Situation zusammenzuarbeiten. Wir haben uns die Hauptziele des Kunden angesehen und eine alternative Lösung vorgeschlagen, die jedoch vollständig auf den bereits implementierten Modulen des Systems basierte. Unsere Methode erlaubte es dem Kunden, sich auf das Geschäft selbst und nicht auf die Systemstruktur zu konzentrieren. Im Laufe eines Monats haben wir ein Konzept entwickelt, mit dem der Kunde seit einem Jahr arbeitet. – sagt Remigiusz Efinowicz.
In den nächsten 7 Monaten implementierte Hicron dann eine Komplettlösung, die die Arbeit der Anwender in hohem Maße automatisierte und die Erreichung der Geschäftsziele des Kunden wie folgt beeinflusste:
- Reduzierung der Fakturierungszeit von 2 Wochen auf 12 Stunden,
- Reduzierung der Anzahl der Personen, die den angegebenen Bereich betreuen müssen, von 8 auf 3.
Zusammenfassend lässt sich sagen, dass der Kunde seine Unternehmensziele auf Grundlage der gleichen ERP-Lösung erreicht hat. Der ursprüngliche Lieferant war auf einen Standardansatz zur Steuerung der Unternehmensprozesse spezialisiert, verfügte aber nicht über den Mut und das Wissen, über die ihm bekannte Lösung hinauszugehen und auf Grundlage der vorhandenen Infrastruktur etwas Innovatives auf Basis desselben ERP-Systems vorzuschlagen.
Das Projekt scheiterte
Eine andere Situation und ein internationaler Kunde aus dem fernen Asien. Implementierung der Standardlösung, aber der erforderliche fachliche Hintergrund wurde nicht berücksichtigt, was dazu führte, dass sie in verschiedenen Märkten nicht einsetzbar war. Beim Implementierungsansatz wurden die folgenden Punkte nicht berücksichtigt:
- Standardisierung der Basisprozesse,
- die Flexibilität der Prozesse in Bezug auf regionale Anforderungen (beispielsweise Rechtsvorschriften in den betreffenden Ländern).
Diese beiden Punkte werden oft als widersprüchlich angesehen, was dazu führt, dass Unternehmen aus Angst vor übermäßigen Komplikationen versuchen, alles zu vereinfachen und eine Lösung zu entwickeln, deren Nutzen in diversifizierten Märkten sehr gering ist. Dies liegt dann unter anderem daran, dass die Endanwender mit der Art und Weise, wie das System ihr Geschäft unterstützt, unzufrieden sind.“ – sagt Efinowicz. „In der beschriebenen Situation ist es notwendig, ein solches System zu stabilisieren, die größten Probleme zu beseitigen und schließlich das Reengineering der Lösung selbst durchzuführen. Letzteres ist wichtig, weil Systeme für das Enterprise Resource Management Werkzeuge sind, die fortlaufend an die Marktveränderungen in einem bestimmten Bereich angepasst werden sollten.
Erwähnenswert ist auch, dass im Zuge der Digitalisierung die Erwartung besteht, Veränderungen im Kontext von Geschäftsprozessen und einem zunehmenden Wettbewerb so schnell wie möglich umzusetzen. Das Projekt-Reengineering unterstützt die Verkürzung des Umstellungszyklus im operativen Geschäftsbereich des Unternehmens.
Die Kosten sind zu hoch
Es kommt auch vor, dass der Grund für den Start eines „Recovery“-Projekts zu hohe Kosten für die Implementierung der Lösung auf verschiedenen Märkten sind, also für die sogenannten Rollouts. Die Veränderung der Sichtweise bei der Verlagerung von Anforderungen in neue Bereiche erfordert einen beratenden Ansatz. Ein Beispiel hierfür ist ein Unternehmen, das viele verschiedene internationale Implementierungen seines Systems durchgeführt hat. Nach erheblichen Budget- und Terminüberschreitungen in den Vereinigten Staaten fragten sie uns von Hicron danach, ob es möglich sei, einen neuen Ansatz für diese Art von Projekten auszuarbeiten. Das übergeordnete Ziel war es, den Rollout-Prozess zu beschleunigen und die Kosten zu senken. In dieser Situation waren wir kein Implementierungspartner und haben auch keine Software implementiert, sondern nur beratend zur Seite gestanden. Das Problem wurde in Zusammenarbeit mit dem Management des gesamten Projektes gelöst. – erinnert sich Remigiusz Efinowicz.
Schwerpunkte waren das Anforderungsmanagement für neue Märkte und die Lösung des Problems im Zusammenhang mit den verpassten Umsetzungsfristen. In einer solchen Situation sollten die Anforderungen an das Projekt in zwei Gruppen eingeteilt werden:
- gesetzliche Anforderungen – bezogen auf das Wirtschafts- und Rechtssystem eines bestimmten Gebiets.
- funktionale Anforderungen – bezogen auf Gewohnheiten und kulturelle Gegebenheiten der jeweiligen Region.
Es ist zu berücksichtigen, dass in einer solchen Situation ein Konflikt zwischen dem Eigentümer des Zentralsystems und der zum Unternehmen gehörenden Einheit entstehen kann. Eine Tochtergesellschaft versucht in der Regel, ihre Arbeitsweise beizubehalten. Unser Vorschlag bestand darin, sich zunächst mit der Umsetzung der gesetzlichen Anforderungen zu befassen. Was die anderen Anforderungen betrifft, so haben wir empfohlen, sie in die Liste der funktionalen Anforderungen aufzunehmen, die von einer eigens zu diesem Zweck eingerichteten zentralen Stelle verwaltet wird, und zwar dem Leitungsorgan. Dies ermöglicht die Identifizierung und Umsetzung von Best Practices sowohl bei der Muttergesellschaft als auch bei der Tochtergesellschaft. Ein weiterer Vorschlag war die Entwicklung von Beschleunigern und Tools zur Implementierung von IT-Lösungen auf neuen Märkten, wie etwa gebrauchsfertige Dokumentationsvorlagen. Der dritte Aspekt, den wir vorgeschlagen haben, war eine Änderung der Herangehensweise an den Rollout. Diese basierte darauf, bestimmte Märkte als Cluster zu behandeln, wenn sie eine gewisse Ähnlichkeit aufweisen, und zwar gesetzgeberisch, geographisch oder kulturell – und diese Cluster dann gleichzeitig zu aktivieren. Dieser Ansatz hat dazu geführt, dass die einzelnen Märkte keine Herausforderung darstellten und keine zusätzlichen Kosten mehr verursachten. – ergänzt Efinowicz.
Beschleuniger zur Unterstützung der Projektpriorisierung
In einer Situation, in der wir gezwungen sind, eine bereits implementierte Lösung zu überarbeiten, verlassen wir uns auf von uns entwickelte Beschleuniger, die uns bei dieser Art von Vorhaben helfen. Sie systematisieren und gewährleisten die Qualität durch einen Implementierungsstandard. Mit ihrer Hilfe vermeiden wir und unsere Kunden viele Probleme bei Implementierungen. – sagt Remigiusz Efinowicz. Die Beschleuniger wurden entwickelt, weil die an der Implementierung beteiligten Personen, also Berater, Programmierer oder Projektmanager, weil jeder von ihnen seine ganz eigene individuelle Herangehensweise hat. Durch das ganzheitliche Bild einer Lösung wirkt sich Individualismus negativ auf das Projekt aus. Beschleuniger erzwingen eine bestimmte Art der Implementierung und alle Teilnehmer, die sie nutzen, führen eine konsistente Implementierung in allen ihren Komponenten durch. Letzten Endes reduziert es auch die Wartungskosten, da alle seine Komponenten auf Grundlage der gleichen Grundannahmen und Standards implementiert werden.
Unterstützung zur Verfügung stellen
Der Prozess der Wartung einer implementierten Lösung hat nicht nur einen erheblichen Einfluss auf den laufenden Betrieb des Unternehmens, sondern auch auf dessen Zukunft. Eine bestmöglich implementierte Lösung, die nicht ausreichend weiterentwickelt wird, kann im Laufe der Zeit an Flexibilität verlieren. Dies ist auch häufig der Fall, wenn die Expansion der Geschäftstätigkeit in neue Märkte beschlossen wird und sich dann herausstellt, dass dies aufgrund des verwendeten Systems nicht möglich ist.
