Wie man 1.700 Clients erneuert

Nach jeweils vier bis sechs Jahren Dienstzeit waren Desktops und Laptops in der Zentralverwaltung der MPG am Ende des Lebenszyklus angekommen. Garantie und Wartung liefen aus. Zudem waren die neuen Software-Releases auf der alten Hardware nicht mehr lauffähig. Auch ließen sich die Sicherheitsanforderungen kaum noch erfüllen. Mit einem Satz: Der Betrieb der alten Geräte war - wenn überhaupt möglich - auf jeden Fall unwirtschaftlich.

Es war also ein Rundumerneuerung fälllig: "Wenn wir schon neue Rechner brauchen, dann wollen wir auch das Betriebssystem und die Arbeitsumgebung redesignen", begründet Projektleiter Otfried Köllhofer das Vorgehen.

Ist-Stand war Windows XP und Office 2003; also seinerzeit schon Systeme, die bereits aus dem Standard-Support gefallen waren. Das nächstfolgende Release, Windows Vista, wurde ausgelassen, wie von vielen anderen Unternehmen auch. Auf Windows 8, das sich damals erst am Horizont abzeichnete, wollte die MPG allerdings auch nicht warten: Sie führte das bereits erprobte 7 mit dem Anwendungspaket Office 2010 ein.

Auf jedem Client laufen rund 50 Standardprogramme und Konfigurationspakete. Die wurden automatisch mit dem Tool "Enteo" installiert. Auf Antrag stehen weitere 40 Programme zur automatischen Installation bereit. Und noch einmal genauso viele, die nicht automatisch installiert werden, mussten Window7-tauglich gemacht werden, dazu zählen beispielsweise spezielle Treiber für Scanner und Drucker.

Was erreicht werden sollte

Ziel des Projekts war unter anderem eine höhere Systemstabilität durch getrennte Bearbeitung von Prozessen. Darüber hinaus sollte die Leistung verbessert werden, was unter anderem durch eine parallele Nutzung von CPU und Speicherressourcen sowie durch ein Redesign der Dateiordner und den dadurch erleichterten Dateizugriff via VPN erreichbar erschien. Last, but not least wurden die Notebooks durch Verschlüsselung mit "Safeguard Lancrypt" von Sophos erheblich besser gegen Datenklau abgesichert.

Erweitert haben Köllhofer und sein Team auch die Anpassbarkeit der Client-Installation. Selbstverständlich gibt es immer Features, die der Anwender nicht verändern darf. Dazu zählen beispielsweise Sicherheitseinstellungen. Aber dort, wo es keine Rolle spielt, beispielsweise bei der Farbwahl, der Anordnung der Icons oder der Startseite sollten die User schon ein paar Möglichkeiten zur Personalisierung haben. "Jeder bekommt eine Konfiguration, mit der man arbeiten kann", stellt Köllhofer klar. Und wer daran nichts verändern wolle, der müsse es auch nicht. Auf der anderen Seite bekomme aber auch kein Anwender irgendwelche Administrationsrechte oder die Erlaubnis, eigene Software zu installieren.

Allerdings will es die Gesellschaft auch noch nicht übertreiben mit der Individualität. Bring your own Device (ByoD) ist für den Abteilungsleiter Informations- und Kommunikationstechnologie (IKT), Harald Suckfüll, derzeit noch kein Thema - "auch wenn man spürt, dass es bald auch bei uns vor der Tür stehen wird." Aber das derzeit noch dringendere Thema seien die Telearbeitsplätze. Sie hatten in dem Projekt einen Sonderstatus: Die Technik zur Dateisynchronisierung wurde erneuert und das Treibermodell erweitert, damit sich beispielsweise private Drucker leichter anbinden lassen.

In der Praxis laufen Projekte immer ein wenig anders, als sie in der Theorie geplant haben. Rückblickend haben Suckfüll und Köllhofer Vieles richtig gemacht. Aber sie haben auch Erkenntnisse darüber gewonnen, was sie beim nächsten Mal anders machen würden. Ihre Erfahrungen lassen sich in zehn Punkten zusammenfassen.

Die Lehren aus dem Projekt

1. Was viel Zeit kostet:

Für Projektplanung, Softwarepaketierung, Feintuning der Clients, eine intensive Testphase und sorgfältige Qualitätskontrolle wurde ein knappes Jahr veranschlagt. Das erwies sich im Nachhinein immer noch als zu wenig. Auch auf das Testing wurde viel Zeit verwandt, obwohl das den Zeitplan durcheinander brachte.

2. Die Anwender ins Boot holen:

Auf Workshops in den einzelnen Instituten durften die User ihre Wünsche und Anregungen geben. Das sei in den Fachbereichen sehr gut angekommen, so Köllhofer. Einige der Ergebnisse: Die User wollten auch offline arbeiten können, sie fühlten sich von der Konfiguration eingeschränkt, und sie bemängelten das lahme Tempo von Office.

3. Pilotphase ernst nehmen:

