Die Herausforderungen bei der Auswahl von Unternehmenssoftware: Whitepaper

Dieses Whitepaper ist Teil unserer Sammlung "Aus der Praxis". Hierin wird beschrieben, warum Implementierungen von Unternehmenssystemen anpassbar und ausbaufähig sein müssen, um erfolgreich zu sein.

Die Word-Version dieses Whitepapers finden Sie unter Die Herausforderungen bei der Auswahl von Unternehmenssoftware.

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

Die Herausforderungen bei der Auswahl von Unternehmenssoftware

Hier bei uns passiert das immer wieder. Ein Kunde schickt eine Angebotsanfrage an unser Büro mit der Bitte, diese in einigen Tagen oder Wochen zu beantworten und zurückzusenden, damit unser Unternehmenssystem bei der Kaufentscheidung in die engere Wahl genommen werden kann. Angebotsanfragen sehen eigentlich immer ziemlich ähnlich aus. Sie enthalten in der Regel einen kurzen Überblick, Anweisungen, was Sie tun müssen, damit Ihre Antwort berücksichtigt wird, wozu auch Formatierungsvorgaben, Einsendeschluss usw. gehören. Darauf folgen eine lange Liste mit den erforderlichen Funktionen und eine Reihe von weiteren Textfragen, die wir beantworten sollen.

Das Problem mit Angebotsanfragen ist, dass sie für die Auswahl von Unternehmenssoftware nicht geeignet sind, und was sich ergibt, wenn die Standards zur Abgabe eines Angebots eingehalten werden, garantiert nicht, dass die Organisation die bestmögliche Entscheidung trifft. Angebotsanfragen wurden von Einkäufern als eine Möglichkeit entwickelt, die beste Ware zum besten Preis zu erhalten, und in diesem Bereich erfüllen sie auch weiterhin ihren Zweck. Wenn die Angebote vergleichbar sind, kann man sich bei der Entscheidungsfindung auf den besten Preis konzentrieren und muss nur eine oder zwei weitere Variablen (wie das Lieferdatum) berücksichtigen. Wenn sich die möglichen Lösungen alle in der gleichen allgemeine Kategorie befinden, jedoch überhaupt nicht vergleichbar sind (was auf Unternehmenssoftware zutrifft), ist die Anzahl der Variablen, die der Einkäufer berücksichtigen muss, hoch, und die Angebotsanfrage macht die Auswahl nicht einfacher. Wie die meisten Firmen Unternehmenssoftware auswählen Im ersten Schritt wollen wir uns das Verfahren anschauen, das jeder Lieferant oder Lösungsanbieter von Unternehmenssoftware standardmäßig verwendet. Ich spreche hier über Enterprise Project Management-Software oder Zeiterfassungssoftware, da genau diese Software von meinem Unternehmen vertrieben wird, aber das Paradigma gilt bei faktisch jeder Auswahl von Unternehmenssystemen.

Wie die meisten Firmen Unternehmenssoftware auswählen

Im ersten Schritt wollen wir uns das Verfahren anschauen, das jeder Lieferant oder Lösungsanbieter von Unternehmenssoftware standardmäßig verwendet. Ich spreche hier über Enterprise Project Management-Software oder Zeiterfassungssoftware, da genau diese Software von meinem Unternehmen vertrieben wird, aber das Paradigma gilt bei faktisch jeder Auswahl von Unternehmenssystemen.

Bei den meisten Organisation sind diverse Probleme die treibende Kraft für die Anschaffung von Unternehmenssoftware. Möglicherweise wurde dieses Problem von den Außendienstmitarbeitern entdeckt. Vielleicht wurde das Problem aber auch von der Geschäftsleitung erkannt. Ganz gleich, vom wem es entdeckt wurde, die Initiative muss von einem Mitglied der Geschäftsleitung unterstützt werden. Eine basisdemokratische Entscheidung für ein System, das Auswirkungen auf das gesamten Unternehmen hat, findet auch in den modernsten Organisationen nicht statt. Also entscheidet eine Führungskraft: "Wir brauchen diese Art von Unternehmenssystem".

