Warum der Support nach dem Go-live scheitert und woran Sie es bei sich erkennen

Das Projekt endet pünktlich. Der Lenkungsausschuss bekommt seine letzte grüne Folie, und dem Implementierungspartner wird in einer Rundmail an die ganze Belegschaft gedankt. Sechs Wochen später führt die Finanzabteilung für den Monatsabschluss eine Schattentabelle, zwei Leute im Lager rufen wieder im Büro an, und im Kundenportal, für dessen Konfiguration Sie bezahlt haben, hat sich noch niemand angemeldet. Nichts ist kaputt. Das System ist online, die Schnittstellen laufen, der Verfügbarkeitsbericht ist sauber. Die Organisation arbeitet schlicht schlechter als im letzten Monat des Projekts.

Wenn das passiert, schaut man instinktiv auf die Software. Fast nie liegt es an der Software. Die größte Gefahr für einen ERP- oder CRM-Go-live ist organisatorisch: wem der Prozess gehört, sobald sich das Projektteam auflöst, wo das Wissen liegt und was mit einem Problem geschieht, wenn es zum dritten Mal auftaucht. Systeme scheitern laut und werden repariert. Organisationen scheitern leise und werden umgangen. Ein Workaround löst, anders als ein Ausfall, nie einen Alarm aus. Im Folgenden die sechs Muster, die wir in belgischen und niederländischen Mittelstandsunternehmen am häufigsten sehen, und eine kurze Liste von Warnzeichen, die Sie mit Ihrem eigenen Unternehmen abgleichen können.

Support nach dem Go-live wird als Phase verkauft, nicht als Fähigkeit aufgebaut

Implementierungsverträge enthalten fast immer Hypercare: eine Phase erhöhter Aufmerksamkeit nach dem Go-live, meist in Wochen statt in Monaten bemessen. Sie ist nützlich, und sie ist kein Support. Sie ist das Ende eines Projekts, besetzt mit Projektleuten, bezahlt aus dem Projektbudget. Was danach kommt, wird meist als Tagesgeschäft beschrieben: ein Wort, das in der Praxis bedeutet, dass niemand etwas entschieden hat. Der Bedarf hört mit dem Ende der Hypercare nicht auf, er verändert seine Form. In den ersten Wochen dominieren Menschen, die einen Button nicht finden. Die Monate zwei bis sechs bringen die Fragen, die wirklich Geld kosten: der Abschluss, der nicht mehr aufgeht, die Preisregel, die sich bei einer Kundengruppe anders verhält, der Intercompany-Ablauf, den niemand getestet hat, weil die Übernahme spät abgeschlossen wurde. Dafür braucht es jemanden, der das Geschäft versteht, und diese Fragen kommen genau dann, wenn die Menschen, die es verstanden haben, aus dem Projekt abgezogen wurden.

Das Kontextwissen geht mit dem Implementierungspartner

Während einer Implementierung sammelt eine kleine Gruppe enorm viel undokumentiertes Wissen an. Warum die Kreditlimitprüfung vor der Auftragsbestätigung erfolgt und nicht danach. Von welchen Feldern im Kundenstamm die Logistikschnittstelle tatsächlich abhängt, im Unterschied zu denen, von denen sie laut Spezifikation abhängt. Warum die niederländische Gesellschaft eine Ausnahme in ihrer Steuerfindung hat. Fast nichts davon wird aufgeschrieben, weil während des Projekts alle, die es brauchen, im selben Raum sitzen. Bei der Übergabe bestehen die Lieferergebnisse aus Dokumenten: Konfigurationsmappen, Testskripte, Schulungsfolien, eine Berechtigungsmatrix. Sie beschreiben, was das System tut. Das teure Wissen ist, warum es das so tut, und das Warum steht nicht auf der Liste der Lieferergebnisse. Wenn der Partner abzieht, verlässt dieses Wissen das Haus, und anders als bei einem fehlenden Dokument bemerken Sie sein Fehlen erst an dem Tag, an dem Sie es brauchen.

Ein Service Desk, der ein Passwort zurücksetzen, aber keinen Workflow lesen kann

