Wir verkaufen Löcher, keine Bohrer!

Ich bin vor kurzem auf einen interessanten Ausdruck gestoßen. Ein Softwareverkäufer sprach über die Bereitstellung der gesamten Lösung für seinen Kunden. "Wir verkaufen keine Drills. Wir verkaufen Löcher", sagte er. Es ist eine großartige Analogie. Viele Leute (ich eingeschlossen) sind in den Baumarkt gegangen und haben sich in der Power Tools-Abteilung eingekauft und sich gefragt, welches Projekt ich mir vorstellen könnte, was den Kauf dieses großartigen Power-Tools rechtfertigen würde. Aber die Anwendung dieser Logik ist in der Do-it-Yourself-Welt genauso sinnvoll wie in Unternehmenssoftwaresystemen.

Wenn Sie kein Problem haben, benötigen Sie keine Lösung.

So wie niemand nach einem Drill suchen sollte, es sei denn, das Problem, das er lösen möchte, ist, ein Loch zu machen, sollte niemand nach Unternehmenssoftware suchen, es sei denn, sie löst ein Problem. Wenn Sie nun ein Problem haben, das durch die Bereitstellung von Unternehmenssoftware behoben wird, müssen Sie als Nächstes sicherstellen, dass das, was Sie kaufen, die Lösung liefert, die Sie benötigen. Das ist oft viel mehr als nur der Kauf der Software.

Die Bereitstellung eines Unternehmenssystems ist eine komplexe Herausforderung, daher muss sich der Aufwand lohnen. In der heutigen Welt der globalen Projektteams besteht eine der häufigsten Aufgaben darin, den enormen Aufwand einer Unternehmenssystembereitstellung aufzuteilen. Dies kann uns zwar Skaleneffekte bei der Verwendung von Teams bieten, die in ihrem Aspekt des Projekts gut ausgebildet sind, birgt aber auch das Risiko, Aspekte des Projekts auf äußerst riskante Weise zu übersehen. Dieses Risiko wird umso größer, je mehr physisch und organisatorisch getrennt die verschiedenen Teams sind.

Sehen wir uns die gängigsten Elemente eines Enterprise-Systemprojekts an.

Was ist ein Unternehmen?

Zunächst einmal, was meine ich mit Unternehmen? Ich nehme eine Definition, die für fast jeden funktionieren sollte. "Enterprise" bedeutet in diesem Zusammenhang jedes Projekt, das sich auf die Funktionsweise der gesamten Organisation auswirkt. Ich werde sagen, dass dies für jede Organisation gilt. Bei Implementierungen, die als Unternehmensimplementierungen gelten, geht es nicht nur um die Anzahl der Benutzer, sondern auch darum, wie viel Auswirkungen sie haben. Eine Aktualisierung unserer Virenscansoftware von Anbieter A auf Anbieter B wäre also wahrscheinlich nicht qualifiziert. Die Implementierung von Projektplanungssoftware auf dem Desktop für eine Handvoll Benutzer wäre wahrscheinlich nicht qualifiziert. Die Zentralisierung unseres Projektmanagements und die Verwendung eines zentralisierten Enterprise-Projektmanagementsystems wäre wahrscheinlich qualifiziert.

Okay, wenn es sich um ein Enterprise-Projekt handelt, was sind dann die häufigsten Elemente einer Bereitstellung eines Unternehmenssystems? In unseren Niederlassungen ist die häufigste Erfahrung die Bereitstellung von Arbeitszeittabellensystemen für Unternehmen, z. B. unserem eigenen TimeControl, oder Enterprise-Projektmanagementsystemen wie Microsoft Project Server, aber diese Elemente werden für fast jede Enterprise-Systemimplementierung gemeinsam sein.

Bits und Bytes

Lassen Sie uns zunächst die grundlegendsten Bausteine der Software angehen: die technische Architektur. Heutzutage müssen wir unser Denken auf der Grundlage unserer Entscheidung, eine lokale Bereitstellung oder ein In-the-Cloud-Abonnement zu verwenden, trennen. Ich überlasse die Wunder der Wahl, welche von diesen unter welchen Bedingungen für einen anderen Tag am besten ist, aber hier sind einige der Grundlagen dessen, was wir in jeder Kategorie denken müssen.

