Readiness-Review

Finden Sie heraus, welcher Track zu Ihrem Projekt passt, bevor jemand einen Preis nennt.

Warum am Anfang eine Readiness-Review steht

Ein Principal Architect erklärt ein Projekt nicht für „nicht bereit“, sondern prüft es in einer kostenlose 48-stündige Readiness-Review gegen sechs objektive Engineering-Kriterien, die Definition of Ready.

Das Ergebnis entscheidet, wie die Arbeit beginnt. Ein Projekt mit klarem Umfang erhält ein verbindliches Angebot, eine Idee ohne Spezifikation geht zuerst durch das Blueprint Studio, und ein laufendes System, das gerettet oder integriert werden muss, bekommt eine Diagnose, bevor jemand einen Preis festlegt.

Prüfen Sie Ihr Projekt

Beantworten Sie pro Dimension eine Frage und danach eine zu einem laufenden System. Die Prüfung schlägt einen Track vor und übernimmt Ihre Antworten in das Anfrageformular, sodass die Prüfung darauf aufsetzt.

Projekt prüfen
Readiness-Dimension	Bereit für Track A	Deutet auf Track B
Funktionaler Umfang und Nutzerabläufe	Nutzerrollen, Workflows, Geschäftsregeln und Sonderfälle sind in einem Anforderungsdokument oder einer RFP dokumentiert.	Nur ein übergeordnetes Ziel, etwa ein individuelles CRM, ein Bürgerportal oder eine Super-App, ohne Abläufe auf Bildschirmebene.
Technologie-Stack und Hosting	Zielumgebung in Cloud oder On-Premises, Datenbankarchitektur und Laufzeit-Stack sind ausgewählt und validiert.	Cloud oder On-Premises, Bauen oder Kaufen (Odoo oder SAP gegenüber Individualsoftware) oder die Wahl des Sprachmodells sind noch offen.
Integrationsgrenzen	Jede Drittanbieter-API, jedes ERP-Modul (SAP, Oracle), jede Bankschnittstelle (ISO 20022) und jeder POS-Endpunkt ist erfasst.	Altsysteme existieren, aber ihre APIs, Datenschemata oder Middleware-Anforderungen wurden noch nicht geprüft.
Daten- und KI-Bereitschaft	Datenquellen, Schemata, Volumina und Regeln für die Zugriffskontrolle sind erfasst.	Unstrukturierte Dokumente oder isolierte Datenbanken brauchen zuerst eine Prüfung von Datenqualität, Datenherkunft und KI-Bereitschaft.
Sicherheits- und regulatorische Anforderungen	Die geltenden Vorgaben (ZATCA, PINT-AE, EU-KI-Verordnung, DORA, PDPL, Post-Quanten-Kryptografie) und die Regeln zum Datenstandort sind festgelegt.	Grenzüberschreitende Datenresidenz, Verschlüsselungsstandards oder die nationale Compliance-Freigabe sind noch unklar.
Abnahme- und SLA-Kriterien	Abnahmetests, Lastziele (Transaktionen pro Sekunde und Latenz) und Verfügbarkeits-SLAs sind definiert.	Noch keine messbare Definition of Done, kein Lastziel und keine Betriebsverantwortung nach dem Start.

Bereit für Track A

Funktionaler Umfang und Nutzerabläufe: Nutzerrollen, Workflows, Geschäftsregeln und Sonderfälle sind in einem Anforderungsdokument oder einer RFP dokumentiert.
Technologie-Stack und Hosting: Zielumgebung in Cloud oder On-Premises, Datenbankarchitektur und Laufzeit-Stack sind ausgewählt und validiert.
Integrationsgrenzen: Jede Drittanbieter-API, jedes ERP-Modul (SAP, Oracle), jede Bankschnittstelle (ISO 20022) und jeder POS-Endpunkt ist erfasst.
Daten- und KI-Bereitschaft: Datenquellen, Schemata, Volumina und Regeln für die Zugriffskontrolle sind erfasst.
Sicherheits- und regulatorische Anforderungen: Die geltenden Vorgaben (ZATCA, PINT-AE, EU-KI-Verordnung, DORA, PDPL, Post-Quanten-Kryptografie) und die Regeln zum Datenstandort sind festgelegt.
Abnahme- und SLA-Kriterien: Abnahmetests, Lastziele (Transaktionen pro Sekunde und Latenz) und Verfügbarkeits-SLAs sind definiert.

Deutet auf Track B

Funktionaler Umfang und Nutzerabläufe: Nur ein übergeordnetes Ziel, etwa ein individuelles CRM, ein Bürgerportal oder eine Super-App, ohne Abläufe auf Bildschirmebene.
Technologie-Stack und Hosting: Cloud oder On-Premises, Bauen oder Kaufen (Odoo oder SAP gegenüber Individualsoftware) oder die Wahl des Sprachmodells sind noch offen.
Integrationsgrenzen: Altsysteme existieren, aber ihre APIs, Datenschemata oder Middleware-Anforderungen wurden noch nicht geprüft.
Daten- und KI-Bereitschaft: Unstrukturierte Dokumente oder isolierte Datenbanken brauchen zuerst eine Prüfung von Datenqualität, Datenherkunft und KI-Bereitschaft.
Sicherheits- und regulatorische Anforderungen: Grenzüberschreitende Datenresidenz, Verschlüsselungsstandards oder die nationale Compliance-Freigabe sind noch unklar.
Abnahme- und SLA-Kriterien: Noch keine messbare Definition of Done, kein Lastziel und keine Betriebsverantwortung nach dem Start.

