Einleitung

Die Auswahl einer Unternehmens-Software ist in der Regel ein komplexes Vorhaben. Auf der einen Seite hat jedes Unternehmen bereits individuelle Rahmenbedingungen und spezifische Prozesse zur Leistungserbringung, die durch das neue Tool optimal unterstützt werden sollen. Auf der anderen Seite gibt es eine Vielzahl von Produkten mit unterschiedlichen Philosophien und Schwerpunkten, die in ihren Auswirkungen für einen Außenstehenden zunächst nur schwer zu erfassen sind. Im Auswahlprozess müssen diese beiden Seiten zusammengebracht werden. Die Vertreter des Kunden müssen die grundsätzlich in Frage kommenden Produkte vorauswählen, verstehen und im Hinblick auf ihre Eignung bewerten. Und die Produktanbieter müssen die Anforderungen des Kunden verstehen, um sinnvolle Lösungen anbieten zu können.

In der Praxis wird häufig das nachfolgend beschriebene Vorgehen angewendet, das hier in drei Phasen gegliedert ist. Dieses Modell lässt sich auf verschiedene Arten von Unternehmenssoftware anwenden, egal ob es sich dabei um eine Anwendung für Risikomanagement handelt oder um ein komplettes ERP-System. Bei größerem Umfang bzw. bei höherer Komplexität der einzuführenden Software und der damit umzusetzenden Prozesse müssen einzelne Schritte jedoch ggf. detaillierter oder mehrfach durchlaufen werden als bei einfacherer Software.

Im öffentlichen Bereich sind darüber hinaus bestimmte Verfahren vorgeschrieben, so dass die Vorgehensweise grundsätzlich anders sein kann.

1. Projektstart

Ist-Zustand, Probleme und Motivation klären, z.B.

  • Unzufriedenheit mit dem Prozess
    - zu viele manuelle Tätigkeiten
    - fehlende Tool-Unterstützung
    - zu viele Fehler
    - mangelhafte Zusammenarbeit über verschiedene Bereiche

  • Probleme mit dem aktuellen Tool, z.B.:
    - individuelles System
    - Betrieb oder Weiterentwicklung ist zu teuer oder ist nicht mehr möglich
    - läuft aus der Wartung
    - genügt den Anforderungen nicht mehr

  • Veränderungen in der Organisation oder in den Prozessen des Unternehmens bzw. der Behörde
  • Vorgaben des Konzerns bzw. übergeordneter Institutionen
  • neue oder geänderte gesetzliche Anforderungen

Lösungsansatz beschreiben

  • Restrukturierung der Prozesse und Toolunterstützung
  • Welche Prozesse sollen angegangen werden?
  • Welche Teile der Organisation und welche Rollen sollen damit arbeiten?

Nutzen für die Organisation

  • Welcher Nutzen würde für die Organisation durch den Lösungsansatz entstehen?
  • Welche Prozesse würden schneller oder mit weniger Fehlern abgearbeitet werden?
  • Werden Kosten minimiert?
  • Werden Risiken minimiert, z.B. durch Ablösung alter Software?
  • Werden damit gesetzliche Anforderungen erfüllt oder Anforderungen von Kunden?
  • Welche Chancen würden für Marketing und Vertrieb entstehen?

Unterstützend:

  • Was sind Best Practices in diesem Bereich? (Normen, Industriestandards)
  • Kann auf Erfahrungen innerhalb der eigenen Organisation zurückgegriffen werden?
  • Gibt es Erfahrungen in befreundeten Organisationen?
  • Erfahrungsberichte, Informationen aus Konferenzen
  • Was sind aktuelle Trends?
  • Gibt es ein solches Tool schon in anderen Bereichen und könnte mitgenutzt werden?

