Gerhard Roland

IT Consulting Management

Erfahrungsberichte:

Personalplanung für ein neues Rechenzentrum der Postbank Data:

Mit Simulation zur neuen Personalstruktur

ExperPraxis 1998/99 - Unternehmenslogistik und Simulation



Personalplanung für ein neues Rechenzentrum der Postbank Data:

Viele Unternehmen untersuchen heute ihre Arbeitsabläufe ("Geschäftsprozesse"), um sie zu effektivieren und die Zusammenarbeit der Beteiligten optimal zu gestalten. Doch wie wird eine "optimale" Organisationsstruktur erreicht? Wie und an welchen Kriterien kann gemessen werden, ob mit der gewählten Struktur die Prozesse besser laufen als vorher - und das, bevor die neue Struktur mit großem Aufwand eingeführt wird? Bei der Personalplanung für ein neues Rechenzentrum der Postbank Data GmbH wurde zur Beantwortung dieser und ähnlicher Fragen das Simulationswerkzeug "AweSim!" eingesetzt.

Die Postbank Data GmbH ist verantwortlich für Planung, Strategie und Betrieb der Informationsverarbeitung der Postbank AG, die insgesamt 13.210 Mitarbeiterinnen und Mitarbeiter beschäftigt. Ab 2000 will die Postbank Data GmbH ihre über Deutschland verteilten Rechenzentren am Standort Bonn/Bad Godesberg in einem großen Rechenzentrum zentrieren. Eine prozeßorientierte Organisation dieses neuen Großrechenzentrums soll Synergieeffekte erzeugen und die Rüstzeiten und Laufzeiten reduzieren.
Zur Umsetzung dieses Vorhabens wurde die Projektgruppe "Organisation des zentralen Rechenzentrums" gebildet. Ihre Aufgabe ist es, die benötigten Personalkapazitäten für die unterschiedlichen Aufgaben des zukünftigen zentralen Rechenzentrums zu ermitteln. Um diese Organisationsplanung sowohl qualitativ als auch quantitativ auf eine solide Basis stellen zu können, entschied sich die Projektgruppe für den Einsatz moderner Simulationstechnik.
Simulation ermöglicht es, realitätsnah verschiedene Modelle im Rechner durchzuspielen und auf diese Weise völlig risikolos einen Blick in die Zukunft zu werfen. Bei der Planung einer neuen Organisationsstruktur wie bei der Postbank Data können mit Hilfe der Simulation Aussagen über die zukünftige Belastung einzelner Abteilungen getroffen und Konzepte für die Verteilung der Personalressourcen entwickelt werden.
Frontstep-Berater aus den Geschäftsbereichen "Unternehmensentwicklung" und "Unternehmenslogistik und Simulation" unterstützten die Postbank Data bei der Geschäftsprozeßanalyse, beim Aufbau und bei der Auswertung der Simulationsmodelle sowie bei der Erstellung der Stellenbeschreibungen. Als Werkzeug diente das von Frontstep vertriebene Simulationssystem "AweSim!" des amerikanischen Herstellers Pritsker.


Von der Aufgabe zum dokumentierten Geschäftsprozeß


Während der Analysephase wurde zunächst ermittelt, welche Aufgaben im Rechenzentrum wie häufig anfallen und von wem sie zu bearbeiten sind. Die analysierten Daten wurden in Form von Ablaufdiagrammen, sog. Prozessen, und Tabellen dargestellt. Basis für die Definition und Abgrenzung der Prozesse waren vorliegende Dokumente sowie von der Projektgruppe aufgestellte Kriterien wie auslösendes Ereignis, Ergebnis, Ort der Leistungserbringung, durchzuführende Funktionen und Beteiligte.
Insgesamt wurden 28 Prozesse beschrieben. Einige davon sind sowohl als selbständige Prozesse als auch als Unterprozesse definiert. So ist z.B. der Prozeß 17 "Dokumentation" auch ein Unterprozeß des Prozesses 27 "Planen: Anforderungen feststellen".


Bild 1
Ablaufdiagramm des Prozesses 27


Als Unterprozeß beansprucht ein Prozeß in der Regel weniger Zeit. Für jeden Unterprozeß wurde deshalb ein Skalierungs­faktor ermittelt, der seine normale Laufzeit (als selbständiger Prozeß) modifiziert und ihn auf diese Weise in die richtige Relation zum aufrufenden Prozeß bringt.


Bild 2
Auschnitt aus der Skalierungsmatrix


Die zum Prozeß "Planen: Anforderungen bereitstellen" gehörige Tabelle enthält Informationen über benötigte Ressourcen, Rüstzeiten und Durchlaufzeiten.


Bild 3
Prozeßtabelle des Prozesses 27


