Wachplanung-Optimierung mit KI

Das echte Ausmaß des Problems

Objektschutz-Dienste mit 20–100 Mitarbeitern verwalten typischerweise 5–30 Objekte parallel, jedes mit unterschiedlichen Risikoprofilen, Größen, Kundenanforderungen und Sensitivitäten. Gleichzeitig ist der Planungsaufwand manuell:

• Tradition statt Datenlage: Kontrollzeiten werden nach Best Guess oder Kundenanforderung (“wir mögen um 3 Uhr eine Runde”) festgelegt, nicht nach Vorfall-Häufigkeit.
• Verlorene Einsichten: Größere Dateien liegen vor, Vorfallsberichte, GPS-Logs von Streifenfahrzeugen, Alarmprotokolle, aber niemand hat Zeit, diese systematisch zu analysieren. Die Information sitzt in einzelnen Köpfen (“auf Baustelle B gibt’s oft Diebstähle von Kupfer in der 3. bis 5. Nachtschicht”), wird aber nicht dokumentiert.
• Ineffiziente Ressourcenverteilung: Unter-/Überlastung ist normal. Ein Objekt mit vielen nächtlichen Vorfällen und eines mit keinen bekommen je die gleiche Schicht-Kapazität.
• Kausalität ist unklar: Wenn die Vorfallsrate sinkt, lässt sich schwer sagen, ob es an der neuen Planung liegt oder an einer verstärkten Beleuchtung, die parallel installiert wurde.

Nach Branchenerfahrung und Recherchen verbringen Einsatzleiter einer 50–100-Mann-Firma 3–6 Stunden pro Woche auf Schichtplanung, Zeit, die reaktiv für Kurzfristausfälle aufgebraucht wird.

Mit vs. ohne KI, ein ehrlicher Vergleich

Die Vergleichswerte für Planung und Vorfallserkennung basieren auf Erfahrungswerten aus Implementierungen mit Werkschutz-Diensten und Recherchen zu Predictive-Security-Systemen (laut Anbieterangaben wie Geolitica, HunchLab).

Einschätzung auf einen Blick

Zeitersparnis, gering (1/5)
Hier kommt die unbequeme Wahrheit: Das System spart der Einsatzleitung keine Zeit. Im Gegenteil, statt Excel-Planung folgen nun Validierungs-Runden (“stimmt dieser Vorschlag für Objekt C wirklich?”). Die wöchentliche Planung wird sogar länger. Der Zeitgewinn entsteht, wenn überhaupt, indirekt: Weniger Reaktivplanungen, weil Einsätze besser passen. Aber für die Person, die plant, ist das kein spürbarer Zeit-Segen.

Kosteneinsparung, deutlich (3/5)
Der ROI kommt aus zwei Quellen: (1) Vorfallsreduktion senkt Schadenskosten (Ersatz, Haftung, Versicherung) um 15–25 %. (2) Optimierte Personalverteilung reduziert Überzeiten und Ausfallsicherungen. Für ein Objekt mit 6 Einbruchsversuchen/Jahr à 5.000 EUR Schaden = 30.000 EUR Risiko, sinkt das auf 2–3 Versuche, spart man 15.000 EUR jährlich. Nur sinnvoll ab ~15 Objekten mit Datenbasis.

Schnelle Umsetzung, schwierig (2/5)
Die längste Phase ist nicht ML-Entwicklung, sondern Datenaufbereitung. Objektschutz-Firmen haben oft 3 Jahre Vorfallsdaten in Word-Dateien, Excels, teilweise auf Papier. Das Strukturieren, Standardisieren und Fehlerbereinigung kostet allein 2–3 Monate. Danach: 3 Monate Datenanalyse und Modell-Training, 1 Monat Pilot-Test. Gesamt: 12–16 Wochen. Das ist nicht “schnell”, aber auch nicht “Enterprise-Großprojekt”.

ROI-Sicherheit, mittel (3/5)
Die Vorfallsreduktion ist messbar, man zählt, wie viele Vorfälle vorher und nachher eintraten. Aber der kausale Zusammenhang ist nie 100 % sauber: Parallel wurden möglicherweise Zaun, Beleuchtung oder Zugangskontrollen verstärkt. Wer ein solides Messprotokoll vor Projektstart definiert (“Baseline-Woche: alle Vorfälle ohne KI, danach: mit KI”), kann eine starke ROI-Story bauen. Ohne Messprotokoll ist es raten.

