Beiträge

Sie sind Leiter eines Software Sourcing Projektes? Herzlichen Glückwunsch! Vor Ihnen liegt ein mehrstufiger Entscheidungsprozess, an dessen Ende die Empfehlung für die fachlich, technisch und wirtschaftlich passendste Tool Lösung steht. Aber Achtung: Auf dem Weg zur optimalen Software lauern gleich mehrere Stolperfallen. Fünf stellen wir Ihnen in diesem mosaiic Impuls vor.

Die fünf Stolperfallen beim Software Soucring

Stolperfalle #1: Ausschließlich an die Lösungen denken

So geht es nicht weiter. Sie brauchen eine Business Intelligence Software. Trotz umfassender VBA Makro-Akrobatik und Diagramm-Trickserei stößt das bei Ihnen über viele Jahre eingesetzte Microsoft Excel-File nun an seine Grenzen.

Ihre erste Anlaufstelle ist die Suchmaschine Google. Schnell sind Schlagworte wie ‚Business Intelligence Tool‘ oder ‚BI Lösung‘ eingegeben und die ersten 17 der über 340.000.000 Suchergebnisse gesichtet. Die Webauftritte der Hersteller A, B und C schauen vielversprechend aus. Warum diese nicht einfach einladen und zu ihrer Lösung befragen?

Empfehlung: In unseren Software Sourcing Engagements beobachten wir regelmäßig, dass Fachabteilungen nach kurzer Zeit bereits den Lösungsraum sondieren. Schnell sind relevante Kandidaten gesetzt, Hersteller-Workshops terminiert und Vorentscheidungen getroffen. Dabei sind Bewertungstreffen erst der übernächste Schritt. Zuvor sollten Ihre Anforderungen feststehen. Welche Anwendungsfälle muss die Software unterstützen? Welche Schnittstelle auf jeden Fall mitbringen? Welche Funktionen unbedingt ausführen? Erst wenn das ‚Was‘ (die Anforderungen) feststeht, gehen Sie auf das ‚Wie‘ (die Tool-Lösungen) ein.

Stolperfalle #2: Wichtige Anforderungsquellen vergessen

Als Nachfolger für die Microsoft Access Datenbank benötigt Ihr Mitarbeiter Herr Schmidt ein Tool. Dazu nimmt er zusammen mit Kollegin Frau Meier die Anforderungen auf. Nach einer Woche steht eine konsolidierte Liste mit insgesamt 30 Top-Anforderungen auf dem Papier. Diese sendet Herr Schmidt an potentiell in Frage kommende Hersteller und bittet um einen Vor-Ort Demonstrations-Workshop. Die Termine laufen gut, nach 6 Wochen steht die optimale Lösung fest.

Plötzlich meldet sich Herr Müller von der Nachbarabteilung. Er möchte ebenfalls mit dem neuen System arbeiten und hat – wenig überraschend – wenige zusätzliche Detailanforderungen. Auch gibt es da noch dieses Nachbarsystem zu dem eigentlich eine Export-Schnittstelle führen muss. Und überhaupt: berücksichtigt die präferierte Lösung überhaupt die Anforderungen der Informationssicherheit nach ISO 27001?

Empfehlung: Identifizieren Sie zu Beginn alle Anforderungsquellen für die neue Software und binden Sie diese in den Auswahlprozess ein. In der Regel sind dies die Stakeholder, beispielsweise die Fachbereichsnutzer bzw. der IT-Betrieb. Aber auch Nachbarsysteme, Vorgängersysteme und ähnliche Systeme sind Quellen für Anforderungen. Schließlich sind dokumentierte Anforderungen ebenfalls für die Auswahl der optimalen Lösung maßgebend. Das 6S Modell hilft bei der Strukturierung.

Stolperfalle #3: Keinen klaren Entscheidungsprozess besitzen

Die Anforderungen sind erhoben, abgestimmt und gewichtet. Die Lösungen wurden gesichtet und bewertet. Ein Favorit ausgewählt. Seitdem hakt es, im Software Sourcing Prozess. Nichts geht mehr weiter.

Der Grund: der Einkauf wurde zu spät informiert. Die vorgeschlagene Tool-Lösung liegt in Anschaffung und Betrieb über den Budgetgrenzen. Der Fachbereich argumentiert dagegen. Ein Festhalten am Ist-Zustand stellt ein signifikantes Risiko für das Unternehmen dar. Die Entscheidung ist festgefahren.

Empfehlung: Legen Sie vor der Softwareauswahl die Entscheidungsprozesse fest. Wert trifft eine Vorauswahl? Wird konjunktiv oder disjunktiv entschieden? Wer verfügt über Veto-Rechte, zeichnet eine Entscheidung also ab? Was passiert bei Patt-Situationen? Eliminieren Sie alle nervenaufreibenden Zeitfresser mit klaren Kommunikations- und Entscheidungswegen.

Stolperfalle #4: Sich von Herstellerpräsentationen blenden lassen

Dienstag 8:30 Uhr, Hersteller-Workshop. Drei adrett gekleidete Mitarbeiter des Software-Vendoren treffen pünktlich im Eingangsbereich Ihres Unternehmens ein. In den folgenden drei gemeinsamen Stunden werden Sie die Softwarelösung im Detail betrachten.

Dazu hat der Hersteller keine Kosten und Mühen gescheut. Ihren Entwicklungsingenieuren sitzen geschulte Vertriebsmitarbeiter gegenüber, die auf Hochglanzfolien und in perfektionierten Demonstrationsumgebungen die Vorzüge ihres Tools aufzeigen. Das Versprechen: Alle geforderten Features sind enthalten oder können binnen kürzester Zeit nachgeliefert werden.

Empfehlung: Lassen Sie sich von den Vertriebsshows der Hersteller nicht blenden. Diese praktizieren nur ihr Handwerk, das Verkaufen. Geben Sie stattdessen das Drehbuch für den Workshop vor. Welche Anwendungsfälle werden zu welchem Grad bereits von der Ist-Version erfüllt? Wie löst das Tool tatsächlich die in Ihrer Praxis anzutreffenden Probleme? Wo gibt es konkrete Beispiele? Verfahren Sie nach einem einheitlichen Procedere für alle Termine und machen Sie auf diese Weise die Fähigkeiten & Eigenschaften der Tools vergleichbar.