Im Laufe der Analysephase wurden einige wichtige Festlegungen getroffen:
  • Es wird von einem Zwei-Schicht-Betrieb ausgegangen, wobei jede Schicht acht Stunden arbeitet.
  • Eine Woche umfaßt fünf Arbeitstage.
  • Das sogenannte "Vieraugenprinzip", das bei einigen Aktivitäten Bedingung, ist, erfährt durch die Konzentration geringere Bedeutung, da ohnehin in jeder Schicht immer mehr als zwei Mitarbeiter anwesend sind. Aus simulationstechnischen Gründen wurde der Aufwand für das Vieraugenprinzip in den Bearbeitungszeiten von vornherein berücksichtigt.
  • Rüstzeiten werden ignoriert.

Simulationsmodelle mit "Knoten" und "Kanten"


Im Anschluß an die Analysephase wurden die ermittelten Prozesse mit Hilfe des Simulationswerkzeugs "AweSim!" für die Simulation modelliert. Für jeden Prozeß wurde ein sogenanntes Netzwerk geschaffen, in dem mit Hilfe von "Knoten" und "Kanten" der Ablauf des Prozesses - wie in der Prozeßbeschreibung definiert - beschrieben wurde. "Knoten", durch Kästchen symbolisiert, beschreiben die Teilaufgaben (Vorgänge und Ereignisse) eines Prozesses; hier werden z. B. Warteschlangen gebildet oder Ressourcen zugeordnet. Die "Kanten", durch Pfeile symbolisiert, zeigen Ende und Beginn von Teilaufgaben an und stellen die Zeitverzögerung zwischen zwei Aufgaben dar. Die Daten des Prozesses, d. h. Informationen über organisatorische Einheiten und Bearbeitungszeiten, wurden als Parameter der Kanten und Knoten eingearbeitet.


Bild 4
AweSim-Netzwerk des Simulationsprozesses 27.1


Bei der Modellierung der Prozesse wurde zunächst ein Startknoten an den Anfang jedes Netzwerkes gesetzt. Dieser Startknoten löst zum Simulationszeitpunkt 0 und anschließend in regelmäßigen Abständen einen Durchlauf des betreffenden Prozesses aus. Die Prozeßaufrufe werden dadurch gleichmäßig über den Simulationszeitraum verteilt. Der Zeitraum zwischen zwei Prozeßaufrufen wurde auf der Basis der Häufigkeitsangabe des Prozesses berechnet. Ein Beispiel:
  • Der Prozeß 27 findet 20mal im Jahr statt.
  • Ein Arbeitsjahr besteht aus 52 Wochen 5 Tagen.
  • Jeder Arbeitstag umfaßt zwei 8-Stunden-Schichten.

Ein Jahr hat 52*5*2*8*60 = 249.600 Minuten, der Prozeß 27 wird demnach durchschnittlich alle 249.600/20 = 12.480 Minuten angestoßen.


Jeder Prozeß erhält eine eindeutige Identifizierung (ID), die sich aus der aktuellen Simulationszeit und der Prozeßnummer ergibt. Für den Fall, daß ein Prozeß in mehreren Varianten auftritt, wird eine Variantennummer angefügt.
Für die Teilaufgaben der Prozesse müssen die Bearbeitungsdauer ("BZeit") und eine Einsprungadresse ("Einsprung") angegeben werden. Die Einsprungadresse wird benötigt, weil die Ressourcen, die die organisatorischen Einheiten repräsentieren, in einem gesonderten Netzwerk mit der Bezeichnung "RESOURCE" modelliert werden. In dieses Netzwerk wird für die Belegung der organisatorischen Einheit verzweigt, nach Ablauf der Bearbeitungsdauer wird an die durch die Einsprungadresse gekennzeichnete Stelle im Prozeßnetzwerk zurückgekehrt.
Soll ein Unterprozeß (im Beispiel Prozeß 17) aufgerufen werden, entfällt die Angabe der Bearbeitungsdauer. Hier wird der definierte Skalierungsfaktor ("Faktor") übernommen. Skalierungsfaktoren unter 1% wurden bei der Modellierung nicht berücksichtigt. In solchen Fällen wird der Unterprozeßaufruf durch das Einfügen der in der Prozeßtabelle beschriebenen Aktivität ersetzt.
Wurden alle Teilaufgaben im Netzwerk modelliert, schließt ein Knoten zur Ermittlung der Durchlaufzeit - momentane Simulationszeit minus Startzeit des Prozesses - die Beschreibung ab.


Simulation


Um sich an das Ziel der Projektgruppe - Schaffung einer "optimalen" Personalstruktur für das zentrale Rechenzentrum - heranzutasten, wurde ein mehrstufiger Experimentierplan aufgestellt.
Zunächst waren geeignete Kenngrößen des Simulationsmodells zu bestimmen, die sowohl zur Modellvalidierung als auch zur Bestimmung der Personalstruktur dienen sollten. Für die "optimale Personalstruktur" wurden folgende Kriterien festgelegt:
  • Die Durchlaufzeiten der Prozesse werden durch die begrenzt verfügbare Kapazität des eingesetzten Personals nicht erheblich vergrößert.
  • Als Indikator hierfür dienen die Warteschlangen vor den Ressourcen (Personalkapazität), die einen stationären Verlauf (d. h. Auf- und Abbau von wartenden Prozessen gleichen sich aus) in angemessener Höhe ausweisen sollen.
  • Die Auslastungen der Ressourcen sollen anhand der Mittelwerte bestimmt werden.