Das typische Verfahren zur Auswahl einer Unternehmenssoftware sieht folgendermaßen aus:

  1. Das Management entscheidet, dass ein neues Unternehmenssystem benötigt wird.

  2. Der Projektmanager wird bestimmt.

  3. Es werden Anforderungen von allen involvierten Abteilungen gesammelt.

  4. Alle Anforderungen werden in einer umfangreichen Tabelle zusammengeführt.

  5. Die Anforderungstabelle wird an eine Reihe von Anbietern geschickt.

  6. Es gehen zahlreiche Antworten ein.

  7. Es wird eine Liste der Anbieter in der engeren Auswahl erstellt.

  8. Es werden Demos angesetzt

  9. Es wird verhandelt.

  10. Die Zustimmung des Managements wird eingeholt.

  11. Es wird dafür gesorgt, dass das Management sich mit etwas anderem befasst.

Für die aufwändige Auswahl wird nun ein Projektmanager bestellt. Er macht das, was wir alle machen würden: Er geht ins Internet, öffnet eine Suchmaschine und gibt "EPM-Software" ein (oder welches Unternehmenssystem auch immer gewünscht wird). Sofort werden eine halbe Million Treffer zurückgegeben. Vielleicht öffnet der gewissenhafte Projektmanager die ersten dutzend Seiten, um sich zu informieren, welche Arten von Systemen überhaupt zur Verfügung stehen, bevor er fortfährt. Natürlich hat niemand die Zeit, sich durch eine halbe Million oder mehr Treffer zu quälen, um zu schauen, ob es sich nicht doch noch beim letzten um das ideale System für die Organisation handelt.

Ganz unverdrossen stellt der Projektmanager nun ein Auswahlkomitee aus den Personen zusammen, die von der Implementierung dieses neuen Unternehmenssystem betroffen sind. Einige der Komiteemitglieder gehören möglicherweise zu den Außendienstmitarbeitern, die den Bedarf zuerst erkannt haben, andere möglicherweise nicht. Diesem Auswahlkomitee können die unterschiedlichsten Personen angehören, die ihrerseits wieder unterschiedliche Interessen im Hinblick auf die Art des Systems haben, das ausgewählt werden soll.

Der unglückselige Projektmanager bittet nun jedes Mitglied des Komitees, in seiner repräsentativen Gruppe eine Befragung zu starten, um herauszufinden, welche Anforderungen sie an das neue Unternehmenssystem stellen. Wie gehen die einzelnen Komiteemitglieder nun vor? Nun, zunächst sei einmal gesagt, dass nicht jeder den gleichen Aufwand betreibt, aber diejenigen, die die Sache ernst nehmen, bitten ihre Mitarbeiter, eine Liste mit den Funktionen einzureichen, die sie für wichtig halten. Diese Mitarbeiter gehen dann ebenfalls ins Internet und besuchen einige Lieferantenwebsites. Sie können nun Funktionen, die sie auf den einzelnen Webseiten finden, kopieren und einfügen, da sie auf jeder Website neue Ideen finden, welche Anforderungen an das neue System gestellt werden könnten.

Nun trifft sich das Komitee erneut, und die lange Tabelle eines jeden Komiteemitglieds wird mit den Tabellen der anderen zusammengeführt, sodass eine höchst umfangreiche Tabelle entsteht. Diese Megatabelle mit Anforderungen wird nun kategorisiert, aber es gibt auch Herausforderungen. Zum Ersten werden die unterschiedlichen Anforderungen der Komiteemitglieder nun offensichtlicher, da Funktionen aus einer breiten Palette von Perspektiven heraus gefordert werden. Es kann Komiteemitglieder aus unterschiedlichen Abteilungen, aber auch aus unterschiedlichen Ländern oder sogar aus unterschiedlichen Geschäftszweigen geben. Es gibt fast immer eine Anforderung, die im Konflikt zu einer anderen Anforderung auf der gleichen Liste steht (wie beispielsweise, dass das System sehr benutzerfreundlich sein und ohne viele Eingabeaufforderungen auskommen soll oder dass das System sehr flexibel sein und eine große Anzahl an Optionen für jeden Benutzer bieten soll).