Stolperfalle #5: Zu viel Zeit in die Evaluierung investieren

Die Entscheidung für eine Business Software ist weitreichend. Ihre Kollegen und Sie binden sich viele Jahre an das neue Tool. Zu den Initialkosten für Auswahl, Konfiguration und Einführung kommen die Wartungs-, Betriebs- und Weiterentwicklungsaufwände sowie die Lizenzkosten. Folgerichtig sollte die Auswahl sorgfältig und strukturiert vonstattengehen.

Das heißt jedoch nicht, dass sich der Evaluierungsprozess monatelang hinziehen muss. Das Umfeld ist in Bewegung. So erlebten wir 2017 in einer von uns begleiteten Tool Evaluierung, dass eine favorisierte Application Lifecycle Lösung von einem deutschen zu einem israelischen Hersteller wechselte. Nach 9 Monaten Assessment hatten sich damit maßgebliche Randbedingungen geändert. Die Konsequenz: die Bewertung musste erneut starten, das Team zurück auf Los.

Empfehlung: Eine Entscheidung wird nicht besser, wenn diese unnötig herausgezögert wird. Begrenzen Sie die für das Software Sourcing verfügbare Zeit. Gehen Sie stufenweise vor und entscheiden Sie nach einem 4-wöchigen Sourcing Sprint, wie Sie weiter verfahren wollen. Bereits ein Kauf? Oder doch erst das Pilotprojekt? Muss es wirklich der Workshop Marathon mit 5 Herstellern sein oder reicht eine kostengünstigere Online-Befragung?

Fazit

In digitalen Zeiten gehört das Software Sourcing zur Standardaufgabe der Fach- und IT-Abteilungen. Vermeiden Sie die oben skizzierten Stolperfallen. Identifizieren Sie dazu die wichtigsten Anforderungsquellen, erheben Sie die Anforderungen und fixieren Sie den Entscheidungsprozess. Lassen Sie sich anschließend von den Herstellern in den Tool-Workshops nicht blenden und treffen Sie Ihre Entscheidungen stufenweise. Viel Erfolg im Sourcing Ihrer neuen Software.

Sie befinden sich aktuell in einem Software Sourcing Projekt? Nutzen Sie als Vorgehensmodell unseren erprobten Auswahlprozess. Kontaktieren Sie uns für weitere Fragen. Wie freuen uns auf die Diskussionen. Download Vorgehensmodell Tool Evaluierung: 5-phasige Vorgehen ‚mosaiic Tool Select‘.

In unseren Softwareauswahl-Projekten erleben wir es regelmäßig: die Fachspezialisten, IT-Architekten und Projektmanager konzentrieren sich ausschließlich auf das neue Softwareprodukt. Dicke Spezifikationsunterlagen werden gewälzt, umfassende Testläufe gefahren und mehrtägige Demonstrations-Workshops durchgeführt. Der Hersteller des Systems? Ist anwesend und präsentiert, wird jedoch nur einer flüchtigen Prüfung unterzogen. Dabei steht dieser doch hinter der Software und ihrer Weiterentwicklung. Was bei der Bewertung eines Tool-Herstellers wichtig, zeigen wir in diesem mosaiic Impuls.

Fokus auf die (nicht-)funktionalen Anforderungen der Softwarelösung

Im Beitrag Auf den Punkt – worauf es bei einer Tool Evaluierung wirklich ankommt haben wir Ihnen bereits mehrere Schwerpunkte bei einer Softwareauswahl vorgestellt. Im Zentrum standen dabei die Anforderungen an die Software. Daher:

  • Zu welchem Grad erfüllt das Produkt unsere fachliche & technische Spezifikation?
  • Inwieweit kommt es internen & externen Vorschriften (Compliance, Datenschutz, ISO-Anforderungen, etc.) nach?
  • In welchem Verhältnis steht der Return on Investment zu den finanziellen & zeitlichen Aufwänden für Projekte und Betrieb der Software?

Verfügbare Lösungen gegen die Anforderungen zu spiegeln kostet Zeit. In einem ersten Schritt fixieren Sie die Systemziele, Scope und Stakeholder. Darauf aufbauend müssen die Bewertungskriterien erhoben, dokumentiert, abgestimmt und priorisiert werden. Anschließend erkunden Sie den Raum der Lösungen und entscheiden sich schließlich für einen Tool-Kandidaten. Während des gesamten Prozesses steht die Software im Vordergrund. Aus unserer Sicht ist das ein Fehler.

Den Hersteller bei der Softwareauswahl berücksichtigen

Neben dem Tool, sollten Sie ebenfalls den Hersteller einer genauen Untersuchung unterziehen. Der Tool-Hersteller ist der Entwickler der Software. Er wartet diese und ist ebenfalls für die Weiterentwicklung seines Produktes zuständig. Im Gegensatz dazu ist der Tool-Anbieter der Verkäufer der Software bzw. der Softwarelizenz.  Je nach Vertrag kann ein Anbieter auch für die Betreuung und den Betrieb der Software verantwortlich sein. Zwecks besserer Lesbarkeit verwenden wir beide Begriffe nachfolgend als Synonym.

Angelehnt an die Pyramide der Wertelemente von Bain & Company (siehe Harvard Business Manager 07/2018 – Eric Almquist et al.: Was B2B-Produkte wertvoll macht), gilt es die Ebene der Geschäftsbeziehung genauer zu beleuchten. Folgende Herstellereigenschaften stehen dabei im Fokus (siehe auch Abbildung):

Abbildung: Bewertungskatalog für die Eigenschaften eines Softwareherstellers
Eigenschaftsgruppe 1: Unternehmen

Stabilität
  • Wie lange ist der Anbieter bereits am Markt?
  • Welche Gesellschaftsform besitzt er?
  • Welche Eigentümer- bzw. Shareholder-Struktur zeichnen ihn aus?
Marktwert
    null
  • Welche Größe (Mitarbeiter, Standorte, etc.) und Kapitalisierung (Umsatz, Gewinn, etc.) hat der Tool-Hersteller?
  • Welchen Ruf besitzt er für das Produkt (Marktanteil, Empfehlungen, etc.)?
  • Wie groß ist das Volumen an Neu- und Bestandskunden (inkl. Installationen)?
