Ein Pilot ist kein verkleinertes Endprodukt. Er ist ein begrenzter Versuch, der Annahmen prüft, relevante Parameter erfasst und eine begründete Entscheidung ermöglicht.
17 Jahre unter regulierten Bedingungen prägen meinen Blick auf Piloten
In Biotechnologie, Pharma und Life Science habe ich 17 Jahre unter stark regulierten Bedingungen gearbeitet. Dort entscheidet nicht nur das Ergebnis. Ebenso wichtig ist, unter welchen Bedingungen es entstand, wie es gemessen wurde und ob der Ablauf nachvollziehbar dokumentiert ist.
Ein häufig verwendeter Satz bringt dieses Prinzip auf den Punkt: „Was nicht dokumentiert wurde, wurde nicht gemacht.“ Die Aussage klingt streng. Sie schützt aber davor, Ergebnisse im Nachhinein nur aus dem Gedächtnis zu erklären.
GMP steht für Good Manufacturing Practice. Der scherzhafte Zusatz „give more paper“ beschreibt den hohen Dokumentationsaufwand. Dieser Aufwand hat einen Zweck: Arbeitsschritte, Messwerte, Abweichungen und Entscheidungen sollen auch später noch nachvollziehbar sein.
Der kleinste Ansatz beantwortet eine begrenzte Frage
Neue biologische Prozesse begannen häufig im Schüttelkolben. Wenige hundert Milliliter Kultur, eine feste Temperatur und ausgewählte Messgrößen reichten aus, um erste Annahmen zu prüfen. Dazu gehörten zum Beispiel pH-Wert, optische Dichte und zeitlicher Wachstumsverlauf.
Der Schüttelkolben war bewusst limitiert. Sauerstoff wurde nicht aktiv eingeblasen und Kohlendioxid nicht gezielt abgeführt. Der Gasaustausch erfolgte passiv über die Oberfläche der Flüssigkeit. Die Schwenkbewegung vergrößerte diese Oberfläche und mischte die aufgenommenen Gase in die Kultur ein.
Mit steigender Zelldichte nahm der Sauerstoffbedarf zu. Gleichzeitig wurde es schwieriger, genügend Sauerstoff einzutragen und Kohlendioxid abzuführen. Auch der pH-Wert wurde in solchen frühen Ansätzen häufig nur gemessen, aber noch nicht aktiv stabil gehalten.
Entscheidender Punkt
Die bekannten Grenzen machten den Versuch nicht wertlos. Sie bestimmten, welche Aussage zulässig war und welche Frage erst im nächsten Maßstab geprüft werden konnte.
Ein Schüttelkolben beweist nicht, dass der große Maßstab funktioniert
Der kleine Ansatz konnte zeigen, ob eine Kultur grundsätzlich wächst, wie sich die optische Dichte entwickelt und wann erkennbare Grenzen auftreten. Er konnte nicht belegen, dass ein Prozess bei zehn, hundert oder tausend Litern identisch funktioniert.
Diese Trennung ist wichtig. Ein begrenzter Versuch liefert belastbare Erkenntnisse innerhalb seines Umfangs. Wer daraus ohne weitere Prüfung eine Aussage für den späteren Gesamtprozess ableitet, überschätzt das Ergebnis.
Für Softwareprojekte gilt dasselbe: Ein Pilot mit wenigen Nutzern oder einem Standort kann eine konkrete Annahme prüfen. Er belegt noch nicht, dass Betrieb, Rollen, Datenqualität und technische Architektur im größeren Maßstab unverändert funktionieren.
Beim Scale-up kommen neue Parameter und aktive Regelungen hinzu
Bei der Maßstabsübertragung, dem Scale-up, wurden die Werte nicht einfach proportional vergrößert. Die Bedingungen änderten sich. In kontrollierten Bioreaktoren konnten deshalb zusätzliche Parameter gemessen und aktiv geregelt werden.
- Sauerstoffsättigung und Belüftung: Sauerstoff wurde aktiv eingetragen und die Abfuhr von Kohlendioxid unterstützt.
- Rührerdrehzahl: Mit zunehmender Zelldichte wurde die Durchmischung wichtiger, damit Sauerstoff und Nährstoffe möglichst gleichmäßig verteilt blieben.
- pH-Regelung: Der pH-Wert wurde nicht nur gemessen, sondern innerhalb festgelegter Grenzen stabilisiert.
- Nährstoffzufuhr: Je nach Prozess wurden Glukose oder Glycerin zugeführt. Die Zugabe orientierte sich am gemessenen Verbrauch, um Mangel und Überdosierung zu vermeiden.
- Biomasse: Neben der optischen Dichte konnte die Zellmasse bestimmt werden, um das Wachstum genauer zu beurteilen.
Der größere Maßstab brauchte daher mehr Beobachtung, mehr Regelung und mehr Dokumentation. Genau diese zusätzlichen Informationen ermöglichten später die Ursachenanalyse, wenn ein Zielwert nicht erreicht wurde.
SOPs machen Messungen vergleichbar
Für wiederkehrende Messungen und Arbeitsschritte gab es Standardarbeitsanweisungen, sogenannte Standard Operating Procedures oder SOPs. Sie legten fest, wie eine Probe genommen, ein Gerät vorbereitet, ein Messwert erfasst und eine Abweichung dokumentiert wird.
Eine SOP garantiert kein gewünschtes Ergebnis. Sie reduziert aber Unterschiede, die allein durch eine abweichende Durchführung entstehen. Wenn mehrere Personen denselben Ablauf nach derselben Anweisung durchführen, werden Ergebnisse besser vergleichbar.
Wurde ein Zielwert verfehlt, konnten die dokumentierten Daten gezielt geprüft werden:
- War die Sauerstoffversorgung über den gesamten Zeitraum ausreichend?
- Blieb der pH-Wert innerhalb des vorgesehenen Bereichs?
- Entsprach die Nährstoffzufuhr dem gemessenen Verbrauch?
- Waren Temperatur und Durchmischung stabil?
- Wurden Probe, Messung und Dokumentation nach dem festgelegten Verfahren durchgeführt?
Der nächste Versuch begann dadurch nicht wieder bei null. Er konnte einen auffälligen Parameter enger kontrollieren oder eine begründete Änderung prüfen.
Softwareprojekte beginnen häufig am falschen Ende
In Softwareprojekten startet die Diskussion oft mit Funktionen: Anmeldung, Rollen, Auswertungen, Benachrichtigungen, Schnittstellen und Automatisierung. Damit wird früh über den späteren Maßstab gesprochen, bevor die zentrale Annahme geprüft ist.
Ein sinnvoller Pilot beginnt stattdessen mit einer konkreten Entscheidung:
- Welches Problem oder welcher Ablauf soll geprüft werden?
- Welche Annahme steht dahinter?
- Welche Daten werden für die Prüfung benötigt?
- Welche Messgrößen zeigen eine relevante Veränderung?
- Welche Grenzen gelten für Zeitraum, Standort und Nutzergruppe?
- Welches Ergebnis rechtfertigt eine Fortsetzung?
Damit wird der Pilot zu einem kontrollierten Praxistest. Er muss noch nicht alle Funktionen eines späteren Produkts enthalten. Er muss genügend Informationen liefern, um über den nächsten Schritt zu entscheiden.
Was sich methodisch übertragen lässt
Fünf Regeln für belastbare Software-Piloten
1. Den Umfang bewusst begrenzen
Ein kleiner Umfang ist kein Mangel, solange er zur Prüffrage passt. Wenige Nutzer, ein Standort oder ein ausgewählter Prozess reduzieren Störfaktoren und halten die Auswertung nachvollziehbar.
2. Nur entscheidungsrelevante Parameter messen
Mehr Daten bedeuten nicht automatisch mehr Erkenntnis. Erfasst werden sollte, was die Ausgangslage, die Veränderung und mögliche Nebenwirkungen beschreibt.
3. Messungen standardisieren
Wenn Nutzer denselben Vorgang unterschiedlich dokumentieren, sind Ergebnisse schwer vergleichbar. Klare Definitionen, Eingaberegeln und Zeitpunkte übernehmen im Pilot eine ähnliche Funktion wie SOPs.
4. Abweichungen dokumentieren
Fehlende Daten, ungewöhnliche Verkaufstage, technische Störungen oder Änderungen im Ablauf gehören in die Auswertung. Ohne diesen Kontext kann eine Kennzahl richtig berechnet und trotzdem falsch interpretiert werden.
5. Erst nach der Auswertung erweitern
Zusätzliche Funktionen sollten aus bestätigten Anforderungen entstehen. Ein größeres System behebt keine ungeklärte Annahme aus dem kleinen Versuch.
Der Bäckerei-Pilot folgt diesem Prinzip
Der aktuelle Bäckerei-Pilot von byte & Handwerk ist auf vier Wochen, eine Filiale und bis zu 30 Artikel begrenzt. Er prüft, ob Verkaufs- und Retourendaten die tägliche Mengenentscheidung nachvollziehbar unterstützen können.
Erfasst werden nicht nur Retouren. Auch Ausverkäufe und Planungsabweichungen gehören zur Auswertung. Eine geringere Retoure wäre kein Fortschritt, wenn wichtige Artikel dadurch regelmäßig deutlich früher fehlen.
Der Pilot verspricht keine vorab festgelegte Verbesserung. Möglich sind mehrere Ergebnisse:
- Die Daten zeigen einen relevanten und messbaren Ansatzpunkt.
- Die Daten reichen für eine belastbare Auswertung noch nicht aus.
- Ein anderer betrieblicher Ablauf ist wichtiger als die Mengenplanung.
- Eine technische Entwicklung ist für das geprüfte Problem nicht sinnvoll.
Auch das letzte Ergebnis ist verwertbar. Es verhindert, dass ein Betrieb Zeit und Geld in eine Lösung investiert, deren Nutzen nicht bestätigt wurde.
Prüfregel
Der Erfolg eines Piloten zeigt sich nicht an der Zahl seiner Funktionen. Entscheidend ist, ob danach eine bessere und nachvollziehbar begründete Entscheidung möglich ist.
Wo die Analogie endet
Ein Software-Pilot ist kein GMP-Prozess. Rechtliche Anforderungen, Risiken und Nachweise unterscheiden sich deutlich. Die Analogie darf deshalb nicht den Eindruck erwecken, ein betrieblicher Praxistest erfülle regulatorische Standards aus der Pharma- oder Biotechnologie.
Auch Menschen und betriebliche Abläufe verhalten sich nicht wie eine Zellkultur. Erfahrung, Zeitdruck, Kommunikation und Organisation beeinflussen Entscheidungen. Diese Faktoren lassen sich nicht vollständig kontrollieren.
Übertragbar ist die Methode: klein beginnen, Bedingungen festlegen, relevante Werte messen, Abweichungen dokumentieren und erst nach der Auswertung vergrößern.
Fazit: Der kleine Versuch soll die nächste Entscheidung verbessern
Der Schüttelkolben war wertvoll, weil seine Möglichkeiten und Grenzen bekannt waren. Er beantwortete eine begrenzte Frage und zeigte, welche Parameter im nächsten Maßstab genauer kontrolliert werden mussten.
Ein guter Software-Pilot erfüllt dieselbe Funktion. Er zeigt, ob ein Problem relevant ist, ob die benötigten Daten verfügbar sind, ob eine Veränderung messbar wird und wo die Grenzen des bisherigen Ansatzes liegen.
Das Ergebnis kann eine technische Erweiterung, eine Prozessänderung oder ein begründetes Nein sein. In allen drei Fällen hat der Pilot seinen Zweck erfüllt, wenn die Entscheidung danach besser belegt ist.
Häufige Fragen zu Software-Piloten und dokumentierten Versuchen
Was unterscheidet ein Pilotprojekt von einem verkleinerten Endprodukt?
Ein Pilotprojekt bildet nicht alle Funktionen eines späteren Produkts ab. Es begrenzt Umfang, Zeitraum und Messgrößen so, dass eine konkrete Annahme unter realen Bedingungen geprüft werden kann.
Warum ist Dokumentation in einem Software-Pilot wichtig?
Dokumentation macht sichtbar, unter welchen Bedingungen ein Ergebnis entstand. Sie hilft, Abweichungen zu erklären, Entscheidungen nachzuvollziehen und den nächsten Versuch gezielter zu planen.
Wann sollte ein Pilotprojekt vergrößert werden?
Eine Erweiterung ist sinnvoll, wenn die zentrale Annahme bestätigt wurde, die Daten verlässlich genug sind und vorab festgelegte Entscheidungskriterien erreicht wurden. Mehr Funktionen ersetzen diese Prüfung nicht.
Was bedeutet die Analogie zum Scale-up für Softwareentwicklung?
Beim Übergang in einen größeren Maßstab ändern sich Bedingungen und Anforderungen. In Softwareprojekten können zusätzliche Nutzer, Standorte, Datenquellen und Rollen neue Anforderungen erzeugen, die im kleinen Pilot noch nicht sichtbar waren.
Über den Autor
Dominik Baki ist gelernter Bäcker und App-Entwickler. Dazwischen arbeitete er 17 Jahre in Biotechnologie, Pharma und Life Science unter regulierten Bedingungen. Mit byte & Handwerk überträgt er die methodischen Grundsätze begrenzter, dokumentierter Versuche auf betriebliche Pilotprojekte. Beruflicher Hintergrund und Qualifikationsnachweis →
Grundlage und Aktualisierung
Einordnung dieses Beitrags
Der Beitrag beruht auf der persönlichen Berufserfahrung von Dominik Baki aus 17 Jahren in Biotechnologie, Pharma und Life Science. Die beschriebenen Beispiele zu Schüttelkolben, Bioreaktoren, Messparametern und SOPs erläutern methodische Grundsätze. Sie sind keine Arbeitsanweisung für einen konkreten biotechnologischen oder pharmazeutischen Prozess.
Der Transfer auf Softwareentwicklung beschreibt eine Vorgehensweise, keine Gleichsetzung mit GMP-Anforderungen. Zuletzt inhaltlich geprüft am 21. August 2026.