#2/ 2020
9/13

Hängt der Fisch erst an der Angel …

Wie ein eine ERP-Einführung im Desaster enden kann

Im Im dpr-Magazin 01/2020 beschreibt Bernd Zipper, wie man ein ERP Wechselprojekt vorbereitet beschreibt Bernd Zipper, wie man ein ERP Wechselprojekt vorbereitet. Um es vorweg zu sagen: Es ist ein guter Beitrag. Hier wird beschrieben, wie man das bestehende „Rückgrat“ des Unternehmens analysiert, einen geeigneten Softwareanbieter wählt und einen Fahrplan zum Softwarewechsel vorbereitet.

In diesem Beitrag soll es darum gehen, was nach der Unterschrift mit dem ERP-Softwareanbieter passieren kann. Wie ein gut vorbereitetes Change Projekt gegen die Wand donnert. Denn hängt der Fisch erst einmal an der Angel, beginnt ein ungleicher Kampf.

Der Fisch in dieser Geschichte ist ein mittelständischer juristischer Fachverlag (40 Mitarbeiter, 100 Neuerscheinungen pro Jahr, 11 Zeitschriften, Online Plattform und ein wenig Loseblatt). Im Jahr 2017 entschied man sich, das in die Jahre gekommene ERP zu tauschen. Es war umständlich zu bedienen, war als Basis des Webshops rückständig, hatte Probleme mit den Schnittstellen zu Buchhaltung und Honorarabrechnung. Die ersten Workshops wurden hausintern durchgeführt: Die Prozesse in den einzelnen Abteilungen (Lektorat, Herstellung, Marketing, Auslieferung, Webshop, Lagerhaltung, Abonnementsverwaltung, Honorarabrechnung und weitere) wurden verschriftlicht, die Schnittstellen betrachtet, der Datenfluss analysiert.

Die Auswahl eines geeigneten Anbieters ist schwierig

Mit dieser Aufstellung der Leistungen, die man von einem neuen ERP erwartet, ging man auf Anbietersuche. Für einen kleinen bis mittleren Verlag gibt es gar nicht so viele Anbieter: Die großen mächtigen scheiden aus, weil hier die Mächtigkeit der Datenbanken und Systeme die Kosten in unvertretbare Höhe schnellen lässt. Die kleinen Softwareschmieden scheiden aus, weil die Komplexität der Produkte im Fachverlag (Print und Online, Einzelverkauf und Abo, Honorarabrechnung nach Umsatz oder Einmalzahlung, mehrere Lagerplätze) hoch ist. Bleibt das Mittelfeld: meist mittelgroße, in starkem Konkurrenzkampf stehende Häuser, die auf etablierte und skalierbare Datenbanken aufsetzen. 

Die Auswahl des geeigneten Anbieters ist schwierig. Es gibt zwei Wege: Man geht mit den skizzierten Erwartungen an die Leistungen der Software und seiner Workflow Analyse zu den Anbietern und/oder spricht mit befreundeten Verlagen über deren Erfahrungen.

Beim ersten Weg wird man bei den Gesprächen gelobt für die Vorbereitungen, und nach kurzem Durchsehen der Workflow-Analyse wird man zu hören bekommen, dass das alles kein Problem sei, dass man das für andere Verlage schon am Laufen habe und dass man bald ein Angebot zur ersten Kosteneinschätzung bemühen werde. Wie gesagt, es herrscht Konkurrenzdruck in der Branche und ein Auftrag, auch der eines kleineren Verlags, verspricht Umsatz in 6-stelliger Höhe, verteilt auf mehrere Jahre. Die Software-Anbieter haben ihre Standardlösungen programmiert und jeder neue Kunde verspricht mehr Verdienst bei geringen Mehrkosten. Man wird als Verlag umgarnt.

Der andere Weg, der über die Empfehlungen anderer Verlagshäuser, hat auch seine Haken: Meist klingen die Prozessbeschreibungen auf den ersten Blick ähnlich (Abo? Ein Abo-Modell haben wir auch), aber hier steckt oft der Teufel im Detail. Und die Gespräche finden immer auf höchster Ebene statt. Und der Verlag, der seine Erfahrungen mit ERP-Wechsel schon gemacht hat, hat diese vor Jahren gemacht. Der ERP-Anbieter von vor fünf Jahren könnte aber in der Zwischenzeit seine Geschäftspolitik geändert haben.

Wechsel im Zwei-Stunden-Modus 

Der Verlag, von dem hier berichtet wird, hat beide Wege beschritten: Er hat sich von ERP-Anbietern beraten lassen und mit befreundeten Verlagen gesprochen. Er hat sich für einen mittelgroßen Anbieter entschieden, der auch Fachverlage im Portfolio hat. Und er hat sich für ein zweistufiges Verfahren entschieden: Erst Wechsel der Workflows in Lektorat und Herstellung (die anderen Abteilungen sollten auf dem alten ERP vorerst bleiben) und erst in Phase 2 der komplette Wechsel. Für den ERP Anbieter war dies kein Problem, denn wie alle (?) ERP Anbieter bietet auch er seine Software in sogenannten Modulen an. Lediglich zwei zusätzliche Schnittstellen zum Datenaustausch mit den alten Systemen würden benötigt. Es wurden Lastenhefte erstellt und der Fisch hing an der Angel.