Kulturelle Übereinstimmung
    null
  • Welche Unternehmenswerte vertritt der Tool-Hersteller nach außen?
  • Aus welcher Zeitzone heraus operieren seine Entwicklungs-, Wartungs- und Vertriebs-abteilungen?
  • Zu welchen Kreisen (Kultur, Land, Branche, etc.) gehören seine Referenzkunden?
Eigenschaftsgruppe 2: Entwicklungspotential

Reichweite
  • Welche geographische Präsenz besitzt der Anbieter (Deutschland, Europa, Welt)?
  • Inwieweit ist seine Technologie in Webforen, Büchern, Wissenschaft, etc. vertreten?
  • Über welches Partnernetzwerk verfügt er (Verbände, Universitäten, komplementäre Firmen, etc.)?
Innovationskraft
  • Welche Zukunftsvision und Roadmap führt der Hersteller für sein Produkt an?
  • Auf welche Weise berücksichtigt er soziale, politische, wirtschaftliche und technologische Trends in den Entwicklungsprozessen?
  • Wie fokussiert ist er auf die Weiterentwicklung des Produkts?
Risikomanagement
  • Welche Maßnahmen hat der Anbieter für interne technischen und personellen Risiken aufgesetzt?
  • Zu welchen Zulieferern und Dienstleistern besteht für ihn ein Abhängigkeitsverhältnis?
  • Inwieweit betrachtet er Markt-, Gesetzes- und Wettbewerbsentwicklungen aktiv?
Eigenschaftsgruppe 3: Zusammenarbeit

Fachwissen
  • Wie fachlich beschlagen ist der Softwareanbieter (Mitarbeiterkompetenz, Zertifizierungen, etc.)?
  • Zu welchem Grad kennt er Ihre Domäne und das entsprechende Fachvokabular?
  • Auf welche Referenzprojekte mit ähnlichen inhaltlichen Bezug kann er verweisen?
Reaktionsgeschwindigkeit
  • Wie schnell reagiert der Softwareanbieter auf Ihre Anfragen?
  • Welche Prozesse für neue Anforderungen bzgl. Software und Service existieren?
  • Inwieweit ist das Pilotieren einer Prototypensoftware möglich?
Selbstverpflichtung
  • Welchen Stellenwert nimmt Ihre Anfrage im Portfolio des Herstellers ein?
  • Welche Flexibilität legt er bei Terminvereinbarungen an den Tag?
  • Wie reagiert er auf Anfrage nach weiterführenden Material und Expertengesprächen?

Jede Softwareauswahl besitzt bzgl. des Tool-Herstellers andere Schwerpunkte, abhängig vom Werkzeug, den Nutzern sowie dem strategischen Stellenwert für das Unternehmen. Fordert beispielsweise eine Bank für ihr Kernsystem bzw. ein Automobilhersteller für seine Stücklistenapplikation bei allen Herstellereigenschaften eine hohe Bewertung, reichem dem einzelnen Expertennutzer für ein Solo-Schreibtisch-Visualisierungstool nur dessen Funktionsumfang.

Wägen Sie daher im Vorfeld ab, welche Anbieteraspekte für die von Ihnen einzusetzende Softwarelösung bestimmend sind. Und durchleuchten Sie anschließend gezielt das Geschäftsmodell des Herstellers.

Quellen für die Herstellerrecherche

Die Unternehmenswebseite und der Workshop sind aufschlussreiche, jedoch nicht die einzigen Informationsquellen, um sich über einen Tool-Hersteller zu kundig zu machen. Ebenfalls helfen Ihnen folgende Quellen, ein Gefühl für das Unternehmen ‚hinter der Software’ zu bekommen:

  • Wirtschaftsauskunfteien (z.B. Creditreform, Bisnode, Bürgel, Schufa, Bundesanzeiger)
  • Messeauftritte, Webinare und Abendveranstaltungen
  • Pressemeldungen und Zeitschriftenbeiträge
  • Empfehlungen von Personen gleicher oder verwandter Branche und/oder Einsatzgebiete
  • Firmenportraits aus Softwarekatalogen (z.B. Softguide, SoftSelect)
  • Jobbörsen und Arbeitgeberportale (z.B. Monster.de, StepStone, kununu)

Achten Sie bei Empfehlungen auf Vergleichbarkeit. Auch wenn das Referenzunternehmen aus Ihrer Branche kommt und ähnliche Produkte bzw. Dienstleistung wie Sie anbietet, können sich die internen Geschäftsprozesse und damit die Anforderungen an eine Tool-Unterstützung sehr unterscheiden. In welchem Bereich wird die Software eingesetzt? Seit wann? Und unter welchen Bedingungen? Vergleichen ist gut – aber nur zwischen Äpfeln und Äpfeln.

Fazit

Der Hersteller einer Software ist Teil seiner angebotenen Lösung. Heute verkauft er Ihnen den aktuellen Stand, morgen wird er diese entlang Ihrer (neuen) Anforderungen weiterentwickeln. Ob Updates, Upgrades, Trainings, Support-Anfragen oder andere nachgelagerte Dienstleistungen – nach der Softwareauswahl schmiedet Sie ein enges Band an den Tool-Hersteller. Beziehen Sie den Anbieter daher bei der Entscheidung mit in Ihre Betrachtungen mit ein. Wir hoffen, unsere Fragen unterstützen Sie bei einer strukturierten Beurteilung.

Sie befinden sich aktuell in einem Softwareauswahlprojekt? Nutzen Sie als Vorgehensmodell unseren erprobten Auswahlprozess. Kontaktieren Sie uns für weitere Fragen. Wie freuen uns auf die Diskussionen. Download Vorgehensmodell Tool Evaluierung: 5-phasige Vorgehen ‚mosaiic Tool Select‘.

Wie definieren Sie Software-Verfügbarkeit? Was auf den ersten Blick banal anmutet, entpuppt sich bei näherer Betrachtung als komplizierte nicht-funktionale Anforderung an eine Business Software. Dabei ist Verfügbarkeit ein Standardthema in Software-Auswahlprojekten. Fast immer wünschen sich die Fachabteilungen einhellig ein „hochverfügbares System mit keiner bzw. minimaler Ausfallzeit“. In diesem mosaiic Impuls gehen wir daher auf den Aspekt der Verfügbarkeit von Kauf-Software ein. Als Orientierungsrahmen nutzen wir dazu fünf praxiserprobte Leitfragen.  

Software-Verfügbarkeit – 5 Leitfragen, die Sie den Fachabteilungen, Tool-Herstellern und Betriebsverantwortlichen stellen sollten

Die Akzeptanz eines Business Systems steht und fällt mit der Software Verfügbarkeit. Der mosaiic Impuls liefert 5 Leitfragen diese Qualität sicher zu bestimmen.
Abbildung 1: Leitfragen zur Präzisierung der Software Verfügbarkeit
Leitfrage 1: Was bedeutet eigentlich ‚verfügbar‘? Den Begriff ‚Software-Verfügbarkeit‘ bestimmen.

Antwortzeitverhalten, Datendurchsatz, Paketverzögerung, Paketverlustrate – keine Fachabteilung interessiert sich für die technischen Merkmale einer neuen Business Software. Vielmehr geht es ihr um die Verfügbarkeit (engl. Availability) der vom Tool bereitgestellten Services. Dabei ist Verfügbarkeit nicht gleich Verfügbarkeit. Tatsächlich ist der Begriff abhängig vom fachlichen Kontext. Dazu ein kleines Beispiel:

Im Falle eines Onlineshops betrachtet ein Nutzer die Ladezeit einer Webseite < 0,5 Sekunden als ausreichend verfügbar. Hingegen gilt ein Airbag-Steuergerät in einem Fahrzeug als nicht verfügbar, falls es für die Auswertung eines Auffahrsignals 0,5 oder mehr Sekunden benötigt.

Fragen Sie nicht nach Verfügbarkeit. Fokussieren Sie sich stattdessen auf die Facetten von verfügbarer Software. Das kann in einem Fall die Zuverlässigkeit und Reaktionszeit sein, im anderen Fall die maximale Ausfalldauer sowie die mittlere Dauer der Wiederherstellung nach einem Ausfall.

  • Was bedeutet im fachlichen Kontext Verfügbarkeit für eine Software und ihre Services?
  • Welche Service-Aspekte aus Nutzersicht sind relevant?
  • Woran merken wir, dass der Service einer Software in hoher Qualität verfügbar ist?

Versetzen Sie sich in Ihren Kunden bzw. dessen Endkunden. In Zeiten von ‚Always on‘ sind es Nutzer gewohnt, dass ein Service immer – und im Falle von Websoftware – (fast) überall zur Verfügung steht.

2018 begleiteten wir einem Automobilhersteller in der Auswahl eines Programm-Bereitstellungs-Tools. Die Fachbereiche wollten das System zum Hochladen und Verteilen von Programmen samt Dokumentation zur Steuergerätentwicklung nutzen. Den Fachbereich war es wichtig, dass sie innerhalb von 2 Minuten ein Steuergerät-Programm hochladen bzw. ein externer Dienstleister diese herunterladen konnte. Die Ladezeiten auf einer Webseite basierenden Services sollte mit kommerziellen Cloud Diensten wie Dropbox oder OneDrive vergleichbar sein.

Leitfrage 2: Ist das wirklich ein Ausfall? Den Begriff ‚Ausfall‘ definieren.

Auch für eine perfekt entwickelte und betriebene Business Software wird früher oder später der Moment kommen: das System streikt. Sie und Ihre Kollegen können keinen der Services mehr nutzen. Hersteller und Betreiber wissen das und sprechen Ihnen vertraglich eine Verfügbarkeit von unter 100 Prozent zu. Typische Angaben sind dann 99,5 Prozent Verfügbarkeit oder 99,2 Prozent Uptime.

Besitzt eine Business Software beispielsweise 99,3 Prozent Verfügbarkeit bei einer zugesagten 7/24 Nutzung, so sind das etwas mehr als 5 Stunden Ausfall pro Monat. In vielen geschäftlichen Fällen ist dieser Wert akzeptabel, insbesondere falls die Fachabteilungen das System nur zwischen 8 bis 18 Uhr von Montag bis Freitag nutzen. Doch reichen diese Angaben?

Als Gegenstück zur Verfügbarkeit, sollten Sie auch den Begriff ‚Ausfall‘ konkretisieren. Nützlich hierfür sind die folgenden Fragen:

  • Was ist ein Ausfall und wie lange bzw. wie oft tritt dieser auf?
  • Wann wird die Software wie lange gewartet (Wartungsfenster)?
  • Welche Daten gehen bei einem Ausfall verloren (maximaler Datenverlust)?

Präzisieren Sie, was der Hersteller bzw. Betreiber unter Ausfall versteht. Je mehr Softwaresysteme und Personen zur Erbringung einen Service interagieren, desto höher die Ausfallwahrscheinlichkeit. Diese ist das Produkt aus den Ausfallwahrscheinlichkeiten der einzelnen Service Komponenten.

Um einen Ausfall in geschäftskritischen Perioden vorzubeugen, können Sie sogenannte ‚Frozen-Zone‘ Zeiträume festlegen. In dieser darf der Hersteller bzw. Betreiber keine Änderungen an der eingesetzten Soft- oder Hardware vornehmen, beispielsweise in Form von Konfigurationen, Updates, Upgrades oder Umbauten. Das Ziel ist die Senkung der Ausfallwahrscheinlichkeit.

Im Beispiel des Programm-Bereitstellungs-Tools einigten sich die Fachbereiche auf folgende Anforderung an das Ausfallverhalten:

Die Software fällt maximal 2 Minuten am Stück, maximal 2x pro Stunde und 5x am Tag aus. Die Wartung erfolgt am letzten Sonntag im Monat zwischen 12 bis 18 Uhr. Das System durfte bei einem Ausfall keine Programme bzw. Dokumentationen verlieren.

Diese Beschreibung ist technisch spezifischer und fachlich wertvoller als die initial artikulierten 99,3 Prozent Verfügbarkeit.

Leitfrage 3: Ein Ausfall, und dann? Die Auswirkungen bestimmen.

