Durchlaufzeit von der Idee bis zur Produktion
Wie lange braucht eine Änderung von der Entscheidung bis zur Auslieferung — und wie viel davon ist Wartezeit statt Arbeitszeit?
~/appetizer-labs/delivery-bottleneck-assessment
Delivery Bottleneck Assessment
Delivery-Engpässe finden und priorisiert beseitigen
Ihr erfahrt, an welchen wenigen Stellen eure Auslieferung tatsächlich hängt, was diese Stellen an Wartezeit, Risiko und gebundener Kapazität kosten — und in welcher Reihenfolge ihr sie in den nächsten 30, 60 und 90 Tagen beseitigt.
30 Minuten, kostenfrei, ohne Verkaufsgespräch.
Die Arbeit ist fertig. Ausgeliefert ist sie deshalb noch lange nicht.
In den meisten Organisationen ist nicht die Entwicklung langsam, sondern der Weg danach. Eine Änderung ist in Stunden geschrieben und braucht Tage bis Wochen bis in die Produktion: Sie wartet auf ein Review, auf eine Umgebung, auf einen Build, der zum dritten Mal grundlos abbricht, auf eine Freigabe, deren Prüfkriterium niemand mehr benennen kann. Diese Wartezeit taucht in keiner Schätzung auf und in keinem Ticket. Sichtbar wird sie erst, wenn ein Termin reißt — und dann fällt die Antwort meistens auf Kapazität: mehr Entwickler. Zusätzliche Leute erhöhen aber den Durchsatz eines Systems nicht, das an einer anderen Stelle begrenzt ist. Sie erhöhen die Menge angefangener Arbeit vor demselben Engpass.
Wann dieses Assessment sinnvoll ist
- Ein zugesagter Liefertermin ist gerissen, und niemand kann belegen, woran es lag.
- Die Roadmap steht, aber die Auslieferung hält das Tempo nicht — und das ist bereits ein Thema im Management.
- Ihr habt eingestellt, und der Ausstoß ist nicht mitgewachsen.
- Ein großer Kunden-Rollout, ein Audit oder eine Zertifizierung steht an, und die Release-Fähigkeit ist der Risikofaktor.
- Ein Vorfall hat gezeigt, wie lange ihr braucht, um eine Korrektur in Produktion zu bringen.
- Ein Plattform- oder Modernisierungsprogramm läuft seit Monaten, die Durchlaufzeit hat sich nicht verändert.
- Die Geschäftsführung fragt, ob mehr Entwickler das Problem lösen, und ihr wollt die Antwort belegen können.
- Die Cloud-Rechnung wächst schneller als das, was am Ende ausgeliefert wird.
Für wen das Assessment gedacht ist
Für die Person, die für Liefergeschwindigkeit geradestehen muss — und für die technische Führung, die die Engpässe danach beseitigt.
- CTOs und VPs of Engineering, die eine Liefergeschwindigkeit verantworten, die sie nicht erklären können.
- Heads of Engineering und Bereichsleitungen mit mehreren Teams an einem gemeinsamen Lieferweg.
- Heads of Platform, die belegen müssen, wo die interne Plattform trägt und wo sie im Weg steht.
- Technische Programmverantwortliche vor einem Rollout, dessen Termin an der Auslieferfähigkeit hängt.
- Geschäftsführungen, die vor einer Einstellungswelle wissen wollen, ob Kapazität überhaupt der Engpass ist.
Für wen es nicht gedacht ist
Ein Assessment, das niemandem hilft, kostet vor allem eure Zeit. In diesen Fällen sagen wir von uns aus ab:
- Ihr wisst bereits, wo der Engpass liegt, und braucht die Umsetzung. Dann fangt damit an.
- Es gibt niemanden auf Führungsebene, der die Maßnahmen danach freigeben darf.
- Gesucht wird eine nachträgliche Begründung für eine bereits beschlossene Werkzeug- oder Plattformentscheidung.
- Das Ziel ist die Bewertung einzelner Teams oder Personen. Wir untersuchen den Fluss der Arbeit, nicht die Leistung von Menschen.
- Ein Team, ein Repository, mehrere Deployments pro Tag: dann liegt euer Problem woanders, und ein Assessment findet nichts, was ihr nicht schon wisst.
Was das Assessment ausdrücklich nicht ist
Der Umfang ist fest, und diese Liste ist der Grund, warum er das bleibt. Was hier steht, ist nicht enthalten — und lässt sich separat beauftragen, falls die Analyse zeigt, dass es nötig ist.
- keine vorab festgelegte Ursache
- kein Penetrationstest und kein Sicherheitsaudit
- kein zeilenweises Code-Audit
- keine Werkzeugauswahl und keine Migration
- keine Umsetzung während der Analyse
- keine Leistungsbeurteilung von Teams oder Personen
- keine Zusage eines bestimmten Produktivitätsgewinns
Abgrenzung
Klassische Beratung liefert die Analyse und geht. Wir schreiben die Empfehlungen so, dass wir sie selbst umsetzen könnten — und in vielen Fällen tun wir das danach auch. Durchgeführt wird das Assessment vom Gründer, nicht von einem Juniorteam mit Foliendeck: Wer den Lieferweg abgeht und die Interviews führt, schreibt auch den Bericht und sitzt im Readout.
Und es ist kein umbenanntes Kubernetes-, CI/CD- oder Cloud-Audit. Diese drei sind Kandidaten, keine Diagnose. Genauso häufig liegt der Engpass in einer Freigabe, die niemand mehr begründen kann, in einer Teamgrenze mitten durch einen Lieferweg, in einer Entscheidung, die seit Wochen niemand treffen darf, oder schlicht darin, dass zu viel gleichzeitig angefangen wurde. Womit wir hineingehen, ist eine Methode — nicht eine Antwort.
Nicht zu verwechseln mit dem Engineering Growth Assessment. Das fragt, ob Organisation und technisches System die nächste Wachstumsstufe tragen, und plant über sechs bis zwölf Monate. Dieses Assessment fragt, was heute den Fluss begrenzt, wo Arbeit wartet und was ihr als Nächstes beseitigt. Methoden und Gesprächspartner überschneiden sich, Fragestellung, Bericht und Zeithorizont nicht.
Fragen, die das Assessment beantwortet
Am Ende steht zu jeder dieser Fragen eine Antwort mit Beleg — nicht eine Sammlung von Beobachtungen.
- 01Was bremst eure Auslieferung tatsächlich?
- 02Welcher Engpass hat die größte Geschäftswirkung?
- 03Sind die Engpässe technisch, organisatorisch, prozessual oder eine Frage der Verantwortung?
- 04Wo wartet Arbeit, wo schlägt sie fehl, und wo braucht sie einen Menschen, der von Hand eingreift?
- 05Welche Verbesserungen wirken messbar innerhalb der nächsten 90 Tage?
- 06Behandelt ihr Symptome, während der eigentliche Engpass unangetastet bleibt?
- 07Braucht ihr mehr Entwickler — oder weniger Reibung für die, die ihr habt?
Woran ihr einen Delivery-Engpass erkennt
Die Auslöser oben sind das, was die Geschäftsführung sieht. Das hier ist das, was die Teams sehen. Trifft mehr als eine Handvoll davon zu, ist die Wartezeit größer als die Arbeitszeit — und dann ist Kapazität nicht euer Problem.
- Zwischen „fertig entwickelt“ und „in Produktion“ liegen Tage oder Wochen, die niemand einplant.
- Ein Release ist ein Termin, kein Vorgang. Freitags deployt niemand.
- Pull Requests warten länger auf ein Review, als ihre Umsetzung gedauert hat.
- Die Pipeline bricht regelmäßig ab, ohne dass am Code etwas falsch ist. Neu starten ist Routine.
- Für eine Testumgebung braucht ein Team ein Ticket bei einem anderen Team.
- Vor der Produktion stehen Freigaben, deren Prüfkriterium niemand mehr benennen kann.
- Dieselbe Handarbeit fällt jede Woche an und steht in keinem Backlog.
- Arbeit liegt still, weil eine Entscheidung fehlt, die niemand treffen darf.
- Neue Entwickelnde brauchen Wochen bis zum ersten eigenen Deployment.
- Es ist ständig vieles angefangen und wenig fertig.
- Nach einem Fehler in Produktion dauert der Weg zurück länger als der Weg hin.
Keiner dieser Punkte ist für sich eine Diagnose. Sie sind der Grund, genauer hinzusehen — welcher davon der begrenzende Faktor ist und welche nur dessen Nebenwirkungen sind, entscheidet die Analyse und nicht die Liste.
Was wir uns ansehen
Fünfzehn Dimensionen, jede mit einer Leitfrage. Nicht jede ist bei euch relevant — was nicht passt, klären wir im Fit-Check ab. Der Umfang bleibt fest, die Tiefe verteilen wir dorthin, wo die Wartezeit liegt.
Auslieferfrequenz und Release-Risiko
Wie oft geht etwas live, wie groß ist ein Release geworden, und wie stark wächst das Risiko mit der Paketgröße?
Fehlerrate und Wiederherstellung
Wie oft geht eine Änderung schief, wie schnell merkt ihr es, und wie lange dauert der Weg zurück?
Verlässlichkeit und Wartezeit der Pipelines
Wie oft bricht ein Build ohne fachlichen Grund ab, und wie lange steht ein Team vor einem verwertbaren Ergebnis?
Umgebungen und Selbstbedienung
Wie kommt ein Team an eine Testumgebung — per Ticket, per Absprache, oder selbst und in Minuten?
Architektur und Abhängigkeiten
Welche Änderungen erzwingen Abstimmung über Systemgrenzen hinweg, weil die Grenzen nicht dort verlaufen, wo die Arbeit anfällt?
Plattform und Betriebsmodell des Plattformteams
Ist die interne Plattform ein Produkt mit Nutzern — oder eine Warteschlange mit Tickets?
Freigaben und Übergaben
Welche manuellen Freigaben und Übergaben liegen zwischen fertigem Code und Produktion, und was prüft jede davon wirklich?
Betriebsaufwand und Vorfallslast
Wie viel Entwicklungskapazität binden Bereitschaft, wiederkehrende Handarbeit und Nacharbeit — und ist der Trend steigend?
Verantwortung und Entscheidungswege
Wo bleibt Arbeit liegen, weil unklar ist, wer entscheiden darf oder wem der betroffene Teil gehört?
Sicherheits- und Compliance-Reibung
Welche Auflagen bremsen die Auslieferung, welche davon sind tatsächlich vorgeschrieben, und welche sind Gewohnheit?
Cloud- und Infrastrukturgrenzen
Wo begrenzen Infrastruktur, Kontingente oder Kosten den Durchsatz — und wo ist die Infrastruktur nur der sichtbare Teil eines anderen Engpasses?
Teamzuschnitt und teamübergreifende Koordination
Wie viele Teams müssen sich abstimmen, damit eine durchschnittliche Änderung live geht?
Einarbeitung und lokale Entwicklung
Wie lange dauert es vom ersten Tag bis zum ersten eigenen Deployment, und woran liegt die Dauer?
Angefangene Arbeit und Priorisierung
Wie viel läuft gleichzeitig, wie oft wird umpriorisiert, und was davon wird nie fertig?
Ablauf
Neun Schritte, fester Umfang. Ihr wisst vorher, wessen Zeit gebraucht wird und wann.
- 01
Fit-Check und Zuschnitt
Ein Gespräch: Symptom, betroffener Lieferweg, Frist, Grenzen des Umfangs. Wenn ein Assessment das falsche Mittel ist, sagen wir das hier — nicht nach der Beauftragung.
- 02
Kickoff
Welcher Lieferweg untersucht wird, welche Belege vorliegen und wer gesprochen wird. Ab hier läuft die Uhr.
- 03
Lieferweg kartieren
Wir gehen den Weg einer echten Änderung gemeinsam ab — von der Entscheidung bis zur Produktion, mit jeder Übergabe, jeder Freigabe und jeder Warteschlange dazwischen.
- 04
Sichtung der Belege
Pipeline-Läufe, Ticket-Verläufe, Deployment-Historie, Vorfalls- und Bereitschaftsdokumentation, Freigabewege — anhand dessen, was vorhanden ist.
- 05
Interviews
Entwicklung, Plattform und Betrieb, Qualitätssicherung, Sicherheit, Produkt und Führung. Vertraulich, einzeln, ohne Protokoll an die Führung.
- 06
Engpassanalyse
Wir trennen Symptom und Ursache und prüfen, ob der vermutete Engpass der tatsächlich begrenzende ist. Häufig ist er es nicht.
- 07
Wirkung und Reihenfolge
Jeder Engpass bekommt eine Geschäftswirkung, eine Aufwandsspanne und einen Platz in der Reihenfolge — inklusive der Abhängigkeiten, die diese Reihenfolge erzwingen.
- 08
Executive Readout
Eine Sitzung mit der Führungsebene: die begrenzenden Engpässe, ihre Kosten, die empfohlene Reihenfolge und die Zielkonflikte dahinter.
- 09
Technische Übergabe
Eine Sitzung mit den beteiligten Teams: Maßnahmen, Verantwortliche, Abhängigkeiten und die Kennzahlen, die ihr ab jetzt erheben solltet.
Was ihr beisteuert
Ohne Zugang zu den Spuren, die eure Arbeit hinterlässt, bleibt die Analyse Meinung. Diese Punkte brauchen wir, mehr nicht:
- eine sponsernde Person auf Führungsebene
- den Lieferweg, um den es geht — Produkt, Systemlandschaft oder Teamverbund
- einen Überblick über die beteiligten Teams und ihre Verantwortungsschnitte
- Lesezugriff auf Ticket-Historie, Pipeline-Läufe und Deployment-Verlauf, oder Exporte daraus
- vorhandene Zahlen zu Durchlaufzeit, Vorfällen, Bereitschaft und Cloud-Kosten
- Zugang zu den Gesprächspartnern für die Interviews
- die Freigabe- und Abnahmewege, so wie sie tatsächlich gelebt werden
Fehlende Kennzahlen sind kein Hindernis, sondern häufig der erste Befund. Wenn ihr Durchlaufzeiten oder Wartezeiten nicht messt, steht genau das im Bericht — zusammen mit der Basislinie, die ihr ab dann erhebt. Für den Fit-Check braucht es keinen Zugang, keine Architekturunterlagen und nichts aus der Produktion.
Was ihr bekommt
Ein Bericht, eine Karte eures Liefersystems, zwei Sitzungen. Alles gehört danach euch.
- Executive Summary
- Die Lage auf zwei Seiten: die wenigen Engpässe, die zählen, und was sie kosten.
- Karte eures Liefersystems
- Der reale Weg einer Änderung von der Idee bis zur Produktion, mit jedem Schritt, jeder Übergabe und jeder Warteschlange.
- Engpass- und Constraint-Analyse
- Welche Stellen den Durchsatz tatsächlich begrenzen — und welche nur laut sind.
- Belegte Ursachen
- Zu jedem Engpass die Beobachtung oder Messung, auf der der Befund beruht. Ohne Beleg kein Befund.
- Geschäftswirkung
- Was jeder Engpass an Wartezeit, Lieferrisiko und gebundener Kapazität verursacht, in der Sprache der Geschäftsführung.
- Priorisiertes Engpass-Backlog
- Alle Engpässe in einer begründeten Reihenfolge statt in einer Liste — jeder mit derselben Struktur.
- Schnelle Verbesserungen und strukturelle Eingriffe
- Getrennt ausgewiesen, damit die schnelle Verbesserung die strukturelle nicht ersetzt.
- Aktionsplan über 30, 60 und 90 Tage
- Drei Horizonte mit Maßnahmen, Verantwortlichen und Abhängigkeiten — was zuerst, was danach, und was erst geht, wenn das Vorherige steht.
- Kennzahlen und Messlücken
- Welche wenigen Kennzahlen ihr ab sofort erhebt, und wo heute keine Basislinie existiert, gegen die sich Verbesserung überhaupt zeigen ließe.
- Verantwortung und Abhängigkeiten
- Welche Rolle welchen Engpass beseitigt, und was vorher stehen muss, damit sie es kann.
- Executive Readout und technische Übergabe
- Eine Sitzung für die Entscheidung über die Reihenfolge, eine für die Teams, die sie umsetzen.
- Optionaler Umsetzungsvorschlag
- Falls ihr Unterstützung wollt — als Option im Bericht, nicht als Bedingung dafür, dass er nützt.
Jeder Engpass im Backlog trägt acht Angaben: Ort im Lieferweg, Beleg, Art des Engpasses, Geschäftswirkung, Aufwandsspanne, Horizont, verantwortliche Rolle und wie sicher wir uns sind. Ein Befund ohne Beleg kommt nicht in den Bericht.
Dauer
10 bis 15 Arbeitstage vom Kickoff bis zum Readout. Der Aufwand auf unserer Seite liegt typischerweise bei 6 bis 9 Beratertagen — der Rest ist eure Terminlage.
- 10 bis 15 Arbeitstage Gesamtdauer, abhängig von der Zahl der beteiligten Teams und eurer Terminlage.
- 6 bis 10 Interviews à 45 bis 60 Minuten, von der Entwicklung bis zur Führungsebene.
- Eine begleitete Kartierung des Lieferwegs mit den beteiligten Teams, meist in zwei Sitzungen.
- Zwei Termine mit euch am Ende: Readout und technische Übergabe.
- Vorgeschaltet der Fit-Check: 30 Minuten, kostenfrei, und danach wisst ihr, ob sich der Rest lohnt.
Preis
Festpreis, keine Tagessatz-Diskussion. Der Einstieg liegt bei 9.500 bis 14.500 Euro zuzüglich Umsatzsteuer und Reisekosten. Ihr kauft keine Beratertage, sondern eine belegte Antwort darauf, was eure Auslieferung begrenzt, und eine Reihenfolge, in der ihr es abstellt.
- Wo im Rahmen ihr landet, hängt an der Zahl der beteiligten Teams und Systeme, nicht an der Zahl der Termine.
- Mehrere unabhängige Lieferwege bekommen nach dem Fit-Check einen eigenen Zuschnitt — dann ist es ein anderes Angebot, kein aufgeblähtes.
- Der Preis steht vor der Beauftragung fest. Er ändert sich auch dann nicht, wenn die Analyse mehr findet als erwartet.
- Eine Umsetzung im Anschluss ist eine Option im Bericht und keine Bedingung.
Wenn der Fit-Check zeigt, dass ihr den Engpass bereits kennt und nur die Umsetzung fehlt, sagen wir das und verkaufen kein Assessment. Dafür gibt es andere Formate.
Wie das Ergebnis aussieht
Zwei Artefakte, beide immer in derselben Form: die Karte eures Liefersystems und ein Eintrag aus dem priorisierten Engpass-Backlog. Unten steht beides in genau der Struktur, in der ihr es bekommt.
Beispielhafte Engpasskarte
Jede Station des Lieferwegs wird zweimal erfasst: die Zeit, in der tatsächlich gearbeitet wird, und die Zeit, in der die Arbeit liegt. Der Engpass ist fast nie dort, wo am meisten gearbeitet wird.
Idee und Entscheidung
Wann die Entscheidung fiel, wie lange sie danach unangetastet blieb und wer sie treffen musste.
BearbeitungszeitWartezeit
Bereit zur Umsetzung
Wie lange geschnittene Arbeit vor der Umsetzung liegt und wie oft sie vorher noch einmal umpriorisiert wird.
BearbeitungszeitWartezeit
Umsetzung
Die tatsächliche Bearbeitungszeit — und wie oft sie für etwas anderes unterbrochen wird.
BearbeitungszeitWartezeit
Review
Wartezeit auf ein Review, Zahl der Runden und die Frage, ob Reviewende überhaupt zuständig sein dürfen.
BearbeitungszeitWartezeit
Integration und Build
Laufzeit der Pipeline, Abbrüche ohne fachlichen Grund und die Zeit bis zu einem verwertbaren Ergebnis.
BearbeitungszeitWartezeit
Testumgebung
Wie eine Umgebung entsteht, wie lange das dauert und ob sie dem Produktionsstand entspricht.
BearbeitungszeitWartezeit
Freigabe
Welche Freigaben nötig sind, wer sie erteilt, wie lange sie liegen und welches Kriterium tatsächlich geprüft wird.
BearbeitungszeitWartezeit
Produktion
Der Weg live, das Vorgehen bei einem Fehler und die Zeit, bis der Zustand davor wiederhergestellt ist.
BearbeitungszeitWartezeit
Was hier bewusst fehlt, sind Zahlen: In einer echten Karte trägt jede Station gemessene Bearbeitungs- und Wartezeiten. Diese Zahlen gehören dem jeweiligen Auftraggeber, und wir veröffentlichen keine, die nicht freigegeben ist. Es steht also die Struktur hier, nicht der Inhalt eines fremden Projekts.
Ein Eintrag im Engpass-Backlog
Beispielhafter Eintrag — Aufbau, nicht Inhalt
- Ort im Lieferweg
- Die Station der Karte, an der die Arbeit tatsächlich stehen bleibt.
- BelegBeispiel ausstehend
- Die Messung oder Beobachtung, auf der der Befund beruht, mit Quelle und Zeitraum.
- Art des Engpasses
- Technisch, prozessual, organisatorisch oder eine Frage der Verantwortung — weil davon abhängt, wer ihn beseitigen kann.
- GeschäftswirkungBeispiel ausstehend
- Was der Engpass an Wartezeit, Lieferrisiko und gebundener Kapazität verursacht — als Richtung und Größenordnung, nie als versprochene Zahl.
- Aufwandsspanne
- Was das Beseitigen kostet — als Spanne, mit den Annahmen, unter denen sie gilt.
- Horizont
- Ob die Maßnahme in den ersten 30 Tagen, bis Tag 60 oder bis Tag 90 gehört — und was diesen Platz erzwingt.
- Verantwortliche Rolle
- Wer den Engpass beseitigen kann — benannt als Rolle, nicht als Person.
- Sicherheit
- Wie belastbar der Befund ist, und was fehlt, damit er belastbarer wäre.
Zwei Felder sind als ausstehend markiert. Dort steht im echten Bericht ein konkreter Befund mit einer gemessenen Zahl, und der bleibt hier leer, bis ein Auftraggeber die Veröffentlichung eines anonymisierten Beispiels freigegeben hat. Wir füllen sie nicht mit erfundenen Werten — das wäre genau die Art Beleg, die dieses Assessment widerlegen soll.
Was uns qualifiziert
Durchgeführt wird das Assessment von Matthias Bruns, Gründer von Appetizer Labs: 15+ Jahre in Software Engineering und technischer Führung, die letzten davon in Cloud-Native und Platform Engineering. Grundlage sind Projekte, in denen genau diese Fragen praktisch beantwortet wurden — technische Leitung verteilter Teams, Aufbau und Aufräumen von Liefersystemen, Plattform- und Architekturarbeit im Konzernumfeld.
Was hier bewusst fehlt, sind Vorher-nachher-Zahlen. Ein Assessment, das seine eigene Wirkung mit unbelegten Kennzahlen bewirbt, hätte die erste Regel gebrochen, die es selbst aufstellt. Prüfbar sind stattdessen die Projektmuster in den Referenzen und der öffentlich einsehbare Code.
Häufige Fragen
Ist das nicht einfach ein DORA-Assessment?
Nein. DORA-Kennzahlen sind ein Messinstrument, kein Befund: Sie sagen euch, dass ihr selten ausliefert, nicht warum. Wo die Zahlen vorliegen, nutzen wir sie; wo sie fehlen, ist das selbst ein Ergebnis. Der Bericht erklärt die Ursache und benennt die Stelle im Lieferweg, an der sie sitzt.
Wir messen unsere Durchlaufzeit nicht. Geht das trotzdem?
Ja, und das ist der häufigste Ausgangspunkt. Wir arbeiten dann mit dem, was da ist — Ticket-Historie, Pipeline-Läufe, Deployment-Verlauf, Vorfallsdokumentation — und vor allem mit dem gemeinsamen Abgehen des Lieferwegs. Im Bericht steht anschließend, welche wenigen Kennzahlen ihr ab sofort erhebt und wo heute schlicht keine Basislinie existiert.
Kommt am Ende raus, dass wir Kubernetes oder eine neue Pipeline brauchen?
Nur wenn die Belege dorthin führen. Wir gehen ohne vorab festgelegte Ursache hinein, und in der Praxis liegt der begrenzende Faktor mindestens genauso oft in einer Freigabe, einer Teamgrenze, einer fehlenden Entscheidung oder in zu viel gleichzeitig angefangener Arbeit. Ein Assessment, das die Antwort schon kennt, braucht ihr nicht zu kaufen.
Wie unterscheidet sich das vom Engineering Growth Assessment?
Dieses hier schaut auf den aktuellen Fluss: Wo wartet Arbeit, was kostet das, was beseitigt ihr als Nächstes. Das Engineering Growth Assessment schaut auf die Tragfähigkeit von Organisation und technischem System für die nächste Wachstumsstufe, über einen deutlich längeren Zeitraum. Wenn ihr euch nicht sicher seid, welches passt, klären wir das im Fit-Check — das ist einer der Gründe, warum es ihn gibt.
Wie viel Zeit kostet uns das?
Pro Gesprächspartner 45 bis 60 Minuten, dazu die begleitete Kartierung des Lieferwegs mit den beteiligten Teams und zwei gemeinsame Termine für Readout und Übergabe. Das Zusammentragen der Belege liegt erfahrungsgemäß bei einem halben Tag. Mehr fordern wir nicht an.
Bewertet ihr einzelne Teams oder Personen?
Nein, und wir liefern auch keine Grundlage dafür. Untersucht wird der Fluss der Arbeit durch euer System. Interviews sind vertraulich; im Bericht erscheinen Stationen, Rollen und Systeme, keine Namen. Wenn ein Befund nur mit Namen verständlich wäre, formulieren wir ihn um oder lassen ihn weg.
Was, wenn der Engpass gar nicht in der Technik liegt?
Dann steht das so im Bericht. Ein Engpass in Priorisierung, Freigabe oder Verantwortung ist ein genauso legitimes Ergebnis wie ein technischer — und häufig das unbequemere. Wir schreiben ihn trotzdem auf, weil ein Bericht, der nur das benennt, was wir selbst umsetzen könnten, sein Geld nicht wert ist.
Müssen wir danach mit euch weiterarbeiten?
Nein. Der Bericht ist so geschrieben, dass euer Team ihn allein umsetzen kann: Maßnahmen, Verantwortliche, Abhängigkeiten und Reihenfolge stehen drin. Wenn ihr Unterstützung wollt, gibt es Wege dafür — sie sind eine Option im Bericht, keine Bedingung.
Was passiert nach der Anfrage?
Innerhalb von zwei Arbeitstagen kommt eine Antwort mit zwei Terminvorschlägen für den 30-minütigen Fit-Check. Darin klären wir, welcher Lieferweg untersucht wird und ob dieses Format überhaupt das richtige ist. Danach bekommt ihr ein Festpreisangebot mit Zuschnitt und Zeitplan — oder die Empfehlung, es zu lassen.
~/appetizer-labs/fit-check
Delivery-Engpass besprechen
Beschreibt kurz, woran es bei euch hängt. Ihr bekommt eine Einschätzung, ob dieses Assessment zu eurer Situation passt — auch wenn die Antwort lautet, dass ihr es nicht braucht.
Noch nicht sicher, ob das der richtige Auftrag ist? Klärt es in einer Viertelstunde, mit dem Ingenieur, der die Arbeit später macht. Fit-Check buchen