Bewährte Methoden für Unternehmenssysteme: Whitepaper

Dieses Whitepaper ist Teil unserer Sammlung "Aus der Praxis". Es beschreibt bewährte Verfahrensmethoden für Unternehmenssysteme im Allgemeinen (einschließlich Microsoft Project Server). Es wird ausgeführt, dass, obwohl Unternehmenssysteme anstreben, auf Benutzerebene eine einfach zu bedienende Oberfläche bereitzustellen, die Technologie und Infrastruktur, die zu ihrer Bereitstellung erforderlich sind, häufig sehr komplex sind. Dieses Whitepaper beschreibt ferner, wie diese Komplexität Sie dazu zwingt, einige grundlegende bewährte Methoden zu verwenden, die Ihnen die beste Möglichkeit verschaffen, ein hohes Maß an Zuverlässigkeit in Ihrem Unternehmenssystem aufrechtzuerhalten.

Eine Word-Version dieses Whitepapers können Sie unter Bewährte Methoden für Unternehmenssysteme herunterladen.

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

Bewährte Methoden für das Unternehmensmanagement

Meistens schreibe ich über Arbeitszeittabellen- oder Projektmanagementsysteme für Unternehmen, und die Phase der Bereitstellung, die ich bei solchen Systemen am häufigsten behandle, ist entweder die Auswahl- oder die Konfigurationsphase: aus strategischer Sicht. Dieser Artikel beschäftigt sich aber mehr mit operationalen Praktiken und gilt nicht nur spezifisch für Arbeitszeittabellen- oder Projektmanagementsysteme für Unternehmen wie Microsoft Project Server. Stattdessen behandelt er Unternehmenssysteme im Allgemeinen, obgleich sich die Thematik sicherlich auf fast alle Project Server-Bereitstellungen anwenden lässt.

Wenn wir es mit bereits bereitgestellten Project Server-Systemen zu tun bekommen oder mit bestehenden Kunden reden, stellen wir oft Fragen darüber, wie die Organisation das System und seine Umgebung bereitgestellt hat und sie unterstützt. Als wir in der Branche angefangen haben, waren dies einfache Gespräche, weil sich die zu installierende Projektsoftware immer auf dem PC des Endbenutzers befinden würde, und die Pflege des Systems immer ein lokales Konzept war. Heutzutage ist das nur noch selten der Fall. Unternehmenssysteme sind auf Oberflächen- oder Anzeigeebene einfach, und die Endbenutzer können dort normalerweise in einem Webbrowser über eine ganz gewöhnlich aussehende Webseite auf die Funktionen zugreifen. So einfach dieses Systeme am Front-End scheinen mögen, so komplex sind sie doch am Back-End. Die Technologie, die erforderlich ist, um diese Oberfläche anzuzeigen, besteht wahrscheinlich aus mehreren Schichten, ist von mehreren Quellen für die Technologie und Infrastruktur abhängig und (falls das noch nicht reicht) wird wahrscheinlich ständig aktualisiert.

Aber es gibt einige grundlegende bewährte Methoden, die Ihnen die beste Möglichkeit verschaffen, ein hohes Maß an Zuverlässigkeit in Ihrem Unternehmenssystem aufrechtzuerhalten.

Finden Sie einen Besitzer

Tatsächlich müssen wir dies in zwei Besitzer unterteilen, weil jedes erfolgreiche Unternehmenssystem einen geschäftlichen und einen technischen Besitzer hat. Nur wenn der geschäftliche Besitzer ein Manager der IT-Abteilung ist, und das Unternehmenssystem primär für diese Abteilung bestimmt ist, können die Besitzer identisch sein. Lassen Sie es uns also in zwei Teile zerlegen:

Finden Sie einen geschäftlichen Besitzer

Diese Person sollte ein Angehöriger des Managements oder des Senior Managements sein, der ein berechtigtes Interesse an den Ergebnissen des Projektmanagementsystems hat. Der Nutzen, den das System bringen muss, bzw. die geschäftlichen Herausforderungen, die das System überwinden soll, müssen Nutzen und Herausforderungen sein, von denen dieser Manager direkt betroffen ist. Und außerdem, bevor auch nur jemand auf den Gedanken kommt: nein, in der Regel kann es keine Gruppe von Personen sein.

