Welche Konfigurationsentscheidungen Sie vor dem Go-live unbedingt dokumentieren sollten

Nach dem Go-live zeigt sich meist schon in den ersten Betriebswochen, ob wichtige Konfigurationsentscheidungen dokumentiert wurden oder nicht. Die kurze Antwort: Wer vor dem Start nicht festhält, wie das System arbeiten soll, warum bestimmte Regeln gewählt wurden und wer sie freigegeben hat, bezahlt später mit Support-Chaos, langen Abstimmungen und unnötiger Fehlersuche.

Das Problem ist selten die fehlende Technik. Meist fehlt die belastbare Erklärung hinter der Technik. Ein Feld ist plötzlich Pflicht. Ein Status löst keine Benachrichtigung aus. Eine Rolle darf etwas nicht bearbeiten. Dann beginnt die übliche Schleife: Fachbereich fragt IT, IT fragt den Implementierungspartner, der Partner sucht in alten Tickets, irgendjemand erinnert sich dunkel an einen Workshop. So verliert man Tage für Fragen, die vor dem Go-live in wenigen Minuten sauber dokumentiert werden konnten.

Besonders teuer wird das bei Personalwechseln. Wenn die Projektleitung weg ist, Key User wechseln oder mehrere Dienstleister beteiligt sind, bricht Wissen schnell weg. Unter engen Go-live-Terminen fällt Dokumentation außerdem gern hinten runter. Genau dann rächt es sich später am stärksten.

Der Effekt ist keine Randnotiz: In einer Befragung von 1.000 IT-Verantwortlichen berichteten 64 Prozent, ihr Unternehmen habe durch Mitarbeiterfluktuation bereits relevantes Wissen verloren, und 67 Prozent zeigten sich grundsätzlich besorgt über Wissensverlust dieser Art (siehe Sinequa-Studie zu Wissensverlust durch Fluktuation).

Auch branchenweite Auswertungen bestätigen, wie viel Schaden in der frühen Projektphase entsteht: Laut der Bitkom-Studie "Heiter Scheitern im Projekt" haben rund 75 Prozent der Fehlerursachen in Projekten ihren Ursprung in der Initialisierungs- und Definitionsphase -- also genau dort, wo Konfigurationsentscheidungen eigentlich festgehalten werden sollten.

Dieser Artikel zeigt, welche Konfigurationsentscheidungen Sie vor dem Go-live unbedingt festhalten sollten, wie Sie Verantwortlichkeiten regeln und wie die Dokumentation so abgelegt wird, dass Support und Betrieb damit tatsächlich arbeiten können.

Was mit „Konfigurationsentscheidungen“ vor dem Go-live gemeint ist

Mit Konfigurationsentscheidungen sind dokumentierte Festlegungen zum späteren Systemverhalten gemeint. Dazu gehören Regeln im Prozess, Rollen und Berechtigungen, Feldlogiken, Schnittstellen, Ausnahmen und technische Abhängigkeiten. Es geht also nicht nur um Einstellungen im System, sondern auch um die fachliche Absicht dahinter.

Ein einfaches Beispiel: „Das Feld Kostenstelle ist im Bestellprozess ab Status X Pflicht“ ist nur die halbe Information. Vollständig wird die Entscheidung erst mit dem fachlichen Grund, etwa: „ab diesem Status wird an Finance übergeben; ohne Kostenstelle kann die Buchung nicht verarbeitet werden“. Genau diese Ergänzung spart später Diskussionen.

Wichtig ist auch die Abgrenzung. Konfigurationsdokumentation ist kein Benutzerhandbuch. Sie beschreibt nicht Schritt für Schritt, wo jemand klicken muss. Sie ist auch kein Sammelordner aus Tickets, Testfällen oder Quellcode. Dort findet man Einzelteile, aber selten eine verlässliche, freigegebene Entscheidungslage. Ein Ticket zeigt vielleicht, was angefordert wurde. Es zeigt aber selten die spätere Änderung oder die finale, freigegebene Version.

Gut nutzbare Dokumentation beantwortet drei Fragen:

• Was wurde eingestellt?
• Warum wurde es so entschieden?
• Wer hat es fachlich und technisch freigegeben?

Warum der Prozess vor dem Go-live oft scheitert

