Softwaresysteme für die Maschinenkonfiguration entwickeln

Die Aufgabe

Die Konfiguration der Anlagen hängt an handgeschriebener Routinglogik und damit an einzelnen Personen. Wächst der Auftragseingang, wächst der Engpass mit.

Kunde: Hersteller von Laborautomation
Branche: Maschinen- und Anlagenbau
Dauer: Konzeption mit Abschlussbericht, danach Lastenheft und Umsetzung

Lösungsansätze erhoben und erstbewertet — zwei davon vertieft, drei begründet verworfen

Werkzeugkonzepte je mit Anforderungen, Systemarchitektur, Technologieauswahl, Risiko- und Kosten-Nutzen-Analyse

Lastenheft, vom Auftraggeber weitgehend selbst erarbeitet und von uns überarbeitet — danach wurde die Umsetzung beauftragt

Kurz zum Kunden

Maschinenfabrik für automatisierte Probenvorbereitung. Die Anlagen sind Sondermaschinen: Jede Konfiguration folgt den Proben, den Laborabläufen und den Platzverhältnissen des jeweiligen Kunden. Damit liegt ein erheblicher Teil des Aufwands nicht in der Fertigung, sondern davor — im Konfigurieren, und das heißt: im Wissen einzelner erfahrener Menschen.

Unsere Lösung

Bevor man ein Werkzeug entwickelt, muss man wissen, welches der fünf möglichen sich rechnet. Diese Rechnung ist die eigentliche Leistung.

Die Aufgabe

Der Konfigurationsprozess der Maschinenlinie ist der Engpass vor der Fertigung. Die Routinglogik — welcher Schritt in welcher Reihenfolge an welcher Station geschieht — wird von Hand in einer Entwicklungsumgebung geschrieben, in Zeilen, die man kennen muss, um sie zu schreiben. Das funktioniert, solange die Menschen da sind, die es können, und es skaliert nicht. Der Auftrag ist nicht, ein Werkzeug zu entwickeln, sondern zuerst zu klären, welches Werkzeug überhaupt hilft: Wo genau verschwindet die Zeit, welche Ansätze kommen in Frage, was kostet jeder von ihnen, und was bringt er. Erst danach soll über eine Umsetzung entschieden werden.

Unser Ansatz

Fünf Ansätze, drei begründet verworfen. Wir haben nicht den naheliegendsten Ansatz konzipiert, sondern das Feld geöffnet: ein Sprachmodell für die Erzeugung der Routingzeilen, Standardbedingungen für Maschinen, eine visuelle Erstellung der Routinglogik, ein Nachschlagewerkzeug für Routingzeilen und weitere. Nach der Erstbetrachtung blieben zwei. Der Wert dieses Schritts liegt in den drei, die wegfielen — jeder von ihnen wäre ein Projekt geworden, das jemand hätte begründen müssen.

Die Beteiligten wurden gefragt, nicht nur beobachtet. Neben der Prozessaufnahme lief eine Umfrage unter den Menschen, die konfigurieren, zu ihren Tätigkeiten und den Verbesserungspotenzialen, die sie sehen. Bei einem Prozess, dessen Wissen in Köpfen liegt, ist das keine Beteiligungsgeste: Die Stellen, an denen Zeit verschwindet, kennt niemand besser, und ein Werkzeug, das an der falschen Stelle ansetzt, wird nicht benutzt, sondern umgangen.

Jeder der beiden Ansätze bekam eine eigene Kosten-Nutzen-Analyse. Nicht eine gemeinsame Bewertung und eine Empfehlung, sondern für jedes Werkzeug Anforderungen, Architektur, Schnittstellen, Technologieauswahl, Risiken und Wirtschaftlichkeit getrennt. Damit konnte der Auftraggeber die Entscheidung selbst treffen, auch anders als wir sie getroffen hätten. Das ist der Unterschied zwischen einer Machbarkeitsstudie und einer Empfehlung mit Anhang.

Getrennte Teilprojekte für Konzeption und Umsetzung, mit einer Entscheidung dazwischen. Der Vertrag unterscheidet ein Teilprojekt Konzeption und ein Teilprojekt Umsetzung, mit optionalem Prototyping am Ende der Konzeption. Diese Trennung ist für den Auftraggeber der Punkt: Er kauft zuerst eine Entscheidungsgrundlage und danach, wenn er will, ein Werkzeug. Der Beleg, dass dieses Vorgehen richtig war, ist unspektakulär und eindeutig: Er hat auf Grundlage des Berichts ein Lastenheft erarbeitet, das wir anschließend überarbeitet haben, und die Umsetzung haben wir entwickelt.

Das gemeinsame Team war gemischt, und zwar planmäßig. Die Phasen sind im Projektplan mit Verantwortlichkeiten hinterlegt: Erhebung durch Entwickler und Ingenieure des Auftraggebers zusammen mit unserem Projektteam, Konzeptentwicklung ebenso, Prototyping bei uns. Bei einem Konfigurationsprozess, dessen Logik in der Domäne steckt, ist eine Aufgabenteilung nach Rollen wirksamer als eine nach Firmen.

Das Ergebnis

Ein Abschlussbericht mit Entscheidungsgrundlage.

Zunächst eine Erhebung: Prozesse aufgenommen, relevante Daten identifiziert, und eine Umfrage unter den Beteiligten zu ihren Tätigkeiten und den Verbesserungspotenzialen, die sie selbst sehen. Daraus fünf Lösungsansätze, erstbewertet — von einem Sprachmodell für die Erzeugung der Routingzeilen über Standardbedingungen für Maschinen bis zu einer visuellen Erstellung der Routinglogik. Zwei davon sind vertieft worden: ein Nachschlagewerkzeug für die Routingzeilen und ein grafisches Werkzeug für die Routinglogik.

Für jedes eine Anforderungsanalyse mit Verifikation, ein Entwurf der Systemarchitektur samt Schnittstellen, eine Technologieauswahl, eine Risikoanalyse und eine Kosten-Nutzen-Analyse, zusammengeführt in einem Machbarkeitsbericht. Auf dieser Grundlage ist das Lastenheft für die Umsetzung entstanden: Der Auftraggeber hat es weitgehend selbst erarbeitet, wir haben es anschließend überarbeitet. Die Umsetzung ist daraufhin beauftragt und von uns durchgeführt worden.