Menü

In sechs Phasen zur Einführung von SAP AIN

Für die Einführung von SAP AIN spricht eine ganze Menge. Stellt sich die Frage, wie die Implementierung am besten gelingt. Wir haben sechs Phasen definiert.

Bei der Instandhaltung ist schon immer Teamarbeit gefragt: Zwischen Betreiber, Hersteller und Instandhalter müssen Informationen ausgetauscht werden, damit Assets sinnvoll gewartet und bei Störungen schnell wieder zum Laufen gebracht werden. Das ist bislang allerdings nicht ganz leicht. Denn alle Parteien organisieren ihre Daten in isolierten Systemen, ein elektronischer Datenaustausch über Schnittstellen ist selten.

SAP hat mit dem SAP Asset Intelligence Network (AIN) das Problem aufgegriffen und eine Lösung dafür gefunden. Denn mit der cloudbasierten Plattform lässt sich ein Wertschöpfungsnetzwerk etablieren: Betreiber, Hersteller und Instandhalter legen sämtliche relevanten Informationen im SAP AIN ab, sodass alle Beteiligten darauf zugreifen können. Der Datenaustausch ist so mühelos möglich. Ausserdem lassen sich mithilfe von SAP AIN ganz neue Geschäftsmodelle und Szenarien realisieren – zum Beispiel Equipment-as-a-Service-Angebote oder Predictive-Maintenance-Ansätze.

SAP AIN: Implementierung in sechs Phasen

Für die Einführung von SAP AIN spricht also eine ganze Menge. Stellt sich die Frage, wie die Implementierung am besten gelingt. Wir haben sechs Phasen definiert:

1. Prozessanalyse und -definition

Ganz zu Beginn sollte jeder Betreiber, Hersteller und Instandhalter seine Instandhaltungs- beziehungsweise Asset-Management-Prozesse genau in den Blick nehmen: Welche Abläufe gibt es überhaupt? Wo läuft es reibungslos und wo hakt es immer mal wieder? Inwieweit sollten bestehende Prozesse modifiziert werden und können einzelne Prozesse ganz wegfallen? Lassen sich auf Basis von SAP AIN neue Abläufe etablieren? Können sogar innovative Geschäftsmodelle aufgebaut werden? Für Hersteller könnten das zum Beispiel Equipment-as-a-Service-Angebote sein. Berücksichtigt werden sollte dabei auch, welche gesetzlichen Vorgaben und Branchenstandards eingehalten werden müssen.

Ausgehend von diesen Überlegungen werden die künftigen Soll-Prozesse definiert und gestaltet. Dabei wird dann auch deutlich, inwieweit sich diese mit den bereits etablierten SAP-Lösungen abbilden lassen und wo zusätzliche Funktionen aus SAP AIN notwendig sind. Das ermöglicht es, eine ganzheitliche IT-Architektur zu planen und daraus die nächsten operativen Schritte abzuleiten – samt der Kosten, Verantwortlichkeiten und Termine. Wichtig dabei: Häufig nehmen sich Unternehmen sehr viel vor, was die Projekte dann sehr komplex macht. Besser ist es nach unserer Erfahrung, überschaubare Teilprojekte zu priorisieren und nacheinander anzugehen. Damit behalten Unternehmen auch eine hohe Agilität und können sich schnell auf neue Situationen einstellen.

2. Definition der Asset-Strukturen und der Prozesse

Mit SAP AIN lassen sich digitale Zwillinge von physischen Assets erstellen und verwalten. Das ist der wesentliche Clou der Lösung. SAP AIN bietet dafür aber lediglich den technologischen Rahmen. In welcher Weise Assets strukturiert sein sollen und welche Informationen in welcher Granularität zu welchen Assets gewünscht sind, müssen die Unternehmen vor einer Implementierung festlegen. Dabei spielen zum einen die definierten Soll-Prozesse eine Rolle, zum anderen die gesetzlichen Vorgaben und Branchenstandards. Ist klar, wie die Assets digital abgebildet werden sollen, lässt sich auch sagen, welche Daten an den physischen Assets erfasst und weitergeleitet werden müssen. Damit ist sichergestellt, dass alle erforderlichen Informationen vorliegen, gleichzeitig aber keine unnötigen Daten generiert werden.

3. Systemintegration und Konfiguration

