Vom Zettel zur Branchenlösung

Die meisten Digitalisierungsprojekte scheitern nicht an der Technik. Sie scheitern daran, dass am Ende ein Werkzeug dasteht, das den Prozess nicht abbildet, den die Leute tatsächlich haben – sondern den, den sie im Workshop beschrieben haben.

Zwischen beiden liegt oft eine erhebliche Lücke. Dieser Beitrag beschreibt, wie man sie schließt.

Der Ausgangspunkt

Ein typischer Betrieb, sagen wir ein Dienst mit zweiundzwanzig Betreuungskräften. Die Einsatzplanung entsteht in einer Excel-Datei, wird morgens ausgedruckt und zusätzlich per WhatsApp verteilt. Änderungen am Tag laufen über Telefon. Die Dokumentation wird auf Papier geführt und abends abgeheftet. Die Abrechnung wird am Monatsende aus Stundenzetteln zusammengesucht.

Das funktioniert. Es funktioniert seit Jahren. Und genau das ist der Punkt, den man ernst nehmen muss: Der bestehende Prozess ist nicht dumm, er ist gewachsen. Jede Umständlichkeit darin hat meistens einen Grund, den niemand mehr benennen kann, der aber existiert.

Wer mit der Haltung hineingeht, das alles durch etwas Besseres zu ersetzen, baut an der Realität vorbei. Wer mit der Haltung hineingeht, herauszufinden, warum es so ist, wie es ist, hat eine Chance.

Anforderungen erheben: zuschauen statt fragen

Die schlechteste Methode, Anforderungen zu erheben, ist, danach zu fragen. Nicht weil die Leute lügen, sondern weil niemand seinen eigenen Arbeitsablauf vollständig beschreiben kann. Was täglich getan wird, wird nicht mehr bewusst wahrgenommen.

Was besser funktioniert:

Einen Tag mitlaufen. Nicht als Beobachter mit Klemmbrett, sondern danebensitzen, während jemand arbeitet. In den ersten zwei Stunden lernt man mehr als in drei Workshops. Vor allem lernt man die Dinge, die in keinem Workshop vorkommen: dass die Planung eigentlich am Vorabend entsteht, dass es eine zweite inoffizielle Liste gibt, dass ein bestimmter Fall immer per Zuruf geregelt wird.

Die Artefakte einsammeln. Die Excel-Datei. Den ausgedruckten Plan mit den handschriftlichen Korrekturen. Das Formular, das seit 2019 unverändert ist. Diese Dokumente sind die ehrlichste Anforderungsdokumentation, die es gibt. Die handschriftlichen Notizen darauf zeigen genau, wo das bestehende System nicht reicht.

Nach dem letzten Ausnahmefall fragen. Nicht „welche Sonderfälle gibt es?" – darauf kommt meist eine unvollständige Antwort. Sondern: „Was war diese Woche der komplizierteste Fall?" Daraus kommen die Anforderungen, die ein Projekt kippen können, wenn sie erst spät auftauchen.

Mit denen sprechen, die es benutzen werden. Nicht nur mit der Leitung. Die Leitung beschreibt, wie es sein sollte. Die Mitarbeitenden wissen, wie es ist. Beides ist wichtig, aber nur eines davon bestimmt, ob die Software später benutzt wird.

Was man bewusst nicht abbildet

Die größte Versuchung: alles nachbauen. Jede Spalte der Excel-Tabelle, jedes Feld des Papierformulars, jede Ausnahme.

Das führt zu Software, die genauso umständlich ist wie vorher, nur digital – und damit zur schlimmsten aller Varianten, weil sie die Nachteile beider Welten vereint.

Besser: Jede Anforderung durch drei Fragen schicken.

1. Wie oft kommt das vor? Ein Fall, der zweimal im Jahr auftritt, braucht keine eigene Funktion. Er braucht ein Freitextfeld und einen Anruf.
2. Was passiert, wenn wir es nicht abbilden? Manchmal lautet die ehrliche Antwort: nichts. Dann fällt es raus.
3. Ist das eine Anforderung oder eine Gewohnheit? „Das haben wir immer so gemacht" ist keine Anforderung. Es kann eine sein, aber es muss geprüft werden.