Schließlich ist die kombinierte Tabelle, die an die Anbieter gesendet werden soll, fertig. Sie enthält Hunderte von geforderten Funktionen, und bei jeder wird vom Anbieter erwartet, dass er "Ja", "Nein" oder "Ja, aber mit Mehraufwand" sagt. Möglicherweise ist auch ein Gewichtungssystem dabei, um darzustellen, welche Funktion unbedingt notwendig ist, welche wichtig ist und welche nur "ganz nett" wäre.

Ausschnitt aus Featureauswahl-Arbeitsblatt

Die Angebotsanfrage ist nun fast so weit, dass sie verschickt werden kann. Es gibt auch einige Textfragen, normalerweise über die technische Architektur der Auswahl, und je nachdem, wie viele Personen befragt wurden, können die Anforderungen an die Architektur ebenfalls widersprüchlich sein (wie: "Das System muss alle Daten zentral in der SQL Server-Datenbank speichern" und "Das System muss es ermöglichen, alle Daten lokal auf dem Computer der Benutzer zu speichern").

Tatsächlich klingt das doch bis hierher noch ziemlich gut, oder? Schlussendlich erhalten wir doch jede Menge Antworten von Anbietern, die zeigen, wer alle von uns gewünschten Funktionen bieten kann. Tatsächlich klingt das doch bis hierher noch ziemlich gut, oder? Schlussendlich erhalten wir doch jede Menge Antworten von Anbietern, die zeigen, wer alle von uns gewünschten Funktionen bieten kann.

Es gibt allerdings ein grundlegendes Problem mit dem, was ich bisher beschrieben habe: Ein Problem, das nicht auftritt, wenn wir Angebotsanfragen für Waren und nicht für ein Unternehmenssystem verwenden. Und das sieht folgendermaßen aus: Ein Unternehmenssystem ist eine Lösung für irgendwas. Aber das Problem wurde bisher noch gar nicht angesprochen. Das kommt so oft vor, dass die Technologiebranche es mittlerweile für normal und akzeptabel hält.

Warum die Auswahl von Unternehmenssoftware auf diese Weise nicht funktioniert

Einkäufer verwenden diese Methode schon seit Jahrzehnten, und sie wird von niemandem in Frage gestellt, aber die Fachleute aus der Unternehmenssoftwarebranche wissen, dass es ein grundlegendes Problem bei der Auswahl von Unternehmenssoftware mit der klassischen Angebotsanfrage gibt.

Zunächst einmal bedeutet die Tatsache, dass Sie über eine ellenlange Liste mit Funktionen verfügen, nicht, dass Sie der Lösung Ihres geschäftlichen Problems auch nur einen Schritt näher gekommen sind. Tatsächlich machen Sie die Dinge wahrscheinlich noch komplizierter und letztendlich schlimmer und nicht besser, wenn Sie keine Aussage dazu treffen, welches spezielle geschäftliche Problem Sie zu lösen versuchen. Die Angebotsanfrage dient dazu, Waren einzukaufen. Wenn es um gleichartige Produkte wie Schuhe oder Kartoffeln oder Zucker geht, kann der Einkauf mithilfe dieser Methode dazu führen, dass Sie den preiswertesten Anbieter und damit den bestmöglichen Lieferanten finden. Die Antworten auf eine Angebotsanfrage für eine ähnliche Ware machen den Vergleich der möglichen Lieferanten sehr einfach. Wenn die Variablen eines jeden Produkts jedoch unendlich sind (was bei Unternehmenssoftware der Fall ist), dann gibt es auch in den Antworten auf die Angebotsanfrage eine unendliche Anzahl von Variablen, und die Anfrage führt zu Ergebnissen, die praktisch wertlos sind.