Sind die Soll-Prozesse, die Asset-Struktur und die Stammdaten definiert, werden in SAP AIN die spezifischen Unternehmensprofile erstellt und die individuellen Anwendungseinstellungen vorgenommen. Massgeblich ist dabei, die Balance zwischen einem hohen Funktionsumfang und einer hervorragenden Usability zu finden. Die Einschätzung der Anwender frühzeitig einzuholen und dann auch zu berücksichtigen, ist hier ein entscheidender Faktor für den Erfolg. Bei der Konfiguration kommt es ausserdem darauf an, die Skalierbarkeit von SAP AIN sicherzustellen. Konkret heisst das: Selbst wenn bestimmte Bestandteile der Lösung im aktuellen Teilprojekt nicht benötigt werden, sollten sie später ohne grossen Aufwand ergänzt werden können. Der strategische Blick auf das gesamte Vorhaben ist also auch dann nötig, wenn operativ einzelne überschaubare Projekte nach und nach realisiert werden.

4. Pilotphase

Weil sich gerade bei innovativen Lösungen häufig erst beim Einsatz in der Praxis zeigt, wo noch Herausforderungen bestehen – zum Beispiel hinsichtlich der Prozesse, der Funktionen oder der Systemverfügbarkeit – bietet sich nach unserer Erfahrung eine Pilotphase an. Deutlich wird dabei auch, wo zusätzliche Chancen liegen. Wenn wertvolle Erfahrungen erst einmal in einem kleinen Rahmen gesammelt werden, lässt sich leichter nachjustieren. Die Lessons Learned können dann in einer Pilot-Summary explizit festgehalten und für die nächsten Projektphasen oder andere Projekte genutzt werden. Das gilt ganz besonders mit Blick auf die Akzeptanz der Anwender. Wenn erst einmal wenige Mitarbeiter ihr Feedback zum Umgang mit SAP AIN abgeben, fliessen die Einschätzungen systematisch in die Gestaltung von Abläufen und vor allem User-Interfaces ein.

Die Ergebnisse bewusst zu fixieren, klingt zwar banal und naheliegend. Wir erleben aber immer wieder, dass zwar in einer Pilotphase getestet wird, die Ergebnisse dann aber mehr oder weniger schnell aus dem Bewusstsein verschwinden. Durch eine exakte Dokumentation, die auch konkrete Empfehlungen für Anpassungen enthält, wird das verhindert. Diese Art des Umgangs mit Erfahrungen sollte im besten Fall über die Pilotphase hinaus praktiziert werden. Denn so hat das Unternehmen die Chance, aus Fehlern zu lernen und sich so kontinuierlich weiterzuentwickeln.

5. Realisierung des Projekts

Wenn die Pilotphase durchlaufen ist, startet die Implementierung mit Detail- und Realisierungsphase auf  Basis der Pilot-Summary. Allerdings hat das Pilotprojekt nur einen kleinen Teil der Möglichkeiten von SAP AIN abgedeckt – daher müssen in einem Detailkonzept weitere Handlungsfelder definiert und ausgearbeitet werden. Danach erst kann das System endgültig konfiguriert und können alle Erweiterung, also Zusatzentwicklungen, programmiert werden.

Ist all das erledigt, folgt der Go-live von SAP AIN. Und der sollte gut vorbereitet sein. Das gilt natürlich für die Technologie an sich. Mindestens ebenso wichtig ist aber, dass die Anwender auf den Einsatz der neuen Lösung vorbereitet sind. Sie müssen daher in den Wochen vor dem Start mit SAP AIN vertraut gemacht werden. Dazu dienen in der Regel Schulungen, die von externen Beratern oder von internen Key-Usern gegeben werden. Wichtig sind auch die richtigen Materialien: etwa eine schriftliche Dokumentation und Video-Tutorials.

6. Betriebsübergabe und Support

Nach erfolgreichem Go-live muss die neue Lösung kontinuierlich betreut werden, Support und Application Management sind unerlässlich. Dafür gibt es zwei Möglichkeiten: Entweder wird die Aufgabe an einen externen Dienstleiter ausgelagert. Dann geht es für das Anwenderunternehmen vor allem darum, diesen zu steuern. Oder das Application Management soll intern erledigt werden. In diesem Fall sind entsprechende Ressourcen in der IT-Abteilung aufzubauen. Bedacht werden sollte bei der Entscheidung ein wichtiger Aspekt: Es geht nicht nur darum, den Betrieb der etablierten Lösung sicherzustellen, technische Fehler schnell zu beheben und den Anwendern bei Fragen zu helfen. Es geht auch darum, die Lösung ständig weiterzuentwickeln, an sich wandelnde Rahmenbedingungen anzupassen und neue Releases einzuspielen.