Leistungen, die Risiko senken und Lieferung planbar machen.

Klar abgegrenzte Pakete mit definierten Deliverables - Audit, Sprint oder Retainer. Technik ist Kontext, Ergebnis ist Stabilität, Performance und Übergabefähigkeit.

Einkauf & Rahmen

Typische Situationen

Stabilisieren & Skalieren

  • Gewachsenes System: Performance-/Stabilitätsrisiken vor Releases
  • Viele Schnittstellen (REST/GraphQL/Legacy DB): Änderungen sind riskant
  • Datenflüsse/ETL sind langsam, intransparent oder fehleranfällig
  • Team-Mix aus Erfahrungsleveln: Standards, Guardrails und Onboarding fehlen

Womit starten wir am besten?

Angebote

Architecture & Integration Audit

typisch 4-6 Tage

Innerhalb von 4-6 Tagen eine belastbare, managementtaugliche Entscheidungsgrundlage für Weiterbetrieb, Investitionen oder bewusste De-Priorisierung (Stop-or-Go). Fokus: Transparente Risiken, wirtschaftlich relevante Prioritäten und klar abgegrenzte Handlungsoptionen - als unabhängige Prüfleistung ohne Implementierungsbindung.

Prüfung anfragen

Deliverables

  • Prüfbericht: Zusammenfassung der wesentlichen technischen und operativen Risiken mit klarer Einordnung ihrer Auswirkungen auf Betriebssicherheit, Release-Fähigkeit und Investitionsentscheidungen - inkl. priorisierter Handlungsempfehlungen, Risikomatrix (Eintrittswahrscheinlichkeit × Auswirkung) mit Ampellogik sowie transparent dokumentierten Annahmen und Grenzen der Prüfung.
  • Systemlandkarte: Verdichtete, managementtaugliche Architektur- und Integrationsübersicht als Grundlage für Risikoabschätzung, Budgetplanung und Reduktion von Personenabhängigkeiten.
  • Maßnahmen- und Entscheidungsplan: Klar priorisierter Entscheidungs- und Maßnahmenplan für die nächsten 2-4 Wochen - geeignet als Grundlage für Budgetfreigaben, interne Abstimmungen oder Stop-or-Go-Entscheidungen; inkl. Quick Wins und Aufwandseinschätzung in Klassen (S/M/L).

Vorgehen

  1. Auftaktgespräch: Klärung von Zielsetzung, Entscheidungsrahmen, betrachteten Systemgrenzen sowie Definition der fachlichen und inhaltlichen Abnahmekriterien.
  2. Analyse: Strukturierte, nachvollziehbare Prüfung von Architektur, Codebasis, Integrationen, Datenhaltung und Betriebsaspekten innerhalb des vereinbarten Untersuchungsumfangs - mit Fokus auf Entscheidungsrelevanz statt Vollständigkeit (u. a. Stichproben in Code/Configs, Sichtung vorhandener Betriebsdaten sowie kurze Interviews mit Betrieb/Entwicklung/Fachseite, sofern verfügbar).
  3. Ergebnis-Workshop: Gemeinsame Einordnung der Ergebnisse, Diskussion realistisch umsetzbarer Optionen sowie Ableitung einer abgestimmten Entscheidungsgrundlage für Management und Einkauf (inkl. Abnahme gegen Lieferliste und Abnahmekriterien).

Scope / Annahmen

  • Ein zentrales System oder eine klar abgegrenzte Hauptdomäne
  • Begrenzte Anzahl geschäftskritischer Schnittstellen oder Module im Fokus
  • Lesezugriff auf Repository sowie vorhandenes Monitoring und Logging, sofern vorhanden

Pricing

Modell: ergebnisorientierter Festpreis auf Basis eines klar definierten und begrenzten Untersuchungsumfangs

Anker

  • Das Audit ist eine einmalige, klar abgegrenzte Prüf- und Entscheidungsleistung mit definiertem Anfang und Ende
  • Der Durchführungsrahmen liegt typischerweise bei 4-6 Arbeitstagen, abhängig von Systemumfang und Komplexität
  • Weiterführende Leistungen (wie z.B. Delivery Sprint oder Retainer) werden bewusst separat und nur bei Bedarf beauftragt

Risikokontrolle

  • Gemeinsame Eingrenzung des Untersuchungsumfangs vor Projektstart zur eindeutigen Abgrenzung von Aufwand und Verantwortung
  • Explizit vereinbarte Abnahmekriterien als fachliche und inhaltliche Abnahmegrundlage
  • Keine offenen Zeit- oder Beratungsmandate: Die Leistung endet mit Lieferung der vereinbarten Ergebnisse