Wenn wir Angebotsanfragen für die Auswahl von Unternehmenssystemen verwenden, sehen die Angebotsanfragen meistens alle gleich aus, denn sie werden alle in Reaktion auf den gleichen Impuls erstellt. Der Projektmanager verlangt einer Liste dessen, "was dieses Unternehmenssystem können muss", und das einzige Werkzeug, das dem mittleren Management zur Verfügung steht, um auf diese Frage zu antworten, ist eine Liste mit Funktionen. Dementsprechend sehen die Antworten auf Angebotsanfragen alle gleich aus. Sie sind eine Checkliste aller Funktionen, die entweder als Teil des Systems oder als Teil des Systems mit einigem Mehraufwand zur Verfügung stehen.

Was den Auswahlteams am häufigsten passiert, ist, dass sie eine Vielzahl von Antworten auf ihre Angebotsanfrage erhalten, dass sie sich durch Hunderte von Seiten wühlen müssen und dass sie, wenn sie fertig sind, der Lösung noch keinen Schritt näher sind als am Anfang. Für den Einkäufer, der eine Menge Arbeit in etwas gesteckt hat, das eine faire Angebotsanfrage werden sollte und das er mühsam ausgewertet hat, ist es extrem frustrierend festzustellen, dass die ganze Übung rein gar nichts gebracht hat.

Noch schlimmer ist, dass erfahrene Vertriebsleute wissen, dass das Prozedere nur zu frustrierenden Ergebnissen führen kann und seit dem Moment, in dem sie erfahren haben, dass eine Angebotsanfrage erstellt wird, schon bei der Arbeit sind. Sie arbeiten jedoch nicht an einer Antwort auf die Angebotsanfrage. Die ist nicht relevant. Sie arbeiten stattdessen zwei oder drei Stufen höher in der Managementstruktur und suchen nach der ursprünglichen treibenden Kraft, die die Angebotsanfrage ins Rollen gebracht hat. Sie suchen nach der Führungskraft, die die geschäftliche Herausforderungen formuliert und das Räderwerk in Bewegung gesetzt hat, sodass Einkäufer und andere Personen aus dem mittleren Management schließlich eine Angebotsanfrage erstellt und an die Anbieter gesendet haben.

Wenn sich schließlich herausstellt, dass die Antworten auf die Angebotsanfrage keine klare Aussage betreffend die geschäftlichen Probleme enthalten, die im Bestellverfahren fast nie formuliert wurden, tritt der Vertriebsmitarbeiter in Aktion und sorgt dafür, dass eine Führungskraft den Prozess insgesamt umgeht und ein System basierend auf seiner eigenen persönlichen Beziehung zu dem leitenden Vertriebsmitarbeiter auswählt.

Wenn Sie nun glauben, dass das abwegig klingt, sind Sie auf dem Holzweg. Tatsächlich ist es besser, sagen zu können, dass Software aufgrund von persönlichen Beziehungen zur Führungsriege ausgewählt wurde, als sagen zu müssen, dass sie im Zuge einer Angebotsanfrage gekauft wurde.

Aber wie sieht es mit einer Machbarkeitsstudie oder einem Pilotprojekt aus?

Wir wissen also, dass das klassische Einkaufsverfahren mangelhaft ist, wenn es für den Kauf von Unternehmenssoftware verwendet wird. Aber wenn das zutrifft, wie sollen wir dann eine Unternehmenssoftware wie ein Enterprise Project Management-System auswählen? Eine gängige Methode ist eine Machbarkeitsstudie oder ein Pilotprojekt.

Diese beiden Begriffe werden häufig synonym verwendet, also lassen Sie uns darüber sprechen, was eine Machbarkeitsstudie und was eine Pilotbereitstellung ist.