Befassen Sie sich anschließend mit den Auswirkungen einer Nicht-Verfügbarkeit der neuen Software. Betrachten Sie sowohl Normal- als auch Hochzeiten in Ihrem Business. Für einen Onlineshop wäre das in der Regel die Weihnachtszeit, bei einer Bank üblicherweise das Jahresendgeschäft. Hilfreiche Fragen hierfür:

  • Wie viel Umsatz geht uns bei einem Ausfall pro Woche, Tag, Stunde, etc. verloren?
  • Mit welchem Mehraufwand müssen wir die Nicht-Verfügbarkeit während und nach dem Ausfall kompensieren?
  • Welche Verträge mit Kunden und Partnern verletzen wir, falls das System stillsteht?

Nicht alle Konsequenzen lassen sich 1:1 in zusätzlicher Arbeitszeit bzw. Geldverlust umrechnen. Wir nutzen bei qualitativen Größen wie beispielsweise Reputation, Markenwert oder Image eine 5-stufige Skala, die von ‚keinerlei Auswirkung‘ bis ‚sehr hohe Auswirkung‘ reicht.

Oft bieten Softwareprogramme mehrere Services. Nur selten sind dabei alle Service gleichwichtig. Am besten Sie zerlegen das Tool, bewerten den Ausfall einer Teilfunktion und priorisieren den Vorfall.

Im Beispiel des Programm-Bereitstellungs-Tools konnte der Fachbereich auf eine 7/24-Verfügbarkeit der Download-Analytics-Funktion verzichten. Das Hoch-/ und Runterladen von neuen Steuergerät-Programmen und -dokumentationen sollte hingegen mit einer Verfügbarkeit von 99,5 % an allen bayrischen Arbeitstagen sichergestellt sein.

Leitfrage 4: Wie die Verfügbarkeit kontrollieren? Das Messverfahren festlegen.

Die Verfügbarkeit steht für die Wahrscheinlichkeit oder das Maß, mit der eine Software bestimmte Anforderungen zu einem bestimmten Zeitpunkt bzw. innerhalb eines vereinbarten Zeitrahmens erfüllt. Es gilt die Formel:

Verfügbarkeit = (Gesamtzeit – Ausfallzeit) / Gesamtzeit.

Liegt die Verfügbarkeit eines Onlinebanking Services beispielsweise bei 99 Prozent, so ist dieser von 100 Stunden insgesamt 99 Stunden ohne Einschränkungen nutzbar.

Soweit die Theorie. In der Praxis messen Sie die Verfügbarkeit eines Softwaresystems mittels technischer Monitoringsysteme. Diese prüfen in einem Intervall die Verfügbarkeit des Services. Eine Messung ist jedoch immer eine Momentaufnahme. Damit stellen sich mehrere Fragen.

  • In welchem Intervall messen wir die Verfügbarkeit eines Software Services (z.B. 10-Minuten, 5-Minuten)? Wie gehen wir mit den Zeiten zwischen den Messungen um?
  • Was sind unsere Messpunkte (z.B. Rechenzentrum, Terminal in Niederlassung, Laptop des Außendienstlers irgendwo in Deutschland)?
  • Wieviel lassen wir uns Messung & Auswertung kosten?

Fakt ist: den Fachbereichen sind technische Details wie Messintervalle, Messpunkte oder Montoring-Einrichtungen egal. Für sie zählt einzig und allein die Zusicherung der Verfügbarkeit der von der Software erbrachten Services. Leiten Sie von dieser sowie den Auswirkungen technisch messbare und wirtschaftlich sinnvolle Kennzahlen ab. Und definieren sich anschließend Messverfahren und Messpunkte.

Für das Programm-Bereitstellungs-Tool schlug die IT eine Messung direkt im eigenen Rechenzentrum in einer Frequenz von 5 Minuten vor. Da die Software zunächst nur in Deutschland in der Zentrale zum Einsatz kommen sollte und bereits ein erprobtes Messverfahren für andere Systeme existieren, war dies ein kostengünstiger und direkt umzusetzender Messansatz.

Leitfrage 5: Wer zahlt für einen Ausfall? Die Sanktionen vertraglich fixieren.

Mit dem Wissen über die Auswirkungen beurteilen Sie anschließend die vom Softwarehersteller bzw. -betreiber vorgeschlagenen Sanktionen. Das sind die Vertragsstrafe, die ein Hersteller bzw. Betreiber zahlt, falls er den Ausfall der Software und der mit ihr verbundenen Services zu verantworten hat. Bewerten Sie diese sogenannten Pönalen genau.

  • Wie wird die Ausfallzeit definiert? Beispielsweise Kumulativ vs. hintereinander, im rollenden Zeitfenster von 30 Tagen vs. pro Kalendermonat?
  • In welchem Maß wiegt die versprochene Kompensation das Schadensaumaß bei Ihnen auf?
  • Wie versuchen Hersteller bzw. Betreiber ihre Haftung zu begrenzen?

Im Falle des Programm-Bereitstellungs-Tools stattete der betreibende Hersteller 5 Prozent der Abrechnungskosten zurück, falls seine Applikation im Monat 1 Stunde hintereinander ausfiel. Wiederum 100 Prozent der Abrechnungskosten waren fällig, falls die Software und Ihre Services 18 Stunden im Monat am Stück ausfallen würden.

Fazit

„Die neue Software muss verfügbar sein“ – diese Anforderung steht bei Software-Auswahlprojekten fast immer direkt im ersten Meeting Raum. Falls Sie Glück haben unterfüttern die Fachabteilungen diesen Bedarf noch mit dem quantitativen Zusatz „99,5 Prozent Software-Verfügbarkeit“. Das Problem: diese Angaben greifen zu kurz. Nähern Sie sich dem Thema Verfügbarkeit effektiver und nutzen Sie dazu die 5 vorgestellten Leitfragen.

Sie haben Fragen zum Thema Software Verfügbarkeit und möchten das Thema weiter vertiefen? Kontaktieren Sie uns für weitere Fragen. Wie freuen uns auf die Diskussionen.

Der Fachbereich verlangt für seine Geschäftsprozesse ein neues Tool? Geänderte regulatorische Bedingungen erfordern die Ablösung einer Alt-Software durch ein gesetzkonformes Werkzeug? Ein Technologiesprung zwingt die IT zum Austausch eines Bestandssystems? Drei klassische Situationen für eine Software Evaluation. Doch bevor Sie jetzt den Herstellermarkt nach einer passenden Lösung für Ihre Anforderungen durchkämmen, dürfen Sie zunächst einen Blick ins eigene Unternehmen werfen. Mit hoher Sicherheit gibt es da bereits ein Tool, welches die gestellten Bedarfe zu mindestens 50 Prozent abdeckt. Das glauben Sie nicht? Lesen Sie weiter!