In Projekten fallen Konfigurationsentscheidungen selten an einem Ort. Ein Teil entsteht im Workshop, anderes in E-Mails, einiges in Tickets und der Rest in spontanen Calls kurz vor dem Release. Das Ergebnis: Die Umsetzung existiert, aber die Entscheidungsgrundlage liegt verteilt über mehrere Kanäle.

Das zweite Problem ist die unklare Zuständigkeit. Häufig denkt der Fachbereich, der Implementierungspartner dokumentiert. Der Partner geht davon aus, dass die Projektleitung die Freigaben sammelt. Die interne IT erwartet, dass alles im Ticket-System sichtbar ist. Am Ende hat niemand die Aufgabe, die vollständige Sicht zusammenzuführen.

Unter Zeitdruck wird es noch dünner. Unter Zeitdruck zählt vor allem, dass etwas sichtbar „funktioniert“ – unabhängig davon, ob die Begründung dokumentiert ist. Dokumentiert wird das Ergebnis, wenn überhaupt, in Form von Screenshots oder kurzen Kommentaren. Das Was ist dann vielleicht noch sichtbar. Das Warum fehlt fast immer. Genau diese Lücke macht spätere Änderungen so riskant. Ohne Begründung kann niemand sicher einschätzen, ob eine Anpassung harmlos ist oder einen Folgeprozess kaputt macht.

Ein weiterer typischer Bruch entsteht bei Freigaben. Die technische Umsetzung ist fertig, aber die fachliche Entscheidung wurde nie formal bestätigt. Nach dem Go-live behauptet dann jede Seite etwas anderes. Das ist kein Einzelfall, sondern ein Standardfehler in Projekten mit engem Terminplan.

Vorlage: Entscheidungsprotokoll zur Go-live-Konfiguration mit Freigaben

Geben Sie Ihre E-Mail-Adresse ein, um eine umfassende Schritt-für-Schritt-Anleitung zu erhalten

Ich bestätige hiermit, dass ich die Bedingungen der Datenschutzpolitik von Bitrix24 vollständig gelesen und verstanden habe.

Schritt 1: Dokumentationsumfang und Verantwortliche vorab festlegen

Bevor Inhalte gesammelt werden, muss der Rahmen stehen. Sonst dokumentiert jedes Team etwas anderes, in anderem Detailgrad und in einem anderen Format. Das ist der direkte Weg zu Lücken.

Legen Sie zuerst fest, welche Entscheidungskategorien zwingend dokumentiert werden müssen. Typischerweise gehören dazu:

• Prozessregeln und Statuslogiken
• Rollen, Berechtigungen und Freigaben
• Pflichtfelder, Validierungen und Feldabhängigkeiten
• Schnittstellen, Trigger und Datenmapping
• Ausnahmen, manuelle Umgehungen und Fallbacks
• umgebungsspezifische Werte und technische Defaults

Danach benennen Sie die Owner. Dabei helfen drei klar getrennte Rollen:

Diese Rollen müssen nicht immer drei verschiedene Personen sein. Aber sie müssen benannt sein. „Macht das Team“ ist keine Zuständigkeit.

Ebenso wichtig ist ein einheitliches Template. Ohne Template entstehen Texte, Screenshots, Tabellen und Ticket-Links ohne gemeinsamen Standard. Ein praxistaugliches Format sollte pro Entscheidung mindestens folgende Felder enthalten:

• Bezeichnung der Entscheidung
• betroffener Prozess oder Systembereich
• Beschreibung der Konfiguration
• fachliche Begründung
• betroffene Rollen oder Systeme
• Ausnahmen oder bekannte Grenzen
• Owner, Prüfer, Freigabe
• Datum und Versionsstand

Ein ausgefülltes Beispiel macht das Format greifbar: Bezeichnung – „Pflichtfeld Kostenstelle ab Status Rechnungsprüfung“; fachliche Begründung – „Ohne Kostenstelle kann Finance die Buchung nicht verarbeiten“; Owner – Teamleitung Einkauf; Freigabe – 14.03., Projektleitung. Zwei bis drei Felder reichen oft aus, um eine Entscheidung im Nachhinein eindeutig zuzuordnen.

Das klingt simpel. Ist es auch. Genau deshalb sollte dieser Rahmen ganz am Anfang stehen und nicht erst zwei Tage vor dem Go-live.

Schritt 2: Geschäftsregeln, Rollen und Prozessausnahmen erfassen