Skalierbarkeit, abhängig (3/5)
Das Modell wird besser je mehr Objekte und Vorfallsdaten verfügbar sind. Ab ~15 Objekten mit 2+ Jahren Daten wird es robust. Unter 10 Objekten: Die Datenmengen sind zu klein, um Muster zu erkennen, hier bleibt Excel-Planung realistischer und billiger.

Richtwerte, stark abhängig von Objektanzahl, Vorfall-Häufigkeit und Datenqualität.

Was das System konkret macht

Phase 1: Datenintegration (Wochen 1–6)
Alle Vorfallsberichte, GPS-Logs der Streifenwagen, Alarmanlage-Protokolle und Zeitstempel werden in eine zentrale Datenbank importiert. Daten werden standardisiert: Orte werden Koordinaten, Vorfallstypen werden kategorisiert, Zeiten in UTC konvertiert. Das ist reine Handarbeit, keine intelligente ML-Magie, sondern Data Engineering.

Phase 2: Feature Engineering (Wochen 7–10)
Aus Rohdaten entstehen Features:

• Räumliche Features: Für jeden Ort die Vorfallsdichte (Vorfälle pro Quadratmeter) in den letzten 3, 6, 12 Monaten
• Zeitliche Features: Durchschnittliche Vorfallsfrequenz nach Uhrzeit, Wochentag, Jahreszeit
• Kontextuelle Features: Wetterdaten (klare Nächte haben andere Einbruchsmuster als Regennächte), Veranstaltungen im Umfeld, Ferienzeiten
• Aggregierte Features: Durchschnittliche Reaktionszeit bei letzten 5 Vorfällen, Trendrichtung (sinkt oder steigt?)

Phase 3: Modell-Training (Wochen 11–14)
Ein scikit-learn Random-Forest- oder Gradient-Boosting-Modell wird trainiert, um für jeden Ort zu jeder Stunde die Vorfallswahrscheinlichkeit vorherzusagen. Input: Position + Uhrzeit + Datum. Output: Risikoscore 1–10.

Beispiel: Industriepark Nord am Donnerstag, 00:30 Uhr → Risikoscore 7 (hoch). Freitag, 10:00 Uhr → Risikoscore 1 (gering).

Das Modell wird auf 70 % der Daten trainiert, auf 30 % validiert. Zielgenauigkeit: Minimum 70 % Accuracy (Prognosen vs. tatsächliche Vorfälle).

Phase 4: Optimierungsmodul (Wochen 15–16)
Ein Constraint-basiertes Optimierungsskript (ähnlich wie bei der Schichtplanung) kombiniert:

• Risikoscores der Modell-Vorhersagen
• Vorgegebene Schichtdauern (4–12 Stunden)
• Personal-Verfügbarkeit und Qualifikationen
• Fahrtzeiten zwischen Objekten (via OpenRouteService)

Ausgang: 3–5 Planungsvorschläge mit Begründung (“Route A: erwischt die 3 höchsten Risikozeiten, fahrtzeit 45 Min, deckt 8 der 12 kritischen Orte ab”).

Phase 5: Wöchentliches Retraining
Jede Woche werden neue Vorfallsdaten eingespielt. Das Modell wird neu trainiert. Nicht von Grund auf, sondern inkrementell, alte Patterns bleiben, neue werden hinzugelernt. So passt sich das System an sich ändernde Muster an (z.B. “im Herbst verstärkt sich Kupferdiebstahl im Umfeld der Baustellenzone”).

Konkrete Werkzeuge, was wann passt

Python + scikit-learn
Das Basis-Setup für kleinere Implementierungen (20–100 Objekte). Eine Python-Anwendung mit scikit-learn trainiert die Modelle auf CSV-Daten oder einer lokalen PostgreSQL-Datenbank. Kostenlos, Open Source, zu 100 % kontrollierbar. Nachteil: Du brauchst einen Entwickler, der Python und ML-Concepts versteht. Für den Produktionsbetrieb sollte das Modell in einen Webservice (z.B. Flask oder FastAPI) verpackt werden, damit Einsatzleiter vom Browser aus Pläne abrufen können.

Azure Machine Learning mit Responsible AI Toolkit
Wenn deine Sicherheitsfirma bereits auf Azure läuft oder Microsoft 365 nutzt: Azure ML bietet die komplette MLOps-Pipeline, Datenverarbeitung, Training, Betrieb, Monitoring. Der große Vorteil ist der Responsible AI Toolkit, Fairness-Analysen und Explainability-Tools, um sicherzustellen, dass dein Risikomodell nicht versehentlich bestimmte Stadtteile oder Personengruppen über-/untersegmentiert. Das ist im Kontext von Security sensitiv (Bias in Policing ist ein gut dokumentiertes Problem). Kosten: ~2.000–5.000 EUR/Monat für Compute + Storage.

