Das unerfüllte Versprechen von anforderungsbezogenen Punktlösungen

Das Entdecken und Verwalten mehrerer Anforderungs- und Spezifikationsebenen spielt eine wichtige Rolle in der modernen Produktentwicklung. Diese Informationen sind ein wesentlicher Bestandteil des geistigen Eigentums moderner Produkte und dienen als Wissensdatenbank für die Ingenieure von morgen, die die Entwürfe von heute iterieren. Und für einige sind validierte Anforderungen der Beweis dafür, dass die Ingenieure tatsächlich ihre Zusagen umgesetzt haben, damit niemand beim Gebrauch des Produkts verletzt wird.

Ebenso wie eine mathematische Formel ein Modell für die physische Realität sein kann, können Anforderungen ein Modell für ein Produkt sein. Traditionell werden „Anforderungsmodelle“ als Texte erstellt, die in einer Reihe von Dokumenten organisiert sind. Die Technologie für die Ausarbeitung und Speicherung dieser Informationen hat sich von der mit Schreibmaschine geschriebenen Seite über Textverarbeitungsprogramme bis zum gezielten Software-Repository für Anforderungen entwickelt. Punktlösungen für die Anforderungsverwaltung wie IBM DOORS haben bis heute überlebt, weil es lange Zeit nichts anderes gab.

In den letzten Jahren wurden zahlreiche Technologiestandards entwickelt, um die Kluft zu früheren Anforderungsverwaltungs-Tools zu schließen. Zwei bekannte Beispiele sind OSLC mit Schwerpunkt auf der Datenverknüpfung und ReqIF mit Schwerpunkt auf der Datensynchronisierung. Jeder dieser Ansätze eignet sich hervorragend für bestimmte Anwendungszwecke, während andere Einsatzbereiche hingegen Herausforderungen darstellen. So ist OSLC, das RESTful-Schnittstellen um die Anwendungen herum definiert, die beste Wahl, wenn aktive IT-Verbindungen rund um die Uhr aufrechterhalten werden können. In typischen OEM-Lieferantenumgebungen ist dies jedoch nicht immer der Fall. ReqIF verwendet ein XML-Schema, um Dokumentensätze für die Übermittlung an einen Partner zu packen. Allerdings ist eine Process Governance erforderlich, um die Synchronizität aller Parteien zu gewährleisten.

Moderne Konstruktionswerkzeuge in diesem Bereich, die so genannte Anwendungslebenszyklus-Verwaltung (Application Lifecycle Management, ALM), haben sich nicht nur hinsichtlich ihres Funktionsumfangs weiterentwickelt, sondern sind auch ausgereifter. Aber diese Entwicklung ging für viele Benutzer nicht schnell genug. Die Benutzer verlangen mehr Wert für eine längere Zeit, d. h. Mehrwert ohne wiederkehrende hohe Zusatzkosten.

Die Wahrheit ist, dass viele der Grundfunktionen moderner ALM-Software standardisiert sind und von zahlreichen Anbieterlösungen unterstützt werden: erstellen, verknüpfen, bearbeiten usw. Ovum schreibt in seiner letzten Untersuchung von ALM-Software: „Unternehmen wissen zunehmend zu schätzen, dass die Standardisierung auf eine einzige ALM-Lösung Unstimmigkeiten zwischen Tools beseitigt, die die Agilität behindern, und sie bei einer schnelleren Markteinführung unterstützt.“¹

Der echte Wert moderner ALM-Lösungen:

• Zusammenarbeit mehrerer Benutzer in Echtzeit zur Steigerung der Produktivität
• Funktionen für technische Fachbereiche neben den Anforderungen, d. h. Planung, Systeme, Mechanik, Elektronik, Tests und ständiger Service
• Weitergabe von Projektinformationen an die richtigen Personen, wenn diese benötigen werden, um die Zahl der Status-Meetings zu verringern
• Wenn möglich, Automatisierung von wiederkehrenden Aufgaben, damit sich die Ingenieure auf Innovationen konzentrieren können
• Rasche Inbetriebnahme der Lösung für schnellstmögliche Wertschöpfung

In den Technikunternehmen von heute ist es üblich, ein gesundes, gegenseitig förderliches Verhältnis zwischen IT und technischer Entwicklung zu finden. Die IT unterstützt die technische Entwicklung. Mit Lizenz- und Wartungskosten sowie der zeitnahen Schulung von Administratoren und Benutzern bedeutet diese Unterstützung jedoch für jedes neue Tool einen hohen Kostenaufwand. Im Laufe der Zeit entwickeln sich Upgrades für Anforderungs-Tools zu einem offiziellen IT-Projekt, da die neuen Versionen nach wie vor mit allen anderen Systemen in der Kette der Tools kommunizieren müssen. Ingenieure andererseits möchten nur „das beste Tool für den Job“. In der Regel bedeutet das „das vertraute Übel“, weil sie es für ihr letztes Projekt oder ihren letzten Auftrag verwendet haben. Sie waren vielleicht nicht davon begeistert, aber sie haben gelernt, mit seinen Unzulänglichkeiten umzugehen.

Sowohl die technische Entwicklung als auch die IT sollten sich fragen: „Sind wir wirklich mit unserer aktuellen anforderungsbezogenen Punktlösung zufrieden?“ „Erhalten wir von unserem derzeitigen Tool und Anbieter alles, was wir benötigen?“ „Ist es an der Zeit, auf eine industrietaugliche ALM-Lösung umzusteigen, die alle unsere Anforderungen erfüllt?“

^{1 Ovum Entscheidungsmatrix für ALM-Lösungen 2016}