Was ist ein Serviceportfolio?

Ein Serviceportfolio ist eine Sammlung aller Dienstleistungen, die ein Unternehmen seinen Kunden anbietet. Es umfasst sowohl die Kernleistungen, die das Unternehmensprodukt oder die Dienstleistung selbst definieren, als auch ergänzende Dienstleistungen, die den Wert des Angebots erhöhen und die Kundenbindung stärken.

Portfolio vs. Katalog

Orientiert man sich an der Definition des Service Portfolio am weit verbreiteten ITIL Framework, besteht ein Serviceportfolio aus drei Bestandteilen:

• Service Katalog - das aktuelle Angebot von Services
• Service Pipeline - das zukünftige Angebot von Services
• Service Retreat/Graveyard (“retired Services” gemäss ITIL) - das historische Angebot von Services

Das Portfolio soll damit ein ganzheitliches Bild der Leistungen einer Organisation auf thematischer, operationeller und zeitlicher Ebene darstellen.

Theoretische Grundlagen

Wie so oft bei Rahmenwerken in der IT (ITIL, SAFe etc.) gibt es auch beim Serviceportfolio kein eindeutiges richtiges oder falsches Vorgehen. Es sind immer die Organisation und ihre Mitarbeitenden, welche die theoretischen Grundlagen mit dem gelebten Vorgehen kombinieren müssen, um die Details zu definieren.

Bei der Arbeit mit unseren Kunden sind wir jedoch in der Lage, aus verschiedenen Quellen unterschiedliche Herangehensweisen und Umsetzungen zu sehen und erleben. Daraus geben sich verschiedene “Good-Practices”, welche sich aus unserer Sicht durchgesetzt haben.

Hierarchie von Services und Assets

Bei der Definition der Services einer Organisation stellt sich meist schnell heraus, dass es Services auf verschiedenen Ebenen gibt. Beispielsweise lassen sich verschiedene Services kombinieren, um eine übergeordnete Verantwortlichkeit realisieren zu können.

Insofern sollte beim Design des Serviceportfolios berücksichtigt werden, dass Services in einer hierarchischen Verbindung zueinander stehen können. Beispielsweise um die Kombination von Services für die Realiserung eines übergeordneten Services darzustellen.

Im Rahmen eines Serviceportfolio sollte die Definition und Verknüpfung von Services ebenso betrachtet werden, wie die Differenzierung und Einbeziehung von solchen Assets, welche die jeweiligen Services ausmachen.

Gemäss ITIL definiert sich ein Service als:

“Eine Möglichkeit, einen Mehrwert für Kunden zu erbringen, indem das Erreichen der von den Kunden angestrebten Ergebnisse erleichtert oder gefördert wird. …” (Axelos ITIL Glossary)

Aus unserer Sicht ist es jedoch ein essentieller Schritt für die Entwickliung eines Serviceportfolios ein gemeinsames Verständnis des Bergiffes “Service” im Kontext der Organisation zu entwickeln.

Am Beispiel der Atlassian Applikationen könnte “Atlassian” als Service definiert werden, welcher sich aus den Applikationen “Jira” und “Confluence” zusammensetzt. Auf gleicher Ebene werden auch die Microsoft Anwendungen unter einem entsprechenden Service gebündelt. Beide könnten dem Service “Collaboration” untergeordnet sein.

Die Bezeichnung von Services nach Herstellern oder einzelnen Produkten wird oftmals vermieden, um den konzeptionellen Aufbau eines Serviceportfolios herstellerunabhängig zu gestallten. Dies kann aber auch für Unklarheiten auf Seiten von Nutzern sorgen, welche mit generischen Begriffen keine konkreten Leistungen assoziieren. Auch hier gilt es also, die aktuellen Gegebenheiten und organisatorischen Eigenheiten zur berücksichtigen.

Eine Hierachie darf unbalanciert