Das Audit dient der Absicherung geschäftskritischer Entscheidungen und der Reduktion operativer Risiken. Der Preis orientiert sich nicht an Stunden, sondern am Umfang, der Komplexität und der Relevanz der zu bewertenden Systeme. Ziel ist eine hohe Entscheidungs- und Investitionssicherheit bei klar begrenztem Aufwand. Das Audit ist bewusst als unabhängige Prüf- und Entscheidungsleistung konzipiert und schafft eine belastbare Grundlage für interne Freigaben, Budgetentscheidungen und weitere Beauftragungen - intern oder extern.

Risiken

Reduziert

  • Risiken in Releases und laufendem Betrieb
  • Intransparenz bei Stabilität, Performance und Abhängigkeiten
  • Abhängigkeit von Einzelpersonen und nicht dokumentiertem Wissen
  • Fehlentscheidungen bei Weiterentwicklung oder Modernisierung
  • Unklare Verantwortlichkeiten bei kritischen Systemen

Wie

  • Strukturierte Risikoübersicht mit Auswirkungen und Prioritäten
  • Identifikation kurzfristig wirksamer Maßnahmen mit überschaubarem Aufwand
  • Priorisierte Roadmap mit realistischen Umsetzungsannahmen
  • Definition technischer Leitplanken als Grundlage für kontrollierte Weiterentwicklung

Einkauf / Procurement

  • Untersuchungsumfang: Vor Projektstart eindeutig definiert (Systeme, Module, Zugänge)
  • Deliverables: Schriftlicher Prüfbericht, Systemlandkarte und priorisierter Maßnahmen- und Entscheidungsplan
  • Planbarkeit: Durchführung innerhalb von 4-6 Tagen, Festpreisoption bei klarer Abgrenzung; Abnahme gegen Lieferliste und Abnahmekriterien
  • Informationssicherheit: Bearbeitung bevorzugt in Kundensystemen; Datenexport nur nach Freigabe; DSGVO/AVV nach Bedarf
  • Mitwirkung: Benannte Ansprechpartner sowie Read-Access; kurze Interviews (z. B. Betrieb/Entwicklung/Fachseite) nach Verfügbarkeit zur Sicherung der Aussagekraft
  • Compliance: NDA vor Projektstart üblich, EVB-IT-nahe oder projektbezogene Vertragsmodelle möglich; keine Subunternehmer, keine Weitergabe von Leistungen.

Delivery Mandate

typisch 1-4 Wochen

Innerhalb von 1-4 Wochen wird ein klar abgegrenzter, produktionsrelevanter Veränderungsbedarf umgesetzt - mit dem Ziel, Risiken im Betrieb, bei Releases oder in kritischen Integrationen messbar zu reduzieren. Die Leistung schafft technische und operative Entlastung durch qualitätsgesicherte Umsetzung, nachvollziehbare Entscheidungen und eine saubere Übergabe.

Umsetzung abstimmen

Deliverables

  • Abnahmefähige Implementierung als PRs/Merges inkl. automatisierter Tests
  • Nachvollziehbare Entscheidungsdokumentation (ADRs/Decision-Log) für die umgesetzten Maßnahmen
  • Betriebs- und Übergabeunterlagen (Setup-Hinweise, relevante Betriebsnotizen, Übergabe-Session)

Vorgehen

  1. Gemeinsame Klärung von Ziel, Scope und Abnahmekriterien (Definition of Done) als verbindliche Startbedingung
  2. Umsetzung der vereinbarten Maßnahmen in kurzen, transparenten Feedbackschleifen innerhalb des definierten Umfangs
  3. Abschluss mit Review, Stabilisierung, Dokumentation und formaler Übergabe der Ergebnisse

Scope / Annahmen

  • Ein klar abgegrenztes, produktionsnahes System oder eine zentrale Domäne
  • Begrenzte Anzahl geschäftskritischer Integrationen, Module oder datenrelevanter Komponenten im Fokus
  • Zugriff auf relevante Repositories sowie notwendige Betriebsinformationen (z. B. Monitoring/Logs), sofern vorhanden

Pricing

Modell: ergebnisorientierter Festpreis oder klar begrenzter Zeitrahmen auf Basis eines eindeutig definierten Umsetzungsumfangs

Anker

  • Das Delivery Mandate ist eine einmalige, klar abgegrenzte Umsetzungsleistung mit definiertem Anfang und Ende
  • Der typische Umsetzungsrahmen liegt bei 1-4 Wochen, abhängig von Komplexität und Kritikalität der Änderungen
  • Weiterführende Leistungen (z. B. Retainer oder Betrieb) werden bewusst separat und nur bei Bedarf beauftragt

Risikokontrolle

  • Verbindlicher Scope-Schnitt und technische Abgrenzung vor Projektstart
  • Explizit vereinbarte Definition of Done als fachliche und technische Abnahmegrundlage
  • Festpreisoption bei klarer Abgrenzung von Verantwortung und Lieferumfang

