Lösungskäufer

Dieser Artikel ist Teil unserer Sammlung "From the Trenches". Es wird beschrieben, wie potenzielle Softwarekäufer interaktionen mit Softwareanbietern effektiver gestalten können, indem sie leicht verständliche Geschäftsanalysemethoden anwenden. Außerdem finden Sie hier eine Übung zum Aufstellen von Softwarebewertungskriterien, indem Sie festlegen, für welche Probleme die Softwarelösung ausgelegt sein muss.

Weitere Artikel finden Sie in den Whitepapers "Aus den Gräben".

Als Lösungskäufer

Allzu oft basiert ein Softwarekauf auf einer Liste von Features, einer Werbekampagne oder der Empfehlung eines Freundes. In diesem Artikel wird beschrieben, wie potenzielle Softwarekäufer interaktionen mit Softwareanbietern effektiver gestalten können, indem sie leicht verständliche Geschäftsanalysemethoden anwenden.

Es ist sicher nicht wie früher. Die Funktionsweise von Software in einer Unternehmenseinstellung wird nicht einmal mehr als Installation bezeichnet. Heutzutage beschreiben die Begriffe Implementierung oder Bereitstellung besser, was erforderlich ist, um ein neues Paket in Betrieb zu nehmen.

Immer mehr Softwareanbieter sprechen darüber, was sie als Lösungen verkaufen, und es ist kein Wunder. Wenn wir über die Bereitstellung eines Enterprise-Systems wie Microsoft Project Server oder Microsoft CRM nachdenken, müssen wir zuerst über die verschiedenen Ebenen der Technologie nachdenken, die beteiligt sein werden, und – bevor wir überhaupt darauf kommen – müssen wir über die Auswirkungen auf unser gesamtes Geschäft nachdenken.

Mit Lösungen zum Verkauf kommt natürlich auch der Vertrieb von Lösungen. Wenn Sie dies überhaupt verfolgt haben, wissen Sie, dass fast jede High-Tech-Organisation auf dem Planeten, die auf mittlere bis große Organisationen ausgerichtet ist, daran arbeitet, sich als Lösungsvertriebslieferer neu zu erstellen. Microsoft gehört sicherlich zu diesen Organisationen. Microsoft hat in den letzten Jahren intensiv daran gearbeitet, Lösungen zu etablieren, die als Leitprinzip im Außendienst und in der Implementierungskräfte verkauft werden.

Was ist also ein Lösungsverkäufer? Es ist wahr, dass sie immer noch ein Verkäufer sind. Lösungsverkäufer zielen jedoch nicht nur darauf ab, eine Softwarebox zu verschieben, sondern etwas zu erstellen, das dem Kunden hilft, seine Situation zu verbessern.

Klingt bisher großartig; ein Nirvana von Vertriebsmitarbeitern, die alle ihr Leben verbessern möchten. Aber dies ist eine Herausforderung, und die Bewältigung dieser Herausforderung ist etwas, an dem Sie – der potenzielle Kunde – teilnehmen können.

Fokus auf das Problem

Die Herausforderung, mit der die meisten Lösungsverkäufer konfrontiert sind, wenn sie auf den Markt kommen, ist unser Vorurteil darüber, wie eine Lösung aussehen sollte. Wir sind es so gewohnt, uns auf Funktionen und Features von Software zu konzentrieren, wenn wir mit einem Softwareverkäufer sprechen, führt das Gespräch fast zwangsläufig direkt zu " Kann Ihre Software das? Kann Ihre Software das tun?" Erfahrene Softwareverkäufer – und dies sind die Typen, die in Lösungsverkaufspositionen verschoben werden – sind so daran gewöhnt, Funktionen und Features zu verkaufen, dass sie oft vergessen, die grundlegendste Frage von allen zu stellen: "Was ist das Problem?"

Nun mag das dumm klingen, aber wenn Sie an Ihre letzten Gespräche mit Softwareverkäufern denken, sind Sie vielleicht überrascht, wie selten diese Frage aufkommt. Anbieter wie Microsoft und seine Partner erhalten jedes Jahr viele Anfragen für Vorschläge. Ich habe hunderte von ihnen im Laufe der Jahre gesehen, und eine Sache, die fast immer vorhanden ist, ist ein langes Raster von Funktionen, die der Anbieter voraussichtlich ausfüllen wird. Dieses große Arbeitsblatt ist häufig der Kern der Antwort an den Client.