Support wird oft als Service Desk eingekauft: abgerechnet pro Anwender oder pro Ticket, besetzt mit Menschen, die auf das allgemeine Verhalten der Software geschult sind und nicht auf Ihre Konfiguration. Innerhalb seines Rahmens ist dieses Team kompetent. Zugangsprobleme, Lizenzen, Drucken, ein Bericht, der nichts liefert, ein Anwender, der eine zusätzliche Rolle braucht. Alles erledigt, und zwar schnell. Dann kommt ein Ticket: Seit Dienstag ziehen Aufträge für eine Kundengruppe die falschen Lieferbedingungen. Das ist keine Softwarefrage. Es ist eine Frage danach, wie eine Preiskondition, eine Änderung im Kundenstamm und eine Versandregel in Ihrem Order-to-Cash-Prozess zusammenwirken, und um sie richtig zu beantworten, braucht es jemanden, der weiß, wie dieser Prozess laufen soll. Ein generischer Service Desk leitet sie weiter, eskaliert sie und schließt sie am Ende mit einer manuellen Korrektur. Die manuelle Korrektur wird dann zum Prozess, und niemand hält das als Fehler fest, weil das Ticket innerhalb des Service Levels geschlossen wurde.

Jemandem gehört das System. Niemandem gehört der Prozess.

Fast jede Organisation benennt nach dem Go-live einen Systemverantwortlichen, meist in der IT. Sein Auftrag umfasst Verfügbarkeit, Upgrades, Berechtigungen, Schnittstellen und Kosten. Alles notwendig, und nichts davon deckt ab, ob Order-to-Cash oder Procure-to-Pay tatsächlich durchgängig funktioniert. Geschäftsprozesse gehen über Abteilungsgrenzen hinweg, Systemverantwortung nicht. Wenn der Fehler zwischen Vertrieb und Logistik liegt (und dort liegt er meistens), gibt es niemanden, dessen Aufgabe es wäre zu schlichten, also baut jede Abteilung eine lokale Lösung, und die Lücke zwischen ihnen wird größer. In einem Benelux-Unternehmen mit 200 Mitarbeitenden ist das schärfer als in einem Konzern mit 5.000, weil es kein Prozessbüro gibt, auf das man zurückgreifen kann, und keine freie Kapazität, um eines zu erfinden. Die Verantwortung fällt dem Key-User zu, der sich am hartnäckigsten beschwert, zusätzlich zu der Arbeit, die er ohnehin schon macht. Das ist kein Governance-Modell, und es übersteht nicht, dass diese Person eine neue Rolle übernimmt.

Ticket-Queues messen Schließzeiten, nicht Wiederholungen

Supportverträge werden an Reaktionszeit und Lösungszeit gemessen. Beides ist leicht zu zählen, beides ist leicht zu berichten, und keines von beiden sagt Ihnen, ob derselbe Fehler nächsten Monat wiederkommt. Eine Queue, die auf schnelles Schließen optimiert ist, wird zuverlässig den Workaround der eigentlichen Behebung vorziehen, denn der Workaround dauert zwanzig Minuten und schließt das Ticket, während die Behebung eine Prozessdiskussion, einen Testzyklus und ein Änderungsfenster braucht. Die Zahl, die Ihnen etwas sagen würde, ist der Anteil der Tickets dieses Monats, die Wiederholungen von etwas bereits Bekanntem sind. Wenige Organisationen messen ihn, weil man dafür Tickets nach dem Geschäftsprozess kategorisieren muss, den sie betreffen, statt nach dem Modul, unter dem sie erfasst wurden. Wer damit anfängt, ist von der Antwort meist unangenehm berührt: eine kleine Zahl zugrunde liegender Prozessfehler, die leise und über Jahre einen unverhältnismäßig großen Teil des Volumens erzeugen.

Jeder wiederkehrende Vorfall ist ein Prozessfehler mit Ticketnummer.

Nichts führt einen wiederkehrenden Vorfall zu einer dauerhaften Lösung