Die Informationserhebung zu einer Software startet im eigenen Unternehmen

Sie kennen die Situation von Ihrem Eigenheim: eine kleine Optimierungsmaßnahme steht an, sagen wir, Sie möchten die Steinfließen auf Ihrer Gartenterrasse ausbessern, benötigen dazu einige Hilfsmittel. Als Do-it-Yourself-Verfechter planen Sie selbst zu Werke zu gehen, schließlich sitzt der Wissensarbeiter heute schon genug am Schreibtisch. Die Optionen sind klar. Sie könnten jetzt in den Baumarkt marschieren und sich von dem anwesenden Personal zu Tools wie Fließenschneider, Lochzangen und Waschsets beraten lassen. Alternativ informieren sich bei einer spätabendlichen Recherche im Internet. Anschließend vertrauen sie den Empfehlungen der Online Shops bzw. den Erfahrungsberichten aus den Webforen. Oder aber Sie wählen die naheliegendste Alternative. Sie fragen Ihren heimwerkenden Nachbarn. Welche Werkzeuge kann er empfehlen? Warum hat er sich gerade für diesen Hersteller entschieden? Und kann er Ihnen über einen Tag das Gerät zum Testlauf ausleihen?

Auch im Rahmen einer Business Software Evaluation muss Ihr erster Gang als Projektleiter nicht gleich zum Hersteller bzw. Anbieter sein. Gerade bei großen Mittelständlern und Konzernen ist die Wahrscheinlichkeit hoch, dass eine andere Abteilung bereits ein für Sie und Ihre Bedarfe passendes Tool im Einsatz hat. Die zentrale Frage lautet:

“Welche im Unternehmen bereits im Einsatz befindliche Software könnte auch unsere Anforderungen erfüllen?”

Nicht die neue Lösung im Markt, sondern die bestehende im Unternehmen wird gesucht und anschließend bewertet. Gleich mehrere Gründe sprechen dafür, mit der Informationsbeschaffung zu einer betrieblichen Software in der eigenen Organisation zu starten.

  • Die unternehmensinterne Recherche nach Lösungen spart Zeit und Aufwand. Keine Hersteller müssen informiert, keine Workshops durchgeführt und keine Ergebnisberichte ausgewertet werden.
  • Interne Kollegen geben offenes Feedback zu einer Software, schließlich haben sie weder Funktionalität noch Qualität des Produktes zu verantworten. Sie agieren als Nutzer und nicht als Verkäufer.
  • Kommt in Ihrem Unternehmen die Software bereits zum Einsatz, dann besteht eine ausgewiesene inhouse Kompetenz. Dies betrifft sowohl die Einführung als auch die Nutzung des Tools.
  • Für bereits verwendete Software existieren Lizenz- und Wartungsverträge. Auf denen können Sie aufsetzen bzw. von neu ausgehandelten kommerziellen Bedingungen profitieren.
  • Schließlich sind betriebliche Bestandstool prozessual, organisatorisch sowie technisch bereits in Ihrem Unternehmen integriert. Auf bestehenden Schnittstellen können Sie aufsetzen und für die neuen Anwendungsfälle erweitern.

Nutzung von Bestehenden, statt Neukauf. Was betriebswirtschaftlich von Vorteil ist, gleicht in der Praxis von Großunternehmen regelmäßig der bekannten Suche nach der Nadel im Heuhaufen.

Unseren Erfahrungen nach ist es meist gar nicht so einfach, interne Verantwortliche, Wissensträger oder Power-Nutzer von eingesetzten Softwareprodukten zu finden. Schnell sind da Tage bzw. gar Wochen vergangenen, bis Sie die richtige Person für ein Werkzeug identifiziert haben. Meint es dann Fortuna doch gut mit Ihnen und ist der Tool-Experte nicht gerade auf Dienstreise, im Urlaub oder auf einem Sabbatical dann hat er meist nur wenig Zeit für Sie. Die meisten Knowhow-Träger bindet ihr Projekt- und Alltagsgeschäft. Und trotzdem können Sie rasch an erste Hand-Infos zu potentiell geeigneten Software gelangen. Wenn Sie die Ansprechpartner gezielt und die Reihenfolge geschickt auswählen.

Fünf unternehmensinterne Quellen für die Software Evaluation

In den von uns begleitenden Software Evaluation Engagements hat sich folgende Kontaktkaskade bewährt (siehe Abbildung 1). Sobald die Anforderungen an Ihre Lösung stehen, klappern Sie diese Kollegen nacheinander ab und werfen somit ein 360° Bild auf das vorhandene Tool.

Abbildung 1: Unternehmensinterne Informationsquellen für eine Software Evaluation
Kontaktpunkt 1: der Software Verantwortliche

Ihre erste unternehmensinterne Anlaufstelle bei einer Software Evaluation ist der IT-Systemverantwortliche, manchmal auch IT Product Owner, Software Owner oder Tool-Eigner genannt. Seine Aufgabe ist die Weiterentwicklung und der Betrieb der Business Software. Der IT-Systemverantwortliche gibt Auskunft über den technologischen Lebenszyklus seines Produktes, weiß über dessen Verbreitung um Unternehmen und kennt relevante Wettbewerbsprodukte. Weniger vertraut hingegen ist ihm die praktische Nutzung des Tools im fachlichen Kontext.

Kontaktpunkt 2: der Enterprise Architekt

Enterprise Architekten bzw. Unternehmensarchitekten verfügen über ein fachbereichsübergreifendes Wissen der in der Organisation laufenden IT-Systeme. Meist in der Anfangsphase eines Projektes involviert, kennt ein Architekt die in Breite eingesetzten Lösungen. Wenden Sie sich an einen Enterprise Architekten im zweiten Schritt Ihrer Software Evaluation. Nutzen Sie ihn als Wegweiser und Tippgeber. Falls vorhanden, gehen Sie gemeinsam mit dem Architekten die Softwareprodukte in Ihrem Enterprise Architecture Management Tool durch und filtern sie relevante Kandidaten und Ansprechpartner heraus.