Was selten vorhanden ist, ist eine Beschreibung der geschäftlichen Anforderungen, die von jeder dieser Funktionen erfüllt werden. Es ist so einfach, sich in einem Feature zu verfangen, das wir aus einem früheren Produkt kennen oder das wir irgendwo gefördert haben, dass es echte Disziplin erfordert, sich auf das zu konzentrieren, was uns überhaupt für dieses neue Produkt interessiert hat. Dies kann insbesondere in einer Unternehmensumgebung der Fall sein, in dem es viele Eingaben gibt, welche Art von Lösung gesucht wird. Es ist viel einfacher, eine Anforderung zu senden, in der personen aufgefordert werden sollen, alle Funktionen aufzulisten, die sie in einem neuen Softwaresystem wünschen, als über ihre speziellen Geschäftsanforderungen zu sprechen.

Wenn Sie anfangen zu denken, dass Ihnen vielleicht etwas Offensichtliches fehlt, sind Sie nicht allein. Diese Bedingung ist derzeit in der Softwarebranche so weit verbreitet, dass eine neue Kategorie von Beratern namens Business Analyst entstanden ist. Diese Personen sind geschult, um die Verbindung zwischen geschäftlichen Notwendigkeiten und Softwarefunktionen herzustellen. Nehmen wir uns ein paar Minuten Zeit, um zu sehen, wie Sie die grundlegenden Konzepte in der Weise anwenden können, wie sie ein Business Analyst anwenden würde, in Ihre Auswertungen von Software auf Unternehmensebene.

Identifizieren der geschäftlichen Notwendigkeit

Zuerst sollten Sie darüber nachdenken, welche geschäftlichen Notwendigkeiten Sie dazu gebracht haben, überhaupt nach einem neuen Softwaresystem zu suchen. Unsere eigene Organisation berät Unternehmen häufig bei der Implementierung von Enterprise Project Management Software. Wenn ich als Berater in einer Organisation ankomme, frage ich lange bevor wir über den Kauf von Software sprechen, wie die Organisation gerade Projektmanagement macht.

Wenn sie ihre Antwort abgeschlossen haben, stelle ich immer diese Folgefrage: "Funktioniert diese Methode für Sie?" Überraschenderweise antworte der Kunde oft, dass dies der Grund ist. Für mich muss das Implementierungsgespräch dort aufhören. "Wenn es kein Problem gibt", erkläre ich, "gibt es keine Möglichkeit für mich, eine Lösung zu finden!" Häufig führt diese Antwort dazu, dass die Leute innehalten. "Warum wurden wir angerufen?" Ich werde fragen. Die Antworten können sehr unterschiedlich sein, und es ist nicht ungewöhnlich, dass sich die Leute im Raum umsehen und feststellen, dass mehrere Tagesordnungen im Gange sind, die abgestimmt werden müssen – und unser Gespräch ist weniger als fünf Minuten alt!

Daher ist die Frage "Was ist unser geschäftlicher Bedarf?" ein guter Ausgangspunkt. Es gibt fast immer ein Gesamtziel, das diese Frage beantwortet – ein Ziel, das die Initiative an erster Stelle gestartet hat.

Durchführen einer Übung zum Sehen

Als Nächstes müssen Sie etwas genauer untersuchen, was dies in Bezug auf die Softwarefunktionalität bedeutet. Wenn wir Enterprise-Projektmanagementsoftware wie Microsoft Project Server in einer Organisation implementieren, beginnen wir immer mit einer Visionsübung, bei der die wichtigsten Mitarbeiter – diejenigen, die die Software bewerten – und die Geschäftsleitung – diejenigen, die die Übung unterstützen, beteiligt sind. Es reicht nicht aus, diese Übung nur mit technischem Personal durchzuführen, da das Ziel dieser Übung darin besteht, Geschäftsziele mit technischen Funktionen zu verbinden.

Hier ist eine effektive Möglichkeit, dies zu tun: Legen Sie das Schlüsselpersonal in einen Raum mit einem großen Whiteboard. Teilen Sie das Whiteboard in vier Spalten auf: Beginnen Sie mit einer Überschrift nur in der spalte ganz rechts. Nennen Sie es "Geschäftsentscheidung".

In der rechten Spalte listen Sie Geschäftsentscheidungen auf, die Sie mit dem neuen System treffen möchten, das Sie in Betracht ziehen. Wenn wir dies mit einem Client tun, ist das erste, was die Leute tun möchten, eine Vielzahl von Features aufzulisten, sodass Sie darauf bestehen müssen, dass die Antworten, die wichtig sind, Geschäftsentscheidungen sind. Beispielsweise kann ein Teilnehmer sofort sagen: "Ich benötige eine Liste aller Ressourcen und ihrer Workload." Das mag natürlich zutreffen, aber Sie müssen herausfinden, welche Geschäftliche Entscheidung sie mit dieser Liste treffen werden.