Machbarkeitsstudie   . Bei einer Machbarkeitsstudie stellt die interessierte Organisation die Unternehmenssoftware in eingeschränkter Weise bereit, um zu belegen, dass hiermit eine technische Herausforderung bewältigt werden kann, wenn es fraglich ist, ob die Lösung für die jeweilige Problemstellung wirklich geeignet ist. Als Beispiel hierfür könnte das Datenvolumen angeführt werden. "Wir befürchten, dass die Software nicht in der Lage ist, die vielen Vorgänge zu verwalten, aus denen sich unsere Projekte zusammensetzen. Wir möchten, dass Sie die Software vorführen und uns anhand von zwei oder drei Beispielprojekten mit jeweils 500 Vorgängen zum einen zeigen, wie diese in die Software geladen werden können, und zum anderen, dass die Software die Basisfunktionen auch mit diesem Datenvolumen immer noch zufriedenstellend ausführen kann."

Pilotphase   . Eine Pilotphase ist die Installation einer Unternehmenssoftware mit begrenztem Umfang. So kann eine Pilotbereitstellung nur für eine kleine Anzahl von Benutzern erfolgen, d. h. beispielsweise, dass nur zehn von 1000 Mitarbeitern die Software über einen Zeitraum von vier Wochen umfassend testen. Oder es kann sich um eine Teilmenge der Funktionen oder eine Teilmenge des Datenvolumens handeln, d. h., dass beispielsweise nur zehn von 500 Projekte geladen werden.

Wie werden eine Machbarkeitsstudie oder eine Pilotphase verwendet?    Ein Problem, das häufig anzutreffen ist, ist die Frage , wie die Pilotphase oder die Machbarkeitsstudie angewendet wird. Es kommt ziemlich selten vor, dass eine interessierte Organisation anruft und uns darum bittet, ihr ein Angebot für eine Machbarkeitsstudie zu machen und gleichzeitig erklären kann, welche technischen Konzepte bewiesen werden müssen. Wir fragen dann: "Was hoffen Sie, bestätigt zu bekommen, und wie können wir messen, dass wir den Beweis erbracht haben?"

Was am häufigsten vorkommt, ist, dass jemand aus dem mittleren Management eine Unternehmenssoftware entdeckt, von der er hofft, dass sie die Arbeit in der Organisation vereinfacht. Die oberste Führungsebene wird überhaupt nicht involviert, und die Mitarbeiter im mittleren Management haben noch nicht einmal formuliert, welche geschäftlichen Probleme sie zu lösen versuchen. Ihre Hoffnung ist, dass nach der Implementierung der Lösung in Kürze einer von der Geschäftsleitung über den Flur wandert, "zufällig" auf die in Betrieb befindliche Lösung aufmerksam wird und sofort seinen Segen für eine unternehmensweite Bereitstellung gibt. Um es mit einem Zitat aus dem Film "Feld der Träume" zu sagen: "Wenn du es baust, kommt er zurück".

Unwirksame Auswahl der Pilotphase

So etwas klappt fast nie. Das Problem mit Unternehmenssoftware ist, dass die oberste Führungsriege involviert werden muss, damit die Bereitstellung ein Erfolg wird. Der Adressat der Berichte und Analysen aus dem Unternehmenssystem ist nämlich die oberste Führungsebene. Es ist die oberste Führungsebene, die sich persönlich dafür einsetzen muss, dass einer Gruppe von Mitarbeitern die erforderliche Zeit zum Entwerfen und Konfigurieren der Unternehmenssoftware sowie für Schulungen zur Verfügung gestellt wird. Es ist die oberste Führungsebene, die die Geschäftsprozesse akzeptieren oder sogar bei deren Umgestaltung mitarbeiten muss, die Teil einer jede Unternehmenssystembereitstellung sind. Jede Machbarkeitsstudie ist sinnlos, wenn die oberste Führungsebene nicht nur ihren Segen gegeben, sondern auch ihre implizite Unterstützung und direkte Hilfe zugesagt hat.

Das Gleiche gilt auch für eine Pilotphase. Wenn es im Unternehmen keine Zustimmung von ganz oben gibt, ein geschäftliches Problem mithilfe einer Unternehmenssoftware zu lösen, ist der Einstieg in eine Pilotphase unproduktiv.

Wirksame Auswahl der Pilotphase

