In der Regel entscheiden sich Unternehmen dafür, mit einem Systemintegrator (SI) zusammenzuarbeiten, der sie bei ihrem Transformationsprogramm unterstützt. Und das zu Recht. Der SI verfügt über Erfahrung in der Durchführung solcher Transformationen, mit der Technologie (unabhängig davon, um welche es sich handelt) und deren anschließender Konfiguration/Einrichtung. Er weiß auch, wie man diese sowohl kurz- als auch langfristig unterstützt. Ein einzelner SI oder eine Kombination aus mehreren SIs ist wahrscheinlich der sicherste Weg, um groß angelegte technologische Veränderungen und die damit unvermeidlich einhergehenden Änderungen der Geschäftsprozesse umzusetzen und zu unterstützen.
Bevor Sie sich jedoch auf einen langfristigen Supportvertrag festlegen, sollten Sie Ihre Herangehensweise überdenken. Der Bedarf ist nicht gleichbedeutend mit der tatsächlichen Umsetzung, und es gibt einige Herausforderungen sowie eine Reihe wichtiger Punkte, die geprüft und berücksichtigt werden müssen. Stellen Sie sicher, dass Sie diese Punkte berücksichtigen – UND SIE ANSPRECHEN –, bevor Sie sich auf ein Supportangebot festlegen.
SI-Redundanz
Stellen wir uns einmal ein Szenario vor, in dem Ihr Systemintegrator Ihre Lösung aus technischer Sicht unterstützt. Möglicherweise verfügt er über ein technisches Team, das die technische Ebene der Lösung überwacht und steuert, während eine Handvoll seiner Fachberater beimThird-Level-Support helfen. Im Tagesgeschäft ist möglicherweise ein Team des Systemintegrators mit 10 bis 20 Beratern an Ihrer Lösung beteiligt. Das verursacht erhebliche jährliche Kosten.
Nun, in einer perfekten Welt müsste man alle Aspekte der Lösung ständig weiterentwickeln – einschließlich des Supportmodells. Neue Versionen enthalten neue Funktionen, die es zu erkunden gilt – auf allen Ebenen der Lösung. Und genau hier liegt das Problem. Je mehr Funktionen veröffentlicht werden, desto mehr muss sich das Support-Modell mit dem Produkt weiterentwickeln, was letztendlich dazu führt, dass weniger Support-Mitarbeiter benötigt werden. Dies senkt letztlich die Support-Kosten für den Kunden (hurra!) und verringert die wiederkehrenden Einnahmen für den SI (buh!). Wird ein SI darauf drängen? Vielleicht/Wahrscheinlich nicht… Die Innovation führt zu einem Interessenkonflikt für den SI.
Letztendlich muss der SI einen ausreichenden Reifegrad erreichen, um sich durch den Einsatz von Technologie überflüssig zu machen. Er muss aktiv nach Wegen suchen, sich selbst überflüssig zu machen. Der SI muss dies als zum Wohle des Kunden betrachten, indem er offensichtliche Selbstaufopferung zeigt und so den Wert der Beziehung steigert – was das Engagement in der Zukunft vertieft und verstärkt.
Integration in den laufenden Betrieb
Ein weiterer wichtiger Aspekt ist der Grad der Integration in den normalen Geschäftsbetrieb. Wenn man sich eine beliebige Organisation ansieht, insbesondere eine, die groß genug ist, um eine ERP-Plattform zu benötigen, wird dort wahrscheinlich bereits ein Service Desk betrieben und es kommen verschiedene ITIL- oder SRE-bezogene Konzepte zum Einsatz.
Logischerweise verlagert sich im Rahmen des Übergangs zur Hypercare-Phase und anschließend zum BAU-Betrieb die Zuständigkeit und Kontrolle über die Systeme vom Programmteam weg, und dieses rückt im Support-Modell weiter nach unten – inden 3rd-Line-Support. An seine Stelle treten der bestehende BAU-Prozess und das entsprechende Team.
Das kann für das Programmteam eine Herausforderung darstellen. Während des Programms verfügten der SI und das Implementierungsteam über eine Reihe von Systemen und Prozessen, die sie vollständig kontrollierten. Wenn sie diese unterbrechen wollten (zum Beispiel für eine dringende Änderung/Korrektur), konnten sie dies – unter Einhaltung gewisser Governance-Regeln – tun. Die Systeme und Prozesse waren genau auf ihre Anforderungen zugeschnitten – sei es Systemüberwachung, Prozessabbildung, Ticketingsysteme, Arbeitsaufträge usw. Sie alle wurden vom Programmteam entwickelt, um den Anforderungen des Programms gerecht zu werden.
Die Herausforderung besteht darin, dass mit dem Übergang des Programms in den Normalbetrieb die Tendenz besteht, all diese Systeme und Prozesse beizubehalten und dies als „Normalbetrieb“ zu bezeichnen. Dies ist der einfache Weg, den die meisten Systemintegratoren einschlagen werden. Die Alternative ist schwierig – alle Prozesse müssen geändert, Kontrollmechanismen aufgegeben werden, und das alles an einem kritischen Punkt des Programms, an dem eigentlich niemand Zeit dafür hat. Man könnte argumentieren, dass es in Ordnung ist, eine ERP-Support-Insel zu schaffen, aber aus mehreren Gründen ist es sehr kurzsichtig, beim Programmstatus quo zu bleiben…
A. Die neue Technologie ist Teil einer Wertschöpfungskette
Ihre Technologielösung wird Teil einer Wertschöpfungskette sein, die sich durch Ihr gesamtes Unternehmen zieht. Sie wird wahrscheinlich von verschiedenen vorgelagerten Systemen gespeist und versorgt ihrerseits verschiedene andere nachgelagerte Systeme. Diese Systeme werden (hoffentlich!) alle im Rahmen der bestehenden BAU-/ITIL-Prozesse betrieben. Es macht absolut keinen Sinn, wenn sich die Hälfte eines Prozesses in einem System und die andere Hälfte in einem anderen befindet. Wenn ein Prozess unterbrochen ist, muss er verwaltet werden, und das Problemmanagement wird durch mehrere Systeme und Prozesse nur behindert.
Um die Sache noch komplexer zu machen: Da wir uns in einer vernetzten Welt aus Märkten und Wertschöpfungszentren bewegen, ist es wahrscheinlich, dass sich die Wertschöpfungs- bzw. Lieferkette auch außerhalb des Unternehmens verlagert. Die Vernetzung von Organisationen untereinander ist eine Herausforderung, und jegliche Unterstützungsstrukturen müssen schlank, rationalisiert und transparent sein, um Probleme schnell lösen oder Innovationen vorantreiben zu können.
B. Sie führen doppelte Prozesse (und möglicherweise auch doppelte Technologien) durch
Das sollte eigentlich ganz einfach sein. Zwei separate Prozessabläufe sind nicht nur schwieriger zu verwalten und zu steuern, sondern verursachen – vorausgesetzt, es gibt eine entsprechende technische Lösung – auch Betriebskosten (und möglicherweise sogar Personalkosten). Sie sollten die Betriebskosten daher wo immer möglich minimieren.
C. Die Benutzererfahrung ist verwirrend / miserabel
Zu guter Letzt sollten Sie an Ihre Nutzer denken. Ich gehe davon aus, dass Sie sich im Rahmen Ihres Studiums intensiv mit User Experience oder Design auseinandergesetzt haben. Machen Sie diese gute Arbeit nicht zunichte, indem Sie die Nutzer verwirren und sie auf verschiedene Prozesse und Systeme verweisen, um eine Aufgabe zu erledigen. Ob es sich nun um einen Fehler oder eine Änderung handelt – unabhängig vom System sollte der Nutzer überall im Unternehmen eine nahtlose Benutzererfahrung genießen.
Gesamtbetriebskosten
Die Gesamtbetriebskosten (TCO) stehen ganz oben auf der Agenda jedes CIOs, und mehr denn je stehen diese unter erheblichem Druck, bei geringeren Kosten mehr Leistung zu erbringen. Supportkosten werden von vielen als Kosten für Absicherung bzw. Risikominderung angesehen, und viele Führungskräfte tun sich schwer damit, den Wert zu erkennen, den sie für ein Unternehmen haben. Daher ist es von entscheidender Bedeutung, dass Sie bei der Zusammenarbeit mit einem Systemintegrator über eine klare Strategie zur Kostensenkung verfügen, wenn das Unternehmen reift und immer mehr automatisierte Funktionen sowie KI- und Machine-Learning-Funktionen zum Einsatz kommen.
Ein weiterer wichtiger Aspekt, den es zu berücksichtigen gilt, ist die Verteilung der Arbeit innerhalb der bestehenden IT-Infrastruktur. Unternehmen sind komplex, und die Systeme, die sie unterstützen, sind es noch mehr. Es ist wahrscheinlich, dass es Spezialisten gibt, die verschiedene Systeme betreuen und sich möglicherweise über System-Silos hinweg überschneiden. Die System-Silos müssen durchbrochen und gemeinsame Technologieaufgaben untersucht und zusammengeführt werden. Spezialisten sind naturgemäß teuer und schwer zu finden, einzustellen und zu halten, was die Gesamtbetriebskosten in die Höhe treibt. Es ist manchmal nicht notwendig, mehrere Systemspezialisten mit denselben technologischen Grundkenntnissen zu haben, die nur ein einziges System betreuen.
Grundsätzlich muss das Organigramm des Support-Teams überarbeitet und die Aufgaben sowie die Arbeit nach technologischen Kompetenzen statt nach Systemkenntnissen aufgeteilt werden.
Warum SAP-Automatisierung in einer digitalen Welt entscheidend ist
Laden Sie das ITOM-Whitepaper noch heute herunter >>
Wie geht es weiter?
Zusammenfassend lässt sich sagen, dass SI-Anbieter sowohl bei der Implementierung als auch beim Support eindeutig eine wichtige Rolle spielen. Das steht außer Frage. Bevor man jedoch einen Vertrag mit ihnen abschließt, sind intensive Gespräche erforderlich, um sicherzustellen, dass sie Ihre Interessen wirklich im Blick haben. Sie sollten eng mit Ihnen zusammenarbeiten, um sich vollständig in Ihre bestehende Betriebslandschaft zu integrieren, Ihre Gesamtbetriebskosten über einen bestimmten Zeitraum zu senken und den CIO dabei zu unterstützen, mehr Leistung für weniger Kosten zu erzielen.
Über den Autor:
Neil How ist der Gründer von Limelight Consulting. Mit einem Hintergrund, der stark von SAP-Transformationsprogrammen geprägt ist, verfügt Neil über mehr als 20 Jahre Erfahrung in der Arbeit als Endnutzer für Kunden, als Berater für Systemintegratoren und als freiberuflicher Auftragnehmer.