Vom Proof of Concept zur Produktion in der Unternehmenssoftware

Ein Proof of Concept zeigt, dass eine Idee unter günstigen Bedingungen funktionieren kann. Ein Produktivsystem muss dagegen jeden Tag laufen, für echte Anwender, mit echten Daten und neben Systemen, die nie für das neue System ausgelegt wurden. Viele Unternehmen erkennen diesen Unterschied erst, wenn auf eine gelungene Demo monatelang nichts mehr folgt. Dieser Artikel beschreibt, warum das geschieht und wie sich ein Projekt so in Stufen gliedern lässt, dass die Demo einen realistischen Weg in die Produktion hat.

Warum Proofs of Concept stocken

Die meisten ins Stocken geratenen Proofs of Concept haben einige wenige gemeinsame Ursachen. Keine davon ist im engeren Sinn technischer Natur, und alle lassen sich in den ersten Wochen eines Projekts erkennen.

• Kein fachlicher Verantwortlicher. Das Vorhaben wird von einem Innovations- oder IT-Team getragen, aber niemand in der Fachabteilung hat zugestimmt, dafür einen Prozess zu ändern.
• Angenommener Datenzugriff. Die Demo nutzte einen von Hand aufbereiteten Export, während die echten Daten in Systemen liegen, die eigene Verantwortliche, Berechtigungen und Qualitätsprobleme haben.
• Keine Anbindung an bestehende Systeme. Der Prototyp läuft für sich allein, daher wurde der Aufwand für die Verbindung mit ERP, CRM oder Anlagensystemen nie geschätzt.
• Fehlende Abnahmekriterien. Ohne ein formuliertes Ziel bleibt der Erfolg Ansichtssache, und ein Projekt, das sich nicht als erfolgreich erklären lässt, wird selten weiter finanziert.

Was ein Produktivsystem über die Demo hinaus braucht

Eine Demo deckt den Hauptpfad ab. Ein Produktivsystem muss auch alles abdecken, was darum herum liegt. Die folgende Liste beschreibt, was wir erwarten, bevor ein Unternehmenssystem in Betrieb geht.

• Authentifizierung und Autorisierung, angebunden an den zentralen Identitätsanbieter des Unternehmens, mit Rollen, die den tatsächlichen Aufgaben entsprechen.
• Logging und Monitoring, damit ein Betreiber Fehler, langsame Anfragen und fehlgeschlagene Jobs sieht, bevor Anwender sie melden.
• Datenverträge, die Felder, Formate, Aktualisierungshäufigkeit und das Verhalten bei unerwarteten Daten eines vorgelagerten Systems festlegen.
• Automatisierte und geübte Verfahren für Deployment und Rollback, damit eine fehlerhafte Version innerhalb von Minuten zurückgenommen werden kann.
• Dokumentation zu Architektur, Schnittstellen, Konfiguration und Betriebsabläufen.
• Ein benannter Verantwortlicher in Bereitschaft, der den Zugriff und das Wissen hat, um Störungen zu beheben.

Wie ein Projekt in Stufen gegliedert wird

Ein gestuftes Vorgehen hält jede Investition klein im Verhältnis zu dem, was bereits gelernt wurde. Am Anfang steht die Discovery-Phase. Sie klärt das fachliche Problem, die betroffenen Personen, die beteiligten Systeme und die vorhandenen Daten. Das Ergebnis ist ein kurzes Dokument und eine Entscheidung, ob das Projekt fortgesetzt wird.

Darauf folgt der Proof of Concept mit einem vorab vereinbarten, messbaren Abnahmekriterium. Bei einem System zur Dokumentenklassifikation kann das eine Mindestgenauigkeit auf einer zurückgehaltenen Stichprobe sein. Bei einem Prognosemodell kann es ein Fehlerschwellenwert gegenüber dem aktuellen manuellen Verfahren sein. Ziel ist ein klares Ja oder Nein.

Anschließend läuft ein Pilot mit echten Daten und einer begrenzten Gruppe echter Anwender. Hier zeigen sich Integrationsprobleme, Datenqualitätsmängel und offene Prozessfragen. Es folgt die Härtung für den Produktivbetrieb mit Sicherheitsprüfung, Lasttests, Monitoring, Backup und Wiederherstellung sowie der Deployment-Pipeline. Die letzte Stufe ist die Übergabe mit Schulung, Dokumentation und einer Supportvereinbarung, die festlegt, wer worauf in welcher Zeit reagiert.

Fragen an den Anbieter vor Vertragsabschluss

Ein Auftraggeber kann mit wenigen direkten Fragen viel erfahren. Wer auf Anbieterseite begleitet das Projekt von der Discovery bis zur Übergabe? Welche Abnahmekriterien gelten für jede Stufe, und wer entscheidet, ob sie erfüllt wurden? Wie wird das System nach der Inbetriebnahme überwacht, und wer wird bei einem Ausfall benachrichtigt? Wem gehören der Quellcode, die trainierten Modelle und die Dokumentation? Wie wird das System bereitgestellt, und wie wird eine fehlgeschlagene Version zurückgenommen?

Ebenso sinnvoll ist die Frage, welche Teile der Arbeit vom Auftraggeber abhängen, etwa Datenzugriff, Testumgebungen und Fachexperten, und bis wann. Verzögerungen auf Auftraggeberseite sind ein häufiger Grund für Terminverschiebungen. Werden sie früh benannt, lassen sie sich leichter steuern.

Fazit

Der Weg vom Proof of Concept in die Produktion hängt vor allem von Verantwortung, Daten, Integration und Betrieb ab und nur zum Teil von der gezeigten Technologie. Unternehmen, die diese Fragen früh klären und die Arbeit mit klaren Kriterien in Stufen gliedern, verbringen weniger Zeit in Piloten ohne Ende und mehr Zeit mit Systemen, auf die sich Menschen verlassen.