Im Rahmen von DevOps-Initiativen, Digitalisierungsprojekten und Cloud-Migrationen investieren viele Kunden in Application Performance Management (APM).
Ziel sind höhere Kundenzufriedenheit und damit verbundene Umsatzsteigerungen, was durch schnellere Release-Zyklen und die dadurch reduzierte Time-to-Market bei verbesserter Software- Qualität erreicht werden kann.
Häufig wird angenommen und auch von den Herstellern der APM-Lösungen suggeriert, dass dies bereits mit der Anschaffung des neuen Tools erreicht werden kann. Wie unsere Erfahrungen jedoch zeigen, ist dies kein realistischer Ansatz. Der Mehrwert von APM kann nur dann voll zum Tragen kommen und ein ROI erreicht werden, wenn die nötigen Prozesse für eine konstante Aktualisierung und Verbesserung des APM-Prozesses etabliert und im Unternehmen verankert werden.
Mit dem amasol Center of Excellence (CoE) für Application Performance Management bieten wir ein erprobtes Verfahren und Einführungskonzept für eine sichere und gut verankerte operationale Adoption von APM in der Kundenorganisation an.
Damit sorgt das CoE dafür, dass unsere Kunden die Potenziale von APM bestmöglich ausschöpfen. Dies erreichen wir durch unser technologisches Know-how im Bereich APM und durch den Aufbau eines CoE. Gleichzeitig stellen wir sicher, dass unsere Kunden das volle Potenzial der APM-Lösung optimal nutzen können, ohne dass unsere Berater*innen dauerhaft vor Ort im Einsatz sein müssen. Dies führt zu einem besseren Verständnis des Verhaltens der Endanwender*innen und ermöglicht eine konstante Überwachung und Verbesserung der End User Experience. Durch die Integration des CoE in den gesamten Application Lifecycle können wichtige digitale Initiativen bereits frühzeitig unterstützt werden, was wesentlich zu einer besseren Produktqualität beiträgt. Die Verknüpfung von CoE und APM ist das Alleinstellungsmerkmal von amasol.
Im CoE verbinden wir die Expertise von amasol mit der IT-Expertise
und der Kompetenz der Anwender auf Kundenseite. So entsteht ein
Framework, das unseren Kunden:
- die Möglichkeiten von APM in greifbarer Form,
- hilft, das Kosten-Nutzen-Verhältnis der eingesetzten APM-Lösung zu erkennen,
- ermöglicht es Ihnen, das Potenzial von APM voll auszuschöpfen und hilft Ihnen
- um die Leistung Ihrer Anwendungen dauerhaft zu optimieren,
- ermöglicht es, das Know-how von amasol dauerhaft zu nutzen, ohne große Investitionen tätigen zu müssen.
Beim Aufbau des CoE wird der Kunde von amasol unterstützt. Die Unterstützung wird nach und nach reduziert. Erfahrungsgemäß braucht der Aufbau ca. zwölf Monate, in denen wir intensiv zusammenarbeiten. Anschließend kann der Kunde das CoE komplett eigenständig weiterführen oder je nach individuellem Bedarf weiter zur Unterstützung auf das Know-how von amasol zurückgreifen.
Wir schlagen vor, das CoE fest im Organigramm auf Kundenseite abzubilden. Dabei gilt es, folgende Rollen zu besetzen:
Dies umfasst alle Mitarbeiter der IT-Abteilung des Kunden, die 100% im CoE arbeiten.
Arbeitnehmer (vor allem aus dem IT-Sektor), deren Fachwissen vorübergehend benötigt wird. Der Zeitaufwand beläuft sich auf 20 bis 50% der Wochenarbeitszeit. In der Regel handelt es sich jedoch nicht um neue Tätigkeiten, sondern um Aufgaben, die von diesen Experten bereits in der Vergangenheit ausgeführt wurden, wie z.B. die Fehlersuche im Problemfall. Neu ist jedoch, dass die Arbeit über den CoE organisiert wird.
Dies sind interessierte und IT-affine Mitarbeiter aus den Geschäftsbereichen des Kunden, in denen die jeweilige Anwendung eingesetzt wird.
Um Ressourcenknappheit vorzubeugen, empfehlen wir, innerhalb der IT-Abteilung eine Steuerungsgruppe für das CoE einzurichten. Dieser besteht aus allen Team- und Abteilungsleitern, aus deren Reihen Mitarbeiter als "Experten" oder als "Kernteam" im CoE arbeiten.
Diese Lenkungsgruppe berichtet direkt und mit einer Stimme an die IT-Leitung. Aufgabe der Lenkungsgruppe ist es, die Arbeitsinhalte zu definieren und die Interessen des CoE mit den Interessen der IT-Abteilungen abzustimmen.
Bevor das CoE beim Kunden aufgestellt werden kann, sind nur wenige zentrale Vorbereitungen erforderlich.
Ziel des Workshops ist es, die Grundlage für die Einführung der APM-Software und des CoE auf Managementebene zu schaffen. Zu diesem Zweck sollte der "Entscheider" auf Kundenseite das Treffen eröffnen und den Anwesenden erklären, warum sich das Unternehmen für diese Investition entschieden hat. Aus dieser "Erklärung" ergeben sich die Ziele für das Projekt.
Während des Strategieworkshops zeigen die Berater von amasol auf, wie die Ziele erreicht werden können (mit Hilfe des CoE). Der Strategie-Workshop kann sich mit folgenden Themen befassen:
- Vorstellung der Möglichkeiten der eingesetzten APM-Lösung
- Vorstellung der Möglichkeiten eines CoE
- Überlegungen, wie das CoE kundenindividuell strukturiert und personell ausgestattet werden kann
Das Kernteam und die Experten benötigen vertieftes Fachwissen über die Software, das in einer Basisschulung vermittelt wird. Zum Zeitpunkt der Schulung sollte den Teilnehmern bewusst sein, dass sie mit der Software in Form eines CoE arbeiten werden. Außerdem sollte zwischen dem Beginn der Arbeit im CoE und der Schulung kein großer zeitlicher Abstand liegen, damit das erworbene Know-how wirklich optimal genutzt werden.
In einer weniger tief gehenden Schulung werden die Geschäftsanwender in der Verwendung der Software geschult.
Alle CoE-Aufgaben, unabhängig davon, woher sie kommen, werden in einem Kanban-Board erfasst, verteilt und bearbeitet. Als Basis dient das vom Kunden verwendete Ticketsystem. Die meisten IT-Abteilungen arbeiten mit Jira. Gemeinsam mit dem Kernteam des CoE definieren die Berater von amasol die grundlegende Logik und Struktur für den Aufbau eines Jira-Boards zur Arbeitsorganisation im CoE.
Alle eingehenden Aufgaben werden im "Backlog" erfasst. Sobald eine Aufgabe nach Prioritäten geordnet und vorbereitet wurde, wird sie in die Spalte "Bereit" verschoben. Wenn ein Mitarbeiter mit der Arbeit an einer Aufgabe beginnt, wird die Aufgabe in die Spalte "In Bearbeitung" verschoben. Sobald eine Aufgabe abgeschlossen ist, wird sie in die Spalte "Erledigt" verschoben. Die Organisation der Arbeit in einer Kanban-Logik ist für IT-Spezialisten geeignet. Da alle Aufgaben in den Bereichen Überwachung und Support ad hoc anfallen und sofort bearbeitet werden müssen, entfallen zeitaufwändige Abstimmungsgespräche in diesen Bereichen.
Die Arbeitsorganisation im CoE orientiert sich an den Grundkonzepten des agilen Arbeitens und greift auf entsprechende Methoden und Strukturen zurück. Im Folgenden beschreiben wir die Arbeitsorganisation entlang der Aufgaben, die im CoE bearbeitet werden.
Diese stammen im Wesentlichen aus zwei Bereichen:
Bestimmte Parameter der verwendeten Anwendungen werden ständig überwacht. Ändert sich ein Parameter signifikant, ergibt sich daraus eine Aufgabe für das CoE. Diese Aufgaben entstehen ad hoc, sie sind nicht planbar und müssen priorisiert werden.
Wenn ein Endnutzer einer Anwendung ein Problem mit deren Leistung hat, wendet er sich (wie bisher) an den IT-Support. In der Regel erstellt der IT-Support eine Aufgabe im internen Ticketsystem des Kunden. Auch diese Aufgaben entstehen ad hoc, sie sind nicht planbar und müssen zudem priorisiert werden.
Neben der Durchführung aller routinemäßigen Überwachungs- und Supportarbeiten bietet das CoE den Kunden die Möglichkeit, einzelne Anwendungen gezielt zu analysieren, zu verbessern und weiterzuentwickeln. Hierfür arbeiten die Abteilungen IT, Operations und Business eng zusammen, gesteuert durch das CoE. Diese Aufgaben fallen gezielt an und können geplant bearbeitet werden. Dies erfordert getrennte Strukturen. Die Berater von amasol plädieren für einen schrittweisen Ansatz zur Leistungsverbesserung. Das bedeutet, dass immer nur ein oder zwei Anwendungen im Fokus der Optimierung stehen sollten.
amasol bildet für jede Anwendung, die verbessert werden muss, ein Arbeitsteam. Dieses besteht aus CoE-Mitarbeitern, IT-Experten und Anwendungsexperten aus dem Fachbereich. In iterativen Verbesserungsschleifen wird die Leistung der jeweiligen Anwendung optimiert. Im Folgenden skizzieren wir Strukturen und Prozesse für die Arbeit des CoE bei der systematischen Verbesserung der einzelnen Anwendungen.
Sobald eine bestimmte Anwendung ausgewählt wurde, treffen sich alle Beteiligten und der gesamte CoE, um gemeinsam das/die zu erreichende(n) Ziel(e) zu definieren. Wir schlagen dafür ein Workshop-ähnliches Format von etwa drei bis vier Stunden vor. Wir planen hier noch keine Meilensteine oder Umsetzungsschritte. Es geht lediglich darum, das Ziel zu definieren.
Zu diesem Zweck beantworten wir die folgenden Schlüsselfragen:
- Wofür verwenden wir diese Anwendung?
- Was wollen wir mit der Verbesserung der Leistung erreichen?
- Woran erkennen wir, dass wir unser Ziel erreicht haben?
Das Ergebnis des Zielworkshops halten wir in der verwendeten Kanban-Tafel fest. In Jira können wir zu diesem Zweck ein Epic (d.h. eine Beschreibung der Anforderung an eine neue Software) erstellen.
Die Zuständigkeiten und Rollen werden im Rahmen des Zielworkshops festgelegt. Wir schlagen vor, mindestens zwei Rollen zu vergeben:
Projektleiter
Diese Person fungiert als zentrale Anlaufstelle. Intern ist er der Ansprechpartner für alle Beteiligten. Der Projektleiter kennt jederzeit den aktuellen Stand und sorgt dafür, dass ausreichend am Thema gearbeitet wird. Er ist nicht allein dafür verantwortlich, dass das Ziel erreicht wird - aber er hat ein Auge darauf, wenn zu wenig fokussiert an dem Thema gearbeitet wird und dadurch das Gesamtziel gefährdet ist.
Kunde
Wenn wir in iterativen Schleifen an der Verbesserung einer Anwendung arbeiten wollen, dann brauchen wir auch eine Instanz, mit der wir überprüfen können, ob wir an den richtigen Themen arbeiten und ob unsere Ergebnisse in die gewünschte Richtung gehen. Aus diesem Grund empfehlen wir, die Rolle des Kunden bewusst auszufüllen. In der Regel eignet sich ein Application Owner oder Key User besonders gut für die Rolle des Kunden. Alle Rollen müssen mit mindestens einer oder maximal zwei Personen besetzt werden. Es ist nicht ratsam, die Rollen mit Gruppen zu besetzen oder sie zu rotieren.
Wir empfehlen, für die Planung und Bearbeitung der anfallenden Aufgaben auf eine Quartalsperspektive umzustellen. Entgegen der klassischen Logik des wasserfallartigen Projektmanagements legen wir keinen Gesamtprojektplan fest. Ausgehend von den Ergebnissen des Zielworkshops beantworten wir die Frage, was im nächsten Quartal konkret zu tun ist.
Außerdem gibt es eine vierteljährliche Sitzung, in der wir die spezifischen Quartalsziele ermitteln und festlegen. Jedes vierteljährliche Ziel besteht aus zwei Elementen:
Anwenderbericht
In Form von ein paar Zeilen Fließtext beantworten wir die Frage, warum wir an diesem Thema arbeiten. Die User Story muss einen Bezug zum Gesamtziel haben.
Checkliste
In Form einer Checkliste definieren wir alle Punkte, an denen wir erkennen können, dass wir ein Quartalsziel erreicht haben.
An der vierteljährlichen Sitzung nehmen alle Mitarbeiter teil, die aktiv zur Verbesserung der Leistung einer Anwendung im kommenden Quartal beitragen.
Darüber hinaus sind alle Interessengruppen und Vertreter der Lenkungsgruppe eingeladen, ihre Teilnahme ist jedoch nicht obligatorisch.
Da wir im Zielworkshop die Rollen des/der Projektleiter(s) und des Kunden definiert haben, ist es sinnvoll, dass diese Personen das Quartalsmeeting vorbereiten, indem sie konkrete Vorschläge für die Quartalsziele erarbeiten. Alle anderen Teilnehmer können diese Vorschläge ergänzen. Am Ende des Quartalsmeetings haben wir das Gesamtziel (das "Epos") um konkrete Quartalsziele (immer nur für das kommende Quartal) erweitert und greifbar gemacht.
Für die Planung konkreter Aufgaben und To-Dos halten wir den Zeithorizont noch kürzer. Hier schlagen wir eine Basis von vier bis sechs Wochen vor. In diesen Planungsgesprächen füllen wir unser Backlog mit konkreten Aufgaben, die wir erledigen müssen, um unsere Quartalsziele zu erreichen. An der Planungssitzung nehmen alle Personen teil, die aktiv für die Bearbeitung der Aufgaben benötigt werden.
Dieses Treffen kann auch vom Projektleiter mit konkreten Vorschlägen für alle anstehenden Aufgaben vorbereitet werden. Diese sollten so beschrieben werden, dass klar ist, warum wir daran arbeiten und woran wir erkennen können, dass die jeweilige Aufgabe erledigt ist. Das interdisziplinäre Team wird äußerst dynamisch und schlagkräftig, wenn es ihm gelingt, die anstehenden Aufgaben in möglichst kleine Teilaufgaben zu zerlegen. Wie groß eine Aufgabe maximal sein darf, hängt vom jeweiligen Arbeitsgebiet ab.
Zwei Beispiele zur Orientierung:
- Im Bereich der Softwareentwicklung sollte keine Aufgabe mehr als acht Stunden in Anspruch nehmen.
- In allen anderen Bereichen sollte es möglich sein, die Aufgaben in maximal zwei Stunden zu erledigen.
Wenn eine Aufgabe umfangreicher ist, muss sie in Teilaufgaben aufgeteilt werden. Eine Zeitschätzung pro Aufgabe wird dringend empfohlen. Anhand der Zeitschätzung der einzelnen Aufgaben bekommt das Team ein Gefühl dafür, wie viel Arbeit in den einzelnen Themen steckt. So lässt sich schnell erkennen, ob die Planung (für die kommenden vier bis sechs Wochen) mit den vorhandenen Ressourcen erreicht werden kann oder nicht.
Am Ende der Planungssitzung wissen wir, welche Aufgaben wir in den nächsten vier bis sechs Wochen erledigen wollen, welche Ressourcen wir dafür benötigen und welche Abhängigkeiten zwischen den Aufgaben bestehen.
In der Sprintplanung legt das Team fest, wer konkret für die Erledigung welcher Aufgabe verantwortlich ist. Diese findet alle zwei Wochen statt und dauert etwa 30 Minuten. Auch hier ist die Anwesenheit aller, die im kommenden Sprint eine aktive Rolle spielen werden, Pflicht. Die Sprintplanung dient dazu, zu entscheiden, welche Aufgaben aus dem "Backlog" von wem bearbeitet werden. Alle Aufgaben für den kommenden Sprint werden in die Spalte "Fertig" verschoben.
Bei diesem Treffen können sich alle koordinieren, insbesondere wenn das Fachwissen mehrerer Personen für eine Aufgabe erforderlich ist. Das Team entscheidet gemeinsam, wie viele und welche Aufgaben im kommenden Sprint erledigt werden sollen. Die Aufgaben werden auch den Personen zugewiesen, die für ihre Erledigung verantwortlich sind.
Während des Sprints kümmern sich die Verantwortlichen selbstständig um die Aufgaben. Treten Schwierigkeiten oder Probleme auf, die sie nicht alleine lösen können, sollten sie sich an den Projektleiter wenden. Das Ziel des Sprints ist es, alle Aufgaben zu bearbeiten ("Doing") und abzuschließen
("Erledigt").
Bevor alle vier bis sechs Wochen ein Planungstreffen stattfindet, lohnt es sich, einen kurzen Rückblick auf das bisher Erarbeitete zu werfen. Alle neuen Funktionen, Ergebnisse und Teilergebnisse, die für das gesamte Team relevant sind, werden im Review vorgestellt. Auch der "Kunde" ist beim Review anwesend. Ihm wird bei dieser Gelegenheit der Fortschritt des Projekts vorgestellt. Das Review befasst sich nur mit den inhaltlichen und technischen Fragen des Projekts. Auch wenn wir hier zwei getrennte Arbeitsschritte beschreiben, ist es im Arbeitsalltag üblich, das Review und das Planungsmeeting am gleichen Tag abzuhalten.
Die Zusammenarbeit in einem interdisziplinären Team, wie wir sie hier beschreiben, unterliegt einer großen Dynamik. Die hier beschriebenen Abläufe müssen sich in Abhängigkeit von den Strukturen und Routinen des jeweiligen Unternehmens weiterentwickeln. Um dies zu ermöglichen, empfehlen wir, Retrospektiven als festes Strukturelement zu etablieren. In einer Retrospektive kommen alle aktiv am Projekt Beteiligten zusammen, um die Art und Weise ihrer Zusammenarbeit zu reflektieren und gezielt Verbesserungen vorzunehmen.
Wir tun dies, indem wir drei Schlüsselfragen beantworten:
- Was hat sich in Bezug auf die Zusammenarbeit bewährt und sollte daher beibehalten werden?
beibehalten?
- Was hat bei der Zusammenarbeit nicht gut funktioniert und sollte daher
geändert/abgeschafft werden?
- Welche neue Idee wollen wir ausprobieren, um unsere Zusammenarbeit zu verbessern?
Die Kombination von APM und CoE gibt uns einen konsistenten Überblick über die Software-Performance vom Mausklick im Browser bis hin zum Mainframe. Die erfolgreiche Integration aller relevanten Akteure ermöglicht es uns zudem, einzelne Anwendungen gezielt weiterzuentwickeln und zu verbessern, um ein optimales Endanwendererlebnis zu bieten.
Das CoE erfordert keine zusätzlichen personellen Ressourcen. Der Mehrwert entsteht durch die Bündelung der vorhandenen Ressourcen und die Optimierung ihres Zusammenspiels.
Alle ad hoc und ungeplanten Aufgaben (aus einem Ticketsystem und der ständigen Überwachung kritischer Parameter) werden vom CoE selbständig angenommen und bearbeitet. Allein die Klarheit der Zuständigkeiten ist ein Argument für die Einrichtung eines CoE. Das Zusammenspiel von APM und CoE entfaltet jedoch seine volle Gestaltungskraft, wenn es darum geht, einzelne Anwendungen genauer unter die Lupe zu nehmen und gezielt weiterzuentwickeln. Durch die Bündelung von Know-how aus verschiedenen IT-Bereichen im CoE können Anwendungsoptimierungen sehr effizient umgesetzt werden, um eine bessere IT-Qualität für die Endanwender zu erreichen.
Das CoE bringt alle relevanten Stakeholder eines Unternehmens (Entwicklung, Betrieb, Geschäft) und deren Interessen zusammen. Dank der klaren Arbeitsmethode, die auf agilem Projektdesign basiert, sind die ersten Ergebnisse in der Regel schon nach wenigen Tagen bis Wochen zu sehen.
Profitieren Sie von über 25 Jahren fundierter Fachkompetenz und hochwertigen Dienstleistungen in unseren Kernbereichen.
Durchsuchen Sie unsere Ressourcenbibliothek nach Inspiration, wie amasol anderen Kunden dabei geholfen hat, ihr Experience Business voranzutreiben.
Entdecken Sie die Tools und Partnerschaften, die uns dabei unterstützen, Ihren Erfolg voranzutreiben und Ihre IT-Umgebung zu optimieren.
Wir wollen die Flexibilität steigern, den Mehrwert erhöhen, die Effizienz der IT verbessern und so den Geschäftserfolg steigern.
Campus Neue Balan
Claudius-Keller-Straße 3B,
81669 München, Deutschland
Gertrude-Fröhlich-Sandner-Str. 2-4, Turm 9,
1100 Wien, Österreich
13/24 2. OG.
West Patel Nagar New Delhi
110008 Indien
60 St Martins Lane Covent Garden,
London, WC2N 4JS, Vereinigtes Königreich