Oft wird uns die Frage gestellt, was eigentlich die genaue Motivation hinter Peakboard ist und warum wir glauben, dass die Welt dieses Produkt braucht. Dieser erste Blogpost soll ein wenig den Werdegang erzählen.

Die initiale Idee zu Peakboard geht weiter zurück, als es in der digitalen Welt üblich wäre, nämlich fast 15 Jahre bis ins Jahr 2002. Nach erfolgreichem Abbruch meines Physikstudiums war ich festangestellter Entwickler beim großen „Schrauben-Würth“. Trotz Großkonzernstrukuren herrschte eine ausgeprägte Bereitschaft für pragmatische Neuerungen rund um den Bereich Logistik. Zum einen natürlich die Straffung und Optimierung interner Logistikprozesse, aber auch ein stetiger Fluss an Innovationen hin zum Kunden – in meinem Fall Großkunden der Industriebranche.

Der damalige Chef kam mit dieser Idee des sogenannten Nasa-Cockpits ins Meeting. So wird es im Übrigen noch heute genannt. Es sollten große Monitore aufgestellt werden, die Logistik-Kennzahlen in Echtzeit anzeigen. Falls Besucher durch die Hallen geführt werden, könnte man mit beeindruckenden Zahlen angeben und falls das gerade nicht der Fall wäre, könnte man den Mitarbeitern ein Gefühl und Verständnis für den Durchlauf durch die große Logistikmaschine geben, deren schiere Komplexität per se einen guten Gesamtüberblick verhindert. Das Nasa-Cockpit bleibt allen Beteiligten als sehr, sehr aufwändiges Prestigeprojekt in Erinnerung. Es hat etliche Mannmonate an Programmierarbeit verschlungen, die sich mit den Konzepten von Peakboard auf wenige Tage oder gar Stunden hätten komprimieren lassen.

Die zweite Ideen-Wurzel ist weniger eindeutig auf eine dedizierte Sache zurückzuführen. Dabei geht es eher um unser tradionelles Geschäft von Theobald Software, der Mutterfirma von Peakboard. Hier wird unsere Software in der Regel in klassischen Architekturen für Business Intelligence eingesetzt. Sehr verkürzt dargestellt, werden Daten aus operativen Systemen (z.B. SAP) abgezogen, aufbereitet, abgemischt, angereichtert, in einem Data Warehouse abgelegt, multidimensional in-memory geladen, um dann ganz am Ende dieser langen Reise in einer Analyseumgebung wie Tableau, Qlik oder Power BI angezeigt zu werden. Was sich für klassische Kennzahlenanalyse als üblicher, herstellerübergreifender Weg etabliert hat, funktioniert natürlich zur direkten Steuerung eines operativen Prozesses nicht. Dafür gibt es zwei wichtige Gründe: Erstens dürfen die angezeigten Daten sinnvollerweise nicht älter als einige Minuten oder gar Sekunden sein, je nach Anwendungsfall möglicherweise sogar komplett ohne Zeitversatz (z.B bei einer Maschinensteuerung). Der zweite Grund gegen einen klassischen BI-Weg ist die Agilität. Der oben beschriebene Weg setzt ein gewisses Maß an struktureller Planung voraus. Jede Änderung muss in mehreren Schichten (Extraktion, Aufbereitung, Speicherung etc.) nachgezogen werden. Das ist natürlich Gift für jede agile Anpassung des Prozesses und führt zu hässlichen, unübersichtlichen Workarounds, anstatt Agilität als Möglichkeit des Wettbewerbsvorteils aktiv zu fördern. Jeder hat schonmal den Satz gehört „das lassen wir vorerst; da brauchen wir die IT dazu“ – ein Killerargument.

Es gibt mit Sicherheit viele Argumente für das Peakboard-Konzept, aber diese beiden – Zeitversatz und Agiltät – stehen am Besten für die Peakboard-Idee und warum es eben nicht mit einem ausrangierten PC, den man an einen Monitor anschließt, getan ist.

Teilen:
FacebookTwitter