Tipps gegen Fehler

17 Fallen bei der Auswahl von Unternehmenssoftware

01.07.2015
Von Doig Chris
Der Kauf von Unternehmenssoftware kann ein gefährliches Unterfangen sein. Ein Verständnis für die vielfältigen Gefahren hilft ihnen die richtige Wahl zu treffen.

Unternehmen wollen nach dem Erwerb einer Software immer einen Return of Investment (ROI) sehen. Allzuoft aber gibt es keinen solchen ROI, weil die falsche Software gewählt wurde. In diesem Beitrag sehen wir uns die häufigsten Fehler beim Einkauf an und geben Ihnen Tipps, wie Sie diese vermeiden können.

1) Unbekannte Anforderungen

Unbekannte Anforderungen sind - nomen est omen - solche, die der Käufer nicht kennt. Sie manifestieren sich erst bei der Implementierung der Software und verursachen zeit- und kostenaufwändige Workarounds. Unbekannte Anforderungen erstrecken sich sowohl in die Breite als auch die Tiefe. In der Breite betrifft es Anforderungen unspezifischer Art, die sich überall bemerkbar machen. In der Tiefe geht es um spezifische Probleme mit einer bestimmten Funktion.

Es empfiehlt sich eine Anforderungssoftware, die sowohl in die Breite als auch in die Tiefe geht. Mit Reverse Engineering haben Sie ein leistungsfähiges Verfahren an der Hand, um unbekannte Anforderungen aufzustöbern. Ist dies erst passiert, können sie bei der Auswahl und später bei der Umsetzung von Software berücksichtigt werden. Und weil sie nun im Projekt- und Kostenplan auftauchen, müssen Sie sich später nicht über Budget-Überschreitungen und Verzögerungen ärgern.

2) Unzureichende Anforderungen

Einige Organisationen unterschätzen den Wert eines ausgeklügelten Anforderungsmanagements zu Beginn eines Projektes. Anforderungen sind nun mal aber die Grundlage für jede vernünftige Auswahl von Software. Wir alle wissen, was mit Gebäuden passiert, deren Fundament unzureichend ist - genauso ist es bei der Auswahl von Software. Führen Sie also eine umfassende Bedarfsanalyse durch.

3) Anwender bleiben außen vor

Desineteressierte oder "passiv-aggressive" Anwender können einen Software-Rollout zum Scheitern bringen, das weiß jeder, der schon mal einen mitgemacht hat. Beteiligen Sie daher alle wichtigen User am Auswahlprozedere. Sie können diese Anwender beispielsweise die Wichtigkeit verschiedener Anforderungen an die Software bewerten lassen. In einer Liste sollten die Für-und-Widers verschiedener Softwarekomponenten genannt werden. Sobald die Anwender ihre Meinung inklusive Namen auf der Liste finden, werden sie sich involviert fühlen und sich für das Projekt engagieren.

4) Der Umfang der Software

Keine Software kann alles, manchmal bilden sich Verantwortliche das aber ein. Dann ist das Spektrum der Probleme, die sie lösen wollen, einfach zu groß. Wir haben beispielsweise einmal einem Kunden bei der Einführung einer Management-Lösung geholfen, dieser hätte auch gerne ein Dokumentenmanagement inkludiert gehabt. Tatsächlich entschied er sich dann für eine Software, die beides konnte, beides aber in unzulänglicher Weise.

Sie lösen das Problem, indem Sie einen Reality-check der tatsächlich vorhandenen Funktionen in der Software durchführen. Erstellen Sie eine Liste mit allen Anforderungen und gleichen Sie sie mit der Liste der Funktionen der Software ab. Arbeiten Sie mit einem Punktesystem - 100 Prozent würde bedeuten, dass alle Anforderungen erfüllt werden. Kommen Sie bei allen potentiellen Kandidaten auf weniger als 70 Prozent bedeutet dass, dass Ihre Anforderungsliste zu groß geraten ist. Im obigen Beispiel verzichtete der Kunde auf besagtes Dokumentenmangement - und stieß dann auf eine Lösung, die ihn zu 79 Prozent befriedigte. Die kaufte er dann.

Inhalt dieses Artikels

 

andreas hoffmann

Guter, hilfreicher Artikel, aber..
Anforderungen mittels Reverse Engineering ermitteln? Bei einem ERP System mal eben Millionen Zeilen Code auswerten? Halte ich nicht für praktikabel. Mal abgesehen davon, dass es auch verboten ist.

Für ebenso fragwürdig halte ich den Rat um COBOL einen grossen Bogen zu machen.
Vielleicht habe ich einen Mainframe, oder eine IBM power Maschine und benötige aufgrund des Workloads und der Verfügbarkeit auch weiterhin ein derartiges System? Dann ist COBOL kein Hindernis. Es muss nicht alles heute in Java, PHP, oder C# geschrieben sein.

comments powered by Disqus