Die Verantwortung muss bei einer Stelle liegen, was praktisch immer eine einzelne Person bedeutet. Dieser Person könnte auch der Executive Sponsor für die Implementierung des Systems sein, muss es aber nicht. Häufig ist der Executive Sponsor nicht der ultimative geschäftliche Besitzer eines Unternehmenssystems.

Selbst nachdem das Bereitstellungsprojekt abgeschlossen ist, besitzt weiterhin der geschäftliche Besitzer das System, und wenn er es nicht mehr benötigt, muss entweder ein anderer geschäftliche Besitzer gefunden und benannt werden, der sich für das System engagieren muss, oder das System sollte außer Betrieb genommen werden.

Finden Sie einen technischen Besitzer

Bei Systemen auf Unternehmensebene reicht es nicht aus, lediglich einen Techniker zur Verfügung zu haben. Denken Sie daran, dass Unternehmenssysteme von vielen Schichten von Technologie abhängig sind. Der technische Besitzer muss ein so ausreichend hoher Senior Manager oder leitender Angestellter in der IT-Abteilung sein, dass er oder sie in der Lage ist, sofort mit den Besitzern der anderen Technologieschichten zu interagieren. Dies kann Vorgesetzte umfassen, die Besitzer der SQL Server-Datenbank, des Datenbankservers, auf dem SQL Server installiert ist, der Anwendungsserver, auf denen Project Server installiert ist, des Netzwerks, des Webservers oder der Serverfarm, der Internetverbindung, der Firewall, von Active Directory und Exchange-Servern, der Sicherheitsserver oder -systeme und des Betriebssystemabbilds auf Clientebene sind. Ein Vorgesetzter muss in der Lage sein, das Unternehmenssystem gegenüber diesen Managern, die andere Aspekte der Umgebung kontrollieren, zu vertreten.

Gehen Sie zweckorientiert vor

Stellen Sie sicher, dass Project Server a) einen Zweck hat und b) seinen Zweck auch erfüllt. Klingt offensichtlich? Ist es aber nicht. Allzu häufig werden Unternehmenssysteme aus den falschen Gründen angeschafft, und es fällt jemandem in der IT-Abteilung zu, einen Zweck zu finden, zu dem das System eingesetzt werden kann. Die Person, die den geschäftlichen Zweck für das Unternehmenssystem abzeichnet, sollte der geschäftliche Besitzer sein, wenn auch andere daran beteiligt sein können. Ich stelle solchen Managern immer eine Frage, die ich schon seit Jahren benutze: "Welche geschäftliche Entscheidung können Sie im Moment nicht oder nur unter großen Schwierigkeiten treffen, die Ihnen durch die Bereitstellung dieses Systems ermöglicht wird?" Sobald die geschäftliche Anforderung (beachten Sie, dass ich nicht von "gewünschter Funktionalität" spreche) festgelegt ist, stellen Sie sicher, dass das Unternehmenssystem diese Anforderung tatsächlich erfüllt. Ich treffe eine Menge Leute, die eine Einkaufsliste mit Funktionen haben, aber kaum wissen, was sie damit eigentlich erreichen möchten.

Stellen Sie im Verlauf der Entwicklung Ihrer Organisation sicher, dass sich der geschäftliche Besitzer auf dieses grundlegende Konzept rückbesinnt. Alleine die Bereitstellung eines Unternehmenssystems wie Project Server kann das Geschäft, in dem es bereitgestellt wird, grundlegend verändern, weshalb es nicht verwunderlich ist, dass sich die Anforderungen einer Organisation an ein System ändern können.

Häufig kommt man Jahre später, nachdem Project Server übernommen und bereitgestellt wurde, wieder in eine Organisation, nur um festzustellen, dass man niemanden auffinden kann, warum das System für die Organisation wichtig ist. Nur dass wir uns richtig verstehen: Das System ist weiterhin in Verwendung. Es wird durch reine Trägheit weitergetrieben, doch der Zweck ist verloren gegangen, und die Manager, die täglich von dem System profitieren, erkennen nicht mehr, woher dieser Nutzen kommt.