Wenn wir eine lokale Installation durchführen, müssen wir überlegen, welche Hardware wir verwenden werden. Welche Hardwareanforderungen gelten für Arbeitsspeicher und CPUs? Werden physische oder virtuelle Server verwendet? Werden dedizierte Server oder freigegebene Server verwendet? Welche Arten von Servern sind möglicherweise erforderlich? Benötigen wir Anwendungsserver, Sicherheitsserver, Webserverserver? Wie sieht es mit Lastenausgleich, Notfallwiederherstellung und Sicherungen aus? Benötigen wir kalte oder warme Sicherungsserver? Puh! Aber wir sind noch nicht fertig! Was ist mit der Datenbank? Welche Anforderungen gibt es? Wie sieht es mit der Unterstützung unserer vorhandenen Sicherheits-, Anwendungs- und Datenbankarchitekturen aus? Wie sieht es mit der Unterstützung für Browser, Browserversionen und mobile Geräte aus? Sobald wir alle diese Fragen beantwortet haben, müssen wir die Probleme der Installations-, Test- und Produktionsumgebungen und dann die Systemintegrität und -überwachung behandeln, sobald das System aktiv ist und ausgeführt wird.

Wenn wir eine In-the-Cloud-Abonnementimplementierung verwenden, müssen wir immer noch Fragen beantworten, obwohl es sich um sehr unterschiedliche Fragen handelt. Welchen Onlinedienst verwenden wir? Verwenden wir eine dedizierte Installation oder einen mehrinstanzenfähigen Dienst? Wie sieht es mit der Sicherheit aus? Können wir mit unserer eigenen Authentifizierung integrieren? Wie behandeln wir die Notfallwiederherstellung mit dem Abonnementdienst? Wo befinden sich die Daten physisch? Stellt uns dies rechtliche Fragen? Wie sieht es mit der Unterstützung für unsere internen Browser und mobilen Geräte aus? Wie werden wir unsere Daten abrufen und wie können wir eine Verbindung mit internen Datenbanken oder anderen externen SaaS-Diensten (Software-as-a-Service) herstellen, um Funktionen zu integrieren?

Aus der Luft noch? Wenn wir über ein Unternehmenssystem sprechen, stehen diese und weitere Fragen auf der Tagesordnung. Wenn wir diesen Teil unseres Projekts zu unserem gut ausgebildeten technischen Team verlagern, könnte es beginnen, dies als den Umfang des gesamten Projekts zu betrachten, wenn dies nur die Konstruktion unserer Bohrmaschine und noch nicht die Herstellung des erforderlichen Lochs ist.

Konfigurieren Sie mich!

Abgesehen davon, dass unser System nur funktioniert, gibt es auch die Anwendung der Funktionalität innerhalb dieses Systems auf unsere spezifischen Probleme. Ich habe Project Server-Bereitstellungen gesehen, bei denen der Client Project Server in Betrieb nimmt und dann feststellt, dass er keine Mittel für die Erstellung von Workflows bereitgestellt hat, wie man lernt, wie man sein Projektportfolio priorisiert oder wie man einen einzelnen Bericht erstellt. Genau wie die Systemanalyse 101 im College beginnen wir diesen Teil der Implementierung in der Regel ganz rechts auf einem Whiteboard, während wir die Geschäftsleute fragen, die das eigentliche Geschäftsproblem haben, welche "Ergebnisse" sie benötigen. Ich habe bereits in anderen Schriften darüber gesprochen, also werde ich es hier nicht weiterarbeiten, aber die Ausgaben sollten letztendlich geschäftsbezogene Entscheidungen sein. Welche Berichte, Analysen und letztlich Dateneingaben benötige ich, um diese Entscheidungen zu treffen? Wir arbeiten uns von der rechten Seite des Bildschirms nach links und erhalten eine Liste aller Bausteine, die wir in Form von Datenelementen, analytischen Berechnungen sowie Exporten und Berichten benötigen, die im System konfiguriert werden müssen. Diese Konfigurationsübung kann je nach Komplexität Wochen oder Monate dauern.

Häufig sind die Ressourcentypen, die wir für diesen Aspekt des Projekts benötigen, eine Kombination aus Business Analyst und Systemexperte, und es ist üblich, dass diese Personen zwar hochqualifiziert in der Funktionalität des bereitgestellten Systems sind, aber nicht so gut in der technischen Architektur sind. Dies macht es sehr üblich, teams für zwei kritische Elemente des Systems getrennt zu haben. Je weniger diese beiden Gruppen kommunizieren, desto wahrscheinlicher ist es, dass wir später vor Herausforderungen stehen.

Es ist ein Prozess

Es ist unmöglich, ein neues Unternehmenssystem bereitzustellen und die Prozesse der Organisation nicht zu beeinflussen. Selbst wenn Sie ein zentralisiertes Unternehmenssystem aufgeben und zu seinem Konkurrenten wechseln, werden sich die Prozesse ändern. Wenn Sie nicht möchten, dass sich Ihre Prozesse ändern, ist es durchaus möglich, dass Sie kein Problem haben, das gelöst werden muss, und hierin liegt eine weitere Herausforderung. Wenn sich die tägliche Routine einer Person ändert, verursacht dies Verärgerung. Ich meine nicht die Zeit. Meiner Erfahrung nach ist verärgert in dieser Zeit des Wandels eine Selbstverständlichkeit. Dies gilt auch dann, wenn die Prozessänderung zu einem besseren Prozess führt! Das Nachdenken darüber, wie sich die Prozesse verändern werden, und die Zusammenarbeit mit den Betroffenen ist also entscheidend für den Erfolg des Projekts. Allerdings sind genau die Experten, die für die Gestaltung dieser Änderung im Prozess wichtig sind, wahrscheinlich die gleichen Personen, die von dieser Änderung betroffen sein werden, sodass dies ein herausfordernder Aspekt der Implementierung sein kann. In der Regel wird ein qualifizierter und erfahrener Vermittler mit den internen Experten zusammenarbeiten, um die Änderung des Prozesses zu leiten, die mit der Implementierung des neuen Systems möglich geworden ist. In unserer Arbeit sehen wir diese Herausforderung ständig. "Aber die Projektmanager müssen zuerst die Arbeitszeittabellengenehmigungen durchführen", sagt uns ein neuer TimeControl-Client. "Das ist unser Prozess." Wenn wir erklären, dass Matrixgenehmigungen projektmanagern ermöglichen können, ihre Arbeitszeittabellengenehmigungen im Rahmen eines größeren, effektiveren Prozesses zu erledigen, dann regt sich uns auf. Pushback. An diesem Punkt arbeiten wir mit einem unserer erfahrensten Mitarbeiter mit den betroffenen Personen zusammen, um sicherzustellen, dass ihre Anliegen berücksichtigt werden und dass sie ein integraler Bestandteil der Art und Weise sind, wie sich der Prozess ändern wird.

Daher sind die Prozessmitarbeiter wahrscheinlich nicht die Konfigurationsmitarbeiter oder die technischen Personen, aber wenn wir dieses Team nicht geplant haben, wird unsere gesamte harte Arbeit an der Installation und Konfiguration wahrscheinlich nicht bereitgestellt. Auch dieses Team muss Teil unserer Planung sein und in die Kommunikation und entscheidungen der beiden anderen Teams einbezogen werden.

Schulungen

"Also, brauchen wir Training?" ist leider eine Frage, die oft zuletzt gestellt wird. Einige Schulungen können durch die Prozessänderungen kommen, da dieser Teil des Projekts viele praktische Diskussionen erfordert, aber wie sieht es mit dem tatsächlichen Benutzerhandbuch aus, wie das neue System schrittweise funktioniert? Zu einem Zeitpunkt wurde die Schulung als kritisches Element bei Softwarebereitstellungen angesehen, und die Clients erwarteten, dass sie etwa 20 % des Gesamtbudgets dafür zur Verfügung stellen. Aber mit den Änderungen der Softwarekosten und der Geschwindigkeit der Installation allmählich, dass 20% immer weniger Geld wurden. Wenn wir 20 US-Dollar pro Monat und Benutzer für ein System zahlen, sollte ich dann 4 US-Dollar pro Benutzer für das Training beiseitelegen? Ich kann nicht versprechen, dass es nicht zu weit geht. Es gibt viele Onlineabonnementoptionen für schulungen, aber keine davon berücksichtigt genau die von Ihnen entworfene Lösung.

Trainer können von außen kommen oder aus den Konfigurations- oder Prozessteilen des Projekts stammen, aber es handelt sich häufig um Personen, die Spezialisten sind und nicht die Personen, die die Implementierungsarbeit tatsächlich ausgeführt haben. Selbst wenn Sie also Mittel für dieses Team zur Seite gesteckt haben (und ich hoffe, dass Sie dies getan haben), müssen Sie sicherstellen, dass diese Personen wissen, in welchem System sie Die Menschen trainieren, für das sie eigentlich konzipiert sind. Ich habe gesehen, wie Trainer für Microsoft Project Server eingetroffen sind und sie damit beginnen, Benutzern zu erklären, wie Unternehmensfelder konfiguriert und Geschäftstreiber in der Portfolioanalyse eingerichtet werden, nur damit die Benutzer einen leeren Blick geben, da ihre Enterprise-Felder bereits alle eingerichtet waren und sie bei ihrem ersten Rollout keine Portfolioanalyse verwenden werden. Kennen Ihre Trainer überhaupt das Problem, das diese spezielle Bereitstellung lösen soll? Sie sollten es auch. Das Denken über die Ausbildung zu Beginn des Projekts gibt ihr die größten Erfolgsaussichten. Die Technischen, Konfigurations- und Prozessteams können kritische Daten in ihren gesamten Abschnitten für die Schulung beiseite legen, die letztendlich bereitgestellt wird. Das bedeutet, das Trainingsteam frühzeitig einzubinden.

Rollout/Akzeptanz/Kulturänderung

Wenn Sie vorausdenken und die Ressourcen für die Initiierung dieser Teams beiseite legen und alle über das Projekt zusammenarbeiten und kommunizieren lassen, dann wird die Einführung Ihres neuen Systems wahrscheinlich viel reibungsloser verlaufen als sonst, aber unterschätzen Sie nicht den Widerstand gegen kulturbedingte Veränderungen. Wichtige Evangelisten zur richtigen Zeit zur Verfügung zu stellen, kann von entscheidender Bedeutung sein. Werden auch alle diese Teammitglieder zusammenpacken und mit ihrem nächsten Projekt fortfahren? Es wird viel Systemwissen in diesen Personen enthalten sein, wenn das Projekt eingeführt wird. Besonders beeindruckt war ich anfang letzten Jahres von einem unserer Kunden. Es war die IT-Abteilung eine große Finanzorganisation. Eine der Bedenken, die wir dem wichtigen technischen Benutzer, der die Software zu Beginn des Projekts bewertete, war "Wer wird der Administrator sein, nachdem Sie das Projekt beendet haben?". "Ich will", sagte er. Er war seinem Wort treu. Seine Fähigkeiten und Kenntnisse haben sich durch die mehrmonatige Bereitstellung weiterentwickelt, die ein großer Erfolg war, und er bleibt weiterhin der wichtigste Administrator.

Abschluss

Es gibt noch hundert andere Dinge, über die sie nachdenken müssen, um sicherzustellen, dass Ihre Teams im Rahmen eines größeren Ziels kommunizieren und arbeiten, und wir haben nur über einige wenige gesprochen. Hoffentlich machen Sie sich damit bereits Gedanken über Ihre nächste Unternehmenssystembereitstellung. "Wie sieht es mit der Dokumentation aus?", denken Sie vielleicht. "Wie sieht es mit dem technischen Support aus?"

Beachten Sie folgendes: Wenn Sie eine Unternehmenssystembereitstellung planen, müssen Sie Ihre Perspektive erweitern, um nicht nur den Installationsaufwand, sondern auch die Bereitstellung der fertigen Lösung einzubeziehen. Stellen Sie sicher, dass das Loch genau dort angezeigt wird, wo es mit der richtigen Größe, der richtigen Tiefe und dem richtigen Winkel angezeigt werden soll.

Über den 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).