Drum prüfe, wer sich ewig bindet

Was uns Friedrich Schiller schon im 18. Jahrhundert mit auf den Weg gab, hat heute und insbesondere in der digitalen Welt mehr denn je seine Gültigkeit. Klar, eine Software wird kaum je für ewig sein, aber 10 Jahre sind in der Informatik bereits eine halbe Ewigkeit.

 

Wenn ein Software-Produkt mal angeschafft und eingeführt ist, ist es mehr als nur ärgerlich, feststellen zu müssen, dass es eigentlich gar nicht so toll ist und nicht alles kann, was es müsste. Ach hätte man doch nur von Anfang an auf das richtige Pferd gesetzt, nämlich dasjenige welches unsere funktionalen Anforderungen bestmöglich erfüllt. Das Budget lassen wir hierbei mal aussen vor. Um herauszufinden, ob eine Applikation die Bedürfnisse abdeckt, raten wir zur Durchführung eines PoC (Proof of Concept). Klingt leider einfacher, als es oftmals ist. Es gibt einige "Fallen", in die immer mal wieder gestolpert wird. Auf zwei der grössten Fallen möchten wir vertiefter eingehen.

 

1. Anforderungen werden zu spät definiert 

Nach Lehrbuch ist die Definition der Anforderungen die erste Phase eines PoC. Als nächste Phasen stehen die Durchführung und die Auswertung der Tests an, welche die Grundlage für einen Entscheid bilden.

 

Zu welchem Zeitpunkt mögliche Kandidaten evaluiert werden, ist nicht vorgegeben. Die Praxis zeigt, dass ein PoC erst gestartet wird, wenn ein oder mehrere "Prüflinge" feststehen. Und das bedeutet in den meisten Fällen leider, dass diese vorgängig bereits näher angeschaut wurden. Dies kann - unbewusst oder nicht - dazu verleiten, dass Anforderungen an die potenzielle Lösung angeglichen werden. Die Gefahr ist gross, dass man sich von den Features dazu verleiten lässt, das Angebotene als das anzusehen, was man gerne möchte, oder die Prioritäten anders zu setzen. Die Anforderungen sollten also unbedingt vor einer ersten Begutachtung oder gar einer Präsentation zusammengetragen und priorisiert werden. Bei einigen Punkten kann man unter Umständen damit leben, wenn sie nur teilweise erfüllt sind, andere müssen zwingend und zu 100% erfüllt werden. Dies sollte von Anfang an so festgehalten werden. Oft erkennt man so relativ schnell, wenn ein Produkt nicht in Frage kommt, und man kann sich weiteren Aufwand sparen.

 

2. Es wird gar nicht richtig geprüft, ob die Anforderungen erfüllt werden, ...

… weil den Versprechungen des Anbieters blind vertraut wird.

Wenn ein Verkäufer gefragt wird, ob sein Produkt dies und das kann, wird er selten bis nie "nein" sagen. Das muss nicht einmal gelogen sein, aber oftmals sind es komplizierte Konfigurationen, umständliche Umwege und Umnutzungen von Feldern, die eigentlich für etwas anderes bestimmt waren, welche es ermöglichen, dass die Applikation etwas ähnliches macht, was der Kunde eigentlich wollte. Mit solchen "Lösungen" wird man niemals glücklich.
Erst wenn man selber gesehen hat, dass und wie etwas funktioniert, kann man beurteilen, ob es die Anforderungen tatsächlich erfüllt. 

 

… weil das Prüfen (zu) umständlich ist.

Manchmal ist es nicht einfach, eine Anforderung durchzuspielen, zum Beispiel weil es dazu umfangreiche Daten benötigt. Klassiker sind auch Schnittstellen zu Drittprodukten. Es mag ja sein, dass solche Schnittstellen bereits bestehen,  aber werden unsere Anforderungen damit wirklich vollumfänglich abgedeckt? - Einer unserer Kunden hat vor ein paar Jahren das SAP Finanzmodul angeschafft. Der Integrator wies darauf hin, dass es 37! verschiedene Schnittstellen gäbe, mit denen "alles" abgedeckt werden kann. Die Schnittstellen wurden nicht geprüft, was dazu führte, dass für teures Geld Schnittstelle Nummer 38 gebaut werden musste.

Sich trotz Hürden die Zeit zu nehmen oder entsprechende Nachweise vom Anbieter einzufordern, lohnt sich.

 

Was nicht ist, kann noch werden

Es kann natürlich sein, dass der Anbieter für die Punkte, die im PoC nicht erfüllt wurden, Anpassungen und/oder Korrekturen verspricht. Okay. Aber vergessen sie auf keinen Fall, diese schriftlich festzuhalten, verbindliche Termine zu definieren und die Konsequenzen zu vereinbaren, sollten die Versprechen nicht eingehalten werden.

 

Wenn sie die genannten Punkte berücksichtigen, steigen die Chancen, dass sie an ihrer neuen Software-Lösung viel Freude haben werden. Wir wünschen gutes Gelingen.