Integrieren Sie es in Ihre Unternehmensarchitektur

Ich erinnere mich daran, dass ich vor mehreren Jahren zusammen mit einem unserer technischen Mitarbeiter einen bestürzten Kunden vor Ort besucht habe. Die Instanz von Project Server, die sie selbst installiert hatten, verursachte alle möglichen Probleme. Vor Ort baten wir darum, eine Reihe technischer Mitarbeiter zu befragen, um das System durch seine Schichten zurückzuverfolgen. Als wir zur Datenbankschicht gelangten, waren wir sprachlos. Statt auf einem Standarddatenbankserver der Organisation, befand sich die SQL Server-Version, auf der das System installiert war, auf dem PC eines Endbenutzers. Bei jedem Neustart oder Abschalten des PCs, oder wenn etwas installiert wurde, war die Datenbank nicht mehr verfügbar. Dies hatte Auswirkungen auf buchstäblich Hunderte von Endbenutzern.

Es handelte sich um eine große Organisation, weshalb es nicht an Unternehmensservern oder zuverlässiger Infrastruktur gemangelt hätte. In diesem Fall ließ sich das Problem also leicht beheben. Allerdings war es dennoch eine gute Lektion. Wird das System, das Sie bereitstellen, in die bestehende Unternehmensinfrastruktur eingebunden, in deren Stabilität, Zuverlässigkeit und Sicherheit die Organisation möglicherweise beträchtlichen Aufwand investiert hat?

Führen Sie Sicherungen durch

Ich weiß. Albern, nicht? Erstaunlicherweise und unglücklicherweise ist es das aber nicht. Unternehmenssysteme können bekanntlich komplex zu sichern sein, da sie von vielen Aspekten des zu sichernden Systems gleichzeitig abhängig sein können. Da gibt es natürlich die grundlegenden Daten, aber auch die Metadaten und Konfigurationsdaten der Implementierung Und alle verbundenen Daten aus Hilfssystemen, die ggf. dem System entsprechen müssen, müssen möglicherweise Bestandteil desselben Sicherungsschemas sein. Wenn wir von Project Server sprechen, müssen wir daran denken, nicht nur die Projektdatenbanken zu sichern, sondern auch die SharePoint Server-Datenbank. Bei Project Server-Versionen, die älter als 2010 sind, müssen wir eventuell auch die globale Projektvorlage sichern. Selbst dann kann es immer noch Elemente von Vorlagen geben, die sich auf einzelnen PCs befinden.

Und nur zu sichern ist auch nicht ausreichend. Wenn sich die Systeme verändern oder Upgrades vorgenommen werden, müssen Sie mindestens einmalig eine Datenbankwiederherstellung durchführen. Ich erinnere mich an einen Kunden, dem wir vor Jahren beim Entwerfen einer Sicherungsstrategie geholfen hatten. Er fuhr den Server herunter, zog die Festplatte heraus, schob eine andere Festplatte ein, sah uns an und sagt: "Bitte sehr. Die Festplatte ist gerade kaputt abgestürzt. Das hier ist eine neu formatierte Festplatte. Bitte stellen Sie meinen Project Server wieder her." Ich war betroffen, aber mehr, weil ich erkannte, was für eine berechtigte Forderung das war. Und je mehr ich darüber nachdachte, desto deutlicher erkannte ich, wie schockierend es war, dass noch niemand diese Forderung zuvor (oder seitdem) gestellt hatte. Führen Sie also mindestens einmal einen Wiederherstellungstest durch. Nebenbei bemerkt, wir konnten dieses System tatsächlich wiederherstellen, aber es lief nicht so glatt, wie wir uns das erhofft hatten, sodass wir unsere Sicherungsverfahren überarbeiten mussten.

Staging/Produktion

