Wie bereitet man ein Unternehmen auf die Auswahl eines Workflow-/BPM-/RPA-/ERP-/CRM-Systems vor, ohne sich an einen Anbieter zu binden?

Halten Sie danach Anforderungen schriftlich fest, die vor Abhängigkeit schützen: Export von Daten und Vorgangshistorie in einem offenen Format, dokumentierte APIs, Prozesse im BPMN-Standard festgehalten, das Recht auf eigene Konfiguration und klare Regeln für den Vertragsausstieg. Benennen Sie die Risiken, die Sie heute bereits identifizieren können. Seien Sie nicht naiv und listen Sie alle Risiken auf. Vergleichen Sie Angebote anhand eigener Szenarien und auf Basis der Gesamtkosten über mehrere Jahre (Investition plus wiederkehrende Betriebskosten). Lizenzen, Verlängerungen, Schulungen, Teampflege, Änderungen, Migrationen. Überlegen Sie, wie wahrscheinlich es ist, dass der Anbieter seine Schlüsselberater verliert, beschließt, Administratoren und Entwickler durch KI zu ersetzen, oder die Unterstützung für das aktuelle Betriebssystem einstellt.

Dieser Beitrag richtet sich an Vorstände von Unternehmen und kommunalen Gesellschaften (spółka komunalna), die den Umlauf von Dokumenten, Kostenrechnungen, Verträgen oder Anträgen ordnen wollen und vor der Wahl eines Workflow-Systems stehen – also eines Werkzeugs, das einen Vorgang nach festgelegten Regeln von einer Person zur nächsten weiterleitet. Üblicherweise stehen drei Wege zur Auswahl: eine fertige BPM-Plattform, ein Low-Code-Werkzeug oder ein maßgeschneidertes System; die nachfolgenden Grundsätze gelten für alle drei. Nützlich ist der Beitrag auch für CFOs, da sie es meist sind, die die Folgen einer Fehlentscheidung bezahlen.

Warum Vendor Lock-in bereits am Anfang entsteht

Abhängigkeit entsteht selten durch eine einzelne falsche Entscheidung. Sie beginnt meist früher, als das Unternehmen bemerkt: Prozesse werden im Werkzeug des Anbieters beschrieben statt in eigenen Dokumenten; Daten und Vorgangshistorie liegen in einem Format, das sich nicht ohne Weiteres herauslösen lässt; die Konfiguration kennt nur der Implementierungspartner; und der Vertrag sagt viel über die Einführung, aber wenig darüber, was passiert, wenn das Unternehmen den Anbieter wechseln möchte. Nach einigen Jahren kostet ein Systemwechsel mehr als der laufende Betrieb – selbst wenn das System den Anforderungen längst nicht mehr gerecht wird.

Schritt 1. Beschreiben Sie Prozesse, bevor Sie mit Anbietern sprechen

Bevor eine Ausschreibung entsteht, lohnt es sich, die Abläufe zu beschreiben, die das System abdecken soll: Wer meldet einen Vorgang, wer genehmigt ihn und in welcher Reihenfolge, welche Ausnahmen und Schwellenwerte gibt es (zum Beispiel ein anderer Pfad ab einem bestimmten Betrag), welche Fristen gelten und welche Entscheidungsspur für eine Prüfung erhalten bleiben soll. Am besten hält man dies im BPMN-Standard fest, den verschiedene Werkzeuge verstehen. So gehört die Prozessbeschreibung dem Unternehmen und nicht dem System.

Ohne eine solche Beschreibung vergleicht man Präsentationen der Anbieter, nicht Lösungen. Jede Vorführung wirkt überzeugend, weil der Anbieter sein bestes Szenario zeigt – nicht Ihre schwierigste Ausnahme.

Schritt 2. Prüfen Sie, was Sie bereits haben

Ein Teil der Abläufe lässt sich häufig mit Werkzeugen abbilden, die das Unternehmen bereits besitzt: im CRM, in Fachverfahren, im Dokumentenmanagementsystem oder im Office-Paket. Manchmal lautet das Ergebnis der Analyse, dass gar kein neues System nötig ist, sondern lediglich eine Änderung der Verfahrensweise oder Konfiguration genügt. Eine solche Bestandsaufnahme zeigt zudem Integrationen auf, die das neue System wird abdecken müssen – etwa mit dem Finanz- und Buchhaltungssystem und KSeF (polnisches E-Rechnungssystem) – sowie Stellen, an denen heute Informationen verloren gehen. Mehr dazu: Inventarisierung von IT-Systemen.

Schritt 3. Anforderungen, die vor Vendor Lock-in schützen

Diese Anforderungen gehören als Bedingungen – nicht als Wünsche – in die Ausschreibung:

1. Export von Daten und Vorgangshistorie in einem offenen, dokumentierten Format, jederzeit und ohne zusätzliche Gebühr.
2. Dokumentierte API für die Integration mit anderen Systemen, mit dem Recht, sie auch durch andere Auftragnehmer nutzen zu lassen.
3. Im Standard festgehaltene Prozesse (BPMN), die sich exportieren und andernorts wieder aufbauen lassen.
4. Recht auf Konfiguration durch das eigene Team oder einen beliebigen Partner, mit Dokumentation der Änderungen.
5. Regeln für den Vertragsausstieg: Übergangsfrist, Unterstützung bei der Datenmigration und deren im Voraus bekannte Kosten.
6. Wahl des Wartungspartners: Kann man nach der Einführung zu einem anderen Implementierungsunternehmen wechseln, ohne den Herstellersupport zu verlieren?