Diese Aussortierung ist unbequem, weil sie Nein sagen bedeutet. Sie ist aber der Unterschied zwischen einem Produkt, das in vier Monaten fertig ist, und einem, das nach einem Jahr immer noch nicht läuft.

Das Datenmodell folgt dem Prozess, nicht dem Formular

Ein häufiger Fehler: Das Formular wird zur Datenstruktur. Was auf dem Papier eine Zeile ist, wird eine Tabellenspalte.

Der bessere Weg führt über die Frage, welche fachlichen Dinge es eigentlich gibt und wie sie zusammenhängen. Bei einem Betreuungsdienst etwa: Kunde, Betreuungskraft, Einsatz, Leistung, Abrechnungszeitraum, Kostenträger. Der Einsatz verbindet Kunde und Betreuungskraft zu einem Zeitpunkt. Die Leistung hängt am Einsatz. Die Abrechnung greift auf Leistungen zu, gefiltert nach Zeitraum und Kostenträger.

Wenn dieses Modell stimmt, lassen sich Formulare beliebig ändern. Wenn es aus Formularen abgeleitet ist, wird jede Änderung zur Migration.

Ein Test, der sich bewährt hat: Lassen Sie sich vom Kunden einen ungewöhnlichen Fall schildern, und prüfen Sie, ob Ihr Modell ihn abbilden kann, ohne dass eine neue Tabelle nötig wird. Wenn ja, ist es tragfähig.

Die Einführung entscheidet

Hier scheitern Projekte, die technisch in Ordnung sind.

Nicht alle auf einmal. Eine Gruppe, ein Bereich, ein Standort zuerst. Zwei bis vier Wochen laufen lassen, zuhören, nachbessern. Erst dann ausrollen. Der Grund ist nicht technische Vorsicht, sondern dass die ersten Nutzer zu Fürsprechern werden – oder zu Warnern, bevor der Schaden groß ist.

Parallelbetrieb, aber befristet. Die alte Excel-Datei sofort abzuschalten, erzeugt Panik. Sie unbefristet weiterlaufen zu lassen, führt dazu, dass beides gepflegt wird und am Ende keins richtig. Ein festes Datum, an dem umgestellt wird, mit klarer Ansage.

Schulung in kleinen Gruppen, am eigenen Gerät. Eine Schulung mit zwanzig Leuten und einem Beamer bringt wenig. Fünf Leute, jeder mit seinem eigenen Telefon, mit echten Daten aus dem eigenen Alltag – das wirkt.

Einen Ansprechpartner im Betrieb. Jemanden, der die Software gut kennt und den man fragen kann, ohne einen Dienstleister anzurufen. Diese Person ist oft wichtiger für den Erfolg als jede Funktion.

Zuhören in den ersten vier Wochen. Und zwar aktiv, nicht abwartend. Die meisten Nutzer melden nichts – sie benutzen die Funktion einfach nicht mehr, die sie nicht verstanden haben.

Der Widerstand, mit dem zu rechnen ist

Er kommt, und er ist meistens berechtigt.

Die häufigste Sorge ist nicht technischer Natur: Es geht um Kontrolle. Eine digitale Zeiterfassung macht sichtbar, wer wann wo war. Eine digitale Dokumentation macht nachvollziehbar, was getan wurde und was nicht. Für die Leitung ist das ein Vorteil. Für die Mitarbeitenden ist es Überwachung, wenn niemand darüber spricht.

Was hilft, ist Offenheit darüber, wer was sehen kann, und Zurückhaltung bei dem, was erfasst wird. Nur weil sich Standortdaten erheben lassen, sollte man es nicht tun. Jede Erfassung, die keinen erkennbaren Nutzen für die erfassten Personen hat, kostet Akzeptanz – und bei personenbezogenen Daten steht ohnehin die Frage der Rechtsgrundlage im Raum, oft samt Mitbestimmung.

