In Allgemein

Grosse IT-Projekte, wie die Evaluation eines neuen ERP-Systems, sind mit Unsicherheit verbunden. Kunden versuchen dem zu begegnen und Sicherheit zu schaffen, in dem sie immer aufwendigere Ausschreibungsverfahren realisieren. Projektteams bei Kunden und die Anbieter beschäftigen sich mit immer detaillierteren Systemspezifikationen und umfassenderen Bewertungsmethoden. Führt das zu besseren Entscheidungen, mehr Sicherheit und erfolgreicheren IT-Projekten? Nein, im Gegenteil. Ich halte es für die Mehrheit der Fälle für schädlich. Hier die drei wichtigsten Argumente dafür:

Argument 1: Details in der Systemspezifikation schränken Sie ein

Sie verhindern professionelle, kreative Lösungen und führen langfristig zu unerwünschten Restriktionen beim Kunden.

Wer eine Software oder ein System spezifiziert, möchte natürlich sicherstellen, dass er gute Arbeit macht und das neue System ein gutes wird. Der Grundsatz „Je genauer die Systemspezifikation desto besser“, sieht in diesem Zusammenhang plausibel, ja geradezu zwingend aus. Je mehr und genauer man spezifiziert, desto weniger kann schief gehen.

Nimmt man die Perspektive derjenigen ein, die sich um die Realisierung bemühen, sieht die Sache anders aus. Der Systemanbieter muss sich mit unzähligen Details auseinandersetzen. Und es wird schwierig, zu erkennen, was wesentlich ist und was nicht. Des Weiteren hat er wahrscheinlich bereits eine Lösung für die Anforderung. Es spricht sogar einiges dafür, dass diese besser ist, als das, was in der Systemspezifikation des Kunden steht:

  1. Die im System vorgesehene Lösung passt in dessen Gesamtkonzept des Softwareentwicklers
  2. In die Lösung des bestehenden Systems sind die Anforderungen und das Know How der Kunden zuvor eingeflossen

Besonders fatal ist die Sache, wenn die Systemspezifikation aufgrund kurzfristiger Überlegungen statt mit langfristiger Perspektive (Anpassbarkeit, Änderbarkeit, Releasefähigkeit) erstellt wurde. So schränken sie die zukünftigen Optionen des Kunden ein oder verhindern, dass eine innovativere Lösung des Systemanbieters zum Einsatz kommt.

Als Kunde spezifizieren sie gut, wenn Sie Ihren „Pain“ oder „Need“ beschreiben. Das gibt den Systemanbietern Raum für kreative und moderne Ansätze, die den Kunden oft nicht bekannt sind. Lassen Sie sich überraschen. Im Restaurant schreiben Sie dem Koch ja auch nicht vor, wie er das Schnitzel zubereiten soll.

Das Spezifikationsexperiment

In einem Experiment werden zwei Gruppen mit je drei bis vier Mitgliedern gebeten, ein Bild zu malen. Die eine Gruppe erhält einer detaillierte Spezifikation, mit Angaben zu Farben, Form, Anzahl und Position der zu zeichnenden Objekte. Die andere bekommt lediglich Infos zu den erwarteten Objekten. Welche Gruppe malt das schönere Bild?

die Bilder unten zeigen links die detaillierte Spezifikation, rechts die grobe. Bleibt noch darauf hinzuweisen, dass das linke Bild nicht exakt der Spezifikation entsprach.

Argument 2: Man scheut sich vor der Verantwortung

Wenn des Ergebnis einer Systemevaluation durch ein Verfahren generiert wird, müssen wir uns bei Fehlentscheidungen nicht schuldig fühlen.