"Die ganze Welt ist eine Bühne und alle Frauen und Männer bloße Spieler.", sagte Shakespeare schon vor langer Zeit. In diesem Fall geht es bei der Bühne mehr um das Staging (stufenweise Bereitstellung), und das ist für ein Unternehmenssystem entscheidend. Sobald das System einmal in der Produktion läuft, möchten Sie neue Konfigurationen ausprobieren, neue Anpassungen hinzufügen, neue Berichte, Verknüpfungen, Felder und andere Änderungen ausprobieren. Sie werden Updates und Upgrades haben, und diese sollten alle zuerst in einer Staging- oder Entwicklungsumgebung getestet werden, bevor die Benutzer in der Produktionsumgebung damit behelligt werden. Etwas so einfaches wie ein Browserupdate oder eine Datenbankaktualisierung kann ein Unternehmenssystem problemlos lahmlegen. Stellen Sie also sicher, dass Sie eine Stagingumgebung bereithalten und pflegen, die von der Produktionsumgebung getrennt ist. Heutzutage, im Zeitalter der virtuellen Server, ist das vielleicht einfacher als in der Vergangenheit. Eine ganze Umgebung kann heute einfach vom Produktionssystem geklont werden, aber das ist vielleicht manchmal einfacher gesagt als getan, je nachdem, wie die Bereitstellung aufgebaut ist. Denken Sie daran, dass möglicherweise auf viele verschiedene Teile des Technologiepuzzles referenziert wird, auch wenn Sie einen ganzen Server kopiert haben.

Überwachen, überwachen, überwachen

Es gibt zahlreiche Übersichtspunkte, an denen sich ein Unternehmenssystem gut überwachen lässt. Zuallererst ist es entscheidend, sicherzustellen, dass Project Server für die Endbenutzer verfügbar ist, und es ist ebenfalls wesentlich, dass sichergestellt ist, dass das geeignete technische Personal so schnell wie möglich benachrichtigt wird, falls es einmal nicht verfügbar ist. Dankenswerterweise gibt es viele Tools auf dem Markt, mit denen Sie sicherstellen können, dass das System funktioniert und verfügbar ist, die das technische Personal automatisch benachrichtigen, selbst wenn die Endbenutzer das Problem noch gar nicht bemerkt haben. Aber es gibt noch andere Aspekte der Überwachung, die ebenfalls wichtig sind. Es ist ratsam, ein Auge auf die Integrität der Anwendung zu haben sowie diese zu protokollieren, einschließlich folgender Faktoren: genutzte Arbeitsspeichermenge, CPU-Belegung, alle Fehler, die möglicherweise vom System gemeldet wurden, auch wenn sich das System selbständig davon erholt hat, alle Neustarts des erforderlichen Servers sowie die relevante Integrität anderer Elemente der technischen Infrastruktur. Die Kenntnis, dass beispielsweise IIS technische Probleme hat, könnte sehr wichtig sein, um die Verfügbarkeit Ihrer Unternehmensanwendung aufrechtzuerhalten.

Auch kleine Änderungen sind Veränderungen

Die Technologie, auf der Project Server basiert, ändert sich täglich. Es ist unmöglich, alle diese Änderungen zu vermeiden. Für das Windows Server-Betriebssystem erhalten Sie oft alle paar Tage Updates, für SQL Server können alle paar Wochen Updates eingehen. Einzelne Windows-Clientbetriebssysteme, deren Virenscanner, Firewalls und Internet Explorer mit seinen Add-Ins erhalten ebenfalls regelmäßig Updates. Jeder Teil der Kette zwischen Daten und Endbenutzer ist ein potenzieller Punkt, an dem die Anwendung gestört werden kann. Bauen Sie also eine Struktur auf, mit der Sie Änderungen innerhalb sämtlicher Technologieebenen verwalten können.

Dies kann eine Herausforderung darstellen, da viele Unternehmensanwendungen von ähnlichen Aspekten der Technologieebenen abhängig sein können. Wir hatten einen Kunden, der vor einer Weile arglos Project Server aktualisiert hat, nur um festzustellen, dass die gesamte SharePoint Server-Umgebung nicht mehr funktionierte. Offensichtlich war bei der Anwendung des Project Server-/SharePoint Server-Updates ein Fehler unterlaufen. Zwar gab es vollständige Sicherungen, und keine Daten gingen verloren, doch da der Upgradeprozess nicht über einen sofortigen Rollbackmechanismus verfügte, waren die Auswirkungen verheerend, da die Rücksetzung Tage dauerte.

