COO — Operationalisierung von RTLS, RFID und IoT.
For a COO, an RTLS, RFID or IoT programme has to move an operational KPI — cycle time, OEE, fill rate, dock-to-stock, OTIF, length-of-stay.
It also has to land in an operating environment where front-line operators actually use it, sustainably, after the implementation team leaves. This insight covers how we think about both halves of that job with COO clients.
Die zugrundeliegende Frage des COO
Not "will the technology work?" — but "will the technology, integrated into our operations, deliver a measurable improvement in the operational KPIs that I'm accountable for,
that holds after the project team leaves?" Most failed RTLS programmes at the COO level fail not because the technology didn't work, but because the operational and adoption work was treated as secondary.
The COO should require operational KPI alignment, adoption design and integration architecture as scoping inputs — not as afterthoughts.
KPI-Ausrichtung – die Gating-Frage
Every RTLS deployment should be scoped against 1–3 specific operational KPIs the COO already tracks. Herstellung: OEE, WIP turn, cycle time variance, first-pass yield. Logistik: dock-to-stock, OTIF, inventory accuracy, throughput per labour hour.
Gesundheitswesen: average length of stay, OR turnover time, hand-hygiene compliance rate, asset utilisation. If the deployment can't be tied to a tracked operational KPI, it shouldn't proceed.
This filter alone kills 30–40% of typical RTLS business cases at the diagnostic stage — usually because the underlying use case was speculative.
Adoptionsdesign – das zweitschwierigste Problem
Operations leaders know that technology deployments fail at adoption more often than at deployment. RTLS adoption depends on three things. Workflow integration: the system has to make a specific operator's job easier or required, not just produce reports for management.
Trust: front-line operators need to trust the data, which means visible accuracy and reliable response when they flag errors.
Time-to-utility: operators have to see benefit within their first week of using the system, not their first quarter. We design for adoption in stage 1 alongside the technical architecture.
Change Management – das drittgrößte Problem
Process change is the leverage point that turns RTLS data into operational KPI improvement. Without process change, the data is reporting overhead, not value.
The COO should require a documented process-change plan as part of the deployment scope, covering: new standard work, decision rights at each level, escalation paths, and what stops being done because the system replaces it.
The system is the smaller half of the change; the process change is the larger half.
Integration mit Betriebssystemen
RTLS data has to flow into systems operators already use — MES on the shop floor, WMS at the dock, EMR at the bedside, EAM for asset management. Standalone RTLS dashboards rarely get adopted; integrated alerts in the operator's existing tooling get adopted.
The COO should require integration into operations systems as a deployment gate, not as a downstream feature. See /integrations for our enterprise integration patterns.
Programmleitung – unter deren Eigentum
RTLS programmes that fail at the COO level often fail at governance — they're owned by IT or by an external consultant rather than by operations. The COO should own the programme governance, with IT and finance as supporting functions.
Steering committee should have operational metrics on every agenda, not just project milestones. We work as independent programme advisors to COOs in this model. See /for-coo for the dedicated COO persona page.
Häufig gestellte Fragen
Wie verknüpfen wir eine RTLS-Bereitstellung mit OEE?
Konkret durch die Messung, welche OEE-Komponente das Programm bewegen soll (Verfügbarkeit, Leistung, Qualität) und welche Ursache es adressiert.
Die Sichtbarkeit von WIP verbessert die Leistung; Der Standort der Werkzeuge verbessert die Verfügbarkeit. Wir entwerfen das OEE-Attributionsmodell in Stufe 1.
Wie lange dauert die Adoption in der Praxis?
Einführung auf Operator-Ebene: 4–12 Wochen mit fokussiertem Change Management; Länger ohne. Entscheidungsfindung auf Managementebene: 8–24 Wochen. Wir entwerfen für beide Zeitrahmen im Umsetzungsplan.
Sollte der Betrieb das Programm übernehmen oder die IT?
Die Operationen sollten die Ergebnisse und die Governance übernehmen; Die IT sollte die Plattformbereitstellung und -integration übernehmen. Gemeinsame Verantwortlichkeit mit getrennten Entscheidungsrechten funktioniert in der Praxis am besten.
Welche Rolle hat der Systemintegrator im Vergleich zum Betriebsteam?
Der Systemintegrator übernimmt die technische Bereitstellung; Das Betriebsteam übernimmt die Prozessänderung und -übernahme. Programme scheitern, wenn diese Rollen verwechselt werden – wir entwerfen das RACI explizit in Phase 1.
Wie gehen wir mit Widerstand der Bediener um?
Widerstand ist meist ein Signal dafür, dass die Integration von Arbeitsabläufen falsch ist – Betreiber widerstehen rational Systemen, die Arbeit ohne Wert hinzufügen. Wir diagnostizieren das Workflow-Problem und gestalten es neu, anstatt den Widerstand zu "managen".
Zuletzt aktualisiert: