Herausforderungen bei der Auswahl der Unternehmenssoftware

Dieser Artikel ist Teil unserer Sammlung "From the Trenches". Es wird beschrieben, wie Unternehmenssystemimplementierungen in der Lage sein müssen, sich anzupassen und weiterzuentwickeln, um erfolgreich zu sein.

Informationen zum Herunterladen der Word Version dieses Artikels finden Sie unter Die Herausforderungen bei der Auswahl von Unternehmenssoftware.

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

Die Herausforderungen bei der Auswahl von Unternehmenssoftware

Es passiert hier die ganze Zeit. Ein Kunde sendet eine "Anforderung für Vorschlag" (Request for Proposal, RFP) mit Anweisungen an das Büro, um eine Antwort in einigen Tagen oder einer Woche abzuschließen und zurückzusenden, damit unser Enterprise-System für den Kauf in Betracht gezogen wird. RFPs sehen fast alle gleich aus. Es gibt in der Regel eine kurze Übersicht, Anweisungen dazu, was Sie tun müssen, um Ihre Antwort zu berücksichtigen, einschließlich der Formatierung und des Zeitpunkts, wann sie zurückgesendet werden muss usw. Dann gibt es ein langes Raster mit erforderlichen Features und eine Reihe zusätzlicher Aufsatzfragen, auf die Sie Antworten schreiben können.

Die Herausforderung bei RFPs besteht darin, dass sie nicht ideal für die Auswahl von Unternehmenssoftware geeignet sind, und was bei der Einhaltung eines RFP-Prozesses eintritt, garantiert nicht die besten Entscheidungen für die organization. RFPs wurden von der Einkaufsgemeinschaft entwickelt, um die beste Ware zum besten Preis zu erhalten, und sie leisten immer noch einen guten Job. Wenn die Angebote vergleichbar sind, kann sich der Entscheidungsprozess auf den besten Preis konzentrieren, wobei nur eine oder zwei zusätzliche Variablen (z. B. Versandtermine) zu bewältigen sind. Wenn sich die möglichen Lösungen in der gleichen allgemeinen Kategorie befinden, aber überhaupt nicht vergleichbar sind (wie bei Unternehmenssoftware), dann ist die Anzahl der Variablen, die von Käufern berücksichtigt werden müssen, enorm, und der RFP-Prozess führt nicht zu einem Mehrwert für die Auswahl. Wie sich die meisten Unternehmen für Unternehmenssoftware entscheiden Beginnen wir mit dem Prozess, der bei jedem Anbieter oder Lösungsanbieter von Unternehmenssoftware ständig abläuft. Ich werde über Enterprise-Projektmanagement-Software oder Enterprise-Arbeitszeittabellen-Software sprechen, wie dies meine Firma bietet, aber das Paradigma ist für praktisch jede Auswahl des Unternehmenssystems dasselbe.

Wie die meisten Unternehmen Unternehmenssoftware auswählen

Sehen wir uns zunächst den Prozess an, der in jedem Anbieter oder Lösungsanbieter von Unternehmenssoftware ständig stattfindet. Ich werde über Enterprise-Projektmanagement-Software oder Enterprise-Arbeitszeittabellen-Software sprechen, wie dies meine Firma bietet, aber das Paradigma ist für praktisch jede Auswahl des Unternehmenssystems dasselbe.

In den meisten Organisationen kommt der Impuls, nach Unternehmenssoftware zu suchen, von einem Problem aus. Vielleicht wird das Problem von den Außendienstmitarbeitern aufgetaucht. Vielleicht wird das Problem von jemandem in der Geschäftsleitung identifiziert. Wie auch immer es passiert, die Initiative muss unterstützung von jemandem in der Geschäftsleitung erhalten. Die Basisauswahl eines Systems, das sich auf das gesamte Unternehmen auswirken wird, ist selbst in den fortschrittlichsten Organisationen eine Fantasie. Ein leitender Manager entscheidet also: "Wir brauchen diese Art von Unternehmenssystem."

Der typische Auswahlprozess für Unternehmenssoftware sieht wie folgt aus:

1. Management sagt, wir brauchen ein neues Unternehmenssystem

2. Der Projektmanager ist ausgewählt.

3. Anfordern von Anfragen von allen beteiligten Abteilungen

4. Zusammenführen aller Anforderungen in einem großen Arbeitsblatt

5. Senden des Anforderungsrasters an viele Anbieter

6. Viele Antworten erhalten

7. Kurze Liste

8. Schauen Sie sich Demonstrationen an

9. Verhandeln

10. Abrufen der Zustimmung zur Verwaltung

11. Lassen Sie das Management über etwas anderes entscheiden

Ein Projektmanager für die Auswahl ist freiwillig. Er oder sie tut, was wir alle tun – gehen Sie ins Internet, laden Sie eine Suchmaschine und geben Sie "EPM Software" ein (oder ein beliebiges Unternehmenssystem). Sofort werden eine halbe Million Treffer zurückgegeben. Vielleicht surft der fleißigen Projektmanager im ersten Dutzend, um zu erfahren, welche Art von Systemen möglicherweise verfügbar sind, bevor er weiterfährt. Offensichtlich hat niemand die Zeit, durch eine halbe Million oder mehr Treffer zu surfen, um zu sehen, ob vielleicht der allerletzte das ideale System für die organization ist.

Unbeeinflußt stellt der Projektmanager nun eine Auswahlkommission aus den Reihen derjenigen zusammen, die von der Implementierung dieses neuen Unternehmenssystems betroffen sein werden. Einige der Mitglieder des Ausschusses können aus dem Bereich der Außendienstmitarbeiter stammen, die den Bedarf in der organization überhaupt erkannt haben. Andere können dies nicht. Es kann eine Mischung von Personen in diesem Auswahlausschuss geben, die unterschiedliche Interessen daran haben, welche Art von System ausgewählt wird.

Der glücklose Projektmanager bittet jetzt jedes Mitglied des Ausschusses, seine repräsentative Gruppe zu fragen, was sie im neuen Unternehmenssystem benötigen. Wie macht jeder Ausschussvertreter dies? Nun, zunächst einmal, nicht jeder gibt sich die gleiche Mühe, aber für diejenigen, die ihre Hausaufgaben machen, bitten sie ihre Mitarbeiter, eine Liste von Funktionen vorzulegen, die sie wichtig finden würden. Dann schlagen sie auch das Internet und surfen einige Anbieter-Websites. Sie können funktionen kopieren und einfügen, die sie in den Broschüren dieser Websites sehen, da jede Website ihnen neue Ideen darüber gibt, welche Arten von Anforderungen sie an ein neues System stellen können.

Jetzt ist der Ausschuss neu zusammengesetzt und die lange Tabelle jedes Ausschussmitglieds wird mit den anderen zu einer riesigen Tabelle zusammengeführt. Die Megatabelle der Anforderungen ist kategorisiert, aber es gibt Herausforderungen. Zunächst einmal werden die vielfältigen Bedürfnisse des Ausschusses jetzt deutlicher, da merkmale aus einer Vielzahl von Perspektiven gefordert werden. Es kann Ausschussmitglieder in verschiedenen Abteilungen, aber auch in verschiedenen Ländern/Regionen oder sogar verschiedenen Abteilungen geben. Es gibt fast immer eine Anforderung, die mit einer anderen Anforderung in derselben Liste in Konflikt steht (z. B. sollte das System sehr einfach sein und nicht viele Eingabeaufforderungen haben, und das System sollte sehr flexibel mit einer großen Anzahl von Optionen für jeden Benutzer sein).

Schließlich ist die kombinierte Kalkulationstabelle, die den Anbietern angezeigt wird, fertig. Es enthält Hunderte von Featureanforderungen, und für jede wird erwartet, dass der Anbieter "Ja", "Nein" oder "Ja mit etwas Aufwand" sagt. Ein Gewichtungssystem kann auch angefügt werden, um zu sagen, ob dieses Feature ein "Must-have", ein "Important-to-have" oder ein "Nice-to-have" ist.

Der RFP ist fast einsatzbereit. Es gibt ein paar Aufsatzfragen, in der Regel über die technische Architektur der Auswahl, und je nachdem, wie viele Personen zu diesen Anforderungen befragt wurden, können die Architekturanforderungen gleichermaßen in Konflikt stehen (z. B. das System muss alle Daten zentral in der SQL Server Datenbank gespeichert haben und das System muss zulassen, dass alle Daten lokal auf dem Computer des Benutzers gespeichert werden können).

Eigentlich klingt es bisher ziemlich gut, denken Sie nicht? Schließlich erhalten wir eine Reihe von Lieferantenantworten, die zeigen, wer alle Features bereitstellen kann, die wir benötigen. Eigentlich klingt es bisher ziemlich gut, denken Sie nicht? Schließlich erhalten wir eine Reihe von Lieferantenantworten, die zeigen, wer alle Features bereitstellen kann, die wir benötigen.

Aber es gibt tatsächlich ein grundlegendes Problem mit dem, was ich bisher beschrieben habe: Ein Problem, das nicht auftritt, wenn wir den RFP-Prozess für eine Ware und nicht für ein Unternehmenssystem verwenden. Es ist folgendes: Ein Unternehmenssystem ist eine Lösung für etwas. Aber wir haben bisher nichts über das Problem gesagt. Dies ist ein so häufiges Ereignis, dass die Technologiebranche es als normal und akzeptabel akzeptiert hat.

Warum die Auswahl von Unternehmenssoftware auf diese Weise nicht funktioniert

Käufer verwenden diese Methode seit Jahrzehnten und niemand stellt sie in Frage, aber die Leute im Unternehmenssoftware-Geschäft wissen, dass es ein grundlegendes Problem mit der klassischen RFP-Methode der Auswahl von Unternehmenssoftware gibt.

Erstens, nur weil Sie eine enorm lange Liste von Funktionen haben, bedeutet dies nicht unbedingt, dass Sie näher an der Lösung eines Geschäftsproblems sind. In der Tat, wenn Sie nicht einmal artikuliert haben, welche spezifischen Geschäftsprobleme Sie zu lösen versuchen, dann werden Sie die Dinge wahrscheinlich komplexer und letztendlich schlimmer, nicht besser machen. Der RFP-Prozess wurde für den Kauf von Waren entwickelt. Wenn wir homogene Produkte wie Schuhe, Kartoffeln oder Zucker haben, kann der Kauf dieser Artikel auf diese Weise zu dem kostengünstigsten Bieter und der besten Auswahl unter den möglichen Lieferanten führen. Die Reaktionen auf eine RFP für eine ähnliche Ware machen den Vergleich möglicher Lieferanten sehr einfach. Wenn die Variablen für jedes Produkt in der Mischung unendlich sind (wie bei Unternehmenssoftware), dann haben die Antworten auf die RFP auch eine unendliche Anzahl von Variablen, und der Prozess liefert Ergebnisse, die wenig Wert haben.

Wenn wir die RFP-Methode zur Auswahl von Unternehmenssystemen verwenden, sehen die RFPs größtenteils alle gleich aus. Dies liegt daran, dass sie alle als Reaktion auf denselben Reiz erstellt werden. Der Projektmanager fordert eine Liste von "was Sie in diesem Unternehmenssystem benötigen" an, und das einzige Vokabular, das die meisten mittleren Manager auf diese Anforderung reagieren müssen, ist eine Liste von Features. Folglich sehen die Antworten auf RFPs alle gleich aus. Sie sind eine Checkliste aller Features, die entweder als Teil des Systems oder als Teil des Systems mit etwas Aufwand verfügbar sind.

Was bei Auswahlteams am häufigsten vorkommt, ist, dass sie eine Reihe von Antworten auf ihre RFPs erhalten, sie durch hunderte von Seiten waten und wenn sie fertig sind, fühlen sie sich nicht näher an einer Lösung als zu Beginn. Dies ist furchtbar frustrierend für Käufer, die sich sehr bemüht haben, eine faire Anfrage für Vorschläge zu erstellen und die Antworten zu bewerten, nur um festzustellen, dass die Übung für unangebracht war.

Schlimmer als all dies ist, dass erfahrene Vertriebsmitarbeiter in Unternehmen wissen, dass der Prozess frustrierende Ergebnisse liefert und von dem Moment an arbeiten, an dem sie hören, dass ein RFP erstellt wird. Sie arbeiten nicht an der RFP-Antwort. Das ist nicht relevant. Stattdessen arbeiten sie zwei oder drei Ebenen höher in der Verwaltungsstruktur und suchen nach dem ursprünglichen Impuls, der die RFP gestartet hat. Sie suchen nach der Leitenden Führungskraft, die eine geschäftliche Herausforderung artikuliert hat, und setzen die Räder in Gang, sodass Käufer und andere Mitarbeiter des mittleren Managements letztendlich die RFP erstellen und an Lieferanten senden würden.

Wenn die RFP-Antworten ohne eine klare Antwort auf die Geschäftlichen Probleme enden, die im Kaufprozess fast nie artikuliert werden, ist der Vertriebsmitarbeiter des Unternehmens bereit, in Aktion zu treten, indem eine leitende Führungskraft den Prozess vollständig umgehen und ein System basierend auf ihrer persönlichen Beziehung zum Leitenden Unternehmensverkäufer auswählen kann.

Wenn Sie der Meinung sind, dass dies verworren klingt, sind Sie falsch. In der Tat können Sie besser dafür sorgen, dass Software über persönliche Beziehungen auf der Führungsebene ausgewählt wird, als für den Kauf über den RFP-Prozess.

Aber was ist mit einem Proof of Concept oder Pilot?

Wir wissen also, dass der klassische Kaufprozess fehlerhaft ist, wenn wir ihn auf den Kauf von Unternehmenssoftware anwenden. Wenn dies der Fall ist, wie sollten wir Unternehmenssoftware wie ein Enterprise-Projektmanagementsystem auswählen? Eine beliebte Methode ist die Verwendung der Proof of Concept- oder Pilotphase-Methode.

Diese beiden Begriffe werden häufig synonym verwendet. Beginnen wir also mit einer Proof of Concept- oder Pilotbereitstellung.

Proof of Concept. In einem Proof of Concept stellt der potenzielle organization die Unternehmenssoftware in begrenztem Umfang bereit, um zu beweisen, dass sie eine technische Herausforderung bewältigen kann, bei der eine Frage nach der Fähigkeit der Lösung besteht, diese Herausforderung zu bewältigen. Ein Beispiel hierfür ist das Datenvolumen. "Wir sind besorgt, dass das Produkt möglicherweise nicht so viele Aufgaben bewältigen kann, wie wir pro Projekt haben. Wir möchten, dass Sie mit der Software kommen, zwei oder drei Beispielprojekte mit jeweils 500 Aufgaben nehmen und uns zeigen, wie diese in die Software geladen werden können und dass die Software mit diesem Volumen trotzdem ihre Grundfunktionen erfüllen kann."

Pilotphase. Eine Pilotphase ist eine Installation der Unternehmenssoftware, jedoch mit einem begrenzten Umfang. Eine Pilotbereitstellung kann für eine Teilmenge von Benutzern erfolgen. beispielsweise werden nur 10 von 1000 Personen die Software für einen Zeitraum von vier Wochen vollständig nutzen. Oder es kann sich um einen Teilabschnitt der Funktionalität oder eine Teilmenge des Datenvolumens handeln. Beispielsweise werden nur 10 von 500 Projekten geladen.

Wie wird der Proof of Concept oder die Pilotphase verwendet? Das problem, das häufig auftritt, ist die Anwendung der Pilotphase oder des Proof of Concept. Es kommt eher selten vor, wenn ein potenzieller organization uns um einen Proof of Concept-Vorschlag bittet und auch erkennen kann, welches technische Konzept nachgewiesen werden muss. "Was wollen Sie beweisen, und wie werden wir in der Lage sein, zu messen, dass wir es bewiesen haben?", fragen wir.

Am häufigsten ist, dass jemand im mittleren Management eine Unternehmenssoftware identifiziert hat, von der sie hoffen, dass sie ihr Leben in ihrer organization erleichtern wird. Die Geschäftsleitung ist überhaupt nicht involviert, und die Mitarbeiter des mittleren Managements haben noch nicht einmal artikuliert, welche geschäftlichen Herausforderungen sie zu bewältigen versuchen. Es ist ihre Hoffnung, dass, wenn sich die Lösung nur im Gebäude befindet, wenn jemand vom Management das nächste Mal den Korridor hinunterwandert, er die Lösung "versehentlich" in Betrieb sehen würde und sofort einen Segen für eine Unternehmensbereitstellung geben würde. Um einen Satz aus dem Film Field of Dreams zu entlehnen: "Wenn wir es bauen, werden sie kommen."

Es ist selten erfolgreich. Das Problem bei Unternehmenssoftware besteht darin, dass wir die Beteiligung der Geschäftsleitung benötigen, um die Bereitstellung zu einem Erfolg zu machen. Es ist die Geschäftsleitung, die die "Kunden" der Berichte und Analysen aus diesem Unternehmenssystem sein wird. Es ist die Geschäftsleitung, die persönlich investieren muss, um einer Reihe von Mitarbeitern die Zeit zu ermöglichen, die für das Entwerfen, Konfigurieren und Trainieren der Unternehmenssoftware erforderlich ist. Es ist die Geschäftsleitung, die die Geschäftsprozesse akzeptieren oder sogar mitgestalten muss, die Teil jeder Unternehmenssystembereitstellung sind. Ohne die Geschäftsleitung nicht nur ihren Segen, sondern auch ihre implizite Unterstützung und direkte Unterstützung zu geben, wird kein Proof of Concept helfen.

Dies gilt auch für eine Pilotphase. Wenn sich das Unternehmen nicht von der höchsten Ebene verpflichtet hat, ein Geschäftsproblem durch den Einsatz von Unternehmenssoftware zu lösen, ist die Einführung einer Pilotphase nicht produktiv.

Das heißt nicht, dass Pilotphasen einer Bereitstellung keinen Platz haben. Sie haben einen kritischen Punkt in einer erfolgreichen Bereitstellung. Dieser Ort ist unmittelbar nach Abschluss der Kaufentscheidung und der Entwurf des Unternehmenssystems abgeschlossen. Jetzt ist eine Pilotphase ein guter Ort, um unser Unternehmenssystemdesign zu testen und für die allgemeine Bereitstellung zu optimieren.

Wenn eine Pilotphase in der Hoffnung durchgeführt wird, dass das Sehen der Software in Aktion dazu führt, dass das Management sie auswählt, dann haben wir einen ineffektiven Pilot und werden im Auswahlverfahren nicht weiterkommen.

Wie sollten Organisationen Unternehmenssoftware auswählen?

Unternehmenssysteme werden täglich von mittleren bis großen Organisationen gekauft, und obwohl die RFP-Methode möglicherweise nicht die effektivste ist, gibt es mehrere Methoden zur Auswahl von Unternehmenssoftware, die sehr effektiv sind. Hier sind einige Tipps zum Erstellen Eines eigenen effektiven Unternehmensauswahlprozesses.

• Artikulieren Sie das Problem. In erster Linie artikulieren Sie das Problem. Dies bedeutet, dass die Geschäftsleitung einbezogen werden muss, und das Problem, das zu artikulieren ist, ist ein geschäftsspezifisches Problem. Eine gute Frage ist: "Welche geschäftliche Entscheidung können wir jetzt nicht oder nur mit großen Schwierigkeiten treffen, deren Entscheidung mit der Bereitstellung dieser Unternehmenssystemlösung erleichtert werden könnte?"

  Es kann eine Reihe von geschäftlichen Herausforderungen geben, die Sie mit der Verwendung dieses Unternehmenssystems lösen möchten.

• Geben Sie Anbietern einen gewissen Spielraum, um die Lösung zu erstellen. Sobald das Geschäftsproblem oder die Probleme artikuliert wurden, wenden Sie sich an mögliche Anbieter, und stellen Sie sicher, dass der Zugriff auf die Geschäftsleitung, die den Prozess unterstützt hat, transparent ist. "Geheime" Lieferantenbesprechungen mit der Geschäftsleitung werden unmöglich, wenn die Geschäftsleitung von Anfang an Teil des Prozesses ist. Lassen Sie die Anbieter das Problem verstehen, und geben Sie ihnen einen gewissen Spielraum bei der Beantwortung dieses Problems. Sie können mehr über Ihre organization erfahren, wenn Sie erklären, wie sich diese geschäftlichen Herausforderungen auf Sie auswirken, als Sie erkennen, und Sie werden sicherlich eine viel größere Palette möglicher Lösungen für Ihr Problem sehen, wenn Sie nicht versuchen, die Lösung den potenziellen Anbietern zu beschreiben.

  Wenn Sie mit möglichen Lösungsanbietern sprechen, stellen Sie sicher, dass diese verstehen, dass sie sowohl mit der Technologie als auch mit der Herausforderung des Geschäftsprozesses sprechen müssen. Es gab noch nie eine Unternehmenssystemlösung, die keine Auswirkungen auf den Prozess der organization hatte. Wenn der Lösungsanbieter nicht dabei helfen kann, wie der Prozess beeinträchtigt wird, sehen Sie sich nur einen Teil der Lösung an.

• Treffen Sie einige Leute. Wenn Sie zu einigen möglichen Lösungsanbietern kommen, bitten Sie, mit einigen ihrer vorhandenen Kunden zu sprechen. Noch besser: Sehen Sie sich an, ob der Anbieter Ihnen erlauben wird, einige seiner bestehenden Kunden zu besuchen. Gute Lösungsanbieter verfügen häufig über Kunden, die in ihren eigenen Bereitstellungen Erfolgreich waren und großzügig genug sind, sich Zeit zu nehmen, um potenzielle Kunden zu treffen.

  Sie erfahren in einigen Stunden mit einem erfahrenen Kunden mehr über die mögliche Lösung, als Sie jemals durch das Lesen der RFP-Antworten oder durch das Betrachten von Verkaufsdemonstrationen von Anbietern gelernt hätten. Wenn Sie den Anbieter nach möglichen Kundenreferenzen und Ortsbesuchen fragen, könnten Sie denken, dass das ideale Unternehmen, das Sie treffen sollten, genau wie Ihr Unternehmen wäre. Das ist nicht immer der Fall.

Es ist oft äußerst wertvoll, Unternehmen aus anderen Branchen zu treffen, die mit Ihren verwandt sind oder ihnen ähnlich sind. Sie können auch viel von Organisationen lernen, die größer oder kleiner als Sie sind. Legen Sie mehr Wert darauf, wie viel Erfahrung die organization mit der Lösung hat, anstatt auf die verwendete Version zu legen oder ob sie genau die Größe oder genau in der Branche haben, in der Sie sich befinden.

Wenn Sie das Glück haben, einen bestehenden Kunden zu besuchen, denken Sie daran, dass es sich nicht um den Anbieter handelt. Seien Sie respektvoll, höflich und dankbar. Das Mitbringen eines kleinen Geschenks, vielleicht des Werbematerials des Unternehmenslogos, wird oft sehr geschätzt. Während Sie mit dem organization oder während der Telefongespräche mit Referenzen sprechen, können einige mögliche Fragen sein:

1. Welchen Prozess haben Sie verwendet, um diese Lösung gegenüber anderen auszuwählen?

2. Welche Auswirkungen hat diese Lösung auf Ihre Geschäftsprozesse gehabt?

3. Was war der herausforderndste Aspekt der Bereitstellung?

4. Was war bisher die wertvollste Rendite?

5. Wie sehen Sie, wie sich die Lösung von hier aus entwickelt?

Erwarten Sie nicht nur zufriedene Antworten.

Ein Anbieter, der völlig nicht in der Lage ist, Referenzen bereitzustellen, muss etwas verdächtiger sein als einer, der eine Reihe zufriedener Kunden hat.

Wenn Sie Ihre Auswahl getroffen haben, stellen Sie die Bereitstellung in Phasen bereit. In dieser Spalte finden Sie weitere Artikel zum Bereitstellen im Phasen- und Big-Bang-Modus. Dies verringert die Risiken, die mit jeder Unternehmenssystembereitstellung verbunden sind, und hilft bei der Optimierung des Bereitstellungsprozesses, während sich das System weiterentwickelt.

Denken Sie daran, dass jede Unternehmenssystembereitstellung ein dynamischer Prozess ist. Es ist keine einmalige Entscheidung mit glücklichen Ergebnissen, die Monat für Monat für immer mehr ankommen. Die erfolgreichsten Unternehmensbereitstellungen beginnen mit einer Auswahl, bei der die wichtigsten Mitarbeiter beteiligt sind, die teil des Bereitstellungsprozesses sind, von der höchsten Verwaltungsebene bis zu den taktischsten auf dem Gebiet, und die Weiterentwicklung des Systems in Phasen nach der anderen.

Eine effektive Unternehmenssystemauswahl ist nur die erste Phase des Prozesses.

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 an 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. Veröffentlichungen, für die Chris geschrieben hat, sind 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).