SYSTHEMIS at Work
Wir arbeiten seit Langem mit Confluence und Jira und haben uns über die Jahre eine Expertise in der Einführung und Betreuung der Tools in Kundenprojekten erarbeitet. Heute wollen wir einen Einblick in unsere Arbeit geben und auf häufige Fehler und Missverständnisse hinweisen, die bei der Einführung zu beachten sind.
Warum Atlassian?
Die SYSTHEMIS setzt aus guten Gründen auf Atlassian-Produkte, da sie sowohl was den Umfang, die Interkonnektivität sowie die Skalierbarkeit betrifft, für jede Art von Projekt – nicht nur in der Softwareentwicklung – eine umfassende Basis für gelungenes Projektmanagement bieten. Eine große Stärke von Atlassian-Tools ist ihre Fähigkeit, organisch mit einem Kundenprojekt zu wachsen. Das gilt sowohl für die individuelle Konfiguration der Werkzeuge selbst, als auch für ihre Interkonnektivität. Jira kann beispielsweise problemlos in eine bestehende Confluence-Infrastruktur integriert werden, wenn zu einem späteren Zeitpunkt im Projekt ein Bedarf entsteht. Zudem stehen zahlreiche Erweiterungen zur Verfügung und auch eine Verbindung mit anderen Systemen ist möglich.
All diese Vorteile und Möglichkeiten dürfen jedoch nicht den Eindruck erwecken, dass die Einführung sowie ein grundsätzliches Verständnis der Anwendungen allein schon eine Struktur in Unternehmensprozesse bringen. Atlassian Tools sind keine Blackboxes, die man mit relevanten Informationen füttert und die einem dann eine Roadmap ausspucken: es sind im besten Sinne Werkzeuge, die von Menschen kompetent bedient werden müssen, um ihre volle Wirkung zu entfalten.
Fallstricke bei der Implementierung
Die Einführung von Confluence und/oder Jira läuft unserer Erfahrung nach häufig so ab: eine oder mehrere Personen werden mit der Aufgabe betraut und befassen sich mit dem Thema. Die Tools werden als ein Aufgabenbereich verstanden, der möglichst von einem kleinen Team abgedeckt werden soll. Dabei haben die betroffenen Personen oft noch andere relevante Funktionen im Unternehmen und sollen die Betreuung der Plattform zusätzlich erledigen. Schon bald nach der Einführung beginnt die Plattform zu wachsen, neue Aufgaben kommen hinzu, das „Unkraut“ sprießt. Der eigentliche Effekt, den man sich von einem Kollaborations-Tool erhofft hat, nämlich ein Mehr an Struktur, ein Mehr an Übersichtlichkeit, droht, sich ins Gegenteil zu verkehren: anstatt dem Team Arbeit abzunehmen, entsteht zusätzliche Arbeit.
Organisatorische Rahmenbedingungen
Um dieses Problem zu vermeiden, sollte die Einführung eines Kollaborations-Tools von Beginn an auf mehrere organisatorische Säulen verteilt werden. Es ist unerlässlich, sich bereits zu Beginn die Frage zu stellen, welche Anforderungen man an das Tool hat und welche Themen im späteren Verlauf noch hinzukommen könnten. Denn jedes Thema bringt auch weitere Aufgaben mit sich und benötigt zusätzliche Ressourcen. Ist der Überblick in einem gewachsenen Kundenprojekt erst einmal verloren gegangen, führt oft kein Weg an einer grundsätzlichen Neustrukturierung vorbei. Als Orientierung dient uns hier das ITIL v4 Framework.
Bereiche und Funktionen
Grundsätzlich lässt sich eine Unterscheidung zwischen technischen und fachlichen Themen treffen. Auf der technischen Seite stehen der Betrieb der Produkte sowie die technische Administration. Im Betrieb geht es um Themen wie das Monitoring auf Systemebene, Lizenzbeschaffung, das Patch- und Updatemanagement, CR-Management und Vertragscontrolling. Die Administration dagegen trägt die Gesamtverantwortung für das System. Von technischer Beratung über Wartungsaufgaben bis hin zu Fehler- und Pluginmanagement laufen hier alle Fäden zusammen.
Der First und Second Level-Support ist der zentrale Ansprechpartner, an den die Nutzer des Systems sich wenden können, um Tickets für alle möglichen Anliegen aufzumachen; wenn beispielsweise neue Nutzer oder Rechte gebraucht werden, aber auch für neue Features und grundsätzliche Fragen.
Fachadministration und Content-Pflege sind stets eng gekoppelt mit der technischen Administration, da jede Neuerung im System individuell konfiguriert werden muss. Sie ist unterstützend tätig für neue Anforderungen, die nicht auf dem First und Second Level liegen. Dabei kann es um die Strukturierung und Gestaltung von Bereichen in den Anwendungen gehen, oder auch um den Umgang mit Plugins und Makros.
Wie verhindert man nun aber das oben beschriebene Sprießen von „Unkraut“? Anstatt die Nutzer selbst wild drauf los arbeiten zu lassen, werden im Bereich Vorlagen und Plugins Standards angelegt: Bereichs- und Seitenvorlagen wie beispielsweise Protokolle, Übersichtsseiten, sowie vorausgewählte Plugins. Dieser Prozess sollte in eine Art Vorlagenmanagement münden, in die sinnvolle Verwaltung und Weiterentwicklung solcher Vorlagen. Auch das Thema Wording spielt hier eine Rolle: wie benenne ich meine Seiten oder wie erziele ich einheitliche Seitenstrukturen, damit sich jeder überall zurechtfindet?
Es empfiehlt sich auch, ein eigenes Testsystem einzuführen, um Plugins ausprobieren zu können. Bei Tests im Produktivsystem geht viel zu schnell der Überblick verloren und es verursacht extra Arbeit im Nachgang, wenn Plugins wieder zurückgebaut werden müssen.
An dieser Stelle schlägt sich eine Brücke zum Thema Prozesse und Standards, also zur Frage: Wie arbeite ich mit den Werkzeugen? Wird beispielsweise ein neues Jira-Projekt benötigt, empfiehlt es sich, das in Confluence festzuhalten, um den Vorgang für die Nutzer nachvollziehbar zu machen. Alle Wege führen in Richtung Standardisierung.
Der Qualitätsmanager ist der Gärtner in unserem System. Er überwacht und prüft, ob Prozesse und Standards gelebt, sowie Vorlagen gemäß den Vorgaben verwendet werden. Er hat das große Bild, das ganze System im Blick. Gerade in Jira besteht immer die Gefahr einer „Übermüllung“. Daher ist es wichtig, eine neutrale Stelle zu installieren, die prüft, ob Tickets oder Teile von Projekten unbearbeitet im System liegen und gegebenenfalls entfernt werden können.
Rollen
Wie nun die beschriebenen Bereiche auf konkrete Rollen verteilt werden, hängt von den individuellen Voraussetzungen und Bedürfnissen des jeweiligen Unternehmens ab. In einem klassischen Kick-Off würde der Berater der SYSTHEMIS mit dem Kunden gemeinsam ein Konzept erarbeiten, wie die richtigen Experten am besten einzusetzen sind, um die Bereiche optimal abzudecken. Unsere Erfahrung zeigt: ein geschulter Blick von außen ist häufig Gold wert, um Potenziale zu erkennen und optimal zu nutzen.