Der zweite Widerstand ist praktischer Natur: Die neue Lösung ist in den ersten Wochen langsamer als die alte. Das stimmt sogar. Wer eine Excel-Datei seit sechs Jahren bedient, ist darin schnell. Diese Phase muss man benennen, sonst wird sie als Beweis gewertet, dass das Neue schlechter ist.

Rechtliche Rahmenbedingungen

Bei Branchenlösungen im sozialen Bereich und in der Pflege kommen Anforderungen dazu, die man früh kennen muss:

• Rechtsgrundlage der Verarbeitung für jede Datenart, besonders bei Gesundheitsdaten
• Auftragsverarbeitungsvertrag, wenn ein Dienstleister Zugang zu Produktivdaten hat
• Aufbewahrungsfristen, die je nach Datenart unterschiedlich sind – Pflegedokumentation und Rechnungsdaten folgen verschiedenen Regeln
• Löschkonzept, das diese Fristen automatisch umsetzt
• Protokollierung von Zugriffen bei besonderen Datenkategorien
• Mitbestimmung, wo ein Betriebs- oder Personalrat existiert – bei Systemen, die Leistung erfassen können, ist das kein Randthema

Diese Punkte gehören in die Leistungsbeschreibung, nicht in die Abnahme. Nachträglich eingebaut, sind sie teuer; von Anfang an mitgedacht, sind sie Teil des Modells.

Ein realistischer Zeitplan

Für eine Branchenlösung mittleren Umfangs:

Phase	Dauer	Ergebnis
Mitlaufen und Erheben	1–2 Wochen	Prozessbild, Artefakte, Sonderfälle
Zuschnitt und Leistungsbeschreibung	1–2 Wochen	Festgelegter Umfang, fester Preis
Umsetzung mit Zwischenständen	10–16 Wochen	Alle 2–3 Wochen ein lauffähiger Stand
Testbetrieb mit einer Gruppe	2–4 Wochen	Korrekturen aus echter Nutzung
Einführung und Schulung	2–3 Wochen	Alle Nutzer im System
Nachbesserung	4 Wochen	Die Dinge, die erst im Alltag auffallen

Vom ersten Gespräch bis zum vollständigen Betrieb also etwa fünf bis sieben Monate. Wer schneller verspricht, lässt eine dieser Phasen weg – meistens den Testbetrieb, und das ist die teuerste Einsparung von allen.

Woran man einen guten Partner erkennt

Nicht an der Referenzliste. Sondern daran, ob im ersten Gespräch mehr gefragt als erzählt wird – und ob jemand bereit ist, Funktionen aus dem Angebot zu streichen, statt sie hineinzuverhandeln.

Ein Dienstleister, der bei jedem Wunsch „ja, machen wir" sagt, ist nicht flexibel. Er hat nur noch nicht verstanden, was es kostet.

Datenübernahme aus dem Altsystem

Fast jedes Digitalisierungsprojekt hat eine Vorgeschichte: eine Excel-Datei, eine alte Software, ein Karteikartensystem. Die Frage, was davon übernommen wird, entscheidet über mehrere Wochen Aufwand.

Die ehrliche Ausgangslage ist meist unschön. Gewachsene Datenbestände enthalten Dubletten, uneinheitliche Schreibweisen, Felder, die zweckentfremdet wurden, und Einträge, die seit Jahren niemand mehr angefasst hat. Das ist kein Vorwurf – so entstehen Daten nun einmal, wenn zehn Jahre lang fünf verschiedene Personen sie pflegen.

Drei Entscheidungen sollten früh fallen:

Was wird überhaupt übernommen? Oft reichen die aktiven Datensätze. Historie aus sieben Jahren mitzunehmen, vervielfacht den Aufwand und wird selten gebraucht. Ein gangbarer Mittelweg: aktive Daten ins neue System, das alte System für Nachschlagezwecke noch ein Jahr lesend erhalten.