Das Delivery Mandate dient der kontrollierten Umsetzung klar identifizierter Maßnahmen. Ziel ist maximale Planbarkeit, klare Abnahmefähigkeit und die bewusste Vermeidung offener Beratungs-, Sprint- oder Implementierungsmandate ohne Ende.

Risiken

Reduziert

  • Release-Risiken in produktionskritischen Systemen
  • Operative Unsicherheit bei Performance oder Stabilität
  • Abhängigkeit von nicht dokumentiertem Einzelwissen

Wie

  • Gezielte Umsetzung priorisierter Maßnahmen mit klarer Abgrenzung
  • Qualitätssicherung durch Tests und explizite Abnahmekriterien
  • Nachvollziehbare Entscheidungen als Dokumentation
  • Übergabefähige Ergebnisse statt implizitem Projektwissen

Einkauf / Procurement

  • Umsetzungsumfang: Vor Projektstart eindeutig definiert (Systeme, Module, technische Abgrenzung)
  • Deliverables: Abnahmefähige Implementierung (PRs/Merges), Tests, Entscheidungsdokumentation (ADRs) sowie Übergabe- und Betriebshinweise
  • Planbarkeit: Fester Umsetzungszeitraum (typisch 1-4 Wochen), Festpreisoption bei klarer Abgrenzung
  • Verantwortung: Umsetzungsverantwortung innerhalb des vereinbarten Scopes; kein Betriebs- oder Reaktionsmandat über die Übergabe hinaus
  • Compliance: NDA vor Projektstart üblich, EVB-IT-nahe oder projektbezogene Vertragsmodelle nach Absprache; keine Subunternehmer

Hinweise

  • Das Delivery Mandate ersetzt keinen Retainer und begründet keine dauerhafte Betriebs- oder Reaktionsverantwortung.
  • Ein Retainer oder Build-&-Operate kann bei Bedarf separat vereinbart werden.

Retainer - Engineering Partner

laufend im vereinbarten monatlichen Kapazitäts- und Verantwortungsrahmen (z. B. 1-2 Tage/Woche); Anpassung oder Kündigung mit definierter Frist (z. B. 30 Tage zum Monatsende)

Technische Stewardship für ein geschäftskritisches System im klar definierten Verantwortungsrahmen: planbar, nachvollziehbar gesteuert und mit kontinuierlicher Reduktion von Betriebs- und Änderungsrisiken. Ziel ist Verlässlichkeit, Steuerbarkeit und dokumentierte Entscheidungsfähigkeit - kein Body-Leasing. Produkt- und Betriebsverantwortung (Owner) verbleibt beim Auftraggeber; ich übernehme technische Leitung, Umsetzung und Risikoführung innerhalb der vereinbarten Systemgrenzen.

Retainer-Verfügbarkeit prüfen

Deliverables

  • Priorisierte Umsetzung vereinbarter Maßnahmen zur Stabilisierung, Weiterentwicklung oder technischen Entlastung (abnahmefähig, innerhalb definierter Systemgrenzen)
  • Kontinuierlicher Abbau technischer und operativer Risiken (Tech Debt, Performance-Engpässe, Betriebs-/Release-Risiken) auf Basis eines fortlaufend gepflegten Risikoregisters (Ampellogik + Trend)
  • Entscheidungsdokumentation: Decision Log/ADRs inkl. Konsequenzen und Leitplanken, um Entscheidungen revisions- und übergabefähig zu machen
  • Betriebsrelevante Artefakte: Runbooks, relevante Betriebsnotizen, Übergabeunterlagen (Zugänge/Flows/Systemgrenzen/Ansprechpartner), damit Wissen nicht an Personen hängt
  • Monatliches Steering-Pack (Leistungsnachweis + Steuerung): 1-seitiger Status, Top-Risiken (Ampel), Decision-Log-Auszug, Prioritäten/Nächste Schritte inkl. Abnahmekriterien
  • Optional (nur bei separater Vereinbarung): Incident/Post-Incident Review inkl. Maßnahmenableitung und Aktualisierung der Runbooks (kein 24/7 ohne explizites Zusatzmandat)

Vorgehen

  1. Onboarding: Systemkontext, Zielbild, Systemgrenzen, Abnahmekriterien, Zugänge sowie klare Definition von Verantwortungsbereich und expliziten Ausschlüssen (inkl. Entscheidungswege/Eskalation)
  2. Steuerungsrhythmus: Regelmäßige Priorisierung und Planung in abgestimmten Zyklen (z. B. wöchentlich/14-tägig) mit transparenten Status-Updates und sichtbarer Backlog-/Prioritätenlage
  3. Governance: Risiken werden fortlaufend geführt (Risikoregister mit Ampellogik); Entscheidungen werden nachvollziehbar dokumentiert (Decision Log/ADRs) und bei Bedarf eskaliert
  4. Qualitäts- und Stabilitätssteuerung: Kontinuierliche Bewertung anhand weniger, vereinbarter Kriterien (z. B. Release-Readiness/Checklisten, Performance-Baselines, Runbook-Abdeckung)
  5. Monatsabschluss: Steering-Pack als verbindlicher Nachweis und Steuerungsgrundlage; ggf. bewusste Anpassung von Umfang/Kapazität (Change des Retainer-Rahmens) statt impliziter Ausweitung