Viele Unternehmen kaufen jedes Jahr bei ihren Banken für teures Geld Prognosen zur Kursentwicklung von Fremdwährungen ein. Das ist natürlich Blödsinn. Niemand kann die Kursentwicklung vorhersagen. Auch grosse Banken mit teuren Rechnern, BigData und künstlicher Intelligenz nicht. Warum kaufen die CFOs die Prognosen trotzdem? Man nennt das Phänomen „defensive Entscheidung„: Entscheidungen, an die sie selbst nicht glauben, die sich aber im Nachhinein gut rechtfertigen lassen. Die Verantwortliche wissen, dass die Prognosen keinen Verlässlichkeit haben. Sie wissen jedoch auch, wenn sie ohne Prognose entscheiden, sind sie verantwortlich. Mit Prognose können sie die Verantwortung für Fehlkäufe auf das Nichteintreffen der Prognose der Bank schieben.

Auch Evaluationstools von Auswahlberatern und umfassende Punktwertverfahren führen zu defensiven Entscheidungen. All diese Konzept lenken ab. Sie verschieben den Fokus von der Frage, „wie gehen wir mit Unsicherheit um“ auf eine nicht relevante Schaubühne der Rechtfertigung.

Zu Entscheiden heisst, Verantwortung zu übernehmen. Verantwortung kann nicht an Tools, Verfahren oder Berater „delegiert“ werden. Stellen Sie stattdessen die Frage

„Was brauchen wir, um Verantwortung übernehmen zu können? Wann ist es sicher genug, damit wir das Experiment wagen können?“

Dazu brauchen die meisten Teams nicht mehr als zwei Variablen: Die Zusammenarbeit mit dem Systemanbieter und die Qualität der für das Unternehmen wichtigsten Funktionen.

Argument 3: Es wird in nicht benötigte Details investiert

Wer spezifiziert bevor er priorisiert, investiert in Lösungen, die er nie brauchen wird.

Angenommen, sie erhalten den Urlaub Ihres Lebens: Drei Monate Entdeckungstour in einem Land, in dem sie noch nie waren. in der Vorbereitung können Sie alles bis ins Detail festlegen und reservieren, von der Stärkung vor dem Abflug über sämtliche Fahrten, Malzeiten, Zwischenverpflegungen, Übernachtungen und Aktivitäten bis zur sicheren Ankunft zu Hause.

Niemand in der mir bekannten Welt bucht so seinen Urlaub. Aber viele Organisationen evaluieren so ihre Business Software. Sie spezifizieren bis ins Detail ohne zu prüfen, wie wichtig die Anforderungen im Gesamtkonzept ist. Sie investieren vorab sehr viel Zeit obwohl jedem klar ist, dass sie bald über neue Erkenntnisse verfügen werden. Und Ortskenntnisse ermöglichen andere, meist bessere Entscheidungen.

Arbeiten Sie iterativ, priorisieren sie die Anforderungen in jeder Iteration neue und investieren sie nur in dei jeweils wichtigsten. So vermeiden sie nicht nur Verschwendung, Sie sorgen auch dafür, dass Ihr System schlank und performant bleibt.

Konsequenzen

Wer ein System evaluiert und einführt muss Unsicherheiten aushalten. Kunden glauben, die Unsicherheit durch hochdetaillierte Systemspezifikationen, ausgefeilte Bewertungsverfahren und einen umfassenden Vertrag eliminieren zu können. Dadurch reduzieren sie jedoch den Spielraum, auf Unvorhergesehenes reagieren zu können. Das ist jedoch wichtig für jedes Projekt.

Regeln Sie mit dem Systempartner, wie sie gemeinsam mit Risiken und Unvorhergesehenem umgehen. Vereinbaren Sie, wie sie zusammenarbeiten und passen sie diese Vereinbarung bei Bedarf an. Die Grundlage für die Zusammenarbeit sollte Vertrauen sein. Und diese bauen Sie in der Evaluation auf. Zum Beispiel, in dem Sie darauf vertrauen, dass der Systempartner gute Lösungen für Sie bereithält und Sie ihm nicht alles vorschreiben müssen.

Recent Posts

Leave a Comment

Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Not readable? Change text. captcha txt

Start typing and press Enter to search

Nutzen-Risiken-Systemevaluationerp-evaluation-neue-technologie-wissensgefaelle