Hinweise für Käufer von Softwarelösungen: Whitepaper

Dieses Whitepaper ist Teil unserer Sammlung "Aus der Praxis". Es beschreibt, wie potenzielle Käufer von Software effektiver mit Softwarelieferanten interagieren können, indem einfach zu verstehende Geschäftsanalysemethoden angewendet werden. Es führt Sie schrittweise durch eine Übung, die Sie beim Erstellen von Softwareauswertungskriterien unterstützt, indem effektiv ermittelt wird, welche Probleme die Softwarelösung berücksichtigen soll.

Die Word-Version dieses Whitepapers können Sie unter Hinweise für Käufer von Softwarelösungen herunterladen.

Weitere Whitepaper finden Sie unter "Aus der Praxis" – Whitepaper.

Hinweise für Käufer von Softwarelösungen

Häufig basiert der Erwerb von Software auf einer Liste von Features, einer Werbekampagne oder der Empfehlung eines Freundes. In diesem Artikel wird beschrieben, wie potenzielle Käufer von Software effektiver mit Softwarelieferanten interagieren können, indem einfach zu verstehende Geschäftsanalysemethoden angewendet werden.

Es ist sicher nicht mehr so, wie es einmal war. Das Einrichten von Software in einem Unternehmensumfeld wird nicht einmal mehr als Installation bezeichnet. Heutzutage beschreiben die Begriffe Implementierung oder Bereitstellung die Aufgaben besser, die erforderlich sind, um ein neues Softwarepaket einzurichten und in Betrieb zu nehmen.

Immer mehr Softwarelieferanten bezeichnen ihr Produkt verständlicherweise als "Lösung". Wenn Sie über die Bereitstellung eines Unternehmenssystems wie etwa Microsoft Project Server oder Microsoft CRM nachdenken, müssen an erster Stelle die verschiedenen Ebenen der eingesetzten Technologie berücksichtigt werden, und noch davor müssen die Auswirkungen auf das Gesamtgeschäft bedacht werden.

Wenn Lösungen verkauft werden, ergibt sich zwangsläufig auch ein Lösungsvertrieb. Wenn Sie diese Entwicklung auch nur am Rande verfolgt haben, wissen Sie, dass beinahe jede Hightech-Organisation weltweit, deren Zielgruppe mittlere bis große Organisationen sind, daran arbeitet, sich als Anbieter von Lösungsvertrieb zu präsentieren. Microsoft gehört zweifellos zu diesen Organisationen. Microsoft hat sich in den letzten Jahren umfassend damit beschäftigt, den Verkauf von Lösungen als Leitsatz für den Außendienstvertrieb und die Implementierungsmitarbeiter zu etablieren.

Was also ist ein Verkäufer für Lösungen? Richtig ist, dass es sich noch immer um einen Verkäufer handelt. Das Ziel von Verkäufern von Lösungen besteht jedoch nicht darin, einen Karton mit Software an den Kunden zu bringen, sondern eine Lösung zu erstellen, die dem Kunden hilft, seine Situation zu verbessern.

Das klingt erst einmal gut: ein Nirvana von Verkaufspersonal mit dem gemeinsamen Ziel, Ihr Leben zu vereinfachen. Damit ist jedoch auch eine Herausforderung verbunden. Das Annehmen dieser Herausforderung ist etwas, an dem Sie – der potenzielle Kunde – teilnehmen können.

Das Problem im Mittelpunkt

Die Herausforderung, mit der die meisten Verkäufer von Lösungen konfrontiert sind, wenn sie in den Markt einsteigen, ist unsere vorgefasste Meinung, wie eine Lösung aussehen sollte. Wir sind so daran gewöhnt, uns auf Funktionen und Features von Software zu konzentrieren, dass ein Gespräch mit einem Softwareverkäufer beinahe zwangsläufig direkt zu der Frage führt "Kann Ihre Software dies? Kann Ihre Software das auch?" Erfahrene Softwareverkäufer – das sind diejenigen, die das Verkaufen von Lösungen übernommen haben – sind so sehr daran gewöhnt, Funktionen und Features zu verkaufen, dass sie häufig vergessen, die grundlegendste aller Fragen zu stellen: "Worin besteht das Problem?"