Kontaktpunkt 3: die Software Anwender

Existiert eine bestimmte betriebliche Software bereits in ihrem Unternehmen, dann wird mindestens ein fachlicher Anwender diese auch nutzen bzw. vor absehbarer Zeit auch genutzt haben. Anwender kennen ein Tool aus ihren täglichen Geschäftsprozessen. Sie können operative Vor- und Nachteile aus ihrer (subjektiven) Sicht aufzeigen. Da sie häufig viel ihrer Arbeitszeit mit der Software verbringen, wissen Anwender über die operativen Eigenheiten und Schwächen bzw. nützliche Hilfslösungen. Hingegen besitzen sie geringen bzw. keine Infos über die zu Grunde liegende Technologie, Systemarchitektur oder technische Anbindung.

Kontaktpunkt 4: der Projektleiter

Wenn Sie ein Softwareprodukt bereits im Haus haben, dann gab es dafür mit Sicherheit ein internes (Mini-)Projekt, welches die Software zuvor evaluiert, getestet, ausgerollt und etabliert hatte. Die Konsequenz: Der zuständige Projektleiter hat sowohl fachliche als auch technische Kenntnisse zum Tool. Fragen Sie diesen, wo die Knackpunkte bei der Software liegen.  Das schlimmste was Ihnen passieren kann, ist das das Einführungsprojekt schon Jahre zurückliegt, das Wissen über das Produkt und den Hersteller veraltet und damit unbrauchbar ist.

Kontaktpunkt 5: die Dienstleister

Beschäftigten Sie externe Dienstleister im Unternehmen, dann sind diese ebenfalls ein naheliegender Quell für wertvolle Softwareinformationen. Consultants sind gerne bereit ihr Wissen zu einem Tool aus vergangenen Einführungsprojekten bei anderen Kunden mit Ihnen zu teilen. Teilweise haben sich Dienstleister auf bestimmte Werkzeuge spezialisiert und können objektiv über deren Stärken und Schwächen berichten.

Fazit

Nicht immer muss es gleich die Beschaffung einer neuen Business Software sein. Gerade in großen Unternehmen existieren bereits viele Tools. Mit hoher Wahrscheinlichkeit passt eines der technischen Lösungen bereits zu 80 Prozent zu Ihren Anforderungen. Beginnen Sie daher eine Software Evaluation im eigenen Unternehmen. Sollten Sie dann nach einer Woche nicht fündig geworden sein, können immer noch an den Herstellermarkt in Angriff nehmen.

Sie befinden sich aktuell in einer Software Evaluation? Nutzen Sie als Vorgehensmodell unseren erprobten Auswahlprozess. Kontaktieren Sie uns für weitere Fragen. Wie freuen uns auf die Diskussionen. Download Vorgehensmodell Tool Evaluierung: 5-phasige Vorgehen ‚mosaiic Tool Select‘.

Wie lange benötigen wir für die IT-Systemauswahl? Tatsächlich müssen wir Ihnen auf diese zentrale Frage mit einem Berater-Standardfloskel antworten: „Es kommt darauf an.“. Erforderliche Mittel und notwendige Zeit für das Sourcing eines neuen IT-Tool bestimmen nämlich drei Faktoren, die wir gerne die ‚3S-Dimensionen‘ nennen. Welche das sind und wie Sie bereits zu Beginn Ihrer Software-Auswahl den Gesamtaufwand pragmatisch abschätzen, zeigen wir im mosaiic Impuls.

Aufwandstreiber bei der IT-Systemauswahl – die 3S-Dimensionen

Die Sachlage ist klar. Ein neues IT-System muss her. Dieses soll die Geschäftsprozesse Ihres Unternehmens automatisieren, die Fehlerrate und den operativen Aufwand senken, sowie die Qualität heben. Nichts Weltbewegendes. In digitalen Zeiten für Firmen ein Standardszenario.

Doch wie lange benötigt die Suche nach dem perfekten System? Wie viele personelle Kapazität und finanzielle Mittel müssen Sie für den Auswahlprozess einplanen? Und wann können Sie eine fundierte Tool-Entscheidung auf Basis belastbarer Fakten fällen?

Nach unseren Erfahrungen bestimmten genau drei Dimensionen den Aufwand und Zeitbedarf für die Auswahl eines IT-Systems: Stakeholder, Systemanforderungen und Suchraum. Nachfolgend stellen wir Ihnen die sogenannten 3S-Dimensionen vor. Bestimmen Sie direkt zu Beginn Ihres Sourcing Vorhabens die genau Ausprägung und schätzen Sie auf diese Weise den Gesamtaufwand ab.

Dimension #1: Stakeholder – Wer ist an der Auswahl beteiligt?

Generell gilt: je größer die Anzahl der an der Systemauswahl beteiligten Stakeholder, desto langwieriger das Unterfangen. Mehr Stakeholder, bedeutet mehr Anforderungen, mehr Randbedingungen und mehr Abstimmungsbedarf sowie ein erhöhtes Risiko, dass der Evaluierungsprozess wegen personellen Kapazitätsengpässen, Krankheitsfällen oder Parallelverpflichtungen ins Stocken gerät. Mit einem handverlesenen fokussierten Kernteam sind Sie häufig schneller unterwegs, als mit einer großen breiten Gruppe an selten verfügbaren Fachexperten.

Auch ist ein heterogenes Bewertungs- & Entscheiderfeld einen bedeutender Aufwandstreiber. Sprechen die beteiligten Bereiche die gleiche Sprache? Bestehen dieselben Prozessziele? Sind die Tätigkeitsfelder deckungsgleich oder zumindest verwandt? Steht der Entscheidungsprozess bereits zu Beginn fest? Falls Sie eine dieser Fragen mit nein beantworten, hat das unmittelbare Auswirkung auf den Gesamtaufwand der Systemauswahl. Dieser erhöht sich, je inhomogener die Teilnehmer.

Eine letzte Determinante in der Kategorie Stakeholder sind die Erfahrungswerte. Fach- und IT-Bereiche, die regelmäßig ein Software Sourcing durchlaufen, agieren weitaus Trittsicherer beim Vorgehen. Wissen die betroffenen Akteure genau was sie wollen, kennen sie vielleicht bereits einige Tools aus dem Lösungsraum, geht die Evaluierung ebenfalls deutlich effizienter über die Bühne.