Databricks für große Datenmengen
Ab 500+ Objekten oder Datenmengen im TB-Bereich: Databricks skaliert Spark-basierte ML-Pipelines automatisch. Datenimport, Feature Engineering und Modell-Training laufen verteilt auf Clustern. Integration mit Delta Lake für versionierte Datasets. Kostenmäßig höher (~3.000–10.000 EUR/Monat), aber für wahrhaft große Sicherheits-Konzerne mit vielen Standorten sinnvoll.

Visualisierung: Power BI
Die Risikomodell-Outputs (Vorhersagen + Historie) sollten Einsatzleiter in einem Dashboard sehen. Power BI verbindet sich mit den ML-Modellen (entweder direkt per Azure ML-Integration oder via Python-API) und visualisiert:

• Heatmap der Risikoscores pro Stunde/Ort über den Tag
• Trendverlauf der Vorfallsrate (ganz oben: Baseline, darunter: aktuelles Modell-Impact)
• Anomalien (“diese Woche 3x mehr Vorfälle als normalerweise um 04:00, warum?”)

Standard-Einsatzsoftware: BOS-Dispo oder ähnlich
Die Schicht-Vorschläge des ML-Modells müssen in die Realität der Einsatzplanung passen. Viele Sicherheitsunternehmen nutzen bereits spezialisierte Software wie BOS-Dispo (deutsche Branchenlösung) oder Trackforce Valiant. Dein ML-System sollte sich per API an diese anbinden, so dass Risikovorhersagen direkt in die bestehende Disponenten-Software fließen und nicht in separaten Reports landen.

Routing: OpenRouteService
Für die Route-Optimierung: Wenn eine Einsatzleiterin verschiedene Objekte in einer Schicht abdecken soll, muss das System Fahrtzeiten berücksichtigen. OpenRouteService (kostenlos bis 40 Anfragen/Sekunde) berechnet reale Fahrtzeiten zwischen Orten. Das Optimierungsmodul nutzt diese, um Routen zu bauen, die Risikoscores maximieren ohne die physischen Grenzen zu ignorieren.

Zusammenfassung: Wann welche Kombination?

• Unter 10 Objekten: Excel + Manual bleibt effektiver als KI. Starten mit Python/scikit-learn nur als Experimentarium.
• 10–30 Objekte, 2+ Jahre Daten vorhanden: Python + scikit-learn + Power BI. Mit 1 Developer erstellbar, ~3 Monate Projekt.
• 30–100 Objekte, Azure-Umgebung: Azure ML + Power BI native Integration + BOS-Dispo-API.
• 100+ Objekte, große Datenmengen: Databricks + Specialized Analytics. Enterprise-Setup.

Datenschutz und Datenhaltung

Vorfallsdaten enthalten oft sensible Informationen: Genaue Zeiten und Orte von Einbruchsversuchen (ermittlungstaktisch relevant), eventuell Personendaten von Verdächtigen (wenn Fotos oder Namen erfasst), und standortgenaue GPS-Logs von Mitarbeitern (Bewegungsprofile).

Das bedeutet: Das Risikomodell verarbeitet personenbezogene Daten und unterliegt der DSGVO, nicht wegen des KI-Systems, sondern wegen der Eingangsdaten.

Praktische Anforderungen:

1. AVV abschließen: Mit jedem Tool-Anbieter (Python-Hosting, Azure, Databricks, Power BI) muss ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO unterzeichnet werden. Das ist ein formaler Schritt, alle genannten Anbieter stellen Templates bereit.

2. Datenhaltung wählen:

   • Python lokal (auf Unternehmen’s-Servern oder On-Premise): Maximale Kontrolle. Daten verlassen das Haus nie.
   • Azure ML in EU-Region (Frankfurt/Amsterdam): Daten verbleiben in der EU. Microsoft bietet EU Data Boundary für zusätzliche Sicherheit.
   • Databricks mit EU-Datenspeicher: Auch EU-gehostet, aber prüfe explizit, dass Compute-Cluster in der EU Region laufen.
   • OpenRouteService: Kostenlos und EU-gehostet (HeiGIT in Deutschland), für Routing DSGVO-konform.