Scope / Annahmen

  • Ein klar definiertes, geschäftskritisches System oder eine Hauptdomäne (Systemgrenzen sind vor Start schriftlich festgelegt)
  • Technischer Fokus auf vereinbarte Kernkomponenten und Integrationen; Änderungen außerhalb des Scopes nur nach expliziter Anpassung
  • Notwendige Zugänge zu Code, CI/CD und Betriebsinformationen im vereinbarten Rahmen
  • Benannte Ansprechpartner (fachlich/technisch) sowie ein klarer Entscheidungsweg für Prioritäten/Trade-offs
  • Betrieb/On-Call verbleibt beim Auftraggeber oder bestehendem Betriebspartner, sofern nicht ausdrücklich anders vereinbart

Pricing

Modell: monatlicher Retainer mit definiertem Kapazitäts- und Verantwortungsrahmen (Mandat); optional erweiterbar um separat beauftragte Reaktions-/Incident-Leistungen

Anker

  • Der Retainer ist kein Stunden- oder Body-Leasing-Modell, sondern ein steuerbares Mandat mit definierter Verantwortung innerhalb klarer Systemgrenzen
  • Die monatliche Beauftragung erfolgt mit klar definiertem Umfang, expliziten Ausschlüssen und nachvollziehbarer Steuerung (Prioritäten, Abnahmekriterien, Steering-Pack)
  • Anpassungen des Umfangs erfolgen bewusst, nachvollziehbar und transparent (Änderung des Retainer-Rahmens statt stiller Scope-Expansion)
  • Nicht genutzte Kapazität verfällt grundsätzlich zugunsten der Planbarkeit; Abweichungen nur nach expliziter Vereinbarung
  • Kein 24/7 / keine Rufbereitschaft ohne separate, explizite Vereinbarung (Add-on/Operate-Modell)

Risikokontrolle

  • Klare Definition von Verantwortungsbereich, Systemgrenzen, Entscheidungswegen und Nicht-Leistungen vor Start
  • Regelmäßige Überprüfung von Prioritäten, Nutzen und Rahmenbedingungen (monatliches Steering-Pack als Nachweis- und Steuerungsinstrument)
  • Kündbarkeit bzw. Anpassung des Retainers mit definierter Frist (z. B. 30 Tage zum Monatsende); Mehrbedarf wird als Scope-/Kapazitätsanpassung oder separates Mandat (Audit/Sprint) vereinbart

Der Retainer dient der planbaren Reduktion technischer und operativer Risiken sowie der kontinuierlichen Verbesserung geschäftskritischer Systeme. Im Vordergrund stehen Verlässlichkeit, Steuerbarkeit und dokumentierte Entscheidungen - nicht maximale Auslastung. Reaktions-/Incident-Leistungen sind optional und werden - falls gewünscht - separat und explizit geregelt.

Risiken

Reduziert

  • Betriebs- und Release-Risiken in geschäftskritischen Systemen
  • Entscheidungsunsicherheit bei Weiterentwicklung und Priorisierung
  • Abhängigkeit von implizitem Wissen oder einzelnen Personen
  • Scope-Drift und unkontrollierte Verantwortungs-Ausweitung (durch klare Systemgrenzen und Change-Logik)

Wie

  • Kontinuierliche Risiko- und Prioritätensicht als Entscheidungsgrundlage (Risikoregister mit Ampellogik + Trend) und monatliches Steering-Pack
  • Nachvollziehbare Entscheidungen und dokumentierte technische Leitplanken (Decision Log/ADRs)
  • Schrittweise Verbesserung mit klaren Abnahmekriterien und überprüfbaren Ergebnissen
  • Wissenssicherung über Runbooks/Übergabeunterlagen, um Personenabhängigkeit systematisch zu reduzieren