Als Kenngrößen des Simulationsmodells waren also die Durchlaufzeiten der Prozesse, die Warteschlangen und die Auslastung der Ressourcen auszuwerten. Neben der Beschreibung durch statistische Maßzahlen - Mittelwert, Standardabweichung, Minimum und Maximum - sind hierzu auch grafische Darstellungen sinnvoll, die die Entwicklung dieser Kenngrößen im Zeitablauf visualisieren. So wird deutlich, ob es sich um stationäre Ergebnisse handelt, d. h. ob die Simulationsergebnisse unabhängig von der Simulationszeit sind, weil Warteschlangen über den Simulationszeitraum ausgeglichen werden.
Reale Spitzen, wie z. B. die Morgenstunden, wurden nicht modelliert. Es konnte die Annahme getroffen werden, daß sich alle Prozesse auf den Simulationszeitraum entsprechend ihrer Häufigkeit gleichverteilen.
Nun wurden verschiedene Szenarien mit einer Simulationszeit von jeweils 100 Tagen durchgespielt. Zunächst wurden zwei (organisatorisch leicht voneinander abweichende) Szenarien mit unbegrenzter Kapazität gefahren. Schon das erste Szenario zeigte, daß das Modell valide ist: Die Prozeßdurchlaufzeiten sind nach Einschätzung der Postbank Data plausibel, das Simulationsmodell bildet den untersuchten Bereich hinreichend gut ab, die Ergebnisse sind daher auf die Realität übertragbar.
Folgende Tabelle stellt den mittleren Ressourcenbedarf für die ersten beiden Szenarien dar. Diese Mittelwerte konnten als Richtwerte für weitere Szenarien verwendet werden.


Bild 5
Kapazitäten in verschiedenen Szenarien


In den nächsten beiden Szenarien wurden die Kapazitäten auf die mittlere Auslastung der ersten Szenarien beschränkt. Auf diese Weise wurde untersucht, ob eine Personalstruktur, die sich an diesen mittleren Bedarfsgrößen orientiert, für den Betrieb des Rechenzentrums ausreicht, ob also keine inakzeptablen Warteschlangen auftreten. Das Ergebnis: Die mittleren Kapazitäten waren zwar generell vernünftig gewählt, doch in Einzelfällen kam es zu inakzeptabel hohen Wartezeiten. Im fünften Szenario wurden daher die Kapazitäten derart erhöht, daß sich keine großen Warteschlangen bildeten und alle Kennzahlen stationär blieben.
Das Resultat des 5. Szenarios ist zufriedenstellend. Alle Indikatoren (mittlere Warteschlangenlänge, mittlere Wartezeit) deuten auf eine fast eliminierte Warteschlange hin.
Die Kapazitäten des 5. Szenarios werden daher für eine Festlegung der Personalstruktur herangezogen.
Für den Aufbau des Rechenzentrums kann es sinnvoll sein, Prozesse zu gruppieren, um zu Abteilungsstrukturen zu gelangen. Deshalb wurde im sechsten Szenario eine andere Sichtweise eingenommen und der Ressourcenbedarf je Prozeß ermittelt.


Bild 6
Auszug aus Aufteilung der Ressourcen auf die Prozesse


Die Tabelle kann nur als Richtwert interpretiert werden, da es sich um Mittelwerte mit unbegrenzter Kapazität handelt. Der Ressourcenbedarf wird nur für selbständig gestartete Prozesse erfaßt. Deshalb hat Prozeß 28 keinen Bedarf. Dieser Bedarf wird den aufrufenden Prozessen zugeschlagen.


Umsetzung und Ausblick


Aus den sechs Simulationsszenarien wurde eine Empfehlung für die Personalausstattung abgeleitet. Die Postbank Data GmbH hat die Organisationseinheiten inzwischen entsprechend definiert, auch Funktionsbeschreibungen wurden bereits ausgearbeitet. Die interne Ausschreibung für das neue Rechenzentrum ist ebenfalls bereits erfolgt.
Das bei Postbank Data durchgeführte Projekt zeigt einmal mehr, wie vielseitig Simulation heute genutzt werden kann. Überall dort, wo komplexe, schwer überschaubare Systeme geplant werden müssen, wo Planungsfehler gravierende Auswirkungen haben können, bietet sich die Simulationstechnik als risikomindernde, zuverlässige Planungshilfe an.


Gerhard Roland, Postbank Data GmbH, Bonn
Gila Brandt-Herrmann, Dr.-Ing. Bodo Fritsche, Frontstep GmbH, Dortmund
Petra Buitmann-Dall, Dr. Thorsten Claus, Prof. Dr. Thomas Witte, Universität Osnabrück