Factory Readiness Assessment
Wisst, was sich ändern muss, bevor ihr skaliert.
Wir prüfen, wie bereit eure Organisation für eine Software Factory ist. Ihr bekommt eine belegte Baseline, die den ersten Engpass und den nächsten Schritt zeigt.
Belegt | auf euren Kontext zugeschnitten | Empfehlung statt Pitch
Das Ergebnis
Was ihr am Ende in der Hand haltet
Das Ergebnis ist für eure Organisation geschrieben, nicht für eine Marktkategorie.
Readiness-Baseline
Ein belastbares Bild davon, wo die Organisation heute steht, gestützt auf Belege, die ihr prüfen könnt.
Engpasskarte
Welcher Engpass euch wirklich zuerst begrenzt: Delivery, Architektur, Produkt, Organisation oder die Art, wie Entscheidungen fallen.
Outcome-Hypothese
Ein Ergebnis für euren Kontext, mit Baseline, Ziel und benannter Datenquelle für die Arbeit danach.
Priorisierte Roadmap
Eine klare Empfehlung: Training, ein Factory Pilot, direkter Rollout oder eine bewusste Reihenfolge daraus.
Umfang
Was wir uns ansehen
Wir folgen einem echten Wertstrom von der Absicht bis in den Betrieb und schauen, was ihn trägt, was ihn bremst und wer entscheidet.
Geschäftsergebnis und Wertstrom
Das Ergebnis, um das es dem Unternehmen geht, und der Wertstrom, der es liefern muss. Wir folgen einem Weg von der Idee bis in die Produktion und schauen, wo die Arbeit liegen bleibt.
Delivery und DORA-Signale
Deployment-Frequenz, Durchlaufzeit, Change Failure Rate, Wiederherstellungszeit. Wir arbeiten mit den Delivery-Signalen, die euer Setup hergibt, und sagen offen, wo ein Signal fehlt oder zu dünn ist.
Agenteneinsatz und Änderungsvertrauen
Wie viel der Arbeit heute schon mit Agenten läuft, und wie sicher sich das Team fühlt, wenn es das System ändert. Wo das Vertrauen niedrig ist, schauen wir, was dahintersteckt.
Architektur und Kontextreife
Ob Codebasis, Grenzen, Tests und aufgeschriebene Regeln einem Agenten genug Kontext geben, um sicher zu arbeiten.
Produkt- und Engineering-Entscheidungen
Wer entscheidet, was gebaut wird, wie die Absicht im Team ankommt und wie viel Nacharbeit aus unklaren Anforderungen entsteht.
Steuerung und Governance
Wie Budget, Besetzung, Security und Compliance den Rahmen setzen, in dem Engineering arbeitet, und wer eine Blockade auflösen kann, wenn wir sie benennen.
Auswertung
Beispiel eines Engpassprofils
Das Assessment liest alle sechs Dimensionen zusammen. Ein starkes Signal in einem Bereich gleicht einen Engpass in einem anderen nicht aus.
- Geschäftsergebnis und Wertstrom
- Delivery und DORA-Signale
- Agenteneinsatz und Änderungsvertrauen
- Architektur und Kontextreife
- Produkt- und Engineering-Entscheidungen
- Steuerung und Governance
Evidenz
Wie wir zu Evidenz kommen
Eine Selbsteinschätzung eröffnet das Gespräch. Ein Beleg ist sie für sich genommen nicht, also prüfen wir das Gehörte gegen mehrere Quellen.
Anonyme Gespräche mit Entwicklerinnen und Entwicklern
Wir sprechen einzeln mit den Leuten, die die Arbeit machen. Was wir hören, ordnen wir niemandem namentlich zu.
Checkliste zu Architektur und SDLC
Euer Team füllt vor dem Termin eine schriftliche Checkliste aus. Sie liefert das Ausgangsbild und zeigt, wo die Antworten im Unternehmen auseinandergehen.
Sichtung der Artefakte
Systemdiagramme, Agentenregeln, Incident-Prozess, Observability, Organisationsschnitt und Zugang zum Quellcode, soweit vorhanden und teilbar. Wir vergleichen das Beschriebene mit dem, was die Artefakte zeigen.
Nachgespräche
Wo Checkliste, Artefakte und Gespräche auseinandergehen, fragen wir nach. Genau dort haken wir ein.
Die Arbeit
Von den Belegen zur Entscheidung in der Führung
Die genaue Dauer und der Anteil vor Ort stehen im Angebot für euren Kontext.
-
01
Das Ergebnis festlegen
Wir klären das Geschäftsergebnis, den Wertstrom, den aktuellen Druck und die Entscheidung, die dieses Assessment stützen muss.
-
02
Das System lesen
Wir sehen uns Delivery-Signale, AI-Nutzung, Änderungssicherheit, Architektur, Context-Reife und die Art an, wie Produkt- und Engineering-Entscheidungen fallen.
-
03
Den Engpass finden
Wir bauen die belegte Baseline und benennen den Engpass, der den Fortschritt begrenzt, bevor wir eine Lösung empfehlen.
-
04
Den Weg entscheiden
Ihr bekommt Roadmap, Pilotempfehlung, Messplan und ein Readout für die Geschäftsführung.
Euer Ergebnis
Ein Entscheidungsprodukt, das bei euch bleibt
Baseline und Roadmap gehören euch, egal ob wir den nächsten Schritt liefern.
Generische Discovery
Ein Anbieter sammelt gerade genug Kontext, um seine Lieblingsleistung zu verkaufen.
- Die Empfehlung steht vorher fest.
- Die Belege bleiben vage oder beim Anbieter.
- Training wird automatisch zum nächsten Schritt.
- Der Geschäftsnutzen hat keine benannte Quelle.
Factory Readiness
Die Organisation bekommt eine klare Einordnung und die nächste Entscheidung.
- Der schwächste Engpass bestimmt die Empfehlung.
- Baseline und Roadmap gehören euch.
- Training ist ein möglicher Weg, nicht der Standard.
- Zu jedem vorgeschlagenen Ergebnis steht, wie es gemessen wird.
Messplan
Engineering-Signale plus ein Geschäftsergebnis
Das Assessment tut nicht so, als würde Engineering-Aktivität allein den Wert belegen.
- Wo ihr heute steht
- Baseline
- Was sich ändern soll
- Ziel
- Woher die Belege kommen
- Quelle
- Wann das Ergebnis geprüft wird
- Takt
Voraussetzungen
Was wir von euch brauchen
Das Assessment liefert eine belastbare Antwort, wenn das hier vor dem Start steht.
Eine benannte Geschäftsentscheidung
Eine Entscheidung, auf die das Assessment einzahlt. Ohne sie entsteht ein Dokument, und ein Dokument ändert nichts.
Zugang zu einem echten Wertstrom und seinen Delivery-Signalen
Ein laufender Strom statt eines aufgeräumten Beispiels, dazu die Signale, die er liefert: Repository-Historie, CI-Läufe, Ticketfluss, Incident-Historie.
Die relevanten Stakeholder
Engineering, Produkt, Architektur und die Führung, die Budget und Mandat verantwortet. Wer mit dem Ergebnis arbeiten soll, sollte an seiner Entstehung beteiligt sein.
Artefakte und Systemzugang
Diagramme, Regeln, Dashboards und Zugang zum Code, über den wir reden, im Rahmen eurer Vereinbarungen und Zugriffsregeln. Wir arbeiten mit dem, was existiert, nicht mit dem, was existieren sollte.
Preis
Ein Festpreis für ein Ergebnis, das euch gehört
Der Preis deckt Diagnose, Roadmap und Readout für die Geschäftsführung ab. Das Ergebnis gehört euch, auch wenn wir den nächsten Schritt nicht liefern.
Bevor ihr das Assessment beauftragt
Für wen ist das?
Für Engineering-Organisationen, die über einzelne AI-Experimente hinaus sind und eine belegte Entscheidung über Training, einen Piloten oder einen breiteren Rollout brauchen.
Für wen ist das noch nicht der richtige Schritt?
Das Assessment ist nicht der richtige Einstieg für eine Werkzeugdemo, einen allgemeinen AI-Benchmark oder eine Organisation ohne benannte Entscheidung, echten Wertstrom und Führungskräfte, die mit dem Ergebnis handeln können.
Wenn zuerst gemeinsame Engineering-Praxis statt einer Organisationsdiagnose gebraucht wird, kann das Team-Training der kleinere nächste Schritt sein.
Was passiert im ersten Gespräch?
Wir klären die Geschäftsentscheidung, den Wertstrom, den aktuellen Engpass, die Verantwortung für das Ergebnis und welche Belege voraussichtlich verfügbar sind. Danach sagen wir, ob das Assessment passt und was vor einem sinnvollen Angebot geklärt werden muss.
Führt das Assessment immer zum Training?
Nein. Es kann Training, einen Factory Pilot, einen direkten Rollout oder eine Reihenfolge daraus empfehlen. Die Belege entscheiden über den Weg.
Worauf braucht ihr Zugriff?
Auf das Geschäftsergebnis, den Wertstrom, eure Delivery-Signale, die AI-Nutzung, die Architektur und das Context-Setup sowie die Menschen, die entscheiden. Die genaue Liste stimmen wir vor dem Start ab.
Was passiert nach dem Readout?
Baseline, Engpasskarte, Outcome-Hypothese, Roadmap, Pilotempfehlung und Messplan gehören euch. Ihr könnt mit uns weitermachen oder das Ergebnis eigenständig nutzen.
Wie lange dauert das Assessment?
Die Dauer hängt von Wertstrom, verfügbaren Belegen, Zugang zu Stakeholdern und dem Anteil vor Ort ab. Das Angebot benennt Arbeitszeitraum, Inputs, Termine und den Zeitpunkt der Entscheidung vor Beginn des Engagements.
Nächste Schritte
Die Belege im nächsten Engagement nutzen
Mit dem Team-Training gemeinsame Praktiken aufbauen
Nutzt die Baseline aus dem Assessment, um ein praxisnahes Training auf den wichtigsten Engpass auszurichten.
Team-Training ansehenEinen Wertstrom im Factory Pilot prüfen
Nutzt Ergebnis, Baseline und Messplan, um einen laufenden Factory-Slice zu schneiden.
Factory Pilot ansehenDie nächste Entscheidung mit Belegen treffen
Beauftragt das Factory Readiness Assessment und geht mit einer Baseline, den echten Engpässen und einem priorisierten Weg nach vorn heraus.