Hier liegt der Teil, der später am häufigsten Support-Fälle auslöst. Geschäftsregeln sind die fachlichen Festlegungen, nach denen das System arbeitet: Wer darf was tun, wann wird etwas gesperrt, welche Felder sind Pflicht und welche Übergänge sind erlaubt.

Dokumentieren Sie zuerst die Freigabelogiken. Also nicht nur „Freigabe ab 5.000 Euro durch Teamleitung“, sondern auch, was bei Vertretung, Eskalation oder mehreren Kostenstellen passiert. Gerade solche Fälle werden in Workshops oft mündlich besprochen und nie festgehalten.

Dann folgen Rollen und Berechtigungen. Hier reicht eine Rollenliste nicht aus. Sie brauchen die konkrete Wirkung im Prozess. Beispiel: „Sachbearbeitung darf Datensatz anlegen und ändern, aber ab Status Prüfen keine Stammdaten mehr anpassen.“ Solche Grenzen müssen eindeutig beschrieben sein, sonst diskutiert der Support später über vermeintliche Berechtigungsfehler, obwohl das Verhalten beabsichtigt war.

Das zeigt sich häufig bei rollenbasierten Berechtigungen: Systeme wie Bitrix24 erlauben es etwa, Zugriffsrechte auf CRM-Datensätze je Rolle granular über die rollenbasierten Zugriffsberechtigungen in Bitrix24 zu steuern. Wird eine Rolle aber nur technisch eingerichtet und nicht mit der fachlichen Begründung dokumentiert, hat der Support zwar ein sauberes Berechtigungskonzept, aber niemanden, der erklären kann, warum diese Rolle bestimmte Datensätze nicht sehen darf.

Pflichtfelder und Statuswechsel gehören ebenfalls in diese Schicht. Halten Sie fest:

• welche Felder in welchem Schritt Pflicht sind
• welche Prüfregeln greifen
• welche Statuswechsel erlaubt, gesperrt oder automatisiert sind
• welche Folgeaktionen ausgelöst werden

Besondere Aufmerksamkeit brauchen Sonderfälle und manuelle Umgehungen. Viele Prozesse haben Ausnahmen, die im Alltag selten auftreten, aber im Ernstfall kritisch sind. Etwa: „Wenn die Schnittstelle zum ERP ausfällt, darf der Fall manuell abgeschlossen werden, sofern Finance per Ticket informiert wurde.“ Wenn solche Regeln nicht dokumentiert sind, entstehen Ad-hoc-Entscheidungen im Betrieb. Das führt fast immer zu Uneinheitlichkeit.

Ergänzen Sie bei jeder fachlichen Regel die Begründung. Nicht lang, aber konkret. Ein Satz reicht oft. Ohne diese Begründung wird jede spätere Änderung zu einer Neuverhandlung.

"Nach der Einführung von Bitrix24 haben wir die Geschäftsprozesse in unserem Unternehmen maximal vereinfacht."

Geschäftsführer, Alexander Dortmann

DortmannKids

KOSTENFREI STARTEN

Schritt 3: Technische Einstellungen, Abhängigkeiten und Integrationen festhalten

Fachliche Regeln allein reichen nicht. Nach dem Go-live entstehen Störungen typischerweise an drei Stellen: bei Übergaben zwischen Systemen (z. B. Timeouts oder doppelte Datensätze), bei Triggern, die nicht wie erwartet feuern, oder an versteckten Abhängigkeiten wie nächtlichen Hintergrundjobs. Genau deshalb muss die technische Seite genauso dokumentiert werden.

Starten Sie mit den Schnittstellen und Datenflüssen. Beschreiben Sie, welches System wann welche Daten an wen übergibt. Dazu gehören Richtung, Auslöser, Format und erwartetes Ergebnis. Wer nur „CRM an ERP angebunden“ notiert, hilft später niemandem.

Für Integrationen sollten mindestens diese Punkte erfasst werden:

• beteiligte Systeme und konkrete Instanzen
• Schnittstellenart, etwa API, Dateiimport oder Middleware
• Trigger, zum Beispiel bei Statuswechsel oder zu festen Zeiten
• Mapping wichtiger Felder
• Fehlerverhalten und Wiederholungslogik
• zuständige Teams auf beiden Seiten

