In diesem Leitfaden wird erläutert, wie der USM Designer bei einer USM-Implementierung im Rahmen eines Bottom-up-Vorgehens angewendet wird.
Im 7-stufigen Modell der Umsetzung ist Schritt 1 bereits abgeschlossen: USM wurde als Zielsetzung ausgewählt. Für Schritt 2 – das Einarbeiten in die USM-Konzepte – hat die Organisation Schulungen durchgeführt, einen Einführungsworkshop abgehalten und/oder Menschen dazu angeregt, sich mit dem USM-Buch, dem Portal oder dem Wiki auseinanderzusetzen. Schritt 3 führte zur Festlegung des Umfangs für die Bottom-up-Implementierung durch ein einzelnes Team. Im anschließenden Schritt 4 definieren wir dann den Service im Servicemodell des USM Designers.
Das gängigste Vorgehen für USM ist das Bottom-up-Vorgehen. Das bedeutet, dass ein einzelnes Team innerhalb des Unternehmens die Umsetzung von USM beginnt. Bei diesem Vorgehen wird die Umsetzung innerhalb dieses einen Teams als Pilotprojekt oder Proof-of-Concept (PoC) für die breitere Umsetzung von USM im gesamten Unternehmen betrachtet. Die Herausforderung besteht dann darin, USM tatsächlich auf mehrere Teams und letztendlich auf das gesamte Unternehmen anzuwenden.
Wenn Sie auf Teamebene beginnen, beschränkt sich die Organisation, mit der Sie es zu tun haben, auf dieses eine Team. Grundsätzlich verfügt dieses Team über einen einzigen zusammengesetzten Service, der aus einer Reihe von Facilities mit zugehörigen Supportfunktionen besteht, die im Umfang dieses Teams existieren. Dieser zusammengesetzte Service ist imServicekatalog und im Anfragekatalog spezifiziert. Das Team besteht aus einer Reihe von Profilen, die mit einzelnen Personen verknüpft werden können. Das Team kann auch aus einer Reihe von Unterteams bestehen.
Wenn Sie ein Bottom-up-Projekt auf diese Weise starten, verknüpfen Sie Einrichtungen, Support-Services, Profile, Arbeitsmethoden und alle anderen zugehörigen Elemente mit diesem einen teamspezifischen Service. Sobald Sie ein zweites Team in den Geltungsbereich der USM-Anwendung einbeziehen, stoßen Sie an die Grenze, dass diese Elemente mit diesem einen Service und nicht mit dem Unternehmen verknüpft sind. Die Anpassung des USM Designers während dieses Skalierungsprozesses kann dann einen erheblichen Aufwand erfordern. Aus diesem Grund ist es bei der Implementierung von USM immer besser, zunächst das Unternehmen in Form des unternehmens-weiten Organisationsbaums und des unternehmens-weiten Servicebaums zu definieren – auch wenn Sie diese nicht sofort anwenden. Darüber hinaus ebnet dies den Weg für Diskussionen über die breitere Anwendung von USM. Dies wirft jedoch sofort die Frage auf: Was fällt unter den Organisationsbaum und was unter den Servicebaum?
In den unternehmensweiten Organisationsbaum nehmen Sie alle Teams auf, von denen erwartet werden kann, dass sie im Rahmen einer unternehmensweiten USM-Implementierung als identifizierbare Serviceprovider agieren. Als identifizierbarer Serviceprovider zu agieren bedeutet, dass das betreffende Team zu einem bestimmten Zeitpunkt eine Servicevereinbarung mit seinen Kunden abschließen wird. Zunächst stellen Sie das Unternehmen also als hierarchische Team-„Struktur“ dar, mit Komponenten, die als einzelne Serviceprovider fungieren (oder fungieren werden) – was wir oft als funktionales Modell bezeichnen. Ob dies später tatsächlich für jedes dieser Teams implementiert wird, spielt in dieser Phase keine Rolle. Eines der Teams, die Sie in dieser Struktur definieren, ist das Team, das als erstes mit der Implementierung des USM beginnen wird. Betrachten wir hierfür einmal kurz „das IT-Team“.
Jede Organisation verfügt, grob gesagt, über dieselben sekundären Aufgabendomänen und die entsprechenden Funktionen oder Teams. Ein gängiges Akronym hierfür ist SCHOPAFILTH: 10 Funktionsbereiche (Positionen oder Teams) mit den dazugehörigen 10 übergeordneten Abteilungen: Sicherheit, Kommunikation, Organisation, Personal, Verwaltungsorganisation, Finanzen, Information, Recht, Technologie und Immobilien.
Jede dieser 10 Abteilungen lässt sich mithilfe eines zusammengesetzten SMC als eine Reihe von Services mit der entsprechenden Unterstützung für Kunden strukturieren.
In der Praxis werden diese 10 Funktionen oft in einer Hierarchie zusammengefasst. So hat beispielsweise das Finanzteam häufig IT und Beschaffung als Unterteams, und das Facility-Team hat oft Facility-Management, Personalwesen und den Rest der Technik als Unterteams. Manchmal ist es auch umgekehrt.
Die „geschäftliche“ Seite des Unternehmens umfasst die primären Aufgabendomänen. Diese primären Funktionsbereiche lassen sich nach verschiedenen Schemata auf unterschiedliche Weise klassifizieren. Die Standard-Wirtschaftsklassifikation (SBI) des niederländischen Statistikamtes (CBS) und der Handelskammer (KVK) umfasst fünf Stufen: Sektion → Abteilung → Gruppe → Klasse → Unterklasse. Darüber hinaus gibt es die NACE, das europäische Pendant zur SBI, sowie die COFOG (Klassifizierung der Funktionen des Staates), die für staatliche Behörden von besonderem Interesse ist.
Die SBI unterscheidet 23 Abschnitte, die von [1] Landwirtschaft, Forstwirtschaft und Fischerei, [2] Bergbau und Gewinnung von Steinen und Erden sowie [3] Verarbeitendes Gewerbe bis hin zu [22] Haushalte als Arbeitgeber und [23] Extraterritoriale Organisationen und Einrichtungen.
Die COFOG anwendet [1] allgemeine öffentliche Services, [2] Verteidigung, [3] öffentliche Ordnung und Schutz, [4] Wirtschaft; [5] Umweltschutz, [6] Wohnungswesen und kommunale Einrichtungen, [7] Gesundheit, [8] Freizeit, Kultur und Religion, [9] Bildung sowie [10] Sozialschutz.
Innerhalb eines bestimmten öffentlichen Sektors gibt es in der Regel einModell, das einschliesslich der für diesen Sektor typischen Funktionen ist. Die Anzahl dieser primären Aufgabenbereiche (Funktionen) reicht von 15 bis 25.
Im Durchschnitt verfügt ein Unternehmen über 25 bis 35 Rollen (Teams/Organisationsstrukturen). Diese Rollen geben Sie zunächst einmalig im USM Designer ein; anschließend müssen Sie das Team nur noch nach dem Bottom-up-Vorgehen entwickeln. So bereiten Sie sich auf zukünftige Erweiterungen vor und können den relevanten Rollen für grenzüberschreitende Workflows sofort Actions zuweisen. Für letztere definieren Sie dann einen Single Point of Contact für diese externe Rolle. Im Durchschnitt verfügt ein Unternehmen über 25 bis 35 Rollen (Teams/Organisationsstrukturen). Sie geben diese Rollen zunächst einmalig im USM Designer ein; anschließend müssen Sie das Team nur noch nach dem Bottom-up-Vorgehen entwickeln. Damit bereiten Sie sich auf jede zukünftige Erweiterung vor und können den relevanten Rollen für grenzüberschreitende Workflows sofort Actions zuweisen. Für letztere definieren Sie dann einen Single Point of Contact für diese externe Rolle.