Das mag sich dumm anhören. Wenn Sie jedoch an Ihre letzten Gespräche mit Softwareverkäufern denken, sind Sie möglicherweise überrascht, wie selten diese Frage gestellt wird. Lieferanten wie Microsoft und Partner erhalten jedes Jahr zahlreiche Angebotsaufforderungen. Im Lauf der Jahre habe ich Hunderte davon zu Gesicht bekommen. Fast immer findet sich darin eine umfangreiche Tabelle mit Funktionen, die der Lieferant ausfüllen soll. Diese umfangreiche Tabelle ist häufig das Kernstück der Antwort an den Kunden.

Was selten vorhanden ist, ist eine Beschreibung der Geschäftsanforderungen, die von jeder dieser Funktionen erfüllt werden sollen. Es ist so einfach, sich in eine Funktion zu verbeißen, die wir aus einem vorherigen Produkt kennen oder die irgendwo beworben wurde, dass es echte Disziplin erfordert, sich auf das zu konzentrieren, was uns ursprünglich an diesem neuen Produkt interessiert hat. Dies kann insbesondere in einem Unternehmensumfeld zutreffen, in dem viele Vorgaben vorhanden sind, nach welchem Typ von Lösung gesucht wird. Es ist viel einfacher, die Mitarbeiter aufzufordern, alle Funktionen aufzulisten, die sie sich in einem neuen Softwaresystem wünschen, als über ihre jeweiligen Geschäftsanforderungen zu sprechen.

Wenn Ihnen langsam aufgeht, dass Sie vielleicht etwas Offensichtliches vergessen haben, stehen Sie damit nicht allein da. Dieser Umstand ist in der Softwarebranche momentan so vorherrschend, dass sich ein neuer Typ von Berater mit der Bezeichnung Business Analyst entwickelt hat. Diese Berater sind darin geschult, die Verbindung zwischen der Geschäftsanforderung und den Softwarefunktionen herzustellen. Nehmen Sie sich einige Minuten Zeit, um zu erfahren, wie Sie diese grundlegenden Konzepte bei der Auswertung von Software auf Unternehmensebene anwenden können – auf die gleiche Weise wie ein Business Analyst.

Identifizieren der Geschäftsanforderung

Der erste Aspekt, den Sie berücksichtigen müssen, ist die Geschäftsanforderung, die Sie ursprünglich dazu bewogen hat, nach einem neuen Softwaresystem zu suchen. Unsere eigene Organisation berät häufig Firmen bezüglich der Implementierung von Projektverwaltungssoftware für das Unternehmen. Wenn ich als Berater bei einer Organisation eintreffe, frage ich lange vor einem Gespräch zu einem eventuellen Kauf von Software, wie die Organisation die Projektverwaltung zurzeit ausführt.

Nachdem ich eine Antwort erhalten habe, stelle ich immer die folgende Anschlussfrage: "Funktioniert diese Methode für Sie?" Erstaunlicherweise antwortet der Kunde häufig, dass dies der Fall ist. Für mich endet das Implementierungsgespräch an diesem Punkt. "Wenn es kein Problem gibt" sage ich dann, "kann ich auch keine Lösung finden!" Diese Antwort bringt mein Gegenüber häufig zum Nachdenken. "Warum wurden wir beauftragt?", frage ich. Die Antworten können sehr unterschiedlich ausfallen, und häufig geht meinen Gesprächspartnern auf, dass die diversen Vorstellungen aufeinander abgestimmt werden müssen – und unser Gespräch hat noch nicht einmal fünf Minuten gedauert!

Die Frage "Worin besteht Ihre Geschäftsanforderung?" ist daher ein guter Ausgangspunkt. Fast immer gibt es ein Gesamtziel, das diese Frage beantwortet – ein Ziel, das die ganze Initiative ursprünglich angestoßen hat.

Eine Übung zur Vision