Das ist der Fehler, der die anderen fünf enthält. Selbst wo das Wissen überlebt und jemand den Prozess verantwortet, haben die meisten Organisationen keinen Mechanismus, der aus „das passiert ständig“ eine Änderung macht, die auch umgesetzt wird. Vorfälle leben in einem Service-Desk-Tool. Änderungen leben in einer Projektpipeline, die sich nur öffnet, wenn eine Budgetrunde ansteht. Dazwischen liegt eine Lücke, und wiederkehrende Probleme fallen dauerhaft hinein. Der Ausweg muss nicht ausgefeilt sein. Er muss kurz und unspektakulär sein. Eine monatliche Durchsicht wiederkehrender Vorfälle, gruppiert nach Prozess. Eine benannte Person mit der Befugnis, etwas zum Prozessfehler statt zum Anwenderfehler zu erklären. Und ein festes Budget für Korrekturen, die zu klein für ein Projekt sind, denn ohne eigene Budgetzeile muss jede Verbesserung begründet werden, als wäre sie eine neue Initiative, und keine nimmt je diese Hürde.

Warnzeichen, die Sie diese Woche prüfen sollten

Keines davon beweist für sich allein, dass Ihr Support versagt. Drei oder vier zusammen tun es meistens.

• Ihre Key-User beantworten mehr Fragen als Ihr Service Desk, und das steht nirgends in ihrer Stellenbeschreibung.
• Für einen Schritt, den das System übernehmen sollte, sind wieder Tabellen aufgetaucht.
• Sie können die Person nennen, die für das ERP oder das CRM verantwortlich ist, aber nicht die, die für Order-to-Cash verantwortlich ist.
• Sie können berichten, welche Module die meisten Tickets erzeugen, aber nicht, welche Geschäftsprozesse.
• Die ehrliche Antwort auf „Warum ist das so konfiguriert?“ lautet: weil der Berater es so eingerichtet hat.
• Das Schulungsmaterial beschreibt den Prozess noch so, wie er entworfen wurde, nicht so, wie er heute tatsächlich läuft.
• Änderungen gibt es nur, wenn ein neues Projekt finanziert wird. Zwischen den Projekten verbessert sich nichts.
• Die letzten drei dringenden Korrekturen waren vorübergehende Workarounds, und alle drei sind noch in Betrieb.

Was funktionierender Support nach dem Go-live wirklich braucht

Es sind nicht mehr Stunden, und selten ist es ein größerer Service Desk. Es sind ein paar strukturelle Dinge. Ein benannter Prozessverantwortlicher auf der Fachseite für jeden End-to-End-Ablauf, mit der Befugnis, zwischen Abteilungen zu entscheiden. Support, besetzt mit Menschen, die Ihren Prozess kennen und nicht nur das Handbuch des Herstellers. Ein Entscheidungsprotokoll, aus der Implementierung übernommen und bei jeder Konfigurationsänderung fortgeschrieben. Wiederholungen, gemessen neben der Lösungszeit. Und ein fester Weg vom wiederholten Vorfall zur dauerhaften Lösung, mit einem bescheidenen Budget, damit kleine Verbesserungen nicht mit Investitionsprojekten konkurrieren müssen.

Diese Fähigkeit lässt sich intern aufbauen oder einkaufen, und bei den meisten Mittelstandsunternehmen im Benelux-Raum wird daraus eine Mischung aus beidem: interne Verantwortung für den Prozess, externe Hände für Konfiguration, Entwicklung und die unbequeme Schnittstellenarbeit. Was nicht funktioniert, ist, sie nachträglich einzukaufen, zu einem Preis, der sich am Ticketvolumen bemisst, beim günstigsten Anbieter, sobald das Projektbudget aufgebraucht ist. Der beste Zeitpunkt, den Support nach dem Go-live zu gestalten, liegt vor dem Go-live, solange Sie gegenüber Ihrem Partner noch einen Hebel haben und das Wissen noch im Raum ist. Der zweitbeste Zeitpunkt ist jetzt. Lesen Sie zum Einstieg die Warnzeichen noch einmal und seien Sie ehrlich, wie viele davon Sie wiedererkennen.