In einer anderen Organisation hatten wir einen Kunden, der eine Unternehmensanwendung aktualisiert hatte und feststellte, dass daraufhin wirklich alle Benutzer ihre Browserversion aktualisieren mussten, um dann wiederum festzustellen, dass andere Unternehmensanwendungen, die bereits im Unternehmen verwendet wurden, die neuere Browserversion nicht unterstützten. Sie befanden sich zwischen dem sprichwörtlichen Hammer und Amboss. Letztendlich musste ein Rollback des Upgrades des Unternehmenssystems durchgeführt und gewartet werden, bis alle Unternehmensanwendungen das Upgrade auf die neue Browserversion durchführen konnten.

Manchmal ist es von Vorteil, nur den Anschein von Integration zu erwecken, statt tatsächlich integriert zu sein.

Verkaufsdemonstrationen lassen die Integration mehrerer Tools immer ganz einfach aussehen. Simsalabim – hier beginnen die Daten, und dort enden sie! Das Herstellen einer Verknüpfung zwischen hoch flexiblen Tools wie Project Server und anderen Unternehmenssystemen wie Buchhaltung/ERP ist schwer genug, und wir empfehlen immer, dass beide Systeme stabil und in Produktion laufen sollten, bevor irgendwelche Verknüpfungen eingerichtet werden. Wenn die Systeme einmal verknüpft sind, ist es um so wichtiger, alle Änderungen beider Systeme unter dem Aspekt zu überwachen, dass sichergestellt werden muss, dass sie weiterhin problemlos miteinander verknüpft bleiben.

Bei jedem Upgrade eines der Systeme kann es zu Änderungen an Daten, Strukturen oder technischen Voraussetzungen kommen. Es kann auch ein paar neue Features und mögliche Vorteile geben, aber Sie sollten sicherstellen, dass die bestehende Verknüpfungsfunktionalität in Ihrer Stagingumgebung getestet wird, bevor die Neuerungen in die Produktion eingeführt werden.

Dokumentieren, dokumentieren, dokumentieren

Die Personen, die dabei waren, als Project Server ausgewählt und bereitgestellt wurde, werden nicht ewig in diesen Rollen dabei sein. Tatsächlich werden Sie, wenn Sie einen guten Job gemacht haben, nicht mehr da sein, sondern die nächste Unternehmensbereitstellung managen, die die Organisation benötigt. Daher ist es essenziell, die Konfigurationsentscheidungen, den projektierten Nutzen, die Betriebserwartungen und die Parameter, die als Grundlage für diese Entscheidungen dienten, zu dokumentieren. In der Zukunft werden sich andere das System ansehen und fragen: "Was haben sie sich bloß dabei gedacht?" Stellen Sie sicher, dass sie es erfahren.

Unternehmenssystemdokumente sollten aktive Dokumente sein, die bei jedem Upgrade, jeder Änderung des geschäftlichen oder technischen Besitzers und bei allen größeren Veränderungen an der Betriebsstruktur oder den geschäftlichen Anforderungen aktualisiert werden.

Sehen Sie nach, bevor Sie springen

Diesen Rat geben wir Menschen, bevor sie zum ersten Mal in ein unbekanntes Gewässer springen. Ist es flach? Befinden sich Felsen unmittelbar unter der Oberfläche? EPM-Systeme wie Project Server können tatsächlich komplexe Datenelemente an eine Stelle bringen, wo sich auf diesen Daten basierende Entscheidungen effektiver treffen lassen, und der Nutzen solcher Entscheidungen kann einen wesentlichen Unterschied für eine Organisation ausmachen. Sie müssen aber zuerst Ihre Hausaufgaben machen, um sicherzustellen, dass Sie Ihr Unternehmenssystem so betreiben, dass Sie den benötigten Nutzen erzielen können, ohne dabei Ihre Organisation Kosten und Risiken auszusetzen, die den Mehrwert dieses Nutzens ganz schnell eliminieren.

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.

×