Sie müssen etwas näher untersuchen, was dies im Hinblick auf die Softwarefunktionen bedeutet. Wenn wir Projektverwaltungssoftware für Unternehmen wie etwa Microsoft Project Server in einer Organisation implementieren, beginnen wir immer mit einer Visionsübung, an der die Schlüsselmitarbeiter teilnehmen: die Mitarbeiter, die die Software auswerten, und das obere Management – die Sponsoren der Übung. Es reicht nicht aus, diese Übung nur mit dem technischen Personal zu veranstalten, weil das Ziel dieser Übung darin besteht, Geschäftsziele und technische Funktionen zu verbinden.

Dies ist eine effektive Möglichkeit, die Übung auszuführen: Versammeln Sie die Schlüsselmitarbeiter in einem Raum mit einem großen Whiteboard. Unterteilen Sie das Whiteboard in vier Spalten: Beginnen Sie mit einer Überschrift nur in der ganz rechten Spalte. Nennen Sie diese Spalte "Geschäftsentscheidung".

Whiteboard mit vier Spalten, einschließlich einer Spalte 'Geschäftsentscheidung'

In der rechten Spalte listen Sie die Geschäftsentscheidungen auf, die Sie durch Verwenden des neuen Systems treffen möchten, das Sie in Betracht ziehen. Wenn wir mit einem Kunden an diesem Punkt sind, möchten die Mitarbeiter zuerst immer viele Features auflisten. Sie müssen also darauf bestehen, dass die Antworten, die wichtig sind, Geschäftsentscheidungen sind. Ein Teilnehmer könnte z. B. sofort sagen: "Ich brauche eine Liste aller Ressourcen und ihrer Auslastung". Das kann natürlich zutreffen. Sie müssen jedoch herausfinden, welche Geschäftsentscheidung auf der Grundlage dieser Liste getroffen wird.

Die folgenden Beispiele sind Geschäftsentscheidungen:

  • Personalaufstockungen oder Entlassungen in einer bestimmten Abteilung

  • Treffen der Entscheidung, ob ein Projekt verwirklicht wird

Whiteboard mit Spalte 'Geschäftsentscheidung' und einer Liste von Geschäftsentscheidungen

Nachdem Sie eine ausreichend große Liste mit Geschäftsentscheidungen erarbeitet haben, legen Sie eine Pause ein. Jetzt ist ein guter Zeitpunkt, die Liste mit den Geschäftsentscheidungen zu untersuchen und die Entscheidungen mit höchster Priorität zu identifizieren. Sie können sich die folgende Frage stellen: Wenn Sie nur Antworten auf eine dieser Geschäftsentscheidungen erhalten könnten, welche Entscheidung würde den höchsten Wert für Ihre Organisation darstellen? Das Auswählen der drei wichtigsten Entscheidungen ist an diesem Punkt der Übung immer am einfachsten.

Wenn Sie bis hierhin gekommen sind, haben Sie bereits mehr erreicht als die meisten Organisationen, die über Projektverwaltungssoftware für das Unternehmen nachdenken. Wenn Sie in der Lage sind, Systemlieferanten eine mit Prioritäten versehene Liste der wichtigsten Geschäftsentscheidungen vorzulegen, haben Sie einen großen Schritt nach vorn im gesamten Vorgang gemacht. Wenn Sie Systemlieferanten mitteilen können, welche Geschäftsentscheidungen getroffen werden müssen, können diese weit mehr als nur über einfache Funktionalität reden und Vorschläge unterbreiten, wie die Organisation effektiver wird.

Im nächsten Schritt sehen Sie sich die einzelnen Entscheidungen an und fragen sich: "Welcher Bericht wird benötigt, damit diese Geschäftsentscheidung getroffen werden kann?" Fast jede Entscheidung wird nach der Durchsicht mindestens eines Berichts getroffen. Versehen Sie die dritte Spalte mit der Überschrift "Bericht". Für jede der drei wichtigsten Entscheidungen listen Sie in dieser Spalte die Berichte auf, die für die jeweilige Entscheidung erforderlich sind.