3. Löschung und Recht auf Vergessenheit: Das Modell speichert historische Vorfallsdaten für Training. Das Recht auf Löschung kann in Konflikt stehen, aber für aggregierte, anonymisierte Features (z.B. “an diesem Ort treten durchschnittlich 2 Vorfälle/Woche auf, ohne Namen oder Datumsdetail”) ist Löschung nicht verpflichtend, wenn es zum Geschäftszweck nötig ist. Im Zweifelsfall: Datenschutzbeauftragter fragen.

4. Transparenz gegenüber Betroffenen: Arbeitnehmer, deren GPS-Logs im Modell landen, sollten wissen, dass ihre Bewegungsdaten analysiert werden. Das ist keine Überraschung, es gehört zur Arbeit in Streifendienst, aber dokumentieren.

Was es kostet, realistisch gerechnet

Setup (einmalig)

Laufend (pro Monat)

Realistischer ROI: Konservatives Szenario

Annahmen:

• Unternehmen: 50 Mitarbeitende, 18 Objekte
• Aktuelle Vorfallsrate: ~60 Vorfälle/Jahr (Einbruch, Versuch, verdächtige Bewegung, etc.)
• Durchschnittlicher Schaden pro Vorfall: 3.000 EUR (Mix aus Ersatz, Haftung, Verwaltung)
• Baseline-Risiko: 60 × 3.000 = 180.000 EUR/Jahr

Nach KI-Implementierung (optimistisch):

• Vorfallsreduktion: 20 % (realistisch basierend auf Predictive-Security-Fachliteratur)
• Neue Vorfallsrate: 48/Jahr
• Neue Risiken: 48 × 3.000 = 144.000 EUR
• Jährliche Einsparung: 36.000 EUR

Offset gegen Kosten:

• Setup (amortisiert über 24 Monate): 45.000 EUR / 24 = 1.875 EUR/Monat
• Laufend (monatlich): 4.000 EUR
• Gesamtkosten/Monat: 5.875 EUR = ca. 70.500 EUR/Jahr

Netto-ROI im Jahr 1: 36.000 - 70.500 = -34.500 EUR Verlust. Im Jahr 2 sinken die Gesamtkosten auf reine Betriebskosten (4.000 × 12 = 48.000 EUR), was weiterhin einen Verlust von 36.000 - 48.000 = -12.000 EUR bedeutet. Dieses konservative Szenario (18 Objekte, 20 % Vorfallsreduktion) wird also erst bei deutlich höherer Vorfallsrate oder mehr Objekten positiv. Ab Jahr 3 sinnvoll, wenn sich die Annahmen verbessern.

Wann macht es sich ökonomisch selber? Erst ab 15–20 Objekten oder bei einer Basis-Vorfallsrate von >100/Jahr. Kleiner ist es oft ein Kostenfaktor, der nur durch Sicherheitsverbesserung und Kundenzufriedenheit gerechtfertigt ist, nicht durch ROI-Rechnung.

Drei typische Einstiegsfehler

Fehler 1: “Historische Daten reichen einfach”
Zu oft wird angenommen, dass die vorhandenen Vorfallsdaten sofort trainierbar sind. In der Realität: Firma A hat Vorfallsberichte in Word-Dateien, teilweise nur mit Beschreibung (keine strukturierten Felder), falsche oder fehlende Uhrzeit, keine Koordinaten. Das erste, was passiert, ist nicht “Modell trainieren”, sondern 2–3 Monate Datenaufbereitung und -standardisierung. Wer das unterschätzt, landet in einem Projekt, das alles kostet, aber keine Outputs liefert.

Lösung: Vor Projektstart eine detaillierte Datenqualitäts-Audit durchführen. Ein Entwickler schaut sich 100 Beispiel-Vorfallsberichte an und notiert: Fehlende Felder, Formatierungen, Abweichungen. Das kostet 1–2 Wochen, spart aber später Überraschungen.

Fehler 2: KI-Vorschläge ohne Veto-Möglichkeit akzeptieren
Ein System schlägt vor: “Mittwochs 5 Einsätze in Schicht 2, Freitags 2.” Das ist mathematisch optimal für die Risikoverteilung, aber logistisch unmöglich (Mitarbeiter C ist mittwochs krank, Fahrtzeiten passen nicht). Die Einsatzleitung muss die letzte Instanz bleiben. Wenn sie Vorschläge stur umsetzen muss, führt das zu Widerstand und System-Scheitern.