Auch umgebungsspezifische Werte müssen hinein. Dazu zählen URL-Endpunkte, Mandanten, Default-Werte, Zeitpläne, Sprach- oder Währungseinstellungen und technische Flags. Gerade bei mehreren Umgebungen passieren hier typische Fehler: abweichende Zeitzonen, andere Sprachpakete oder andere Default-Werte zwischen Test und Produktion. Ohne Doku wird dann lange gesucht, obwohl nur ein Wert anders gesetzt ist.

Abhängigkeiten sollten ausdrücklich genannt werden. Wenn ein Workflow nur läuft, weil ein Hintergrundjob nachts um 2 Uhr startet, muss das sichtbar sein. Genauso, wenn ein Feld aus einem anderen System befüllt wird oder wenn Versionen aufeinander abgestimmt sein müssen.

Ein Mini-Beispiel macht das konkret: Ein Trigger im CRM feuert, sobald ein Deal auf den Status „Gewonnen“ wechselt, und übergibt drei Felder an das ERP-System – Kundennummer, Bestellwert und Kostenstelle. Fehlt die Kostenstelle, landet der Datensatz in einer Fehlerwarteschlange, und Finance wird per Ticket informiert, statt dass der Auftrag stillschweigend hängen bleibt. Regeln und Trigger dieser Art lassen sich beispielsweise direkt in der CRM-Automatisierung von Bitrix24 konfigurieren – nachvollziehbar wird die Übergabe an das ERP aber erst, wenn Trigger-Bedingung, Feld-Mapping und Fehlerverhalten wie unten beschrieben dokumentiert sind.

Hilfreich ist eine kompakte Tabelle pro Integration:

Das ist keine technische Kür, sondern Betriebsvoraussetzung. Wenn später ein Datensatz fehlt oder doppelt ankommt, will niemand erst aus Logs und alten Tickets rekonstruieren, wie die Integration eigentlich gedacht war.

Schritt 4: Entscheidungen validieren, zentral ablegen und für den Betrieb nutzbar machen

Dokumentation nützt wenig, wenn sie nicht geprüft, verteilt abgelegt oder für den Betrieb unbrauchbar ist. Vor dem Go-live braucht jede relevante Entscheidung eine fachliche und technische Freigabe. Nicht als loses „passt so“, sondern nachvollziehbar mit Datum und Verantwortlichen.

Die Validierung sollte zwei Fragen klären: Entspricht die Doku der tatsächlichen Konfiguration? Und entspricht die Konfiguration der freigegebenen fachlichen Entscheidung? Genau an dieser Stelle fallen oft Abweichungen auf, die sonst erst nach dem Start sichtbar würden.

Danach gehört alles in einen zentralen, auffindbaren und versionskontrollierten Ablageort. Das kann ein Confluence-Bereich, ein DMS oder ein anderes zentrales System sein. Entscheidend ist nicht das Tool, sondern dass alle dieselbe Quelle nutzen. Freigegebene Dokumentation verteilt über E-Mails, geteilte Laufwerke und Chatverläufe ist im Ernstfall wertlos.

Konkret heißt das: Bei Confluence liefert die Seiten-Historie automatisch Versionsstände inklusive Autor und Zeitpunkt; bei YAML- oder JSON-Konfigurationsdateien übernimmt ein Git-Repository dieselbe Aufgabe, inklusive Diff-Ansicht zwischen zwei Ständen. Zugriffsrechte sollten dabei rollenbasiert vergeben werden, etwa Lesezugriff für den Fachbereich und Schreibzugriff für Owner und Prüfer. Auch die Wissensdatenbank von Bitrix24 versioniert Seiten automatisch und lässt sich über Rollen einschränken – entscheidend ist aber, dass Zugriff und Versionsstand nachvollziehbar bleiben, unabhängig vom gewählten Tool.

Für den Betrieb muss die Doku außerdem anschlussfähig sein. Verknüpfen Sie sie mit:

• Runbooks für wiederkehrende Störungen oder manuelle Eingriffe
• Kontaktwegen für Fachbereich, IT, Partner und Hersteller
• Änderungsverlauf mit Bezug auf Releases oder Changes
• bekannten Einschränkungen und offenen Punkten

Praktisch ist ein kurzer Betriebsblock am Ende jeder Entscheidung: Wer wird bei Abweichungen informiert? Welche Prüfschritte gelten zuerst? Wann wird an den nächsten Support-Level übergeben? So wird aus Projektdokumentation etwas, das im Alltag wirklich genutzt werden kann.