Ab Mai 2011 bildeten fünf Institute und zwei Abteilungen der Generalverwaltung die Vorhut für den flächendendeckenden Rollout des neuen Client. Unterstützt wurde die MPG dabei von den externen Dienstleistern Datagroup und Hewlett-Packard Education Services. Die Installation übernahm die Datagroup, die vorher schon für den Helpdesk verantwortlich gezeichnet hatte, und das laut Rahmenvertrag auch in den kommenden zwei Jahren tun dürfte.

Ein Pilot ist wie eine Generalprobe: Wenn alles läuft, wie geschmiert, hakt es oft bei der Aufführung vor dem ganz großen Publikum. In diesem Fall traten jedoch schon beim Praxistest einige Fehler auf, die vor dem Rollout in der Breite tatsächlich beseitigt wurden. Da bereits der Pilot verspätet gestartet war (im Mai statt im Januar), schob sich das Projekt dadurch noch mehr in Richtung Jahresende.

4. Allzu straffe Zeitplanung:

Dass sich Teams erst mühsam aufeinander einspielen müssen, wird bei den meisten Projekten übersehen. Auch in diesem Fall musste die zeitliche Planung im Projektverlauf angepasst werden. Eigentlich hatte der Rollout schon im September 2011 abgeschlossen sein sollen. De facto dauerte es zwei Monate änger. Pro Woche wurden zwei bis drei Institute umgestellt. Demnächst wollen die Verantwortlichen mehr Reserven in den Zeitplan einbauen.

5. Technische Evaluierung schwierig:

Leider sind Softwareprogramme nicht immer so kompatibel miteinander und mit dem Betriebssystem, wie die Anbieter es versprechen. Das fiel vor allem bei der Verschlüsselungssoftware von Sophos (vormals Utimaco) ins Gewicht, die laut Köllhofer zunächst "etwas hakelig" daherkam. Auch die Anwendungssoftware sei teilweise noch nicht auf Windows 7 vorbereitet gewesen. Einige technische Probleme machten sich erst beim Rollout bemerkbar.

6. Begleitende Schulung hilfreich:

Zum ersten Mal unterstützte die MPG den Rollout durch eine umfangreiche Schulung der Anwender. "Manche Anwender tun sich ja schwer mit so einem Umstieg", weiß Köllhofer. Für die Einweisung übernahm HP die Verantwortung. Der Dienstleiter rückte mit mobilen Schulungsräumen an, wo die Mitarbeiter in das System eingewiesen wurden, während gleichzeitig ihre Arbeitsplätze neu installiert wurden.Die Schulungen dauerten etwa sechs Stunden. Sobald die User an ihren Arbeitsplatz zurückkehrten, konnten sie das Gelernte anwenden, denn in der Zwischenzeit war ihr Rechner eingerichtet. Beim nächsten Mal, so Köllhofer würde er die Schulung zeitlich etwas straffen, damit danach bis zum Ende des Arbeitstags noch genug Zeit für erste Erfahrungen und gegebenenfalls Rückfragen an die Schulungsleiter bliebe.

7. Zuviel Mitspracherecht und Flexibilität:

Die Planung der Rollout- und Schulungstermine lief nicht optimal, weil die Anwender ihre Terminbuchungen nicht immer einhielten. So wurde die beabsichtigte Parallelität von Installation und Schulung teilweise ausgehebelt. Darüber hinaus versäumten es einige User mit Sonderkonfigurationen oder speziellen Softwareanwendungen, ihre Anforderungen vorab zu melden, was zu Mehraufwand beim Rollout führte.

8. Jede Installation begleiten:

Die MPG schickte den Dienstleister nicht allein zu den Anwendern. Vielmehr gehörte zu jedem Team auch ein eigener IT-Mitarbeiter, der nicht direkt mit dem Rollout beschäftigt war, sondern für erste Fragen zur Verfügung stand und so dafür sorgte, dass die Tekkies "in Ruhe installieren konnten", wie Köllhofer augenzwinkernd sagt. Willkommener Nebeneffekt: Der MPG-Mitarbeiter konnte etwaige Problem direkt aufnehmen und rückmelden: "Die Beschwerden werden ja sonst beim Dienstleister abgeladen und kommen hier unter Umständen gar nicht oder schon verfälscht an", erläutert Suckfüll.

9. Feedback hochwillkommen:

Für Verbesserungsvorschläge und Anregungen hatte das AP2010-Team eine eigene E-Mail-Adresse eingerichtet, die nach Projektschluss noch fünf Monate verfügbar blieb.

10. Beim nächsten Mal wird Vieles besser:

Das Team würde beim nächsten Mal früher eine Configuration Management Database (CMDB) nutzen. Insgesamt müsse noch mehr Zeit für Paketierung, Vorplanung und Pilot eingerechnet werden, damit auch wirklich alle Pakete und die notwendigen Mitarbeiter zum Zeitpunkt X bereitstehen, so die Selbstkritik. Diesmal konnten nicht alle Anforderung vor dem Rollout umgesetzt werden, so beispielsweise die Plattenverschlüsselung, die aus dem Projekt rausgelöst wurde und separat umgesetzt wird. Wie Köllhofer und Suckfüll einräumen, gab es dieses Mal noch einige Reibungsverluste. Die sollen beim Projekt "AP 2014" vermieden werden, das im kommenden Jahr an den Start geht. (Computerwoche)