Grundsätzliche Bereitschaft und Fähigkeit klären, ein solches Projekt durchzuführen

  • Wo in der Organisation würde die Verantwortung für ein solches Tool liegen? Kann es, sofern notwendig, dezentral eingeführt werden oder liegt die Verantwortung zentral?
  • Ist grundsätzlich Budget vorhanden bzw. eingeplant?
  • Besteht ein Konflikt zu anderen Vorhaben?
    Eine Tooleinführung erfordert Aufwände bei der Auswahl, Implementierung und Nutzung. Wenn gleichzeitig andere größere Projekte anstehen, kann das zu einem Konflikt bei den Ressourcen führen. Ggf. müssen die Vorhaben zeitlich entzerrt werden.

Ziele und Scope klären

  • Was gehört in das Projekt?
  • Was gehört explizit nicht zum Projekt?
  • Beispiele:
    - manuelle Tätigkeiten strukturieren oder automatisieren
    - Ablösung Altsystem
    - Übernahme von Altdaten
    - Prozesse digitalisieren
    - Prozesse vereinfachen / verbessern
    - Prozesse an veränderte Organisation anpassen (Zentralisierung/Dezentralisierung, M&A …)

  • Abhängigkeiten zu anderen Vorhaben in der Organisation
    - Ziele und Strategie des Unternehmens bzw. der Organisation für die kommenden 3 bis 5 Jahre
    - anstehende organisatorische Veränderungen
    - anstehende Prozessänderungen
    - anstehende andere Tooleinführungen

  • Eher die Prozesse dem Tool anpassen oder das Tool den Prozessen?
    Systeme, die hochgradig auf gegebene Prozesse anpassbar sind, sind in der Regel wartungsintensiver.
    Daher kann es sinvoll sein, die eigenen Prozesse mehr an den Vorgaben der Software zu orientieren, insbesondere wenn die Prozesse nicht in der Kern-Wertschöpfung liegen.

Ergebnis: Das Vorhaben ist ausreichend umrissen und mit den Beteiligten abgestimmt

Erste Marktsichtung durchführen

Bei der ersten Marktsichtung geht es darum, aktuelle Trends und Strömungen sowie allgemeine Fähigkeiten von Tools kennenzulernen. Ziel ist es hier noch nicht, möglichst vollständige Listen der Anbieter und Produkte zu erstellen. Vielmehr soll grundsätzliches Wissen aufgebaut werden, um die nachfolgenden Schritte sinnvoll bearbeiten zu können.

  • Was sind aktuelle Trends in diesem Umfeld?
  • Welche Möglichkeiten bieten marktgängige Werkzeuge?

Ergebnis: Sie kennen einige Anbieter und Produkte sowie deren Ansätze und Herangehensweisen.

Sollzustand definieren

Beim Sollzustand entwickeln Sie eine Vorstellung davon, wie Ihre Organisation und Ihre Prozesse zukünftig funktionieren sollen. Sofern Sie tatsächlich nur ein neues Tool benötigen und Sie die Prozesse genauso wie bisher weiterführen wollen, können Sie sich diesen Schritt sparen. In der Regel gibt es jedoch immer Verbesserungspotenziale und durch die sich in der heutigen Zeit permanent ändernden Rahmenbedingungen auch Anpassungsbedarfe – dafür ist jetzt eine gute Gelegenheit.

  • Übersicht über die geplanten Prozesse
  • Beteiligte Organisationseinheiten und Rollen
  • Rolle des Tools
  • Schnittstellen
  • Mengengerüste

Einführungsprojekte geraten gerne in Schwierigkeiten, weil sie zu einem sehr späten Zeitpunkt von anderen Organisationseinheiten unter dem Vorwurf torpediert werden, sie seien in die Konzeption nicht einbezogen worden und die Software würde nicht zur ihrer tatsächlichen Arbeitsweise passen. Achten Sie deshalb sehr sorgfältig darauf, dass alle relevanten Einheiten intensiv eingebunden sind und regelmäßig ihr Commitment zur Systemeinführung geben.

Ergebnis: Die zukünftige Arbeitsweise ist in groben Zügen definiert und mit allen Beteiligten abgestimmt.

Grobkonzept zusammenstellen

  • Beschreibung des Vorhabens
  • Rahmenbedingungen
  • Ziele und Scope
  • Istzustand und Probleme
  • Lösungsansatz
  • Sollzustand
  • Nutzen
  • Zeitlicher Rahmen