Dasselbe gilt für RPA, ERP und CRM

Diese Grundsätze gelten für jedes System, das die Arbeit des Unternehmens ordnet. Dabei lohnt es sich jedes Mal, mit der Frage zu beginnen, was erreicht werden soll – denn von der Antwort hängt ab, ob überhaupt die richtige Werkzeugklasse gewählt wird.

RPA. Die erste Frage lautet: Warum gerade RPA und nicht BPM? Ein Software-Roboter übernimmt wiederkehrende menschliche Tätigkeiten in bestehenden Systemen, verändert aber den Prozess nicht; BPM ordnet den Prozess selbst. Geht es darum, Mitarbeiter von der manuellen Übertragung von Daten zwischen Systemen zu entlasten, kann ein Roboter genügen. Geht es um einen neuen, kürzeren Vorgangsablauf, zementiert ein Roboter oft den alten Zustand. Zudem hängt der Roboter von Bildschirmmasken und Formaten anderer Systeme ab: Jede Änderung daran kann ihn zum Stillstand bringen. Daher sollte man die Kosten der Pflege der Szenarien kennen und deren Beschreibung außerhalb des Herstellerwerkzeugs vorhalten.

ERP. Hier lautet die entscheidende Frage: Soll das ERP uns Best Practices und fertige Prozesse liefern, oder soll es unsere eigenen Prozesse unterstützen, die den Wettbewerbsvorteil ausmachen? Im ersten Fall empfiehlt es sich, sich an den Systemstandard zu halten und Anpassungen zu begrenzen, da jede Änderung Updates und einen Partnerwechsel erschwert. Im zweiten Fall bewährt sich manchmal ein einfaches ERP, das von einem agilen BPM-System umhüllt wird, in dem die für das Unternehmen charakteristischen Prozesse angepasst werden, ohne den Kern anzutasten. In beiden Fällen müssen sich Finanz-, Lager- und Personaldaten sowie Integrationen mit KSeF und Banken vollständig samt Historie herauslösen lassen.

CRM. Bevor man Angebote vergleicht, sollte man klären, was unter CRM verstanden wird: die Ordnung der Kundenbetreuungsprozesse, Multichannel-Vertrieb oder eine Plattform zur Akquise von Aufträgen. Das sind drei verschiedene Projekte mit unterschiedlichen Nutzern, unterschiedlichen Integrationen und unterschiedlichem Erfolgsmaßstab. Unabhängig von der Variante sollten der Export der Kundendatenbank mit Kontakthistorie und Einwilligungen sowie eine API zu Vertriebs- und Kundenservicesystemen eine Bedingung in der Ausschreibung sein – kein nachträglicher Zusatz.

Schritt 4. Vergleichen Sie Gesamtkosten, nicht den Lizenzpreis

Angebote sollten anhand der Gesamtkosten über mehrere Jahre gegenübergestellt werden: Anschaffung und Einführung, Betrieb und Lizenzen, Weiterentwicklung sowie Ausstiegskosten aus dem Vertrag. Die günstigste Lizenz erweist sich im dritten Jahr oft als die teuerste, wenn jede Prozessänderung einen kostenpflichtigen Auftrag bei einem einzigen Partner bedeutet. Der Vergleich gelingt am besten anhand eigener Szenarien: Lassen Sie jeden Anbieter denselben schwierigen Fall aus Ihrem Unternehmen vorführen. Mehr zur Angebotsbewertung: Angebotsbewertung und Gespräche mit Anbietern.

Schritt 5. Abnahme und Wartungsvertrag

Das System sollte nach zuvor vereinbarten Testszenarien und Kriterien abgenommen werden, nicht nach den Zusicherungen des Anbieters. Der Wartungsvertrag sollte festlegen, innerhalb welcher Frist Fehler behoben werden, wer Änderungen zu welchen Kosten vornimmt, und die Regelungen zu Datenexport und Vertragsausstieg bestätigen.

Praxisbeispiel

In einer Gruppe von Tochtergesellschaften eines internationalen Konzerns nutzte das Unternehmen ein zentrales ERP-System und musste gleichzeitig Finanzprozesse aus dem Procure-to-Pay-Bereich automatisieren – und zwar gemäß den konzerninternen Einkaufsrichtlinien (corporate purchasing guidelines). Die Versuchung war groß, auf konzerneigene Werkzeuge für die Gruppenarbeit zurückzugreifen, doch diese erwiesen sich als recht teuer und erfüllten weder die Anforderungen an Unabhängigkeit noch an einen einfachen Ausstieg im Problemfall.

In Gesprächen mit den Stakeholdern erarbeiteten wir eine detaillierte Anforderungsbeschreibung, die über die Standardfunktionen fertiger Lösungen hinausging. Wir entwickelten mehrere alternative Wege zur Integration mit den Fachverfahren sowie Mechanismen, die das Risiko einer Bindung an einen einzigen Anbieter verringerten. Das Ergebnis war eine stimmige, auf Standards basierende Anwendungsstrategie und eine Umgebung, in der neue Abläufe agil entstehen – durch Prototyping in kurzen Treffen mit den Prozessverantwortlichen, auch den nicht-technischen. Diese Umgebung umhüllt das ERP-System: Sie bietet dort, wo sich das Unternehmen abhebt, hohe Flexibilität, ohne die Kosten großer Einführungsprojekte.