Wenn Sie z. B. ermitteln möchten, ob Personal in einer bestimmten Abteilung eingestellt oder entlassen werden soll, benötigen wir einen nach der Abteilung aufgeschlüsselten Bericht, der die Planungsdaten für die Ressourcenkapazität enthält. Dies beinhaltet eine Prognose der erwarteten Arbeitslast, die erwartete Ressourcenverfügbarkeit und einen Zeitplan. Wenn Sie ein mittelgroßes Unternehmen führen, kann auch der Kapitalfluss ein weiterer Aspekt sein. Es kann z. B. weiteres Personal erforderlich sein, Sie verfügen jedoch nicht über die Mittel, dieses einzustellen. Der Bericht zum Kapitalfluss würde die geschätzten Einnahmen und Ausgaben mit einem fortlaufenden Saldo enthalten.

Whiteboard mit Spalten 'Bericht' und 'Geschäftsentscheidung'

Wenn wir die Spalte "Bericht" für jede der Entscheidungen, die als Prioritäten identifiziert wurden, ausfüllen, nimmt die benötigte Lösung bereits Form an. Wenn Sie diesen Schritt abgeschlossen haben, verfügen Sie über eine Liste der physischen Ausgaben, die von Ihrem zukünftigen System erforderlich sind.

Legen Sie hier erneut eine Pause ein, um herauszufinden, ob bereits Berichte des ermittelten Typs vorhanden sind, die schon in der Organisation verwendet werden. Wahrscheinlich sind solche Berichte vorhanden. Sie liegen jedoch in vielen verschiedenen Formaten und ggf. mit unvollständigen Daten vor, oder der Aufwand für ihre Generierung ist unverhältnismäßig hoch. Wenn Sie Berichte in Formaten finden, die in der Organisation funktioniert haben, können Sie diese Ihrer Liste der Systemanforderungen hinzufügen. Nun können Sie den Systemlieferanten noch mehr Informationen zur Verfügung stellen.

Da die Schlüsselberichte nun identifiziert wurden, können wir mit den Elementen eines Systems fortfahren, die erforderlich sind, um diese Berichte zu generieren. Fügen Sie der zweiten Spalte des Diagramms die Überschrift "Analyse" hinzu. Identifizieren Sie für jeden Bericht die Analysen oder Algorithmen, die erforderlich sind, um den Bericht zu generieren. Für einen Bericht zur Ressourcenkapazitätsplanung benötigen wir z. B. möglicherweise einen Netzplan aus dem Projektverwaltungssystem und eine Ressourcenabgleichsanalyse.

Whiteboard mit Spalten 'Analyse', 'Bericht' und 'Geschäftsentscheidung'

Diese Analysen werden von Lieferanten häufig auf der Grundlage der unzähligen Features vermarktet, die jede Analyse enthält. (Ja, der Verkauf von Features geht weiter und floriert!) Sie müssen die Mindestfunktionen ermitteln können, die für die erforderlichen Berichte benötigt werden, mit denen Sie dann die Geschäftsentscheidungen treffen oder optimieren können, die Sie identifiziert haben. Möglicherweise sind Sie überrascht, wie einfach die Funktionen sind, die Sie benötigen, um Ihre tatsächlichen Geschäftsanforderungen zu erfüllen. Für einige Berichte sind überhaupt keine Analysen oder Berechnungen erforderlich. Die Berichte müssen nur einfache Aggregate sein, die unmittelbar aus den Daten des neuen Systems generiert werden können.

Schließlich kommen wir zur ersten Spalte des Diagramms. Nachdem Sie die erforderlichen Analysen identifiziert haben, können Sie ermitteln, welche Datenelemente erforderlich sind, um die Analysen zu füttern.

Fügen Sie der ersten Spalte Ihres Diagramms die Überschrift "Eingaben" hinzu.

Im verwendeten Beispiel ist ggf. eine vollständige Liste der Aufgaben für jedes Projekt im Arbeitsbereich der Abteilung erforderlich. Dabei kann es sich sogar um jedes Projekt in der Organisation handeln. Wir benötigen außerdem ein vollständiges Profil der Verfügbarkeit jeder Ressource sowie die Arbeitslast, die für jede Aufgabe definiert wird, damit bei jeder Bewegung der Aufgabe in der Zeitplananalyse die Arbeitslast in der Ressourcenabgleichsanalyse verschoben wird. Erinnern Sie sich noch daran, wie wir mit der Entscheidung über Einstellungen oder Entlassungen in einer bestimmten Abteilung begonnen haben? Wir müssen auch in der Lage sein, die Ressourcen nach Abteilung zu identifizieren.