Einige Beispiele für Geschäftsentscheidungen sind:

• Einstellung oder Entlassung in einer bestimmten Abteilung

• Treffen einer Entscheidung für ein Projekt

Sobald Sie eine anständige Liste mit Geschäftsentscheidungen haben, halten Sie an. Jetzt ist ein guter Zeitpunkt, um die Geschäftsentscheidungsliste zu überprüfen und die Entscheidungen mit der höchsten Priorität zu identifizieren. Vielleicht möchten Sie sich diese Frage stellen: Wenn Sie nur Antworten auf eine dieser Geschäftsentscheidungen erhalten könnten, was würde den größten Nutzen für die Organisation bringen? Die Auswahl der drei wichtigsten Entscheidungen ist an diesem Punkt im Prozess immer am einfachsten.

Wenn Sie so weit gekommen sind, haben Sie bereits mehr erreicht als die meisten Organisationen, die nach Enterprise-Projektmanagementsoftware suchen. Die Möglichkeit, Systemanbietern eine priorisierte Liste der wichtigsten Geschäftsentscheidungen zur Verfügung zu stellen, ist ein großer Schritt nach vorn für den gesamten Prozess. Wenn Sie Systemanbietern mitteilen können, welche Geschäftlichen Entscheidungen Sie treffen müssen, sind sie in der Lage, über einfache Funktionen hinaus darüber zu sprechen, wie die Organisation effektiver gemacht werden kann.

Sehen Sie sich als Nächstes jede Entscheidung an, und fragen Sie: "Welchen Bericht würden Sie benötigen, um diese Geschäftsentscheidung zu treffen?" Praktisch jede Entscheidung wird nach der Betrachtung eines oder mehrerer Berichte getroffen. Bezeichnen Sie die 3. Spalte als "Bericht". Listen Sie für jede der drei wichtigsten Entscheidungen in dieser Spalte die Berichte auf, die für die entsprechende Entscheidung erforderlich sind.

Wir könnten beispielsweise sagen, dass wir einen Bericht nach Abteilung benötigen, der die Daten zur Ressourcenkapazitätsplanung anzeigt, um zu bestimmen, ob Personal für eine bestimmte Abteilung eingestellt oder feuert. Dies umfasst eine Vorausschätzung der erwarteten Workload, der erwarteten Ressourcenverfügbarkeit und des Zeitplans. Wenn Sie ein mittelständisches Unternehmen sind, kann der Cashflow ebenfalls ein Problem darstellen. Sie können z. B. zusätzliches Personal benötigen, aber nicht in der Lage sein, das Geld zu finden, um sie einzustellen. Der Cashflow-Bericht würde geschätzte Einkommen und Geldabflüsse mit einem laufenden Saldo enthalten.

Wenn wir die Spalte Bericht für jede der Entscheidungen ausfüllen, die wir als unsere Prioritäten identifiziert haben, wird die Form der erforderlichen Elemente bereits klar. Sobald Sie fertig sind, haben Sie eine Liste der physischen Ausgaben, die Sie von Ihrem zukünftigen System benötigen.

Halten Sie hier erneut an, um herauszufinden, ob bereits Berichte des Typs vorhanden sind, den Sie identifiziert haben, der bereits in der Organisation verwendet wird. Die Wahrscheinlichkeit ist, dass solche Berichte vorhanden sind, aber in zahlreichen Formaten und möglicherweise mit unvollständigen Daten oder mit übermäßigem Aufwand, um sie zu generieren. Wenn Sie Formate von Berichten finden, die in der Organisation funktioniert haben, können Sie diese der Liste der Systemanforderungen hinzufügen. Jetzt können Sie den Systemanbietern noch mehr Informationen bereitstellen.

Nachdem die wichtigsten Berichte nun identifiziert wurden, können wir zu den Elementen eines Systems wechseln, die zum Generieren dieser Berichte erforderlich sind. Fügen Sie der zweiten Spalte des Diagramms die Überschrift "Analysis" hinzu. Identifizieren Sie für jeden Bericht die Analysen oder Algorithmen, die zum Generieren des Berichts erforderlich sind. Für einen Bericht zur Ressourcenkapazitätsplanung können wir beispielsweise einen kritischen Pfadzeitplan aus dem Projektmanagementsystem und eine Analyse des Ressourcenausgleichs benötigen.