Wer bereinigt? Das ist Fachwissen, kein Programmierproblem. Ob zwei Einträge dieselbe Person sind, weiß der Betrieb, nicht der Entwickler. Diese Arbeit gehört zum Kunden – und sie braucht Zeit, die im Projektplan stehen muss.

Wie oft wird geprobt? Eine Datenübernahme gelingt nie beim ersten Versuch. Planen Sie mindestens drei Durchläufe: einen, um zu sehen, was schiefgeht, einen nach der Bereinigung, und den echten. Jeder Durchlauf erzeugt eine Liste der Datensätze, die nicht übernommen werden konnten – diese Liste ist das eigentliche Arbeitsergebnis.

Ein Muster, das sich bewährt hat: Die Übernahme wird als wiederholbares Skript gebaut, nicht als einmalige Handarbeit. Dann kostet der vierte Durchlauf zehn Minuten statt eines Tages.

Die Abnahme vorbereiten, bevor gebaut wird

In der Leistungsbeschreibung steht, was gebaut wird. Was fehlt, ist meistens: woran erkennt man, dass es erledigt ist?

Diese Frage sollte für jede Funktion beantwortet sein, bevor die Umsetzung beginnt. Nicht als förmliches Testkonzept, sondern als ein Satz je Punkt: Wenn eine Betreuungskraft ihre Zeit erfasst und die Leitung sie freigibt, erscheint sie in der Monatsabrechnung.

Der Nutzen ist doppelt. Beim Bauen ist klar, wann Schluss ist. Bei der Abnahme gibt es keine Diskussion darüber, was gemeint war. Und rechtlich ist das relevant: Beim Werkvertrag startet die Abnahme die Gewährleistungsfrist und macht die Schlussrechnung fällig – beides sollte nicht an einer Auslegungsfrage hängen.

Eine Regelung, die sich bewährt hat, ist die Einteilung von Mängeln in drei Stufen. Ein schwerer Mangel macht eine Kernfunktion unbenutzbar und hält die Abnahme auf. Ein mittlerer schränkt ein und wird mit Frist behoben, die Abnahme erfolgt unter Vorbehalt. Ein leichter ist ein Schönheitsfehler und wird im Rahmen der Gewährleistung erledigt. Ohne diese Abstufung wird jede Kleinigkeit zum Abnahmehindernis.

Nach einem Jahr: was wir regelmäßig sehen

Wenn man nach zwölf Monaten in einen Betrieb zurückkommt, wiederholen sich drei Beobachtungen.

Ein Teil der Funktionen wird nicht benutzt. Meist ein Viertel bis ein Drittel. Das ist kein Scheitern, sondern normal – niemand kann vorher wissen, was sich im Alltag bewährt. Es ist allerdings ein starkes Argument dafür, die erste Version klein zu halten.

Es hat sich ein Nebenweg gebildet. Irgendwo gibt es wieder eine Liste, eine Nachricht, einen Zettel. Fast immer an einer Stelle, die im Projekt als Sonderfall abgetan wurde. Diese Nebenwege sind wertvoll: Sie zeigen genau, wo die Software den Prozess nicht trifft.

Die wichtigste Verbesserung ist eine Kleinigkeit. Ein Feld, das vorausgefüllt sein sollte. Eine Liste, die anders sortiert gehört. Eine Bestätigung, die man wegklicken muss und die niemand braucht. Solche Dinge kosten Stunden und verändern die tägliche Erfahrung mehr als jede neue Funktion.

Deshalb halten wir eine Nachbesserungsphase nach dem Launch für Pflicht – und ein kurzes Gespräch nach einem Jahr für die günstigste Investition im ganzen Projekt.

Was den Unterschied macht

Am Ende entscheidet über den Erfolg einer Branchenlösung selten die Technik. Es entscheidet, ob jemand sich die Mühe gemacht hat, den Betrieb wirklich zu verstehen, bevor er angefangen hat zu bauen.

Das kostet ein bis zwei Wochen zu Projektbeginn. Es ist die einzige Phase, in der sich Aufwand nachweislich mehrfach zurückzahlt – weil jede Anforderung, die man nicht falsch versteht, keine Korrektur erzeugt.