Aus der Verknüpfung von Services und untergeordneten Assets ergibt sich somit eine Hierarchie in einer Art Baumstruktur.  Aus praktischer Erfahrung muss dieser Aufbau nicht ausbalanciert sein. Soll heissen, die Elemente unterhalb eines möglichen Services könnten drei Zwischenebenen haben, während ein anderer aber über vier Zwischenebenen verfügt.

Diese potenzielle Disbalance ermöglicht die flexible Abbildung von komplexeren Strukturen und Abhängigkeiten, die sich aus Schnittstellen oder organisatorischen Verantwortlichkeiten ergeben. Auch bei zukünftigen Änderungen lassen sich nach Bedarf neue Zwischenebenen einschieben ohne den gesamten Portfolioaufbau neu entwickeln zu müssen.

Entsprechend lassen sich nicht nur Abhängigkeiten darstellen, sondern auch Verantwortlichkeiten klarer dokumentieren und kommunizieren.

Verknüpfungen zu anderen Configuration Items bieten zusätzliche Möglichkeiten

Neben den Verknüpfungen zwischen Services und Assets bietet sich während des Aufbaus eines Serviceportfolios und der Definition von Services auch die Möglichkeit, die Verknüpfungen zu anderen Configuration Items (CIs) oder Assets einzubinden.

Die Verknüpfung zu physischer Hardware (Server, Laptops, Scanner, etc.), Lizenzen oder Organisationseinheiten ermöglicht es, ein umfangreiches Netz abzubilden.  Damit lassen sich Abhängigkeiten nicht nur zwischen Services oder Applikationen darstellen, sondern auch auf konkrete Hardware oder sonstige Komponenten verfolgen die für die Erbringung von Services notwendig sind.

(Jira) Assets als Grundlage

Ursprünglich als eigenständige App “Insight” der Firma Mindville entwickelt, kaufte im November 2020 Atlassian den Hersteller auf und integrierte fortan die App in das bestehende Produkt Jira Service Management. Heute ist die App unter dem Namen “Jira Assets” voll in Jira Service Management (JSM) integriert. Für JSM Data Center sowie JSM Cloud Premium Lizenzen ist Assets bereits vollständig inkludiert.

Während einige Lösungen sich hauptsächlich auf CIs oder Assets konzentrieren (und damit beispielsweise User oder Organisationseinheiten ausschliessen), bietet Jira Assets die Möglichkeit, Objekte frei zu definieren. Es gibt auf technischer Ebene also keine Unterscheidung zwischen Services, Assets oder CIs.

Jira Assets bietet eine Plattform für die Definition von Objekten. Die Ausgestaltung zur Nutzung und Verwendung dieser Objekte obliegt allein dem Nutzer. Daraus ergeben sich zwar auch die Aufwände zur Definition und Erstellung, aber eben auch grosse Freiheiten und die Möglichkeiten zur weitreichenden Verknüpfung von Elementen, die traditionell nicht im gleichen System vorhanden sind.

Umsetzung in Jira Assets

Jira Assets baut sich aus drei wesentlichen Bausteinen auf.

• Objektschema stellen einen Container, eine Sammlung dar. Ähnlich zu Vorgängen in Jira Projekten müssen alle Objekte einem Objektschema zugeordnet sein.
• Innerhalb eines Objektschemas können beliebig viele Objekttypen definiert werden.
• Ein Objektyp zeichnet sich in erster Linie durch die definierten Attribute aus, welche die Detailinformationen eines Objektes aufnehmen. Neben Text- und Listenattributen gibt es ausserdem die Möglichkeit, Verknüpfungen zu anderen Objekten als Attribut zu definieren.

Im konkreten Beispiel könnten Services und Applikationen als eigene Objekttypen im gleichen Objektschema definiert werden. Auf den Service-Objekten gibt es dann jeweils Verknüpfungen zu übergeordneten und abhängigen Services. Auf dem Applikationsobjekt gibt es wiederum eine Verknüpfung zum übergeordneten Service sowie zu anderen abhängigen oder verbundenen Applikationen. (vgl. Grafik oben)

