Ich hatte wieder einmal ein Aha – Erlebnis, und davon muss ich berichten. Ich bekam eine Ausschreibung und sollte ein Angebot abgeben. Soweit erst einmal ein ganz normaler Vorgang. Das Pflichtenheft hatte eine Fremdfirma maßgeblich mitgestaltet und war für mich eher ein Sollkonzept. Gefordert war ein Festpreis Angebot innerhalb von zwei Werktagen (+Wochenende). Angefordert waren über 60 einzelne Angebotspositionen. Also mal wieder ein ganz normales Vorgehen.

Mal was zum Projekt Inhalt (soweit wie ich davon berichten kann bzw. darf).

Der Kunde besitzt eine sehr individuelle Lösung zur Anbindung der Produktion an ein fertigungsnahes Informationssystem. Dieses System läuft bereits seit einigen Jahren produktiv und stabil. Natürlich kann man diese Anlageninformationen gut zur Prozessunterstützung nutzen. Nur, dass man sich vor Jahren und auf Grundlage einer schlechten Beratung (nicht von T-Systems!) für eine (m.E. absehbare) Sackgasse entschieden hat. Jetzt muss der Kunde mit den Konsequenzen zu Recht kommen muss. Konkret heißt dass, dass man zur (nicht Standard) Middleware eine zusätzliche Middleware baut, nur damit die Prozessdaten gut genutzt werden können. Eine individuelle Middleware für die individuelle Middleware – das war mir neu. Da war mein erstes kariertes Maiglöckchen.

In diesem ganz speziellen Projekt gab es außerdem zwei weitere spannende Nebenkriegsschauplätze: Zum Einen bei den Erweiterungen, zum Anderen beim Budget. Bei einer Erweiterung handelte es sich um eine Funktion, welche m.E. eher eine Programmiersprache genannt werden sollte. Diese „individuelle Middleware Programmiersprache“ sollte in Echtzeit (weil Produktion gesteuert werden sollte) auf dem nicht echtzeitfähigen Informationssystemen für die Fertigung operieren. Genaue Realtime Anforderungen waren nicht aufgeführt und sollten erst nach Projektstart vom Kunden definiert werden (wobei der Auftragnehmer diese Vorgaben blind vorab akzeptieren sollte). Da war das karierte Maiglöckchen 2.

Zum Anderen war das Budget (Time & Money) unrealistisch, weil beides viel zu gering ausfiel. Nachdem ich das Pflichtenheft (ich hätte es eher Lastenheft oder Sollkonzept genannt) die ersten Male gelesen und peinlich genau abgeschätzt hatte, kam ich auf Größenordnungen weit über den Vorgaben. Die starre Zeitschiene empfand ich allerdings noch viel spannender: Fester Endtermin mit Penale in extrem kurzer Zeit, bei einem geschätzten Aufwand von zu vielen Mannwochen. Die Vorstellungen des Kunden lagen davon unvereinbar weit entfernt. Schwupdiwupp: karierte Maiglöckchen 3&4.

Die Anlagen und SPS’en des Kunden sollten mit an die Lösung angebunden werden und auf die Rückmeldungen der Middleware reagieren. Mehr Details fehlten. Gefordert war ein Festpreisangebot, da interessiert das ja nicht so sehr. Außerdem sind alle Anforderungen im „Pflichtenheft“ umfassend beschrieben. Noch ein kariertes Maiglöckchen.

Die Stimmung beim Vertrieb war entsprechend „uneinheitlich“, als ich das ablehnende Ergebnis mitteilte (Ich hatte mich noch mit anderen Fachleuten zuvor beraten und sie waren ähnlicher Auffassung wie ich). „Wie kann man derart weit neben den Kundenvorstellungen liegen?“ Anscheinend sind wir alle vollkommen inkompetent.

Dabei wäre es sicherlich sinnvoller gewesen, eine genormte Schnittstelle zu den Anlagen (z.B. OPC oder GDI) einzuführen und den historischen Ballast langsam aber sicher über Bord zu werfen. Anschließend  würde man eine schlanke und zukunftsfähige Lösung anstelle eines gefräßigen Dinosauriers besitzen. Und in manchen Standardlösungen gibt es heute bereits die Möglichkeit, einfach Daten zwischen SPS’en und Servern bidirektional auszutauschen und somit die Produktion gezielt zu steuern. Davon ab sind Mehrwertfunktionen besser in einem zentralen „Fertigungsinformationssystem“ als in einer Middleware aufgehoben (Separation Of Affairs).

Ach waren das noch Zeiten, als man sich noch jedes karierte Maiglöckchen (finanziell) leisten konnte. Zu dumm nur, dass man nicht bedacht hat, dass Produktionsanlagen sehr viel langlebiger sind als so mancher Desktop PC. Es finden sich in so mancher Produktion heute immer noch DOS 3.x PCs, CGI Grafikkarten, 80486 Prozessoren und – halt eben eine Middleware für die Middleware. Problematisch finde ich, dass es immer noch Menschen gibt die denken, dass man das alles kompliziert machen muss. Einige Lösungen gibt es bereits „von der Stange“, andere zeichnen sich bereits ab und werden sich durchsetzten. Glauben Sie daher nicht, dass eine Anbindung der Produktion, nur weil es sich um Sondermaschinen handelt, kompliziert sein muss, sie ist nur aufwändig. Eine Ausnahme wäre allerdings die individuelle Erweiterung einer individualisierten „Standardschnittstelle“ durch eine Middleware für eine Middleware. (Und glauben Sie mir, manchmal ist es langfristig wirklich besser, historischen Ballast über Bord zu werfen als kurzfristig einen Schnellschuss durchzupeitschen …)

Da ich allerdings immer wieder solche Pflichten- oder Lastenhefte sehe, müssen sich offensichtlich ganze Horden mit diesen Themen beschäftigen.

Ich mache mir daher keine Angst, karierte Maiglöckchen wird es weiterhin geben (obwohl Orchideen weiterhin hübscher und –realistisch betrachtet– günstiger sind). Die neue Middleware mit der integrierten Programmiersprache für die Middleware wird jemand anderes bauen – und ich bin nicht böse drum. Zwar geht mir jetzt ein Auftrag durch die Lappen, aber in so einem Projekt, kann man m.E. nur verlieren. Mit mangelnder Fachkompetenz hat das Nichts zu tun, eher mit jeder Menge Realismus und Erfahrung.

Kennen Sie solche Projekte? Hat man bei Ihnen schon mal karierte Maiglöckchen bestellt? Oder müssen Sie regelmäßig karierte Maiglöckchen liefern? Dann berichten Sie mir bitte von Ihren Erfahrungen.