So steuern Sie optimale Softwareprojekte

Sebastian Wiemer entwickelt beim Dortmunder IT-Dienstleister Adesso neue Geschäftsfelder im Bereich Beratung und Softwareentwicklung für die Medienbranche. Foto: Adesso.

Die Beschaffung von Software für Kernprozesse ist in Verlagen ein höchst kritischer Vorgang, denn die Investition ist meist ungewöhnlich hoch und die Folgen falscher Entscheidungen können die Produktivität jahrelang belasten. Wie aber packt man eine Beschaffung methodisch richtig an?

Die sicherste Methode basiert nicht auf Merkmalsvergleichen, sondern nennt sich Requirements Engineering und erfordert die Einhaltung einiger Formalia. Geschäftsentwickler Sebastian Wiemer fasst im IT-Channel von buchreport.de die Grundzüge in einer Reihe von Tipps zusammen.

Sie stehen vor der Herausforderung, eine neue Software auszusuchen oder entwickeln zu lassen. Nicht selten besteht in Verlagen der Auswahlprozess darin, dass eine „Feature-Matrix“ erstellt wird. In dieser wird eine Reihe von Softwareprodukten – ähnlich einem Vergleichstest in einer Zeitschrift – anhand einer Reihe von Eigenschaften mit einer Wertung und manchmal auch einer Gewichtung gegenübergestellt. Zum Schluss werden alle Wertungen zu einer Gesamtsumme zusammengezählt, und die Produkte sollen mithilfe dieser Summen objektiv verglichen werden.

Einmal davon abgesehen, dass am Ende häufig doch nur der Preis entscheidet, ist dieses Vorgehen aus mindestens den folgenden Gründen keine gute Idee:

• Die Bewertungsskala, etwa ++,+,o,-,– vereinheitlicht die Bewertung über alle Features, obwohl gar nicht alle Features gleich wichtig sind. Ein ++ für ein unwichtiges Feature zählt dann genau so viel wie ein — für ein sehr wichtiges Feature.
  Selbstverständlich gibt es auch numerische und gewichtete Bewertungen, bei denen je nach Feature mehr oder weniger Punkte vergeben werden. Doch nur selten kommt es vor, dass die möglichen Werte um mehrere Zehnerpotenzen auseinanderliegen, was der Wirklichkeit entsprechen würde. Wenn also die Punkte insgesamt 100 in einer Matrix ergeben würden, dann müsste es Features geben, für die es deutlich unter 1 Punkt gibt.
• Der Zusammenhang zwischen Features wird nicht berücksichtigt: Es mag sein, dass ein Feature nur dann wirklich nützlich ist, wenn es in Kombination mit einem anderen Feature vorhanden ist. Was nützt beispielsweise die Unterstützung von verschiedenen Übertragungsprotokollen, wenn die Software nichts Nützliches übertragen kann?
• Die Objektivität der Summen von Featurebewertungen (zum Beispiel 95,3 > 77,5) täuscht darüber hinweg, dass die Einzelwerte tatsächlich subjektiv sind und damit gar nicht seriös addiert werden können.
• Und zum Schluss der wichtigste Punkt als Überleitung zum Thema: Es gibt keinen allgemeingültigen Zusammenhang zwischen der Auswahl der Kriterien und der Relevanz der Kriterien.

Wenn Sie sich mit einer solchen Methode ein Produkt aussuchen, ist der Erfolg schlicht Zufall. Um herauszufinden, welche Kriterien für eine Auswahl wirklich wichtig sind, müssen Sie nämlich Ihre Anforderungen kennen. Um diese aufdecken zu können bedarf es einer „Anforderungsanalyse“ (engl. „Requirements Engineering“ oder kurz „RE“), einer Disziplin, die zwischen BWL und Informatik liegt und als Kompetenz in Unternehmen so gut wie nie ausreichend für komplexere Vorhaben vorhanden ist. Das liegt in der Natur der Sache. Nur für Unternehmen, die Software erstellen, lohnt es sich, Requirements Engineers auszubilden und anzustellen.

Da es in manchen Bereichen (zum Beispiel bei ERP-Systemen für Buchverlage) nur eine Handvoll von möglichen Standard-Softwaresystemen gibt, ist die Auswahl mit der Feature-Matrix zwar immer noch zufällig aber wenigstens nicht fatal. Lassen Sie eine Software jedoch von Grund auf neu entwickeln und geben die zu entwickelnden Features selber vor, sieht das mit den schlimmen Konsequenzen schon anders aus.

Wie also kommt man in einem Verlag ohne einen Requirements Engineer an eine gute Anforderungsanalyse und damit letztlich zu einem guten „Lastenheft“ – dem Schnittstellendokument zwischen Auftraggeber und Software-Dienstleister?

Die beste Antwort darauf ist: Holen Sie sich einen Requirements Engineer ins Haus, den Sie zum Beispiel von einem Beratungsunternehmen ausleihen. Wenn das nicht geht (keinen gefunden, zu teuer, spricht ihre Sprache nicht, …), hilft nur Weiterbildung. Die kann dieser Artikel nicht ersetzen, aber Sie bekommen an Hand der folgenden Tipps schon mal einen Eindruck, worauf Sie achten sollten, und wie groß (oder klein) ihr Bedarf an externer Unterstützung ist.

