[et_pb_section fb_built=“1″ _builder_version=“4.27″][et_pb_row][et_pb_column type=“4_4″][et_pb_text]<\/p>\n
Ein OEE Dashboard Bedienterminal<\/strong> ist kein Visualisierungs-Spielzeug \u2013 es ist ein Arbeitswerkzeug, das die Effektivit\u00e4t ganzer Schichten bestimmt. Das Design dieses Terminals entscheidet dar\u00fcber, ob der Bediener die Plattform akzeptiert, die Qualifizierungs-Compliance hoch bleibt und die abgeleiteten Pareto-Analysen tragf\u00e4hige Verbesserungen erm\u00f6glichen. Dieser Beitrag erkl\u00e4rt die Design-Prinzipien, die sich in DACH-Mittelstandsbetrieben durchgesetzt haben.<\/p>\n Adressat sind Methoden-Ingenieure, UX-Designer von Industrie-4.0-Plattformen und Werksleiter, die ein bestehendes Bedienterminal-Design hinterfragen oder ein neues spezifizieren m\u00fcssen. Der Beitrag baut auf dem verwandten Pillar Echtzeit-Leistungs\u00fcberwachung: Was Bediener wirklich sehen<\/a> auf.<\/p>\n Aus mehreren hundert validierten DACH-Implementierungen konsolidieren sich f\u00fcnf Design-Prinzipien, die f\u00fcr jedes OEE-Bedienterminal gelten sollten. Jedes Prinzip l\u00e4sst sich aus einer konkreten Schicht-Beobachtung herleiten.<\/p>\n Das Bedienterminal wird nicht aktiv betrachtet, sondern beim Vorbeigehen erfasst. Innerhalb von 1,5 bis 2 Sekunden muss der Bediener den aktuellen Zustand erfassen k\u00f6nnen. Diese Anforderung an „Glanceability“ hat Konsequenzen f\u00fcr jedes Layout-Element: Schriftgr\u00f6\u00dfen ab 24 Punkt f\u00fcr die Hauptanzeige, Kontrast-Verh\u00e4ltnisse \u00fcber 7:1 (analog zu WCAG-AAA-Standards), Ampel-Farbschema (gr\u00fcn\/rot\/gelb) als dominantes visuelles Element.<\/p>\n Was nicht in zwei Sekunden lesbar ist, wird vom Bediener ignoriert. Diese Regel gilt unabh\u00e4ngig davon, wie wertvoll die Information aus Anbieter-Sicht ist.<\/p>\n Layer 1 ist die immer-sichtbare Hauptanzeige: Maschinenstatus mit Ampel und Schichtfortschritt. Layer 2 sind Pop-ups, die kontextbezogen aktiviert werden \u2013 prim\u00e4r die Qualifizierungs-Aufforderung bei Stillstand. Layer 3 sind die optionalen Erg\u00e4nzungsangaben (Detail zur aktuellen Auftragsabwicklung, Werkstoff-Status, Werkzeug-Information), die durch eine bewusste Geste erreichbar sind.<\/p>\n Mehr als drei Layer \u00fcberlasten die mentale Karte des Bedieners. Vier oder f\u00fcnf Ebenen f\u00fchren erfahrungsgem\u00e4\u00df dazu, dass nur Layer 1 und 2 jemals verwendet werden und alles tiefere brachliegt.<\/p>\n Jede produktive Bedien-Aktion am Terminal sollte in maximal drei Gesten erreichbar sein. Stillstands-Qualifizierung: Kategorie w\u00e4hlen (1), Sub-Kategorie w\u00e4hlen (2), Best\u00e4tigen (3). Werkzeugwechsel-Best\u00e4tigung: Werkzeug-Tab \u00f6ffnen (1), aktuelles Werkzeug ausw\u00e4hlen (2), Wechsel best\u00e4tigen (3). Vier oder mehr Gesten f\u00fchren zur Aufgabe des Vorgangs \u2013 die Compliance bricht ein.<\/p>\n Dieses Drei-Gesten-Prinzip gilt auch f\u00fcr die Sprachumschaltung, das Login (falls erforderlich) und alle anderen Bediener-Aktionen am Terminal.<\/p>\n Wenn der Bediener auf das Terminal tippt, muss innerhalb von 200 Millisekunden eine visuelle Best\u00e4tigung erscheinen \u2013 Farb\u00e4nderung, Pulsation, Hervorhebung des angew\u00e4hlten Elements. L\u00e4ngere Latenzen f\u00fchren zu Mehrfach-Tipps, ungewollten Doppel-Aktionen und Frustration.<\/p>\n Diese 200-Millisekunden-Regel gilt f\u00fcr die UI-Schicht, nicht f\u00fcr die Server-Antwort. Die UI muss optimistisch reagieren („Aktion erkannt“) und im Hintergrund die Server-Best\u00e4tigung abwarten.<\/p>\n Das Bedienterminal arbeitet in Schichtumgebungen mit Schmiermittel-Spr\u00fchnebel, Staub, Vibrationen, Temperaturschwankungen, gelegentlich nassen Bedienerh\u00e4nden. IP65-Schutzart ist der Mindeststandard. Touch-Empfindlichkeit muss auch bei Arbeitshandschuhen funktionieren \u2013 das ist eine Hardware-Auswahl-Frage (Pro-Cap-Touch statt resistivem Touch, ggf. mit Glove-Mode).<\/p>\n Was im klimatisierten Demo-Showroom funktioniert, kann in der realen Halle versagen. Die Hardware-Auswahl muss zur Schicht-Realit\u00e4t passen.<\/p>\n Aus den f\u00fcnf Prinzipien leitet sich ein Standard-Layout ab, das in den meisten DACH-Implementierungen tragf\u00e4hig ist.<\/p>\n Oberer Bereich (Header)<\/strong>: Maschinenbezeichnung links, Datum\/Uhrzeit rechts, Sprachsymbol oben rechts. Dieser Bereich ist statisch und dient der Orientierung.<\/p>\n Mittlerer Bereich (Hauptanzeige)<\/strong>: Gro\u00dfer Ampel-Statusbalken (gr\u00fcn\/rot\/gelb), darunter Schichtfortschritt (Soll\/Ist\/Differenz). Dieser Bereich ist die Glanceability-Zone \u2013 er muss in unter 2 Sekunden erfassbar sein.<\/p>\n Unterer Bereich (Aktions-Buttons)<\/strong>: Drei bis vier gro\u00dfe Buttons f\u00fcr die h\u00e4ufigsten Aktionen \u2013 Werkzeugwechsel starten, Auftrag wechseln, Hilfe rufen, Eintrag im Schichtbuch. Diese Buttons sind statisch positioniert, damit der Bediener Muskelged\u00e4chtnis aufbauen kann.<\/p>\n Pop-up-Overlay<\/strong>: Wird bei Stillstands-Erkennung aktiviert. Zeigt die Qualifizierungs-Aufforderung als Modal-Overlay \u00fcber der Hauptanzeige. Schlie\u00dft sich automatisch nach Best\u00e4tigung. Wenn nicht innerhalb von 10 Minuten qualifiziert, wird ein „Unbekannt“-Default gesetzt und das Overlay schlie\u00dft.<\/p>\n Dieses Layout funktioniert auf Touchscreens zwischen 10 und 15 Zoll. Bei kleineren Tablets ist eine Anpassung des Layer-3-Bereichs n\u00f6tig.<\/p>\n Im Gegensatz zum Bedien-Terminal ist das Schichtleiter-Dashboard f\u00fcr analytische \u00dcbersichten konzipiert. Es zeigt typischerweise:<\/p>\n Eine Multi-Maschinen-Heatmap mit Ampel-Status aller Anlagen einer Linie oder eines Verantwortungsbereichs. Eine Schichtfortschritts-Tabelle mit Soll\/Ist pro Maschine. Eine Live-Pareto der h\u00e4ufigsten Stillstands-Ursachen der laufenden Schicht. Trend-Charts f\u00fcr OEE \u00fcber die letzten 24 Stunden bis 7 Tage. Eine Alarm-Liste f\u00fcr ungew\u00f6hnliche Ereignisse (Stillstand-H\u00e4ufung, Performance-Einbruch).<\/p>\n Dieses Dashboard l\u00e4uft typischerweise auf einem 22- bis 27-Zoll-Monitor im Meisterzimmer und erg\u00e4nzend auf einem Schichtleiter-Tablet, das die wesentlichen Informationen mobil bereitstellt.<\/p>\n Wichtig: Die Schichtleiter-Sicht ist eine andere Anwendung als die Bediener-Sicht, auch wenn beide auf denselben Daten beruhen. Das Versuchen, beide Sichten in ein einziges Interface zu pressen, f\u00fchrt erfahrungsgem\u00e4\u00df zu Akzeptanz-Problemen auf beiden Seiten.<\/p>\n Die Mobile-App \u2013 auf einem geteilten Schicht-Tablet oder auf Schichtleiter-Smartphones \u2013 hat eigene Design-Anforderungen, die sich aus der mobilen Nutzungssituation ableiten.<\/p>\n Bediener-Mobile-App: Reduzierte Funktionalit\u00e4t (nur Qualifizierung und Schichtfortschritt), gro\u00dfe Touch-Ziele f\u00fcr Bedienung mit Arbeitshandschuhen, robuste Offline-Funktion (Qualifizierungen lokal cachen und synchronisieren, sobald wieder Konnektivit\u00e4t besteht).<\/p>\n Schichtleiter-Mobile-App: Volle \u00dcbersichts-Funktionalit\u00e4t, Push-Notifications f\u00fcr Eskalations-Trigger (etwa: Maschine X seit 30 Minuten Stillstand ohne Qualifizierung), schneller Zugriff auf Pareto-Analysen der letzten Schicht.<\/p>\n Beide Apps m\u00fcssen auf Android (Mindestversion typischerweise 8.0) und iOS (Mindestversion 14) funktionieren. Native Apps sind in der DACH-Praxis besser akzeptiert als Web-Apps, weil sie zuverl\u00e4ssiger funktionieren bei wechselnder Netzqualit\u00e4t und weil sie tieferen Ger\u00e4te-Funktionen (Push, Kamera f\u00fcr QR-Scan) zugreifen k\u00f6nnen.<\/p>\n Das Bedienterminal arbeitet selten isoliert. In der DACH-Praxis kommt es typischerweise zu Schnittstellen mit ERP-Systemen (Auftragsabschluss, Materialverbrauch), MES-Systemen (falls vorhanden, f\u00fcr Auftrags-Best\u00e4tigung), Schichtbuch-Systemen (manuelle Eintr\u00e4ge) und Wartungs-Systemen (Ausl\u00f6sen von Wartungstickets bei wiederkehrenden Stillst\u00e4nden).<\/p>\n Diese Integrationen sollten unsichtbar f\u00fcr den Bediener funktionieren. Wenn der Bediener einen Auftrag abschlie\u00dft, soll der Auftrag automatisch im ERP-System geschlossen werden \u2013 ohne dass der Bediener doppelt eingeben muss. Wenn ein Wartungsticket erforderlich ist, soll es im Hintergrund erzeugt werden \u2013 die Schichtleitung erh\u00e4lt die Benachrichtigung in ihrer App.<\/p>\n Diese Hintergrund-Integrationen sind technisch anspruchsvoll, aber sie sind der Schl\u00fcssel zur Bediener-Akzeptanz. Ein Bedienterminal, das den Bediener zwingt, dieselbe Information zweimal einzugeben (einmal in das OEE-System, einmal in das ERP), wird sehr schnell abgelehnt.<\/p>\n Bevor ein Bedienterminal-Design produktiv geht, ist eine kurze Validierung mit echten Bedienern unter Schichtbedingungen zwingend. Eine bew\u00e4hrte Vorgehensweise:<\/p>\n Phase 1 \u2013 Konzept-Review<\/strong>: Das Layout wird der Schicht-Vertretung (zwei oder drei erfahrene Bediener) vorgestellt. Erste Reaktionen werden aufgenommen.<\/p>\n Phase 2 \u2013 Mockup-Test<\/strong>: Ein klickbarer Prototyp wird in der Halle aufgebaut. Bediener probieren in normalen Schichtbedingungen die Hauptfunktionen. Beobachter notieren H\u00fcrden.<\/p>\n Phase 3 \u2013 Pilot-Schicht<\/strong>: Das Terminal wird an einer Maschine produktiv installiert. \u00dcber zwei Wochen werden Compliance-Rate (Anteil qualifizierter Stillst\u00e4nde) und Bediener-Feedback erhoben.<\/p>\n Phase 4 \u2013 Iteration<\/strong>: Basierend auf den Pilot-Erfahrungen wird das Design angepasst. H\u00e4ufige Anpassungen: Kategorien zusammenf\u00fchren, die kaum genutzt werden; Buttons umpositionieren, weil sie \u00fcbersehen wurden; Schriftgr\u00f6\u00dfen erh\u00f6hen; Touch-Empfindlichkeit kalibrieren.<\/p>\n Phase 5 \u2013 Rollout<\/strong>: Erst nach der Iteration erfolgt der Rollout auf den gesamten Maschinenpark. Dieser disziplinierte Ablauf vermeidet teure R\u00fcckrufe und Akzeptanz-Probleme im gro\u00dfen Stil.<\/p>\n Aus der DACH-Praxis kommen wiederholt dieselben Design-Fehler vor, die sich vermeiden lassen.<\/p>\n Fehler 1 \u2013 Zu viele Hauptkategorien<\/strong>. 12, 15 oder 20 Stillstands-Hauptkategorien wirken auf den ersten Blick „vollst\u00e4ndig“. In der Praxis l\u00f6sen sie Abbruch-Verhalten aus, weil der Bediener nicht durch eine 15-Optionen-Liste scrollen will. Maximum sind 8 Hauptkategorien.<\/p>\n Fehler 2 \u2013 Vergessene Mehrsprachigkeit<\/strong>. Wenn das Terminal nur Deutsch unterst\u00fctzt, schlie\u00dft es einen relevanten Teil der DACH-Belegschaft aus. Mindestens Deutsch, Englisch, T\u00fcrkisch, Polnisch ist die Faustregel.<\/p>\n Fehler 3 \u2013 Glanceability geopfert f\u00fcr Sch\u00f6nheit<\/strong>. Schlanke serif Schriftarten, blasse Pastellfarben, dezente Graustufen wirken im Marketing-Mockup elegant. In der Halle mit 200 Lux Beleuchtung und schmierigen Bedienerh\u00e4nden sind sie unleserlich. Hohe Kontraste, kr\u00e4ftige Sans-Serif-Schriften und kr\u00e4ftige Ampelfarben sind die richtige Wahl.<\/p>\n Fehler 4 \u2013 Doppelte Datenerhebung<\/strong>. Bediener m\u00fcssen Stillstands-Ursachen im OEE-System eingeben, parallel Wartungs-Anfragen ins CMMS schreiben und Auftrags-Abschluss ins ERP melden. Das ist nicht haltbar. Das OEE-Bedienterminal muss als zentrale Eingabe-Schnittstelle fungieren und im Hintergrund die anderen Systeme bedienen.<\/p>\n Fehler 5 \u2013 Fehlende Iteration nach Rollout<\/strong>. Ein Bedienterminal-Design ist nie fertig. Schicht-Routinen \u00e4ndern sich, Maschinen-Typen kommen hinzu, Sprachen werden erg\u00e4nzt, neue Stillstandsursachen werden identifiziert. Eine quartalsweise Design-Iteration mit Schichtleiter-Feedback ist die Faustregel.<\/p>\n Wenn Sie ein OEE Dashboard Bedienterminal in Ihrem Werk planen oder ein bestehendes \u00fcberarbeiten m\u00f6chten, empfiehlt sich folgender Ablauf: Beginnen Sie mit einer Bedien-Beobachtung \u00fcber zwei Schichten (Fr\u00fch und Sp\u00e4t) an einer typischen Maschine. Erfassen Sie, wie viele Sekunden die Bediener aktuell auf welche Anzeigen schauen, welche Aktionen sie wie oft ausf\u00fchren, welche Stillstand-Ursachen sie als Top-3 nennen.<\/p>\n Auf dieser Basis spezifizieren Sie die Anforderungen: welche Pflicht-Informationen, welche Aktionen, welche Sprachen, welche Schnittstellen. Holen Sie zwei oder drei Anbieter-Angebote ein, basierend auf dieser Spezifikation. Achten Sie auf die Iterations-F\u00e4higkeit der Plattform: kann das Design quartalsweise angepasst werden, oder ist es fest verdrahtet?<\/p>\n Planen Sie einen 2- bis 4-w\u00f6chigen Pilot auf einer Maschine, bevor Sie skalieren. Skalieren Sie erst, wenn die Compliance-Rate stabil \u00fcber 85 Prozent liegt und die Bediener-Akzeptanz sp\u00fcrbar ist.<\/p>\n Mehr \u00fcber die TeepTrak-Plattform f\u00fcr OEE-Bedienterminals finden Sie auf teeptrak.com<\/a>.<\/p>\nDie f\u00fcnf Design-Prinzipien f\u00fcr ein wirksames Bedienterminal<\/h2>\n
Prinzip 1: Glanceability vor Funktionsumfang<\/h3>\n
Prinzip 2: Maximal drei Informations-Layer<\/h3>\n
Prinzip 3: Geste-Effizienz \u2013 maximal drei Aktionen<\/h3>\n
Prinzip 4: Visuelle Feedback-Schleife innerhalb von 200 Millisekunden<\/h3>\n
Prinzip 5: Robustheit gegen\u00fcber Schichtumgebung<\/h3>\n
Layout-Standardmuster f\u00fcr das Bedienterminal<\/h2>\n
Schichtleiter-Dashboard: Was zus\u00e4tzlich gezeigt wird<\/h2>\n
Mobile-App-Design f\u00fcr Bediener und Schichtleiter<\/h2>\n
Integration mit Bestandssystemen<\/h2>\n
Validierung des Bedienterminal-Designs<\/h2>\n
H\u00e4ufige Design-Fehler und ihre Vermeidung<\/h2>\n
Wie Sie als n\u00e4chstes vorgehen<\/h2>\n