Achten Sie auch hier auf die Abstimmung mit allen relevanten Organisationseinheiten.

Ergebnis: Es gibt ein Grobkonzept zur Tool-Einführung und -Nutzung. Es ist so verfasst, dass sich die Tool-Anbieter ein umfassendes Bild von Ihrer aktuellen Situation und den Zielen machen können, die Sie erreichen wollen.

Projektplan erstellen

  • Phasen und Termine
  • Ressourcen für die Tool-Auswahl
  • Ressourcen für die Tool-Einführung
  • externe Unterstützung, z.B. Beratung, Projektleitung
  • geschätzte Aufwände
  • geschätzte interne Kosten
  • geschätzte externe Kosten (SW-Lizenz/Wartung bzw. SaaS-Gebühren, Dienstleistungen)
  • Risiken

Ergebnis: Es gibt eine erste Version eines Projektplans mit Vorstellungen zu Terminen, Aufwänden, Kosten und Risiken. Das Dokument ist zur internen Verwendung bestimmt, damit die Anbieter zunächst keine Informationen zu Ihren „Schmerzgrenzen“ bekommen.

Review

Alle Arbeitsergebnisse sollten von einem nicht unmittelbar an der Erstellung beteiligten Dritten geprüft werden. Kriterien sind u.a.: Logische Zusammenhänge, Plausibilität, Widerspruchsfreiheit und Vollständigkeit

Ergebnis: Geprüfte und ggf. überarbeitete Dokumente, die eine Fortsetzung des Vorhabens sinnvoll erscheinen lassen.

Entscheidungsvorlage erstellen und zur Genehmigung vorlegen

In diesem Schritt soll das Vorhaben entsprechend den Vorgaben der Organisation bestätigt und Die dafür benötigten Kapazitäten und Mittel genehmigt werden.

Neben dem formalen Weg kann es nützlich sein, die Entscheider frühzeitig auf inoffiziellem Weg einzubeziehen und sie für das Vorhaben zu gewinnen. Neben dem Nutzen für die Organisation kann die damit verbundene Aussicht auf das Erreichen persönlicher Karriereziele und auf besondere Anerkennung die Bereitschaft erhöhen, dem Projekt zuzustimmen. Es kommt also oft darauf an, welche der ohnehin vorhandenen Aspekte in welchem Zusammenhang betont werden 🙂

Ergebnis: Genehmigung zur Durchführung, Budget- und Ressourcenzusagen.