Diese Analysen werden häufig von Anbietern auf der Grundlage der unzähligen Features vermarktet, die jeweils enthalten sind. (Ja, feature-by-feature selling ist noch aktiv und gut!) Sie müssen in der Lage sein, die minimale Funktionalität zu bestimmen, die die von Ihnen benötigten Berichte bereitstellt, mit denen Sie dann die von Ihnen identifizierte Geschäftsentscheidung treffen oder verbessern können. Sie werden überrascht sein, wie einfach die Funktionalität ist, die Sie benötigen, um Ihre tatsächlichen Geschäftlichen Anforderungen zu erfüllen. Für einige Berichte sind überhaupt keine Analysen oder Berechnungen erforderlich. Die Berichte müssen nur einfache Aggregate sein, die direkt aus den Daten des neuen Systems generiert werden können.

Schließlich kommen wir zur ersten Spalte in unserem Diagramm. Nachdem Sie die erforderlichen Analysen identifiziert haben, können Sie bestimmen, welche Datenelemente für die Analyse erforderlich sind.

Fügen Sie der 1. Spalte Ihres Diagramms die Überschrift "Eingabe" hinzu.

In dem beispiel, das wir verwendet haben, benötigen wir möglicherweise eine vollständige Liste der Aufgaben für jedes Projekt, das in die Arbeit der Abteilung beteiligt ist. Dies kann sehr gut jedes Projekt in der Organisation sein. Wir benötigen auch ein vollständiges Profil der Verfügbarkeit jeder Ressource zusammen mit der workload, die für jeden Vorgang definiert ist, sodass sich die Workload in der Analyse des Ressourcenabgleichs verschiebt, wenn der Vorgang in der Zeitplananalyse verschoben wird. Denken Sie auch daran, wie wir mit der Entscheidung begonnen haben, eine bestimmte Abteilung einzustellen oder zu feuern? Wir müssen auch in der Lage sein, die Ressourcen nach Abteilung zu identifizieren.

Wir können auf diese Weise von den Ausgaben auf der rechten Seite zu den Eingaben auf der linken Seite wechseln, bis wir alles identifiziert haben, was wir in unserem neuen Unternehmenssystem benötigen.

Bewertung von Risiken

Nachdem diese Übung abgeschlossen ist, lohnt es sich, zu den einzelnen Eingaben zurückzukehren und zu bestimmen, wie verfügbar diese Datenelemente sind. Sie können feststellen, dass einige dieser Elemente – wie wir es oft tun – nicht einmal vorhanden sind. Beispielsweise verwalten einige Organisationen keine vollständige Liste der Ressourcenverfügbarkeit. Möglicherweise stellen Sie auch fest, dass nicht für jedes Projekt ein Zeitplan mit geladenen Ressourcen vorhanden ist, der die von diesem Projekt generierte Ressourcenauslastung anzeigt. In vielen Organisationen werden bestimmte Arten von Projekten nicht in ein System jeglicher Art eingefügt. Notarbeiten, technische Unterstützung oder regelmäßige Wartungsarbeiten sind einige gängige Beispiele.

Wenn Sie keinen Zugriff auf die grundlegenden Daten haben, die Sie benötigen, um den Geschäftswert zu liefern, müssen Sie dieses Element des Systems als hoch riskant betrachten. Wenn wir z. B. feststellen, dass wir ressourcenlastige Zeitpläne für 80 % der Projekte der Organisation identifizieren können, können wir dann vernünftigerweise erwarten, dass wir unsere Geschäftliche Entscheidung zur Erhöhung oder Verringerung des Personals verbessern? Die Antwort lautet wahrscheinlich" "Nein". Warum? Denn vielleicht machen die 20 % der Projekte, die nicht im System vorhanden sind, 80 % der Arbeitslast für eine bestimmte Abteilung aus. Wenn Sie nicht über alle Daten verfügen, wissen Sie nie, ob der endgültige Bericht korrekt ist.