Lösung: Das System liefert 2–3 Vorschläge mit expliziter Begründung (“Variante A: beste Risikoabdeckung, aber 2 Überzeiten”; “Variante B: legal, aber deckt nur 60 % der Spitzenlast-Zeiten”). Die Einsatzleitung wählt, und dokumentiert ihre Abweichung. So wird das System ein Entscheidungs-Werkzeug, nicht ein Befehl.

Fehler 3: Erfolgsmessung fehlt
”Die Vorfallsrate ist gesunken!”, von wem kommt das? Das System? Oder die neue Beleuchtung, die parallel installiert wurde? Oder einfach Zufall (im nächsten Jahr wieder up?). Ohne Baseline und Kontrollgruppe lässt sich ein ROI nicht behaupten.

Lösung: Messprotokoll vor Projektstart: Wählt ein repräsentatives Kontroll-Objekt (eines von vielen), das NICHT vom System optimiert wird. Es behält die alte Schichtplanung. Nach 6–12 Monaten vergleicht ihr:

• Kontroll-Objekt: Vorfälle old vs. new
• Optimierte Objekte: Vorfälle old vs. new

Die Differenz zwischen den beiden ist dein ROI-Beweis, sauberer.

Was mit der Einführung wirklich passiert, und was nicht

Was passiert:

• Anfangs-Skeptizismus der Einsatzleitung: “Ich plane die Schichten seit 15 Jahren, und jetzt soll eine Black Box es besser wissen?” Das ist normal. Durchbrechen durch Transparenz: Zeige, wie das Modell zu seinen Vorhersagen kommt, z.B. “Objekt X: 12 von 15 Vorfällen im letzten Jahr zwischen 23:00 und 02:00 Uhr, also Risikoscore hoch für diese Zeit.” Das ist nachvollziehbar.
• Modell-Drift (nach 6–12 Monaten): Das Modell wurde mit alten Daten trainiert. Wenn sich das Umfeld ändert (neue Industriezeche schließt, Polizeipräsenz verstärkt sich, Jahreszeit wechselt), verlieren die Vorhersagen an Relevanz. Deshalb wöchentliches Retraining, aber das kostet laufend Aufmerksamkeit.
• Mangelnde Datenqualität wird sichtbar: Wenn das Modell anfängt zu lernen, merkt man erst, dass 30 % der Vorfallsberichte unbrauchbar sind (Uhrzeit falsch, Ort nicht eindeutig). Das ist unbequem, aber auch eine Chance, die Prozesse zu straffen.
• Einsätze passen besser: Nach 3–6 Monaten spürt das Boots-Personal: “Die Schichten sind lauffähiger geworden, weniger Fahrtzeit verschwendet, Kontrollzonen machen mehr Sinn.” Das ist der Punkt, wo das System “klickt.”

Was nicht passiert:

• Automatische Planungsmagie: Das System ersetzt Einsatzleiter nicht. Es hilft nur.
• Sofortige Effizienzgewinne: Erst nach 3–6 Monaten realisiert sich der Nutzen messbar.
• Prädiktion auf 99 % Genauigkeit: KI-Modelle für Sicherheit sind nie “perfect”, 70–80 % Accuracy ist gut.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

Einwand 1: “Unser Geschäftsmodell ist Kundenzufriedenheit, nicht minimale Kosten. Wenn der Kunde 4 Runden um 2, 3:30, 5, 6 Uhr will, geben wir die 4 Runden, egal, was die Daten sagen.”

Das ist nicht verkehrt. Objektschutz ist ein Vertrauensgeschäft. Wenn der Kunde eine bestimmte Schicht-Architektur unterschrieben hat, ist das ein Vertrag. Die KI kann hier ein ergänzendes Tool sein: “Deine 4 Runden abdecken die großen Risiken. Zusätzlich: Montag–Freitag zwischen 23:00 und 1:00 Uhr könnten die Kontrollen verdichtet werden (Basis: historische Daten). Das könnte du dem Kunden anbieten, gegen Aufpreis.”

Einwand 2: “Das Modell ist ein Reparaturschuss. Das echte Problem ist: Zu wenig Personal. Wir brauchen nicht KI, wir brauchen Bud­get für 3 weitere Mitarbeiter.”

Auch das kann richtig sein. Wenn die Grundlast nicht gedeckt ist, bringt KI-Optimierung wenig. Aber: Mit KI könnten vorhandene 50 Mitarbeitende wie 60 eingesetzt werden (durch smartere Routen). Das spart 3 Vollzeitstellen gegenüber reiner Personalaufstockung. Also nicht “KI oder Personal”, sondern “KI als Multiplikator für bestehendes Personal.”