Der hier beschriebene ERP Anbieter arbeitet mit sogenannten Use Cases: man zwingt den Verlag dazu, seine Workflows mit der neuen Software zu üben und zu verschriftlichen. Das ist kein schlechter Weg, denn die Verlagsmitarbeiter denken fast nie in Datenbankdimensionen und die erstellten Workflowbeschreibungen sind notgedrungen kursorisch. Der Softwareanbieter lernt seinen neuen Kunden kennen und die Verlagsmitarbeiter lernen die Software bedienen. 

Der hier beschriebene Verlag machte seine Hausaufgaben (Use Cases) so gut, dass er gebeten wurde als Referenzkunde auf Veranstaltungen des Softwareanbieters aufzutreten. Die Schnittstellen zu den alten Systemen des Verlags waren analysiert, die Workflows durch die Use Cases klar, versprochen wurde ein „Go live“ der Phase 1 zur Buchmesse Frankfurt 2018.

Datenmigration from hell

Die Probleme begannen mit der ersten Datenmigration aus dem alten ERP: Die Kundendaten im alten System sind in einer anderen Logik aufgebaut als dies in der neuen Datenbank gemacht wird. Die Verwaltung der Auflagen eines Buches ist im alten System anders organisiert. Das machte schon beim Weg altes System zu neuem System große Probleme – an den Re-Import ins alte System (dort sollte in Phase 1 ja noch die Vertriebs- und Umsatzdaten bleiben) wagte man gar nicht zu denken. Der ERP Anbieter behauptete zwar, dass er die Schnittstellen programmiert hätte, nur gab es nie eine Besprechung, gar eine Freigabe der Schnittstellen.

In der Presse war in diesem Zeitraum von den vielen erfolgreichen Akquisitionen des ERP Anbieters zu lesen. Das betreuende Personal beim ERP Anbieter wurde getauscht – er suchte händeringend neue Leute. Die Expansion belastete die Mitarbeiter so, dass viele krankheitsbedingte Ausfälle und Kündigungen unser ERP-Projekt ins Schlingern geraten ließen. Im Sommer 2019 schrieb der CEO des ERP-Anbieters, dass man jetzt die Personalsituation wieder im Griff habe und schnell (zur Buchmesse Frankfurt 2019?) das Projekt (Phase 1) abschließen möchte. Zu diesem Zeitpunkt war man bereits bei etwa 180 Prozent der veranschlagten Kosten, hatte unzählige Stunden mit Use Cases, Test Cases und Datenqualität verbrannt.

Die Forderungen des ERP Anbieters wurden forscher: Man stellt Rechnungen über „Bestandsaufnahme in den Akten“, weil man selbst nicht mehr wusste, was man zwei Jahre zuvor versprochen hatte, und Rechnungen über „Onboarding eines neuen Mitarbeiters“, weil man den dritten Projektleiter einsetzen musste.

Heute, rund drei Jahre nach Start des Projekts ERP müssen wir eine ernüchternde Bilanz ziehen: Wir haben alle Punkte, die Bernd Zipper im dpr 1/2020 zur Auswahl eines ERP Anbieters rät, befolgt. Darüber hinaus haben wir die Schnittstellen zu den anderen Systemen beschrieben, haben einzelne Projektschritte definiert und vertraglich vereinbart, und unsere Daten mit hohem Aufwand bearbeitet und exportiert. Wir haben einen hohen Betrag in Software, Server und Schulung der Mitarbeiter und sehr viel Zeit und Nerven investiert. Wir arbeiten heute noch mit dem alten System.

Unsere Erkenntnisse

  • Auch bei bester Vorbereitung: Software-Projekte können scheitern.
  • Software-Anbieter verdienen auch bei nicht erfolgreichen Projekten gut. Verlage verlieren bei gescheiterten Projekten.
  • Es gibt ein großes Informations- und Wissensgefälle zwischen Anbieter und Käufer, was die Leistungsfähigkeit der Software, aber insbesondere die Fähigkeiten der Programmierer der Schnittstellen betrifft.
  • Ist der Softwareanbieter vor allem mit seinem Wachstum und dem Bezug neuer Firmengebäude beschäftigt, leidet der Projektfortschritt. 
  • Man sollte auf gute Projektleiter auf Seiten des ERP Anbieters bestehen. (Sie sind selten)
  • Man sollte als Verlag seine Prozesse der Software anpassen und nicht erwarten, dass die Software sich anpasst.
  • Man muss alle Vorgänge sauber dokumentieren, denn man wird schnell vom Vorzeigekunden zum Schuldigen an Verzögerungen.
  • Möchte man Altdaten ins neue System mitnehmen, ist eine Datenanalyse (Felder und Abhängigkeiten) im Vorfeld unerlässlich: Eine Adresse ist nie nur eine Adresse.
  • Die Frustration des verschleppten Projekts trifft das ganze Team: Use cases Schreiben und Datenprüfungen belasten alle und müssen neben der normalen Arbeit erledigt werden. 
  • Es besteht ein Machtgefälle zwischen ERP-Anbieter und Verlag: Ist die Operation erst einmal gestartet, steht die Projektleitung im Verlag unter Erfolgszwang. Der ERP Anbieter hat den Fisch an der Angel, und je länger dieser zappelt, desto länger wird er für Schulung, Anpassungen und Beratung zahlen.

 

Stephan Kilian ist seit 2017 Programmleiter Juristische Medien beim Stämpfli Verlag in Bern. Davor war er 10 Jahre Produktmanager und Projektleiter E-Business beim C.H. Beck Verlag und Vahlen Verlag in München.