Tipp 1: Lastenheft – das Was und das Wie

Das Lastenheft sagt dem IT-Dienstleister, was zu tun ist, aber nicht, wie es zu tun ist. Für das Was übersetzt der Requirements Engineer geschäftliche Anforderungen in eine IT-verständliche Sprache – eben das Lastenheft. Ein Requirements Engineer muss dazu über technisches Verständnis und eine gute Kenntnis der Branche und Ihrer Geschäftsprozesse verfügen.

In agilen Projekten landen die Anforderungen übrigens nicht in einem Lastenheft, sondern ein einem „Backlog“ und werden projektbegleitend kontinuierlich neu erstellt und bewertet. Hier begleitet der Requirements Engineer das Projekt über den ganzen Zeitraum und nicht nur so lange, bis das Lastenheft vollendet ist.

Für das Wie benötigen Sie das Software-Entwicklungsunternehmen. Dieses schreibt in das Pflichtenheft, wie das Was mit der Lösung umgesetzt wird.

IT-Grundlagen und Technologien der Zukunft

Mehr zum Thema IT und Digitalisierung lesen Sie im IT-Channel von buchreport und Channel-Partner knk. Hier mehr

Das Wie erkennen Sie an technischen Details, Produktnamen, Methoden- oder Verfahrensnamen. Wenn also schon vorher in Ihrem Lastenheft das Wie steht, zum Beispiel etwas von „agil“ oder von „Micro-Service“, „Oracle“ oder „REST“, dann deutet dies darauf hin, dass Ihr Projektmanager Unterstützung brauchen könnte, denn Sie haben definitiv kein sauberes Lastenheft vor sich liegen.

Das Was erkennen Sie daran, dass Sie einen unmittelbaren oder wenigsten mittelbaren Zusammenhang zu Ihren geschäftlichen Zielsetzungen herstellen können. Dafür benötigen Sie logischerweise eine gute Vorstellung von Ihren Zielsetzungen.

Damit kommen wir zum zweiten Tipp.

Tipp 2: Bestimmen Sie Ihr Ziel richtig

Jedes Unternehmen sollte seine Zielsetzungen genau kennen. Tatsächlich ist es rein logisch gar nicht möglich, ohne Zielsetzungen erfolgreich zu sein, da der Erfolg durch das Erreichen von Zielen definiert ist.

Wie sieht es also mit Ihren Zielen aus? Können Sie diese in 15 Minuten auf ein Blatt Papier schreiben, so dass Ihr 14-jähriges Patenkind sie versteht?

Wenn Sie ihre Zielsetzungen aufgeschrieben haben, können Sie an einem einfachen Merkmal erkennen, ob diese etwas taugen: Gute Zielsetzungen lösen ein Spannungsverhältnis auf. Vielleicht kennen Sie die SMART Methode. Diese thematisiert letztlich auch ein Spannungsverhältnis. Nämlich aus:

• Spezifität,
• Messbarkeit,
• Angemessenheit,
• Realitätsnähe und
• Zeit.

Ein typisches Spannungsverhältnis für ein gewinnorientiertes Unternehmen wäre: Time to Market, Ressourceneinsatz und Produkteigenschaften. Hier muss ich mich als Unternehmer entscheiden, ob ich der Erste auf dem Markt sein möchte, einen hohen Profit wünsche oder den Produkteigenschaften (Qualität, Features usw.) einen höheren Stellenwert beimesse.

Lösen meine Zielsetzungen das wesentliche Spannungsverhältnis meines Geschäftsmodells nicht auf, dann kann ich davon ausgehen, dass meine Zielsetzungen mir keine Entscheidungshilfe für die Optimierung von Geschäftsprozessen oder für die Formulierung von Anforderungen sind.

Damit kommen wir zum Thema Geschäftsprozesse.

Tipp 3: Formulieren Sie Ihre Anforderungen im Kontext Ihrer Kerngeschäftsprozesse

Ein Kerngeschäftsprozess beschreibt, einfach formuliert, womit Sie Ihr Geld verdienen (wenn Sie keine Behörde oder gesetzliche Krankenversicherung oder Ähnliches sind). Alle anderen Prozesse in Ihrem Unternehmen sind entweder Führungsprozesse (zum Beispiel Budgetplanung und Organisationsentwicklung) oder Unterstützungsprozesse (zum Beispiel Buchhaltung, Gehaltsabrechnung und Urlaubsanträge). Für die Formulierung und Visualisierung Ihrer Kerngeschäftsprozesse sollten Sie eine standardisierte, von allen Experten lesbare Notation verwenden, zum Beispiel BPMN (Business Process Modeling Notation).