Merksatz: Vor dem Go-live muss Dokumentation nicht nur vollständig, sondern auch betriebstauglich sein.

Häufige Fehler sowie Tipps für Skalierung und verlässlichen Betrieb

Ein paar Fehler tauchen in fast jedem Projekt auf. Der bekannteste: Es werden nur Screenshots gespeichert. Screenshots zeigen eine Oberfläche zu einem Zeitpunkt. Sie erklären weder Logik noch Abhängigkeiten. Noch schlechter wird es, wenn Begründungen fehlen. Dann sieht man zwar die Einstellung, aber niemand weiß mehr, warum sie so gewählt wurde.

Ebenso problematisch ist das Vergessen von Sonderfällen. Viele Teams dokumentieren den Standardprozess und blenden Ausnahmen aus. Genau diese Ausnahmen verursachen später Störungen, Eskalationen oder manuelle Mehrarbeit.

Ein Beispiel aus der Praxis: Ein B2B-Softwareanbieter mit 45 Mitarbeitenden im Customer Support hielt vor dem Go-live nur Screenshots der Feldkonfiguration fest. Sechs Wochen nach dem Start häuften sich Rückfragen zu einer Pflichtfeld-Regel, deren fachlicher Grund nirgends vermerkt war. Der Support brauchte im Schnitt zwei bis drei Arbeitstage pro Fall, um die Entscheidung über alte E-Mails und ehemalige Workshop-Teilnehmer zu rekonstruieren – bei rund 30 vergleichbaren Fällen im ersten Quartal ein Aufwand, den ein einziger dokumentierter Begründungssatz vermieden hätte.

Typische Fehler im Überblick:

• nur Oberflächen statt Regeln dokumentieren
• keine fachliche Begründung hinterlegen
• Sonderfälle und Umgehungen auslassen
• Freigaben nicht verbindlich erfassen
• Dokumentation nach Go-live nicht mehr pflegen

Wenn mehrere Länder, Mandanten oder Produkte im Spiel sind, skaliert das Thema schnell. Dann reicht freie Textdokumentation nicht mehr aus. Arbeiten Sie mit Pflichtfeldern im Template, damit Unterschiede systematisch erfasst werden, etwa lokale Steuersätze, Sprachlogiken, regionale Freigabegrenzen oder mandantenspezifische Schnittstellenwerte.

Nicht jedes Projekt braucht den vollen Rahmen. Bei sehr kleinen Implementierungen mit einer Handvoll Entscheidungen und einem einzigen Verantwortlichen kann ein Template mit allen acht Feldern mehr Aufwand erzeugen als Nutzen stiften. Hier reicht häufig eine reduzierte Version mit Was, Warum und Freigabe. Der volle Prozess lohnt sich vor allem, sobald mehrere Teams, Systeme oder Freigabeinstanzen beteiligt sind.

Sinnvoll sind auch feste Review-Zyklen. Zum Beispiel vor jedem größeren Release, nach relevanten Changes oder quartalsweise für kritische Prozesse. So wird die Dokumentation nicht nur einmal erstellt und dann vergessen.

Am zuverlässigsten wird der Prozess, wenn Dokumentation ein fester Teil von Change, Abnahme und Release-Checkliste ist. Keine Freigabe ohne dokumentierte Entscheidung. Keine Produktionssetzung ohne Ablageort. Keine abgeschlossene Änderung ohne Aktualisierung des Stands. Das klingt streng, verhindert aber genau die späteren Diskussionen, die sonst viel mehr Zeit kosten.

Go-live-Preflight: Kurz-Checkliste

• Sind alle Pflichtfelder und Statuslogiken mit fachlicher Begründung dokumentiert?
• Sind Owner, Prüfer und Freigeber für jede Entscheidung namentlich benannt?
• Liegen alle Freigaben mit Datum vor, nicht nur mündlich zugesagt?
• Sind Schnittstellen inklusive Trigger, Feld-Mapping und Fehlerverhalten erfasst?
• Liegt die Dokumentation an einem zentralen, versionierten Ort statt verteilt in E-Mails oder Chats?
• Sind Sonderfälle und manuelle Umgehungen berücksichtigt, nicht nur der Standardprozess?
• Ist ein Ansprechpartner für Rückfragen im laufenden Betrieb benannt?

FAQ und Fazit: Praktische Sonderfragen vor und nach dem Go-live klären