Ergebnisse
  • Grobkonzept
  • Projektplan
  • genehmigte Entscheidungsvorlage mit Budget- und Ressourcenzusagen
  • Team für die Tool-Auswahl

    2. Anforderungen definieren

    Um die für die Organisation am besten geeignete Software zu finden, muss man die Bedürfnisse und die Rahmenbedingungen genau kennen. Da die Prozesse in Unternehmen und Behörden in der Regel komplex sind und unterschiedliche interne wie externe Organisationseinheiten einbeziehen können, kann die Erhebung und Strukturierung der Anforderungen schnell eine aufwändige Angelegenheit werden. Es lohnt sich jedoch, diese Mühe mit der gebotenen Sorgfalt zu erbringen, um böse und vor allem teure Überraschungen zu einem späteren Zeitpunkt zu vermeiden. Es wäre fatal, wenn eine wichtige Anforderung erst nach Beschaffung der Software erkannt werden würde und diese Anforderung von der neuen Software nicht erfüllt werden kann.

    Anforderungen an die Software definieren

    • Was sind die Anwendungsfälle in der Anwendung?
    • Anforderungen der IT bzw. Anforderungen an den Betrieb
    • Zu erwartende Mengengerüste?
      - Benutzer: Power-User, Gelegenheitsnutzer
      - Anzahl der Interaktionen pro Zeiteinheit
      - Datenmengen, Anzahl der Datensätze

    • Besonderheiten der Organisation, der Prozesse
    • Welche Anforderungen an die Software leiten sich davon ab? → Kriterienkatalog
      - Allgemeine Anforderungen
      - funktionale Anforderungen
      - technische Anforderungen
      - Qualitätsanforderungen

    Die Anforderungen sollten sinnvoll erläutert werden, damit die Anbieter ein gutes Verständnis erhalten. Außerdem kann die Erläuterung auch intern helfen, bestimmte Dinge nachzuvollziehen.

    Kriterienkatalog erstellen

    Der Kriterienkatalog ist eine strukturierte Darstellung der Anforderungen an die Software, die von den Anbietern auszufüllen ist. Hiermit lassen sich Erfüllungsgrade abfragen und mit Bewertungszahlen koppeln, so dass am Ende für jedes Produkt eine Zahl steht, die das Maß der Übereinstimmung mit den Kriterien ausdrückt und die Angebote vergleichbar macht. Allerdings sollte diese Zahl mit entsprechender Vorsicht betrachtet werden, da die Fragen oft Raum für Auslegung bieten und von den Anbietern unterschiedlich verstanden werden können. Außerdem haben die Produkte in der Regel unterschiedliche Stärken und Schwächen, so dass die formale Eignung für eine Aufgabe von der tatsächlichen Eignung abweichen kann. Solche Unterschiede lassen sich meistens nur in einem praktischen Test herausfinden.

    • Oft als Tabellenkalkulation, eventuell online in einer speziellen Anwendung
    • Gliederungsvorschlag:
      - Allgemeine Anforderungen
      - funktionale Anforderungen
      - technische Anforderungen
      - Qualitätsanforderungen

    • Alle Anforderungen sollten durch eine ID eindeutig identifizierbar sein
    • Einstufung in Muss- und Kann-Kriterien
    • Erfüllungsgrade, z.B. „im Standard“, „durch Konfiguration“, „durch Customizing“ usw.
    • Die Anbieter sollten immer die Möglichkeit zur Kommentierung haben. Eine Anwendung hat zu einer Anforderung vielleicht ein ganz anderes Konzept und dieser Umstand sollte beschrieben werden können.

    Auf dieser Webseite finden Sie vorbereitete Kriterienkataloge zu den verschiedenen Disziplinen, die Sie für Ihre innerbetrieblichen Zwecke nutzen können. Diese sollten Sie jedoch zunächst auf ihre konkreten Bedürfnisse hin anpassen.

    Ergebnis: Ein strukturierter Katalog mit konkreten Anforderungen an die Software. Das Dokument ist so gestaltet, dass es von den Anbietern ausgefüllt werden kann und sich daraus eine über die verschiedenen Produkte vergleichbare Bewertung im Hinblick auf die Erfüllung der Kriterien ergibt.

    Grobkonzept und Projektplan aktualisieren.

    In dieser Phase werden Sie wichtige Erkenntnisse über Ihre Prozesse und Ihre Bedürfnisse gewonnen haben. Das ist normal und das ist gut, deshalb sollten Sie Grobkonzept und Projektplan in den relevanten Punkten auf den neuesten Stand bringen.

    Ergebnis: Die Dokumente sind auf einem aktuellen Stand.

    Review

    Auch die Ergebnisse dieser Phase sollten von einem nicht direkt beteiligten Dritten geprüft werden. Gerade der Kriterienkatalog kann umfangreich werden und sollte trotzdem konsistent sein, da er an die Anbieter geht und Grundlage für die weitere Evaluierung ist. Hierauf sollte besonderes Augenmerk gelegt werden.

    Ergebnis: Geprüfte und ggf. überarbeitete Dokumente.

    Genehmigung

    Ergebnisse
    • Grobkonzept
    • Projektplan
    • Anforderungen
    • Kriterienkatalog

      3. Auswahl und Vertragsabschluss

      Longlist erstellen

      • Anbieter aufnehmen, die erwarten lassen dass sie die Anforderungen erfüllen
      • Basis: Marktsichtung, Analysten

      Verfahren planen

      Die folgenden Schritte sollten sorgfältig geplant werden, da Termine sowohl mit internen Mitarbeitern als auch mit mehreren Anbietern abgestimmt werden müssen.

      • Rückfragen der Anbieter:
        - Zeitraum, in dem Fragen gestellt werden können
        - Wie können die Fragen gestellt werden? (z.B. per Mail an eine bestimmte Adresse)
        - Wie werden die Fragen und Antworten an alle anderen Anbieter (anonymisiert) weitergegeben?

      • Abgabe für die Informationen der Anbieter
        - Termin
        - Verfahren (z.B. per Mail)

      • Präsentationstermine: Die Termine mehrerer Anbieter sollten zeitlich nicht zu weit auseinander liegen, damit man die Produkte noch miteinander vergleichen kann.

      • Zeit zur Beurteilung und zur Entscheidungsfindung

      • Immer zu berücksichtigen:
        - Urlaubstermine
        - Perioden mit hohem Arbeitsanfall, z.B. Inventur, Jahresabschluss
        - verfügbare Räume

      Bitte planen Sie fair gegenüber den Anbietern. Es sind zwar Dienstleister, aber auch dort arbeiten Menschen, die mit ihrer Familie Urlaub machen oder Weihnachten feiern möchten. Vermeiden Sie deshalb möglichst Situationen, bei der man beispielsweise eine Ausschreibung kurz vor Weihnachten an die Anbieter verschickt, um am 02. Januar die Rücksendung der Angebote zu erwarten.

      Informationen der Produktanbieter einholen

      • Anschreiben
      • Beschreibung des Verfahrens gemäß der Planung
      • Erwartete Ergebnisse
      • Grobkonzept
      • Leistungsbeschreibung
      • Anforderungskatalog
      • Grober Projektplan

      Antworten der Anbieter auswerten

      Die von den Anbietern eingeschickten Antworten und Kriterienkataloge nach dem Bewertungsschema auswerten und die Anbieter bzw. Produkte in eine Rangfolge bringen.

      Anbieterpräsentationen

      Die in Frage kommenden Anbieter zu einer Präsentation einladen. Bei der Planung sollte berücksichtigt werden:

      • Beteiligte aus der eigenen Organisation festlegen.
        - Eventuell müssen nicht alle Teilnehmer die gesamte Zeit anwesend sein, manche nur während ihres Themas.
        - Urlaubszeiten und Perioden mit hohem Arbeitsanfall (z.B. Jahresendgeschäft) berücksichtigen.
        - Vertreter für kurzfristige Ausfälle bestimmen (betriebsbedingte Notfälle, Krankheit usw.)

      • Agenda festlegen.
        - Die Agenda sollte in Blöcken von ein bis zwei Stunden definiert werden.
        - Ausreichend Pausen einplanen
        - Puffer für unvorhergesehene Schwierigkeiten einplanen

      • Termine festlegen.
        Die Termine sollten wegen der Vergleichbarkeit nicht zu weit auseinander liegen. Aber am besten auch nicht 2 oder 3 Termine an einem Tag. Bei realen Besprechungen sollten sich die verschiedenen Anbieter nicht begegnen.

      • Arbeitsmodus festlegen.
        - Wer ist Moderator?
        - Wie werden Fragen gestellt?
        - Wer darf mit dem Anbieter außerhalb des offiziellen Teils sprechen? (wichtig vor allem bei öffentlichen Auftraggebern)
        - Wie und wann erfolgt die Bewertung? (z.B. 5 Minuten Zeit zur Bewertung nach jedem Abschnitt)

      • Organisation bei realen Besprechungen
        - Einladungen versenden, inkl. Agenda und Anfahrt
        - Räume und Technik reservieren
        - Ggf. Sitzordnung festlegen
        - Bewirtung/Getränke und Mittagessen organisieren
        - Besucher am Empfang anmelden

      • Organisation bei virtuellen Besprechungen
        - Einladungen für Webkonferenz erstellen und versenden, inkl. Agenda

      Präsentationen durchführen und Anbieter bewerten

      Shortlist erstellen

      Nach den Präsentationen wird für jeden Anbieter eine Zwischenbewertung erstellt, die jeweils die Ergebnisse aus dem Kriterienkatalog und aus der Präsentation berücksichtigen. Daraus wird eine Rangfolge erstellt und nur die führenden n Anbieter kommen eine Runde weiter.

      Die Rangfolge sollte trotz der eigentlich "objektiven" Punktzahl mit den intern Beteiligten diskutiert werden. Denn durch anfangs unglücklich gewählte Gewichtungen und durch im Verfahren gewonnene Erkenntnisse könnten sich formal Ergebnisse einstellen, die nicht zielführend sind. Sofern die Organisation die Freiheit besitzt, vom vereinbarten Verfahren abzuweichen, sollte bei Bedarf diese Möglichkeit zumindest erörtert werden, wenn es gute Gründe gibt. Andererseits darf das nicht dazu genutzt werden, um rein interessensgeleitet ein spezielles Tool nach vorne zu bringen, das aber die Anforderungen nur unzureichend erfüllt.

      Referenzen

      Mit den vom Anbieter genannten Referenzen sprechen und sich einen Eindruck verschaffen. Mit einer guten Gesprächsführung sollte der Referenzgeber ermutigt werden, sehr offen zu sprechen, auch über Schwächen des Systems bzw. in der Projektdurchführung. Aus diesem Grund sollte ein solches Referenzgespräch auch immer ohne den Anbieter stattfinden.

      Proof of concept

      • Anwendungsfälle definieren und beschreiben, die demonstriert werden sollen, dabei auch Besonderheiten in Ihrer Organisation einbeziehen, die das Tool abdecken können muss.
      • Termine planen
      • realistische und machbare Agenda aufstellen

      Testversion

      Eine Testversion des Produkts dient dazu, sich selbst ein Hands-on-Eindruck vom Tool zu verschaffen:

      • Wie ist die allgemeine Anmutung und Bedienung?
      • Sind die logischen Strukturen und die Konzepte der Software verständlich?
      • Wie einfach ist die Bedienung? Wie oft muss man für eine Aufgabe klicken? Sind wichtige Bedienelemente sofort auffindbar?
      • Wie ist die Masseneingabe? Wie leicht können 100 neue Datensätze angelegt werden?
      • Wie einfach ist die Software konfigurierbar bzw. anpassbar?

      Teststellungen, auf denen man als Interessent alleine testen kann, werden von manchen Anbietern kritisch angesehen. Die Möglichkeiten der heutigen Software-Systeme sind oft umfangreich und dementsprechend muss man zunächst die zugrunde liegenden Konzepte und Bedienmodelle kennenlernen, bevor man ein System sinnvoll nutzen kann. Die Furcht mancher Anbieter ist nun, dass bei einer "schnellen" Teststellung dieses eigentlich notwendige Training entfällt und damit die Software von den Testern nicht verstanden und deshalb als ungeeignet bewertet wird. Trotzdem sollte die Software hands-on getestet werden. Auch wenn man nicht jedes Detail des einzelnen Systems verstehen wird, so ergeben sich im Vergleich über alle Systeme wichtige Eindrücke, auf die man nicht verzichten sollte.

      Anbieter weiter eingrenzen

      • Ergebnisse aus dem Proof of concept und aus dem Test bewerten
      • Auf dieser Basis die weiter betrachteten Anbieter auf die zwei oder drei besten reduzieren

      Verhandlungen

      • Lizenzmetrik des Anbieters, Module
      • Supportstufen und -bedingungen
      • Projektaufwände zur Einführung

      Finale Angebotspräsentationen

      Hier sollte der Anbieter nochmals auf offene kritische Themen eingehen, Vorschläge zu deren Lösung einbringen und eine "best and final offer" machen

      Entscheidungsvorlage zur Einführung des Tools und Genehmigung

      Vertragsabschluss

      Ergebnisse
      • Lizenzvertrag bzw. Nutzungsvertrag für das Tool
      • Wartungsvertrag
      • Dienstleistungsvertrag zur Einführung
      • Kriterienkatalog