Ich will damit nicht sagen, dass Pilotphasen einer Bereitstellung keine Existenzberechtigung haben. Ganz im Gegenteil, sie sind eine wesentlicher Bestandteil einer erfolgreichen Bereitstellung. Sie sollte erfolgen, sobald die Kaufentscheidung getroffen wurde und der Entwurf des Unternehmenssystems abgeschlossen ist. Eine Pilotphase bietet eine großartige Möglichkeit, den Entwurf eines Unternehmenssystems zu testen und eine Feinabstimmung für die allgemeine Bereitstellung vorzunehmen.

Wenn eine Pilotphase in der Hoffnung erfolgt, dass das Management sich für die Software entscheidet, wenn es sie einmal in Aktion sieht, ist die Pilotphase ineffektiv und bringt uns im Auswahlverfahren keinen Schritt weiter.

Wie sollten Organisationen eine Unternehmenssoftware auswählen?

Unternehmenssysteme werden von mittelgroßen und großen Organisationen jeden Tag gekauft, und Angebotsanfragen stellen nicht gerade die effektivste Methode dar. Dennoch gibt es eine Reihe von Methoden für die Auswahl von Unternehmenssoftware, die sehr effektiv sind. Hier einige Tipps für die Definition eines eigenen effektiven Verfahrens für die Auswahl von Unternehmenssoftware:

  • Formulieren Sie das Problem   . Der allererste Schritt besteht darin, das Problem zu formulieren. Dies bedeutet, dass die oberste Führungsebene involviert werden muss und dass das zu formulierende Problem ein geschäftliches Problem ist, also sollte es in geschäftlichen Begriffen formuliert werden. Eine gute Frage lautet: "Welche Geschäftsentscheidung können wir zurzeit nicht oder nur unter größten Schwierigkeiten treffen, und wie kann uns die Bereitstellung dieser Unternehmenslösung dabei helfen, dies zu vereinfachen?"

    Möglicherweise gibt es eine Reihe von geschäftlichen Problemen, die Sie mithilfe dieses Unternehmenssystems lösen möchten.

  • Gewähren Sie den Anbietern einen gewissen Spielraum bei der Erstellung der Lösung   . Nachdem das oder die geschäftlichen Probleme formuliert worden sind, kontaktieren Sie mögliche Anbieter. Vergewissern Sie sich, dass der Kontakt zu der Führungskraft, die das Verfahren unterstützt hat, transparent ist. "Geheime" Treffen von Anbietern mit der obersten Führungsebene werden unmöglich, wenn das Management von Anfang an in das Verfahren involviert ist. Sorgen Sie dafür, dass die Anbieter das Problem verstehen, und lassen Sie ihnen Spielraum bei der Vorbereitung der Antwort. Möglicherweise erfahren Sie mehr über Ihre Organisation als Sie ahnen, wenn Sie erklären, welche Auswirkungen diese geschäftlichen Probleme für Sie haben, und Sie sehen sicherlich eine viel breitere Palette an möglichen Lösungen für Ihr Problem, wenn Sie nicht versuchen, den potenziellen Anbietern die Lösung zu beschreiben.

    Wenn Sie sich mit möglichen Lösungsanbietern unterhalten, machen Sie ihnen klar, dass sie sowohl die Technologie als auch die Problematik der Geschäftsprozesse angehen müssen. Es hat noch nie eine Unternehmenssystem-Lösung gegeben, die keine Auswirkungen auf die Prozesse einer Organisation gehabt hätte. Wenn der Lösungsanbieter Ihnen nicht sagen kann, welche Auswirkungen sich für die Prozesse ergeben, dann sehen Sie nur einen Teil der Lösung.

  • Treffen Sie sich mit anderen   . Wenn Sie sich für eine Reihe möglicher Lösungsanbieter entschieden haben, fragen Sie, ob Sie mit einigen vorhandenen Kunden sprechen können. Noch besser ist es, wenn der Anbieter Ihnen die Möglichkeit gibt, einige vorhandene Kunden zu besuchen. Gute Lösungsanbieter haben häufig Kunden, bei denen die Bereitstellung erfolgreich war und die bereit sind, Zeit in Treffen mit potenziellen Kunden zu investieren.

    In ein paar Stunden mit einem erfahrenen Kunden der möglichen Lösung erfahren Sie mehr, als Sie jemals aus Antworten auf Angebotsanfragen oder bei Vertriebspräsentationen von Anbietern erfahren würden. Wenn Sie den Anbieter nach möglichen Kundenreferenzen und Besuchen vor Ort fragen, denken Sie vielleicht, dass das ideale Unternehmen für einen Besuch dem Ihren möglichst ähnlich sein sollte. Das ist nicht immer der Fall.