Dimension #2: Systemanforderungen – Was soll das IT-System leisten?

Mehr wichtige Geschäftsprozesse, führt zu mehr Aufwand – so die simple Faustformel für eine IT-Systemauswahl. Ein Tool was eine einzelne Aktivität eines Prozesses unterstützt, ist rascher aufzuspüren, als die eierlegende Wollmilchsau für die Geschäftsprozesse eines gesamten Unternehmensressorts. Expertentools haben weniger Nutzer und damit weniger Funktionen, als die großen „Ich-automatisiere-Alles-für-Jeden“-Lösungen. Ebenfalls sind geschäftskritische Systeme deutlich detaillierter zu beleuchten, als die kleine Schreibtischanwendungen eines nachgelagerten Unterstützungsprozesses.

Ein weiterer Aufwandstreiber für die Systemauswahl sind die Daten. Bestehen fachlich hohe Anforderungen an Informationssicherheit, also an Vertraulichkeit, Verfügbarkeit und Integrität, so zieht das eine sorgfältigere Prüfung der in Frage kommenden Lösungen mit sich. Vorausgesetzt die Fachbereiche wissen, wie ihre Daten einzustufen sind. Falls nicht, muss zunächst eine Informationsschutzfeststellung vorgeschaltet werden, die natürlich auch Zeit und Energie frisst.

Schnittstellen sind ein dritter Treiber für den Gesamtaufwand in der Dimension Anforderungen. Je mehr (bilaterale) Kommunikation zu Nachbarsystemen besteht, je komplizierter diese ausfällt, desto umfassender der Evaluierungsprozess. Immerhin müssen nun auch die fachlichen und technischen Verantwortlichen der angrenzten Systeme mit in die Auswahl eingebunden, ihre Anforderungen und Lösungsvorstellungen berücksichtigt werden.

Schließlich bestimmen die organisatorischen & technischen Randbedingungen, wie viele Zeit und Ressourcen Sie für die Systemauswahl einplanen müssen. Das Tool muss spezifische regulatorische Anforderungen erfüllen? Bei Roll-out und Betrieb der Lösung sind interne Rahmenparameter zu berücksichtigen? Mehr Prämissen, längere Evaluierung.

Dimension #3: Suchraum – Welche Tools kommen in Frage?

Dritte und letzte Dimension für den Gesamtaufwand bei der IT-Systemauswahl ist der Suchraum. Wie bei den Anforderungen gilt der Grundsatz: je weniger relevante Systemlösungen abzuklopfen sind, desto schneller sind Sie fertig. Bewerten Sie sechs Tools im Detail kostet Sie dies doppelt soviel Aufwand, wie die Begutachtung von drei Kandidaten. Vorausgesetzt, die zu bewertenden Optionen erfüllen die Anforderungen der Stakeholder.

Auch sind Sie um ein Vielfaches schneller und wirtschaftlicher unterwegs, falls Sie nur solche Lösungen unter die Lupe nehmen, die bereits in anderen Unternehmensbereichen zum Einsatz kommen. Bei intern in Verwendung befindlichen IT-Systemen besteht bereits Kontakt zum Hersteller, besitzt Ihre Organisation Tool-Knowhow, kennt ihr Personal die Vorzüge und Nachteile, existiert bereits ein erprobtes Betriebs-, Wartungs- und Lizenzmodell.

Falls Sie intern nicht fündig werden, den Suchraum auf Lösungen außerhalb Ihrer Unternehmensmauern ausdehnen müssen, wird es teuer. Hersteller müssen kontaktiert, Vertraulichkeitserklärungen unterzeichnet, Workshops anberaumt, Technologiekompatiblität strategisch bewertet sowie Rahmenverträge für Wartung, Weiterentwicklung und Nutzungslizenzen abgeschlossen werden.

Ein letzter Aufwandstreiber ist ein Vorgängersystem. Zum Einen kapselt die Status-Quo-Lösung implizit Anforderungen an den Nachfolger und muss in Konsequenz bei der Softwareauswahl damit (detailliert) berücksichtigt werden. Kein Fachbereich wird sich mit einem System zufriedengeben, welches wichtige Funktionen der Ist-Lösung nicht erfüllt. Zum anderen kann ein bestehendes System den Suchraum für den Nachfolger erheblich einschränken. Die beiden Stichworte sind hier Hersteller- bzw. Technologie-Lock-in.

Abbildung 1: Aufwandsklassen für die Auswahl eines IT-Systems

In oberer Übersicht haben wir unsere Praxiserfahrung für Sie in eine kompakte Übersicht gebracht. In unseren Beratungsmandaten unterscheiden wir zwischen einfachen, mittleren, umfangreichen und intensiven Systemauswahlprojekten. So benötigt die Auswahl eines einfachen Codeeditors, mit wenigen Stakeholdern, überschaubaren Anforderungen und einem kleinen Suchraum maximal 2 Wochen. Soll hingegen ein komplexes Warenwirtschaftssystem für das gesamte Unternehmen am internationalen Herstellermarkt gefunden werden, können Sie von einem Projekt von mehreren Monaten mit hohem Personalaufwand ausgehen.

Beachten Sie, dass es bei den Angaben um Daumenwerte handelt. Die Tabelle dient als pragmatische Richtschnur, um zum Projektauftakt nach einem Initial-Workshop erste Aussagen über die Länge und den Mitteleinsatz für die Systemauswahl treffen zu können.

Fazit

Bestimmen Sie den Gesamtaufwand für die Auswahl eines IT-Systems anhand der Stakeholder, den Systemanforderungen sowie den Suchraum für die Lösungen. Verschaffen Sie sich dazu direkt zu Beginn des Sourcing Projektes ein Überblick über die drei Kerndimensionen.

Wir unterstützen Sie beim Aufsetzen Ihres Systemauswahlprojektes. Kompetent, erfahren und Hersteller-unabhängig. Fordern Sie dazu einfach unverbindlich die Systemauswahl-Checkliste bei uns an und beurteilen Sie strukturiert, in welche Aufwandsklasse Ihr Vorhaben fällt. Kontakt aufnehmen.