Einkauf / Procurement

  • Mandat: Technische Stewardship im klar definierten Rahmen - kein Projekt, kein Body Leasing
  • Abgrenzung: Kein Ersatz für ein Audit oder ein Delivery Mandate (Sprint); diese Leistungen werden separat beauftragt
  • Planbarkeit: Monatlicher Retainer mit definiertem Umfang; Anpassung/Kündigung z. B. 30 Tage zum Monatsende
  • Leistungsnachweis/Steuerung: Monatliches Steering-Pack (Status, Risikoregister/Ampel, Decision-Log-Auszug, Prioritäten & Abnahmekriterien)
  • Verantwortung: Produkt- und Betriebsverantwortung (Owner) verbleibt beim Auftraggeber; Umsetzung/Entscheidungsdokumentation/Risikoführung innerhalb vereinbarter Systemgrenzen
  • Incident/Support: Keine 24/7 Rufbereitschaft ohne separate, explizite Vereinbarung (optional als Add-on regelbar)
  • Informationssicherheit: Bearbeitung bevorzugt in Kundensystemen; Datenexport nur nach Freigabe; NDA üblich; DSGVO/AVV nach Bedarf
  • Compliance: EVB-IT-nahe oder projektbezogene Vertragsmodelle nach Absprache
  • Leistungserbringung: Keine Subunternehmer; Leistung persönlich (sofern nicht anders vereinbart)

Hinweise

  • Der Retainer ist kein „Projekt ohne Ende“, sondern ein steuerbares Mandat mit klaren Grenzen, mess-/sichtbarer Steuerung (Steering-Pack) und definierter Anpassungslogik.
  • Audit und Delivery Mandate bleiben eigenständige, klar abgegrenzte Produkte und sind nicht automatisch Bestandteil des Retainers.
  • Kontinuität ist Teil der Leistung: Runbooks, Decision-Log/ADRs und Übergabeunterlagen reduzieren Personenabhängigkeit und sichern die Übergabefähigkeit.
  • Reaktions-/Incident-Leistungen sind optional und werden - falls gewünscht - ausdrücklich separat vereinbart (Zeiten, Reaktionsfenster, Kommunikationsweg, Post-Incident Review).

Engineering Governance Mandate

1-2 Tage Workshop + optionale, befristete Einführungssicherung

Ein einmaliges, formell abnehmbares Governance-Mandat zur Etablierung eines verbindlichen Entscheidungs- und Kontrollrahmens für Releases und technische Änderungen. Ziel ist höhere Management-Steuerbarkeit (delegierbare Entscheidungen mit klaren Eskalationswegen), reduzierte Betriebs- und Revisionsrisiken sowie weniger Abhängigkeit von Schlüsselpersonen. Ergebnis sind dokumentierte, prüfbare Standards und Abnahmekriterien, die im Alltag als verbindlicher Referenzrahmen gelten - abgeleitet an realen Beispielen aus Ihrem bestehenden System, jedoch ohne Audit-Charakter und ohne Implementierungsbindung.

Termin abstimmen

Deliverables

  • Governance-Playbook: verbindliche Leitplanken für Architektur, APIs, Reviews, Testing und Performance - als Referenzrahmen zur Standardisierung von Entscheidungen, Reduktion von Varianz und Folgekosten
  • Verbindliche Qualitäts- und Abnahmekriterien: klare Go/No-Go-Kriterien für Releases und Änderungen inkl. prüfbarer Nachweise (Evidence) - als Grundlage für Freigaben, Übergaben und Compliance
  • Decision Rights (RACI light) inkl. Eskalationslogik: eindeutig geklärte Entscheidungs-, Prüf- und Freigaberechte - damit Delegation möglich ist, ohne Kontrollverlust im Management
  • Management Summary (1 Seite): Zielbild, Kontrollrahmen, Entscheidungslogik, Eskalationswege, Annahmen/Grenzen, nächste Schritte - geeignet für Management/Einkauf/Recht
  • Priorisierter Maßnahmen- und Entscheidungsplan: nächste Schritte in sinnvoller Reihenfolge nach Risiko- und Werthebel - anschlussfähig an interne Umsetzung oder separate Beauftragung (ohne Lock-in)
  • Optional: zeitlich und inhaltlich strikt begrenzte Einführungssicherung (Implementation Assurance) zur kontrollierten Etablierung der vereinbarten Standards

Vorgehen

  1. Gate 0 (Vorabklärung): Zielbild, Systemgrenzen, Stakeholder, Entscheidungs- und Freigaberahmen sowie Abnahmekriterien definieren (keine Vollanalyse, kein Audit) - damit Management, Einkauf und Engineering dieselben Steuerungsgrößen nutzen
  2. Gate 1 (Mandats-Workshop 1-2 Tage): Ableitung verbindlicher Leitplanken sowie Qualitäts-/Abnahmekriterien anhand ausgewählter realer Code-, Architektur- oder Release-Beispiele - Fokus: Kontrollierbarkeit, Prüfbarkeit, Delegierbarkeit, Eskalationsfähigkeit und Alltagstauglichkeit
  3. Gate 2 (Dokumentation & formale Abnahme): Lieferung von Playbook, Decision Rights, Abnahmekriterien und priorisiertem Plan; Abnahme gegen Lieferliste und Abnahmekriterien - damit das Ergebnis verbindlich gilt und nicht als Empfehlung verpufft