Es erweist sich oftmals als außerordentlich hilfreich, Unternehmen aus anderen Branchen zu treffen, die mit der Ihren in Beziehung stehen oder ihr irgendwie ähnlich sind. Sie können auch eine Menge von Organisationen lernen, die größer oder kleiner als Ihre Organisation sind. Suchen Sie die Organisation danach aus, wie viel Erfahrungen sie mit der Lösung hat, und nicht danach, welche Version verwendet wird, ob die Größe übereinstimmt oder ob sie genau in der gleichen Branche tätig ist wie Sie.

Wenn Sie in der glücklichen Lage sind, einen vorhandenen Kunden besuchen zu dürfen, denken Sie daran, dass es sich nicht um den Anbieter handelt. Seien Sie respektvoll, freundlich und dankbar. Bringen Sie ein kleines Geschenk mit. So wird Werbematerial mit Ihrem Firmenlogo immer sehr geschätzt. Bei Ihrem Besuch oder bei einem Telefongespräch mit dem Referenzkunden können Sie beispielsweise die folgenden Fragen stellen:

  1. Welches Verfahren haben Sie verwendet, um speziell diese Lösung auszuwählen?

  2. Welche Auswirkungen hatte die Lösung auf Ihre Geschäftsprozesse?

  3. Welcher Aspekt der Bereitstellung hat die meisten Probleme bereitet?

  4. Was war bis jetzt der größte Vorteil Ihrer Investition?

  5. Wie wird sich die Lösung Ihrer Meinung nach weiterentwickeln?

Erwarten Sie nicht nur positive Antworten.

Einem Anbieter, der keinerlei Referenzen bieten kann, sollte eher mit Misstrauen begegnet werden als einem Anbieter, der mit einer Reihe zufriedener Kunden aufwarten kann.

Und wenn Sie dann Ihre Auswahl getroffen haben, unterteilen Sie die Bereitstellung in Phasen. In dieser Kolumne finden Sie weitere Artikel zur phasenweisen Bereitstellung im Vergleich zur "Urknall"-Methode. Mit dem phasenweisen Ansatz verringern Sie die Risiken, die mit jeder Bereitstellung eines Unternehmenssystems einhergehen, und tragen zur Feinabstimmung des Bereitstellungsprozesses bei, während das System weiter ausgebaut wird.

Denken Sie daran, dass die Bereitstellung eines Unternehmenssystems ein dynamischer Prozess ist. Es ist keine einmalige Entscheidung mit Glücksmomenten, die sich Monat für Monat und bis in alle Ewigkeit wiederholen. Die erfolgreichsten Bereitstellungen von Unternehmenssystemen beginnen mit einer Auswahl, die die wichtigsten Mitstreiter umfasst, die Teil des Bereitstellungsprozesses sind, vom wichtigsten Mitglied der obersten Führungsebene bis zum talentiertesten Taktiker unter den Außendienstmitarbeitern, und werden Phase für Phase über die gesamte Weiterentwicklung des Systems fortgesetzt.

Die Auswahl eines effektiven Unternehmenssystems stellt nur die ersten Phase des Prozesses dar.

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).

Teilen Facebook Facebook Twitter Twitter E-Mail E-Mail

War diese Information hilfreich?

Sehr gut. Noch anderes Feedback?

Was können wir verbessern?

Vielen Dank für Ihr Feedback!

×