Eine Prozessbeschreibung in BPMN enthält Informationen darüber, wer was wann in welcher Reihenfolge womit tut. Sie dokumentieren die Zuständigkeiten, Rollen, Abläufe, Dokumente, Systeme usw. in einem übersichtlichen Diagramm. Dazu benötigen Sie einen geschulten Business Analyst. Im Gegensatz zum Requirements Engineer, den man wirklich nur für Software-Entwicklungs- oder -Auswahlprojekte benötigt, ist ein Business Analyst auch zu jeder anderen Zeit eine sinnvolle Ergänzung.

Wenn Sie Anforderungen entlang von Aufgaben und damit im Kontext von Prozessen formulieren, haben diese immer einen Bezug zu Ihrem Geschäftsziel. Meist lassen sich an solchen Prozessdiagrammen sogar die Wichtigkeit für den Prozess, die Wertschöpfung in Euro, die Produkteigenschaften oder die Zeitersparnis ablesen. Dies macht es später leichter, die Anforderungen, die Sie an Hand der Aufgaben im Geschäftsprozess ermitteln, zu priorisieren. Anforderungen, die beispielsweise häufig vorkommen und hohe Kosten verursachen, rechtfertigen eine längere und gründliche Bemühung um eine Optimierung als Aufgaben, die selten und/oder kostengünstig sind.

Aber nicht nur Kosten und Wertschöpfung lassen sich im Kontext von Prozessen besser beurteilen. Der Prozesskontext ermöglicht es auch, die Eingangsvoraussetzungen (also was muss vor Aufnahme einer Aufgabe passiert sein oder welche Vorprodukte oder Vorzustände werden in welcher Qualität für diese Aufgabe benötigt?) genau zu definieren.

Somit kommen wir zum vierten und letzten Tipp.

Tipp 4: Das beste Werkzeug für Anforderungen ist „Warum“

Im Prinzip haben kleine Kinder in ihrer „Frag-deinen-Eltern-ein-Loch-in-den-Bauch-“ bzw. in ihrer „Warum-Phase“ die besten Voraussetzungen dafür, Requirements Engineer zu werden. Denn das wichtigste Werkzeug eines Requirements Engineers ist die Frage „Warum“. Mit einem Prozess-Modell fällt Ihnen die Antwort übrigens deutlich leichter als ohne (womit wir nochmals bei Tipp 3 wären). Ein gute Anforderungsanalyse erkennt man an ermüdenden Warum-Fragen. Wenn die Anforderungsanalyse bei Ihnen anders läuft (siehe ganz am Anfang die Feature- Matrix) und niemand „warum“ fragt, dann ist das ein Anzeichen dafür, dass etwas bei Ihnen nicht gut läuft. Die Warum-Fragen sind übrigens nicht ad infinitum möglich, weil sie immer bei Ihren Geschäftszielen landen müssen.

Damit Sie nicht zu Unrecht an Ihrem Lastenheft zweifeln: Es gibt tatsächlich doch noch etwas, das technisch ist, vielleicht mal einen Produktnamen enthält oder nicht so einfach auf Ihre geschäftlichen Zielsetzungen zurückzuführen ist. Das sind die nicht-funktionalen Anforderungen (womit auch schnell klar sein dürfte, dass bisher von den funktionalen Anforderungen die Rede war). Diese heißen richtiger „Randbedingungen“. Randbedingungen können zum Beispiel vorhandene Lizenzen sein (die Sie weiterverwenden wollen) oder Einschränkungen beschreiben, die in der Leistungsfähigkeit Ihrer bestehenden Netzwerk-, Software- oder Hardware-Infrastruktur bestehen. Solche nicht-funktionalen Anforderungen haben in angemessenem Umfang ihre Berechtigung. In jedem Fall fragwürdig sind jedoch Lastenhefte, die überwiegend aus nicht-funktionalen Anforderungen bestehen und nicht erkennen lassen, was mit der Software für Ihr Unternehmen erreicht werden soll.

Zusammenfassung

Wenn Sie ein Softwareprojekt vor der Brust haben, dann müssen Sie Ihre Anforderungen kennen. Dabei hilft es ungemein, wenn Sie eine Dokumentation Ihrer Kerngeschäftsprozesse und schriftlich formulierte Zielsetzungen haben. Wenn Sie das nicht haben, hilft Ihnen ein Business Analyst, der für Sie Geschäftsprozess-Diagramme im BPMN-Standard erstellt. Entlang der Zielsetzungen und Geschäftsprozess-Diagramme erarbeiten Sie die „funktionalen Anforderungen“. Dabei hilft Ihnen ein Requirements Engineer, der Ihnen ein Lastenheft erstellt oder einen agilen Entwicklungsprozess begleitet. Erkennen können Sie den guten Requirements Engineer zum Beispiel an den vielen „Warum“-Fragen.

Dieser Beitrag ist sicher keine Anleitung für eine Anforderungsanalyse, aber vielleicht hilft er Ihnen dabei, zu erkennen, ob Sie Hilfe brauchen und an wen Sie sich dafür wenden können oder ob Sie schon auf einem guten Weg in Ihrem nächsten Softwareprojekt sind.