Scope / Annahmen

  • Ein klar abgegrenztes System oder eine Hauptdomäne
  • Fokus auf ausgewählte, geschäftskritische Schnittstellen oder Module
  • Zugriff auf Code und relevante Artefakte zur Ableitung praxistauglicher, überprüfbarer Standards
  • Benannte Ansprechpartner für Engineering, Betrieb und (falls erforderlich) Freigabe/Compliance - zur Sicherstellung delegierbarer Decision Rights

Pricing

Modell: Festpreis für den Workshop; optionale Einführungssicherung separat vereinbart

Anker

  • Einmaliges Governance-Mandat mit definiertem Anfang und Ende (abnahmefähiges Ergebnis statt Ergebnisoffenheit)
  • Typischer Umfang: 1-2 Workshoptage inkl. Dokumentation und formaler Abnahme
  • Kein offenes Beratungs-, Trainings- oder Begleitmandat

Risikokontrolle

  • Klare Abgrenzung von Prüfleistungen (Audit) und Umsetzungsleistungen (Delivery Sprint) - verhindert Scope-Drift und Haftungsdiffusion
  • Explizit definierter Lieferumfang und Abnahmekriterien (inkl. Lieferliste) als Vertrags- und Steuerungsgrundlage für Management/Einkauf
  • Prüfbarkeit: Abnahmekriterien werden so formuliert, dass sie als Evidence/Checkliste im Release-Prozess nutzbar sind (nicht nur als Leitbild)
  • Optionale Einführungssicherung zeitlich und inhaltlich strikt begrenzt (Form, Termine, Themen, Ende automatisch) - Risikominimierung ohne Dauerbindung

Der Auftrag etabliert einen delegierbaren, prüfbaren technischen Kontrollrahmen (Leitplanken + Abnahmekriterien + Decision Rights). Er ist bewusst kein Audit und keine Umsetzung - sondern die verbindliche Grundlage, um Releases, Standards und technische Entscheidungen managementtauglich zu steuern und revisionssicher zu begründen.

Risiken

Reduziert

  • Inkonsistente technische Entscheidungen (und daraus entstehende Folgekosten)
  • Steigende Release- und Betriebsrisiken durch fehlende oder nicht überprüfbare Standards
  • Abhängigkeit von implizitem Teamwissen und Schlüsselpersonen
  • Eskalationen zwischen IT, Fachbereich und Betrieb durch unklare Abnahme- und Entscheidungslogik
  • Revisions- und Haftungsrisiken durch nicht dokumentierte oder nicht delegierbare Freigaben

Wie

  • Verbindlicher Referenzrahmen (Playbook) statt Einzelfalllösungen - reduziert Varianz und macht Qualität systematisch prüfbar
  • Explizite Qualitäts- und Abnahmekriterien als Steuerungsinstrument (Go/No-Go, Übergaben, Freigaben) inkl. Evidence-Logik
  • Geklärte Decision Rights inkl. Eskalationslogik - Entscheidungen werden delegierbar, ohne dass Management Steuerbarkeit verliert
  • Formale Abnahme gegen Lieferliste - Ergebnis erhält verbindlichen Status und ist intern zitier- und durchsetzbar
  • Klare Anschlussfähigkeit an weitere Maßnahmen ohne Lock-in (interne Umsetzung oder separate Beauftragung)

Einkauf / Procurement

  • Leistungsart: einmaliges Governance-Mandat (Mandats-Workshop) mit definiertem Umfang, Lieferliste und formaler Abnahme
  • Deliverables: Governance-Playbook, Qualitäts-/Abnahmekriterien (Release Control), Decision Rights (RACI light) inkl. Eskalationslogik, priorisierter Maßnahmen- und Entscheidungsplan, Management Summary (1 Seite)
  • Abgrenzung: kein Audit, keine Umsetzung, keine offene Trainings- oder Dauerbegleitung; keine Implementierungsbindung
  • Planbarkeit: kurzer Durchführungszeitraum, Festpreis möglich; optional befristete Einführungssicherung separat
  • Compliance: NDA üblich, keine Subunternehmer

Hinweise

  • Das Mandat eignet sich als verbindlicher Entscheidungs- und Kontrollrahmen vor einem Delivery Sprint oder zur Operationalisierung von Audit-Ergebnissen (Standards werden abnahme- und delegationsfähig gemacht).
  • Die Verantwortung für Umsetzung oder Betrieb entsteht ausschließlich durch separate Beauftragung.

Build & Operate

Initial Release typ. 2-8 Wochen + Betrieb im definierten Rahmen

