Beleg
Wer für ein Werk einkauft, kauft vor allem Risiko ab. Auf dieser Seite zeigen wir, dass dieses Risiko schon einmal getragen wurde. Solange wir kein belegtes Projekt zeigen können, füllen wir den Platz nicht mit Ersatz — wir veröffentlichen den Maßstab.
Projekte mit schriftlicher Freigabe des Kunden, deren Zahlen wir gemeinsam mit der Messmethode nennen können.
Zurzeit ist keine Referenz veröffentlicht. Uns liegen weder ein freigegebener Kundentext noch eine belegte Messung vor, und ohne beides kommt kein Projekt in diese Liste.
Veröffentlichungsregel
Wir schreiben die Regel vorher auf, denn eine nachträglich formulierte Regel ist keine.
Kundenname, Projektname und jeder zitierte Satz erscheinen nur mit schriftlicher Freigabe. Einen Satz, den wir nicht freigeben lassen können, streichen wir — wir formulieren ihn nicht weicher.
Neben jeder Zahl steht, was wo und über welchen Zeitraum gemessen wurde. Prozentwerte ohne Kontext nennen wir nicht, und eine Verbesserung, die wir nicht messen konnten, schreiben wir auch nicht auf.
Wird der Kundenname nicht freigegeben, veröffentlichen wir das Projekt trotzdem: Branche, Größenordnung und Problem bleiben echt, nur der Name entfällt. Ein anonymes Projekt ist besser als gar keines.
Aufbau einer Referenz
Die Reihenfolge steht fest. Wer Abschnitte auswählt, stellt den gut gelaufenen Teil nach vorn; deshalb schreiben wir alle, immer in dieser Reihenfolge.
Branche, Größe des Werks, Dauer des Projekts, eingesetzte Leistungen und die beteiligten Systeme.
Was vor dem Start wie lange gedauert hat. Wo nichts gemessen wurde, messen wir zuerst; ein Ergebnis ohne Ausgangspunkt lässt sich nicht lesen.
Was wir nicht ändern konnten: eine Linie, die nicht stehen darf, ein ERP, das niemand anfassen darf, Hardware, die bleibt, ein fester Schichtplan.
Welcher Schritt in welcher Reihenfolge kam, was an welchem Entscheidungspunkt gewählt wurde und warum.
Architektur, Schnittstellen, Datenfluss und Berechtigungen. Für technische Leserinnen und Leser geschrieben und nicht gekürzt.
Die Ergebniszahlen, jede mit ihrer Messmethode. Was wir nicht messen konnten, beschreiben wir im Text und nie im Ergebnisblock.
Was wir zuerst falsch gebaut haben, wo wir zurückgegangen sind, welche Annahme nicht gehalten hat. Lässt man diesen Abschnitt weg, bleibt Werbung übrig und kein Projektbericht.
Woran wir arbeiten
Das Folgende sind Problembeschreibungen, keine behaupteten Ergebnisse. Wenn Sie eines davon in Ihrem Werk wiedererkennen, sind Sie richtig hier.
ERP, MES und die Systeme in der Fertigung laufen einzeln korrekt und zusammen nicht. Derselbe Fertigungsauftrag steht an drei Stellen in drei Zuständen.
Das Schichtbuch, eine Tabelle, die herumgereicht wird, ein Störungsgrund, der telefonisch weitergegeben wird. Die Daten werden erfasst, liegen aber im Moment der Entscheidung nicht vor.
Das Modell läuft in der Demo und nicht an der Linie. Meist liegt es nicht am Modell, sondern am Datenfluss und daran, wie in Betrieb genommen wurde.
Es wurde eingeführt, geschult wurde auch, genutzt wird es nicht. Das Team arbeitet wieder wie vorher, weil der neue Weg den Arbeitstag bremst.
Anonymes Projekt
Wir haben die anonyme Form von Anfang an entworfen, damit wir sie nicht an dem Tag improvisieren müssen, an dem eine Freigabe ausbleibt.
Die Karte unten ist kein echtes Projekt. Kunde, Ergebnis und Schlagworte sind Platzhalter; sie zeigt allein den Aufbau eines anonymen Projektberichts.
Ein Glashersteller — anonym
Im Kartentext stehen Problem und Lösung in zwei Sätzen. Zahlen stehen nicht hier, sondern mit ihrer Messmethode im Ergebnisteil der Referenz.
Bis wir ein belegtes Projekt veröffentlichen können, ist unsere Arbeitsweise das Konkreteste, was Sie prüfen können. Oder schildern Sie direkt ein Problem aus der Fertigung — Sie bekommen eine technische Antwort.