Da (analog zu Jira) Verknüpfungen in Assets immer bidirektional sind, lassen sich über definierte Verknüpfungen ein entsprechendes Baumdiagramm zeichnen sowie über Abfragen Listen erstellen. Effektiv kann Assets damit einen erhablichen Beitrag zur Überlichkeit und Transparenz leisten.

Verknüpfung mit anderen Prozessen

Der meiste Wert eines Serviceportfolios in Jira Assets ergibt sich jedoch aus der Nutzung der verfügbaren Objekte in anderen Prozessen (oder Disziplinen, gemäss ITIL 4):

• So kann im Rahmen des Change Enablements ein Change automatisch dem Service Owner zur Freigabe zugewiesen werden, wenn dieser als Attribut auf dem Service gepflegt wird und dieser Service bei der Erstellung von Changes auf einer Maske in Jira zur Auswahl steht.
• Incidents können vollautomatisch der richtigen Support-Organisation zugewiesen werden, nachdem auf der Nutzeroberfläche die betroffene Applikation gewählt wurde. Im Hintergrund erfolgt die Auflösung der Verknüpfungen von Applikation, über Service zum Support Team und gegebenenfalls bis zur Einzelperson.
• Neben der Auswahl von Applikationen im Testmanagement oder im Bereich der Entwicklung, ergibt sich ein besonders umfangreicher Use-Case im Rahmen des Service Request Managements. Nicht nur die Definition der wählbaren Anfragen, auch das Routing zur richtigen Supportstelle bis zur Auswahl des richtigen SLAs kann auf Basis entsprechender Objekte in Assets definiert und automatisiert werden.

Schlüssel zum Erfolg

Ein klar definiertes Serviceportfolio und eine Umsetzung in Jira Service Management bzw. Jira Assets kann sowohl für Organisationen im Aufbau, Wachstum oder auch im Umbruch eine tolle Möglichkeit sein, ihre Services in einer State-Of-the-Art-Lösung abzubilden.

Mit den flexiblen Möglichkeiten zur Definition und Verknüpfung von Objekten und deren Nutzung in Jira und Confluence ergeben sich grosse Potentiale, ein bestehendes Service Management zu neuem Schwung zu verhelfen oder Organisationen für die Entwicklung der Maturität ihrer Services eine Plattform zu bieten.

Bei Swarmit unterstützen wir unsere Kunden aus verschiedensten Branchen bei der Umsetzung unterschiedlichster Anforderungen und Herangehensweisen. Unsere Consultants helfen dabei in verschiedenen Bereichen, von der Entwicklung eines Service Portfolios, über die Abbildung in Jira Assets und/oder beim Betrieb der Applikationen, egal ob lokale Installation oder in der Cloud, ob aus Zürich, Lausanne oder direkt bei euch vor Ort im Office.

Kontaktiere uns!

Wie mehrfach erwähnt sollte der Aufbau eines Service Portfolios immer im Kontext der jeweiligen Organisation betrachtet werden. Daraus ergeben sich sehr unterschiedliche Herangehensweisen und Ansichten über Begriffsdefinitionen und strukturelle Bausteine.

Dieser Artikel stellt dabei nur eine von vielen Möglichkeiten vor.

Gerne besprechen wir mit dir eure individuellen Anforderungen und zeigen dir, wie die Swarmit dich bei der Umsetzung eines erfolgreichen Serviceportfolios in Jira Assets unterstützen kann.

Weitere Informationen:

• Jira Service Management: https://www.atlassian.com/de/software/jira/service-management
• Jira Assets: https://www.atlassian.com/de/software/jira/service-management/features/asset-and-configuration-management
• Swarmit: https://www.swarmit.ch