Whiteboard mit Spalten 'Eingabe', 'Analyse', 'Bericht' und 'Geschäftsentscheidung'

So können wir uns von den Ausgaben auf der rechten Seite zu den Eingaben auf der linken Seite bewegen, bis wir alle Elemente identifiziert haben, die wir in unserem neuen Unternehmenssystem benötigen.

Einschätzen von Risiken

Nachdem diese Übung abgeschlossen wurde, lohnt es sich, zu jeder der Eingaben zurückzukehren und zu ermitteln, wie verfügbar diese Datenelemente sind. Ggf. finden Sie heraus, dass einige dieser Elemente gar nicht vorhanden sind (so geht es uns häufig). Einige Organisationen verwalten z. B. keine vollständige Liste der Ressourcenverfügbarkeit. Möglicherweise finden Sie auch heraus, dass nicht jedes Projekt einen mit Ressourcen versehenen Zeitplan besitzt, der die Ressourcenlast ausweist, die von dem betreffenden Projekt generiert wird. In vielen Organisationen werden bestimmte Projekttypen in überhaupt keinem System erfasst. Häufige Beispiele sind dringende Arbeiten, technischer Support oder regelmäßige Wartungsarbeiten.

Wenn Sie keinen Zugriff auf die grundlegenden Daten besitzen, die Sie benötigen, um den Geschäftswert bereitzustellen, müssen Sie dieses Element des Systems als mit hohem Risiko behaftet betrachten. Wenn wir z. B. herausfinden, dass wir über mit Ressourcen versehene Zeitpläne für 80 % der Projekte der Organisation verfügen, wäre es dann vernünftig zu erwarten, dass wir unsere Geschäftsentscheidung bezüglich Neueinstellungen oder Entlassungen optimieren können? Die Antwort lautet wahrscheinlich "Nein". Warum ist das so? Weil die 20 % der Projekte, die nicht im System enthalten sind, ggf. 80 % der Arbeitslast für eine bestimmte Abteilung darstellen können. Wenn die Daten unvollständig sind, wissen Sie niemals, ob der Abschlussbericht genau ist.

Natürlich lassen sich diese Probleme auch umgehen. Eine Methode besteht darin, alle Geschäftsprozesse der Aspekte der Organisation, in denen Sie keinen Zugriff auf die Datenelemente erhalten können, zu isolieren. Für einen Geschäftsbereich, dessen Projekte nicht im System enthalten sind, werden auch die Ressourcen nicht aufgelistet. Dies ist nicht in allen Fällen so einfach. Sie müssen Element für Element untersuchen, um herauszufinden, welches Risiko der betreffende Geschäftsprozess und die jeweiligen Geschäftsentscheidungen für Ihre Implementierung bedeuten. Es ist nicht ungewöhnlich, an diesem Punkt die endgültigen Geschäftsentscheidungen, die Sie optimieren möchten, mit einer neuen Priorität zu versehen. Möglicherweise ist eine Entscheidung ausgesprochen wünschenswert, entpuppt sich jedoch als großes Risiko und sollte daher in den frühen Phasen Ihrer Bereitstellung nicht getroffen werden.

Dokumentieren, was geschehen ist

Wenn Sie diese Art von Besprechung durchführen, ernennen Sie einen Protokollführer – eine Person, die während des gesamten Vorgangs Aufzeichnungen vornimmt und Kommentare erfasst. Die Gründe, warum eine bestimmte Geschäftsentscheidung mit hoher oder geringer Priorität versehen oder etwas als risikoreich eingestuft wurde, geraten schnell in Vergessenheit, wenn keine verlässlichen Aufzeichnungen vorhanden sind, auf die Sie sich berufen können.