Ein phasenbasiertes Mandat zur kontrollierten Lieferung und - falls gewünscht - definierten Betriebsbegleitung. Jede Phase ist separat beauftragbar, hat klare Abnahmekriterien und endet mit einer formalen Abnahme. Verantwortung wird jeweils explizit übernommen, dokumentiert und sauber übergeben. Betrieb erfolgt bevorzugt im Kunden-Account; Steuerbarkeit und Ownership verbleiben beim Auftraggeber. Ein Exit ist jederzeit möglich und wird durch ein definiertes Transition-Paket unterstützt.

Build & Operate anfragen

Deliverables

  • Discovery-Paket: Zielbild, Scope-Abgrenzung, Risiko- und Annahmenliste, priorisierte Roadmap (abnahmefähig)
  • Build-Lieferung: abgenommene Implementierung (Frontend/Backend) inkl. Tests, ADRs und technischer Dokumentation
  • Go-Live-Paket: reproduzierbares Deployment, CI/CD-Konfiguration, Monitoring & Alerting (definierte Mindestabdeckung), Logging, Backup- und Rollback-Konzept inkl. dokumentiertem Restore-Nachweis
  • Operate-Rahmen (separater Betriebs-/Wartungsretainer): Servicekatalog mit Servicezeiten, Incident-Klassen (P1-P3) und Reaktionszielen, Triage- und Kommunikationswegen, Change-Verfahren für Enhancements (Change Request / Mini-Scope-Schnitt), Patch-/Update-Policy inkl. Security-Handling (z. B. kritische CVEs), klaren Ausschlüssen und regelmäßiger Rahmenprüfung
  • Exit- & Transition-Paket: Runbooks, Architektur- und Betriebsübersicht, Zugriffs- und Berechtigungsliste, Secrets-Rotation-Plan, Übergabe-Session; optional befristete Shadowing-Phase

Vorgehen

  1. Phase 1 - Discovery & Scope-Festlegung: Zielbild, Systemgrenzen, Risiken, Abnahmekriterien
  2. Phase 2 - Build: Umsetzung innerhalb des vereinbarten Scopes inkl. formaler Abnahme
  3. Phase 3 - Operate: Betrieb im definierten Rahmen mit Servicekatalog, regelmäßiger Überprüfung von Nutzen/Risiken sowie klaren Verantwortlichkeiten und Exit-Option

Scope / Annahmen

  • Ein klar abgegrenztes System oder Produkt mit definierter Hauptdomäne
  • Begrenzte, vorab benannte Schnittstellen oder Module im Fokus
  • Zugriff auf relevante Repositories sowie notwendige Betriebsinformationen (Monitoring/Logs), sofern Bestandteil des vereinbarten Scopes

Pricing

Modell: phasenbasiert und ergebnisorientiert mit separater Beauftragung von Discovery, Build und Operate

Anker

  • Discovery: klar abgegrenzte Vorleistung zur Entscheidungs- und Scope-Festlegung
  • Build: Umsetzung als Festpreis oder klar begrenzter Zeitrahmen nach Scope-Schnitt
  • Operate: separater Betriebs-/Wartungsretainer mit Servicekatalog (Servicezeiten, Reaktionsziele, Ausschlüsse) und definiertem Verantwortungsrahmen

Risikokontrolle

  • Formale Scope- und Haftungsabgrenzung vor jeder Phase
  • Explizite Abnahmekriterien je Phase
  • Operate nur nach erfolgreicher Build-Abnahme
  • Operate mit definierten Servicezeiten/Reaktionszielen; 24/7 und Bereitschaft nur bei separater Vereinbarung
  • Exit- und Übergabemechanik als fester Bestandteil (Transition-Paket)

Build & Operate ist ein bewusst strukturiertes Mandat mit klaren Entscheidungs- und Exit-Punkten je Phase (Discovery, Build, Operate) sowie prüfbaren Betriebs- und Übergabeartefakten. Es ist kein Full-Service-Versprechen, sondern ein kontrolliertes Mandat mit bewusst gesetzten Grenzen.

Risiken

Reduziert

  • Unkontrollierte Release-Risiken
  • Intransparenz bei Stabilität und Betrieb
  • Personenabhängigkeiten im Betrieb
  • Vendor-Lock-in-Risiken durch fehlende Übergabefähigkeit

Wie

  • Explizite Risiko- und Annahmenliste
  • Priorisierte, wirtschaftlich begründete Roadmap
  • Definierte technische Leitplanken (Guardrails)
  • Abnahmefähige Betriebs- und Übergabeartefakte inkl. Runbooks und Restore-Nachweis
  • Servicekatalog im Operate-Rahmen (Servicezeiten, Incident-Klassen, Reaktionsziele, Change-Verfahren, Patch-/Security-Handling)
  • Explizites Exit- & Transition-Paket zur kontrollierten Übergabe