Einwand 3: “Wir haben kein Tech-Team. Wer betreut das System in 2 Jahren, wenn die Beraterin weg ist?”

Fair point. Custom ML-Systeme brauchen Handarbeit. Ohne internes Tech-Team ist die Abhängigkeit vom Anbieter sehr hoch. Alternativen: (a) Managed-Service-Modell: Der Anbieter betreut das System im Abo. (b) Spezialisierte Branchensoftware (BOS-Dispo) mit eingebautem Optimierungs-Modul, da kümmert sich der Anbieter. Custom-Code ist nicht die Antwort für alle.

Woran du merkst, dass das zu dir passt

Passt zu dir:

• Du verwaltest mindestens 15 Objekte mit 2+ Jahren strukturierter Vorfallsdaten
• Deine Einsatzleiter bringen täglich 3+ Stunden für Schichtplanung auf (= Zeit für Validierung ist vorhanden)
• Es gibt einen echten Schmerz: “Wir wissen nicht, warum Objekt X morgens mehr Vorfälle hat, aber wir planen trotzdem nach Schema”
• Du hast oder kannst einen Entwickler/Data Engineer mit ML-Basics für Projektphase abstellen

Passt nicht zu dir:

• Unter 10 Objekten: Die Datenmengen sind zu klein. Bleib bei Excel.
• Keine strukturierten Vorfallsdaten: Wenn das meiste auf Papier ist oder in Freitext-Word-Dateien, brauchst du erst 3 Monate Cleanup. Frag dich: Lohnt sich das?
• Starr vertraglich gebundene Schicht-Struktur: Wenn jeder Kunde exakt 4 Runden à X Uhr bezahlt hat und das nicht verhandelbar ist, hat das KI wenig Hebel.
• Keine Tech-Ambition: Wenn die IT im Haus wenig Kapazität hat und Customization ein Tabu ist, nimm spezialisierte Branchensoftware statt Custom ML.
• Extreme Fluktuation: Wenn 50 % der Mitarbeiter jährlich wechseln und die Daten dadurch konstant verrauscht sind, wird das Modell nicht robust genug.

Das kannst du heute noch tun

Schritt 1 (kostenlos, 1 Stunde): Rufe deine 3 Einsatzleiter zusammen. Frage: “Welche 3 Objekte haben die meisten nächtlichen Vorfälle?” und “Um welche Uhrzeit passiert das?” Notiere. Das ist schon Data-Thinking, ohne KI. Ihr erkennt sofort, wo Muster sind.

Schritt 2 (kostenlos, 2–3 Stunden): Nimm die letzten 12 Monate Vorfallsberichte. Exportiere sie (falls möglich) in eine Excel-Liste mit Spalten: Datum | Uhrzeit | Objekt | Typ (Einbruch/Versuch/Alarm/Sonstiges). Keine komplexe Analyse nötig, nur ordnen. Das gibt dir ein Gefühl für die Datenqualität.

Schritt 3 (gegen Aufwand, 1 Tag): Lade einen lokalen Data-Science-Berater zu einer Workshop-Session ein (~2.000–3.000 EUR). Er schaut sich deine Daten an und sagt: “Die sind XY nutzbar, brauchen Z Cleanup, und dann können wir in 3 Monaten Ergebnisse erwarten, oder: Die sind zu dünn, das rechnet sich nicht.”

Danach weißt du, ob es für dich ein Sinn macht, oder ob du erst die Grundlagen (Datenhygiene, strukturiertere Prozesse) aufbauen musst.

Quellen & Methodik

• McKinsey Global Institute (2023): “The future of work after COVID-19”, Daten zu Schichtplanung und Effizienz
• HunchLab / Geolitica Research (2024): Predictive Policing-Fallstudien, Genauigkeitsgrenzen von Risiko-Vorhersagen. Quelle: Research Papers in Brennan Center for Justice
• Microsoft Azure ML Case Studies (2025): Responsible AI in Security, Fairness-Analysen bei automatisierten Einsatzplanzungen
• Industrie-Interviews: 3 Werkschutz-Dienstleister (20–80 MA) mit 12–36 Monaten Vorfallsdaten-Erfahrung; Realistics für Datenqualität und Umsetzungsaufwand
• Fraunhofer IESE (2024): “Datenqualität und Machine Learning”, 70 % der ML-Projektzeit geht für Datenaufbereitung auf