Prototyping statt Pflichtenhefte

Die Evaluation einer betriebswirtschaftlichen Software gehört zu den grossen Herausforderungen der KMUs. Der oder die Verantwortliche ist mit dem Software-Markt nicht vertraut, kennt die Stärken und Schwächen der angebotenen Produkte und Lösungen nicht und ist kein Software-Spezialist.

Dabei wären die Ziele eines Auswahlverfahrens eigentlich klar: Das neue Softwareprodukt soll die Anforderungen abdecken (das Problem lösen) und die Kosten für die Einführung und der Zeitrahmen sollen klar sein (Qualität, Kosten, Zeit). Wie aber kann ein KMU-Manager sicherstellen, dass er unter diesen Gesichtspunkten den richtigen Anbieter und das richtige Produkt auswählt?

Die Tücken des Pflichtenhefts

Die meisten Firmen erstellen Pflichtenhefte mit allen bekannten Anforderungen, die sie den Anbietern zur Stellungnahme schicken. Die Anforderungen in den Pflichtenheften sind normalerweise in Kategorien zusammengefasst ("Technik", "Usability", "Auswertungen", etc.) und besitzen fast immer ein Wichtigkeitsattribut wie "killer", "must" oder "nice to have". Die Anbieter füllen den Anforderungskatalog aus, geben Preisinformationen an und schicken das Ganze an den potentiellen Kunden zurück. Dieser entscheidet sich für ein Produkt aufgrund der "objektiven" Informationen der Anbieter.

So weit die Theorie. In der Praxis sieht es weniger rosig aus: Die Anbieter, vertreten durch ihre Verkäufer, möchten natürlich ihr Produkt verkaufen und interpretieren sämtliche Unklarheiten und Unterlassungen in den Formulierungen zu ihren Gunsten. Im besten Fall wird bei den unklaren Anforderungen geschrieben "unklar, muss besprochen werden". Der Kunde erhält also eine eher schöngefärbte Antwort auf sein Pflichtenheft. Doch der Nachfrager fühlt sich auf der besseren Seite, weil er die Antworten des Pflichtenhefts in den Vertrag aufnehmen kann. So werden potentielle Probleme nicht besprochen, da sich beide Parteien eigentlich einig darüber sind, dass nach der Vertragsunterzeichnung ohnehin alles besser wird (Kunde: Der Anbieter hat den Funktionsumfang ja zugesagt, Anbieter: Wenn erst mal unterschrieben ist, packen wir die Probleme an, wenn sie auftreten).

Aus diesem Grund werden potentielle Probleme nicht angesprochen, da beide Parteien gar kein Interesse daran haben, möglichst früh die sich anbahnenden Schwierigkeiten zu sehen. Dies führt dazu, dass viele Probleme erst spät im Projekt auftauchen. Die Lösung solcher Probleme verschlingt je mehr Ressourcen, desto länger das Projekt schon in die falsche Richtung fortgeschritten ist.

Dass man über Einträge in einem Pflichtenheft trefflich streiten kann (was bedeutet: "Die wichtigsten Auswertungen sind schnell aufrufbar"?), kann schliesslich zu hässlichen Rechtsstreitereien führen, die keinen der beteiligten Parteien weiterbringen.

Bauch und Kopf

Auswahlverfahren mit Pflichtenheften haben eine ganze Reihe von weiteren Nachteilen. So werden anstelle der Anforderungen oft bereits Lösungen beschrieben ("Kontenplan sollte in Baumansicht bearbeitbar sein"). Die lässt dem Anbieter wenig Raum, seine Lösung eines Problems zu präsentieren. Auch die Unterteilung der Kriterien in "Muss", "Kann" und "Wunsch" ist oft problematisch, da die "Wunsch"-Kriterien im Bauch des Kunden die wichtigsten sind.

Schlimm sind auch Evaluationsverfahren mit Pflichtenheften, bei denen sich der Nachfrager im Bauch eigentlich schon für eine Lösung entschieden hat, seinen Entscheid aber noch "wissenschaftlich" absichern will. Das Pflichtenheft wird dann so formuliert, dass es genau auf eine Lösung passt – die Evaluation wird zu einem zeitraubenden, teuren Leerlauf.

Rapid Prototyping mit Standardsoftware

In den letzten Jahren haben wir eine Methode für die Einführung von betriebswirtschaftlichen Lösungen in KMU entwickelt, die versucht, diesem offensichtlichen Missstand beizukommen. Die Methode ist in Anlehnung an die Engineering-Methode des "Rapid Prototyping" entstanden und wurde darum von uns auch so benannt.

Ohne viel Papier zu produzieren oder sich abstrakt über die genauen Anforderungen zu unterhalten, erstellt der Anbieter mit dem Kunden zusammen einen Prototyp der zukünftigen Lösung, und zwar mit Hilfe des einzusetzenden Softwareprodukts selber. Das Produkt muss dies natürlich zulassen, es muss also genügend flexibel und parametrisierbar sein, so dass unterschiedliche Anforderungen ohne Weiterentwicklung der Software abgebildet werden können.