Folgendes muss unbedingt aufgezeichnet werden:

  • Was Sie auf das Whiteboard geschrieben haben

  • Wer am Vorgang teilgenommen hat

  • Wer für jede endgültige Geschäftsentscheidung verantwortlich ist

Wenn Sie sich im Moment etwas überfordert fühlen: keine Angst. Diese ganze Übung kann selbst in den größten Organisationen schnell ausgeführt werden. Nicht selten kann der gesamte Vorgang in einem oder vielleicht zwei Tagen zum Abschluss gebracht werden. Der Schlüssel für den Erfolg besteht darin, die richtige Managementebene im Raum zu versammeln. Außerdem wird diese Art von Besprechung am besten von einer Person geleitet, die nicht in der Organisation beschäftigt ist und bei der nicht die Gefahr besteht, dass die Dinge genau so wie immer gemacht werden.

Wissen ist Macht

Wenn Sie sich mit Projektverwaltungssystemen für Unternehmen (oder Unternehmenssystemen jeder Art) beschäftigen, verleiht Ihnen diese Übung nach ihrem Abschluss enorme Macht, wenn Sie mit Lieferanten von Softwaresystemen interagieren. Sie können sofort eine Unterscheidung zwischen den Elementen eines Systems treffen, die für Sie wichtig sind, und den Elementen, die es nicht sind. Sie können Softwarelieferanten die Liste der Berichte zur Verfügung stellen und die Entscheidungen nennen, die Sie treffen möchten.

Vielleicht werden Sie überrascht sein über die Reaktionen der Lieferanten. Wenn keine Notwendigkeit mehr besteht, allein featurebasiert zu argumentieren (und damit die Quadratur des Kreises zu versuchen), sind die besseren Lieferanten in der Lage, Ihnen zu zeigen, wie Sie sich Ihren geschäftlichen Herausforderungen stellen können, indem Sie deren Systeme bestmöglich nutzen.

Der größte Vorteil dieser Übung: Sie haben gebrauchsfertige Auswertungskriterien erstellt. Während der Machbarkeitsphase können Sie sich nun sofort darauf konzentrieren, ob das System die benötigten Informationen bereitstellt, die erforderlich sind, um die Geschäftsentscheidungen zu optimieren, die getroffen werden müssen.

Informationen zum Autor

Chris Vandersluis ist der Präsident und Gründer von HMS Software, einem im kanadischen Montreal ansässigen Microsoft Certified Partner. Er hat einen Abschluss in Wirtschaftswissenschaften von der McGill University und mehr als 30 Jahre Erfahrung in der Automatisierung von Projektsteuerungssystemen. Er ist ein langjähriges Mitglied des PMI (Project Management Institute) und hat geholfen, die Ortsverbände der Microsoft Project-Benutzergruppen (MPUG) in Montreal, Toronto und Quebec zu gründen. Vandersluis hat Beiträge in Fortune, Heavy Construction News, im Magazin "Computing Canada" und im PMNetwork von PMI veröffentlicht. Darüber hinaus verfasst er regelmäßig die Leitartikel für Project Times. Er unterrichtet Projektmanagement für Fortgeschrittene an der McGill University und hält häufig Vorträge auf Veranstaltungen der Project Management Association in Nordamerika und weltweit. HMS Software ist der Herausgeber von TimeControl, einem projektorientierten Zeiterfassungssystem, und seit 1995 ein Microsoft Project Solution Partner.

Sie können Chris Vandersluis per E-Mail kontaktieren: chris.vandersluis@hms.ca

Wenn Sie weitere EPM-bezogene Artikel von Chris Vandersluis lesen möchten, besuchen Sie die EPM Guidance-Website von HMS (http://www.epmguidance.com/?page_id=39).

Ihre Fähigkeiten erweitern
Schulung erkunden
Neue Funktionen als Erster erhalten
An Office Insider teilnehmen

War diese Information hilfreich?

Vielen Dank für Ihr Feedback!

Vielen Dank für Ihr Feedback. Es klingt, als ob es hilfreich sein könnte, Sie mit einem unserer Office-Supportmitarbeiter zu verbinden.

×