Natürlich gibt es Möglichkeiten, solche Probleme zu umgehen. Eine Methode besteht darin, alle Geschäftsprozesse dieser Aspekte der Organisation zu isolieren, bei denen Sie keinen Zugriff auf die Datenelemente erhalten können. Für eine Abteilung, deren Projekte möglicherweise nicht im System vorhanden sind, werden die Ressourcen auch nicht aufgelistet. Dies kann nicht in jedem Fall einfach erfolgen; Sie müssen Nachschlagen, um herauszufinden, wie viel Risiko diese Geschäftsprozesse und Geschäftsentscheidungen für Ihre Implementierung darstellen. An diesem Punkt im Prozess ist es nicht ungewöhnlich, die endgültigen Geschäftsentscheidungen, die Sie verbessern möchten, neu zu priorisieren. Möglicherweise haben Sie eine Entscheidung, die sehr wünschenswert ist, sich aber als sehr hohes Risiko erweist und daher in den frühen Phasen Ihrer Bereitstellung nicht sinnvoll ist.

Dokumentieren, was Sie getan haben

Wenn Sie diese Art von Besprechung durchführen, weisen Sie einen Schreiber zu – eine Person, deren Aufgabe es ist, Notizen und Kommentare während des gesamten Prozesses aufzuzeichnen. Die Gründe, warum eine bestimmte Geschäftsentscheidung als hohe oder niedrige Priorität eingestuft wurde oder warum etwas als hohes Risiko angesehen wurde, werden schnell vergessen, wenn Sie keine guten Notizen haben, auf die Sie sich beziehen können.

Es ist sehr wichtig, Folgendes aufzuzeichnen:

• Was Sie auf dem Whiteboard geschrieben haben

• Wer hat am Prozess teilgenommen?

• Wer ist der Besitzer jeder endgültigen Geschäftsentscheidung?

Wenn Sie sich zu diesem Zeitpunkt überfordert fühlen, fürchten Sie sich nicht. Diese gesamte Übung kann sehr schnell durchgeführt werden, selbst in den größten Organisationen. Es ist nicht ungewöhnlich, den gesamten Prozess in ein oder zwei Tagen abzuschließen. Der Schlüssel zum Erfolg besteht darin, die richtige Managementebene in den Raum zu bringen. Darüber hinaus wird diese Art von Besprechung am besten von jemandem von außerhalb der Organisation unterstützt, der nicht dazu veranlagt ist, Dinge so zu tun, wie sie schon immer gemacht wurden.

Wissen ist Macht

Wenn Sie sich mit Enterprise-Projektmanagementsystemen – in der Tat bei Unternehmenssystemen jeglicher Art – ansehen, erhalten Sie durch diese Übung eine enorme Leistung, wenn Sie mit Softwaresystemanbietern interagieren. Sie können sofort zwischen den Elementen eines Systems unterscheiden, die für Sie wichtig sind und nicht. Softwareanbieter können mit der Liste der Berichte und Entscheidungen bereitgestellt werden, die Sie treffen möchten.

Möglicherweise sind Sie überrascht über einige der Antworten, die von den Anbietern an Sie zurückgegeben werden. Die besseren Anbieter können Ihnen zeigen, wie Sie Ihre geschäftlichen Herausforderungen lösen können, indem Sie ihre Systeme optimal nutzen.

Hier ist der größte Vorteil der Durchführung dieser Übung: Sie haben vorgefertigte Bewertungskriterien erstellt. Während der Proof-of-Concept-Phase können Sie sich jetzt sofort darauf konzentrieren, ob das System die Informationen liefert, die Sie benötigen, um die geschäftlichen Entscheidungen zu verbessern, die Sie treffen müssen.

Informationen zum Autor

Chris Vandersluis ist Präsident und Gründer von HMS Software aus Montreal, Kanada, einem zertifizierten Partner von Microsoft. Er verfügt über einen Abschluss der Wirtschaftswissenschaften der McGill University und über 30 Jahre Erfahrung in der Automatisierung von Projektleitsystemen. Er ist langjähriges Mitglied des Project Management Institute (PMI) und hat die Kapitel Montreal, Toronto und Quebec der Microsoft Project Users Group (MPUG) gegründet. Zu den Publikationen, für die Chris geschrieben hat, gehören Fortune, Heavy Construction News, Computing Canada Magazine und PMI's PMNetwork, und er ist ein regelmäßiger Kolumnist für Project Times. Er unterrichtet Advanced Project Management an der McGill University und spricht häufig in Projektmanagement-Verbandsfunktionen in Nordamerika und auf der ganzen Welt. HMS Software ist Herausgeber des projektorientierten Timekeeping-Systems TimeControl und seit 1995 Microsoft Project Solution Partner.

Chris Vandersluis ist per E-Mail erreichbar unter: chris.vandersluis@hms.ca

Weitere EPM-bezogene Artikel von Chris Vandersluis finden Sie auf der HMS EPM Guidance Site (https://www.epmguidance.com/?page_id=39).