Einkauf / Procurement

  • Leistungsmodell: Phasenbasiertes Mandat (Discovery / Build / Operate) mit separater Beauftragung und formaler Abnahme
  • Abgrenzung: Keine Ressourcenüberlassung; keine Betriebsverantwortung außerhalb des vereinbarten Servicekatalogs
  • Planbarkeit: Festpreisoptionen bei klarer Abgrenzung; Operate als Retainer mit Servicezeiten, Reaktionszielen und definierten Ausschlüssen
  • Compliance: NDA vor Projektstart üblich; EVB-IT-nahe oder projektbezogene Vertragsmodelle möglich
  • Betrieb: Bevorzugt im Kunden-Account; Ownership verbleibt beim Auftraggeber; Exit/Transition über definiertes Übergabepaket
  • Kontinuität: Vertretungs-/Ausfallregelung im Operate-Rahmen nach Vereinbarung (Kommunikationswege, geplante Abwesenheiten, optional Backup-Engineer)

Hinweise

  • Build & Operate bündelt Discovery, Delivery und - falls erforderlich - Betrieb unter einem einheitlichen Governance-Rahmen; jede Phase bleibt eigenständig beauftrag- und abnahmefähig.
  • Nach Abschluss jeder Phase kann das Mandat bewusst beendet oder fortgeführt werden; ein Wechsel zu Audit, Delivery Mandate oder Retainer ist jederzeit möglich.
  • Operate ist bewusst als klar begrenzter Servicekatalog gestaltet (Servicezeiten/Reaktionsziele/Ausschlüsse), um Steuerbarkeit und Einkaufbarkeit zu maximieren.

Verantwortung & Übergabe

Was Sie bekommen

  • Lieferung mit artefaktbasierter Nachvollziehbarkeit: PRs, Tests, ADRs
  • Betriebsrelevantes Wissen als Runbooks
  • Übergabe-Session + Next-Steps Plan

Was ich dafür brauche

  • Klare Ansprechpartner + Entscheidungen in <48h
  • Zugang zu Repo/CI/Monitoring
  • Scope-Schnitt + Definition of Done als Startbedingung

FAQ

Arbeiten Sie als Freelancer oder als Dienstleister?

Als Dienstleister mit klaren Paketen (Audit/Sprint/Retainer/Workshop/Build & Operate) und definierten Deliverables - damit Ergebnisse intern nutzbar bleiben.

Übernehmen Sie auch Hosting/Betrieb?

Ja - im Build & Operate oder Retainer. Bevorzugt im Kunden-Account (Ownership bleibt bei Ihnen). Alternativ gemanagt nach Vereinbarung.

Wie stellen Sie Release-Qualität sicher?

Über Definition of Done, Reviews, Tests, nachvollziehbare Entscheidungen (ADR/Decision-Log) und Runbooks - Qualität ist Teil des Lieferumfangs.

Remote / vor Ort?

Primär remote. Vor Ort nach Absprache (z.B. Kickoff/Workshops/Übergabe).

Festpreis möglich?

Für klar abgegrenzte Reviews und Sprints: ja (nach Scope-Schnitt).

Zusammenarbeit & Einkauf

Arbeiten Sie über Rahmenverträge oder Preferred Supplier?

Ja, eine Einbindung über bestehende Vertragsmodelle ist nach Absprache möglich.

Ist eine NDA vor Projektstart möglich?

Ja, NDAs sind üblich und vor Projektstart möglich.

Gibt es Subunternehmer oder Offshore-Anteile?

Nein. Leistungen werden persönlich erbracht. Abweichungen nur nach expliziter Abstimmung.

Wie sieht die Abrechnung aus?

Festpreise bei klar abgegrenzten Leistungen, Retainer als monatlicher Rahmen. Details nach Scope-Schnitt.

Erstgespräch (20 Min) - wir klären Einstieg, Scope und den schnellsten Weg zum Ergebnis.

Commercials & Rahmenbedingungen

Die folgenden Punkte beschreiben übliche Rahmenbedingungen aus Enterprise-Projekten. Details werden projektspezifisch abgestimmt.

Beauftragung

  • Direktbeauftragung oder über Rahmenvertrag möglich
  • Einbindung über bestehende Lieferantenmodelle nach Absprache

Vertrag & Recht

  • NDA vor Projektstart üblich und möglich
  • Projektverträge oder EVB-IT-nahe Modelle nach Absprache

Abrechnung & Zahlung

  • Festpreis bei klar abgegrenzten Reviews/Sprints möglich
  • Retainer i. d. R. monatlich, mit definierter Kapazität
  • Zahlungsziel typischerweise 14-30 Tage

Reise & Vor-Ort

  • Primär remote
  • Vor-Ort-Termine (Kickoff, Workshop, Übergabe) nach Absprache

Zusammenarbeit

  • Bevorzugt direkte Zusammenarbeit mit IT-/Engineering-Verantwortlichen
  • Einkauf und Recht frühzeitig eingebunden