Zuerst wird versucht, für die kritischen oder noch unklaren Anforderungen eine Lösung zu finden. Dies geschieht durch direktes Konfigurieren der Software beim Kunden. Der Projektleiter des Anbieters erarbeitet im Rahmen von Projektmeetings vor Ort, zusammen mit den zukünftigen Anwendern, eine mögliche Lösung. Durch dieses Vorgehen wird sichergestellt, dass die Kommunikationswege sehr kurz sind und der Kunde sofort auf Lösungsvorschläge reagieren kann. Natürlich ist es für die Erstellung des Prototypen von grossem Vorteil, wenn der Kunde sein Problem (oder seine Anforderungen) genau kennt, aber es muss nicht alles in detaillierter schriftlicher Form vorliegen.

An den Projektmeetings sollten weitere fachlich involvierte Personen auf Seite des Kunden anwesend sein. So können diese die Lösungsvorschläge des Beraters direkt kommentieren und sind für das Testen des Prototypen auch besser vorbereitet. Der Prototyp wird in Projektmeetings in kurzen Abständen (eine Woche) iterativ verfeinert. Zwischen zwei Projektmeetings prüfen die Mitarbeiter des Kunden den Prototypen auf Herz und Nieren und bringen Ihre Anregungen am nächsten Projektmeeting ein.

Nach einigen Iterationen ist der Prototyp soweit ausgereift, dass der Kunde entscheiden kann, ob das Produkt seine Anforderungen abdeckt. Entscheidet er sich für das Produkt, so ist ein Grossteil der Anpassungsarbeit schon gemacht oder wenigstens angedacht. Entscheidet er sich hingegen gegen die Einführung des Produktes, so waren die Bemühungen nie sinnlos, denn erstens kennt der Kunde seine Anforderungen nun viel besser und zweitens konnte er eine Fehlinvestition in den Kauf des falschen Produkts vermeiden.

"Spüren" statt Formulare

Der grosse Vorteil des "Rapid-Prototyping" gegenüber ausführlichen Pflichtenheften besteht darin, dass der Nachfrager seine Lösung früh "spüren" kann und die Mitarbeiter des Anbieters (Berater, Projektleiter) von Anfang an kennen lernt. Da mittels des Prototypen die wichtigsten und kritischen Anforderungen vertieft analysiert werden, treten auch Missverständnisse im Projekt rasch zu Tage. Ein Prototyp kann auch beim Anforderungs-Management, insbesondere beim Formulieren von Anwendungsfällen helfen, weil der Prototyp dem Kunden ein frühes Feedback ermöglicht, und er prüfen kann, ob die ursprünglichen Anforderungen richtig formuliert waren.

Viele Softwareprojekte verteuern sich unverhältnismässig, weil im Laufe des Projektes neue Anforderungen auftauchen. Auch hier kann ein Prototyp helfen, weil der Kunde das Produkt live sieht und "fühlen" kann, und so bereits im Angebotsstadium über zusätzliche Anforderungen nachdenken wird

Gerade für KMU-Manager mit wenig Fachkenntnissen in Software und Technologien bietet die Einführung mittels Prototyping die Möglichkeit, sich an die zukünftige Lösung heranzutasten. Da der Prototyp mit dem Anbieter des Produktes zusammen erstellt wird, lernt der Kunde auch die Konfigurationsmöglichkeiten des Produktes vertieft kennen, so dass sich eine separate Schulung der Schlüsselpersonen beim Kunden bei Produkteinführung meist erübrigt.

Voraussetzungen für Rapid-Prototyping

Nicht für alle Projekte eignet sich die Vorgehensweise mit beim Kunden erarbeiteten Prototypen. Die wichtigsten Voraussetzungen sind:

• Der Ansprechpartner oder Projektleiter beim Kunden ist mit dem Problem vertraut und kann entscheiden, ob eine Lösung den Anforderungen genügt
• Die Projektleiter auf beiden Seiten haben genügend Kompetenzen, während des Projekts auch schwierige Entscheidungen zu fällen
• Der Kunde muss klare Vorstellungen davon haben, was benötigt wird
• Der Verkäufer auf Anbieterseite muss ein tiefes technischen Verständnis haben und die Kundenbranche gut kennen. Am besten betreut dieselbe Person später auch die Einführung des Produkts.
• Das Produkt muss einfach und vielfältig konfigurierbar sein, nur so ist Prototyping überhaupt möglich. Der Projektleiter des Anbieters muss über sehr gute Produktkenntnisse verfügen und die wichtigsten Änderungen am Prototypen in Minutenfrist durchführen können.

Eine ausführliche Beschreibung des Einführungsprozesses finden Sie auf der Seite Vertec Standard Einführungsprojekt.