01Funktionaler Umfang und Nutzerabläufe

Nutzerrollen, Workflows, Geschäftsregeln und Sonderfälle sind in einem Anforderungsdokument oder einer RFP dokumentiert.Nur ein übergeordnetes Ziel, etwa ein individuelles CRM, ein Bürgerportal oder eine Super-App, ohne Abläufe auf Bildschirmebene.

02Technologie-Stack und Hosting

Zielumgebung in Cloud oder On-Premises, Datenbankarchitektur und Laufzeit-Stack sind ausgewählt und validiert.Cloud oder On-Premises, Bauen oder Kaufen (Odoo oder SAP gegenüber Individualsoftware) oder die Wahl des Sprachmodells sind noch offen.

03Integrationsgrenzen

Jede Drittanbieter-API, jedes ERP-Modul (SAP, Oracle), jede Bankschnittstelle (ISO 20022) und jeder POS-Endpunkt ist erfasst.Altsysteme existieren, aber ihre APIs, Datenschemata oder Middleware-Anforderungen wurden noch nicht geprüft.

04Daten- und KI-Bereitschaft

Datenquellen, Schemata, Volumina und Regeln für die Zugriffskontrolle sind erfasst.Unstrukturierte Dokumente oder isolierte Datenbanken brauchen zuerst eine Prüfung von Datenqualität, Datenherkunft und KI-Bereitschaft.

05Sicherheits- und regulatorische Anforderungen

Die geltenden Vorgaben (ZATCA, PINT-AE, EU-KI-Verordnung, DORA, PDPL, Post-Quanten-Kryptografie) und die Regeln zum Datenstandort sind festgelegt.Grenzüberschreitende Datenresidenz, Verschlüsselungsstandards oder die nationale Compliance-Freigabe sind noch unklar.

06Abnahme- und SLA-Kriterien

Abnahmetests, Lastziele (Transaktionen pro Sekunde und Latenz) und Verfügbarkeits-SLAs sind definiert.Noch keine messbare Definition of Done, kein Lastziel und keine Betriebsverantwortung nach dem Start.

07Gibt es ein laufendes System, das ausfällt, nicht dokumentiert ist oder integriert werden muss?

Zum Beispiel eine Plattform, die ein früherer Anbieter halbfertig hinterlassen hat, oder ein 10 Jahre altes ERP, das an ZATCA Phase 2 und ISO 20022 angebunden werden soll.

Ja: Ein bestehendes System fällt aus, ist nicht dokumentiert oder muss integriert werdenNein: Das Projekt ist neu, oder seine Systeme sind in gutem Zustand

Beantworten Sie alle Fragen, um den vorgeschlagenen Track zu sehen.

Fragen und Antworten

Ist der Vorschlag des Selbsttests verbindlich?

Nein. Er ist ein Ausgangspunkt für das Gespräch. Ein Principal Architect bestätigt den Track in der kostenlose 48-stündige Readiness-Review, nachdem er Ihre Unterlagen mit Ihnen durchgegangen ist.

Auf diese Frage verlinken

Was kostet die Readiness-Review?

Nichts. Die Prüfung ist wie die kostenlose 30-minütige Online-Vorberatung davor kostenlos. Ein Honorar fällt nur für ein Blueprint-Studio- oder Diagnoseprojekt an: fest vereinbart und im Angebot genannt.

Auf diese Frage verlinken

Was gilt als laufendes System?

Ein bereits genutztes System, das ausfällt, undokumentiert ist oder integriert werden muss: etwa eine Plattform, die ein früherer Anbieter halbfertig hinterlassen hat, oder ein ERP, das an E-Invoicing oder ISO-20022-Zahlungsnachrichten angebunden werden muss.

Auf diese Frage verlinken

Was sollten wir für die Prüfung vorbereiten?

Was Sie haben: eine Ausschreibung oder Spezifikation, Architekturdiagramme, die Liste der zu integrierenden Systeme, die geltenden Vorschriften und etwaige Abnahmekriterien. Lücken sind kein Problem; sie weisen auf den richtigen Track.

Auf diese Frage verlinken

Beginnen Sie mit einem Gespräch, nicht mit einem Vertrag.

Sagen Sie uns, was Sie bauen, verbinden oder absichern möchten. Ein Architekt geht es mit Ihnen durch und empfiehlt dann, wo Sie beginnen sollten.

Kostenlose Vorberatung buchen

Wie es weitergeht

Terminabstimmung
Unser Team schreibt Ihnen, um einen Termin für das Gespräch zu vereinbaren.
Beratungsvorgespräch
Ein kostenlose 30-minütige Online-Vorberatung: Wir gehen Ihre Ziele, Systeme und Rahmenbedingungen durch.
Readiness-Review
In einer kostenlose 48-stündige Readiness-Review prüft ein Principal Architect Ihr Projekt gegen die 6-Punkte-Definition of Ready und empfiehlt den passenden Track.
Wahl des Tracks
Projekte mit klarem Leistungsumfang erhalten innerhalb von 3–5 Werktagen ein verbindliches Angebot. Projekte in der Konzeptphase starten im Blueprint Studio. Ein laufendes System, das ausfällt, nicht dokumentiert ist oder integriert werden muss, beginnt mit einer Diagnose von 1–2 Wochen. Blueprint Studio und Diagnose haben jeweils ein festes Honorar, das im Angebot genannt wird.