GitLab Use Case: Qualitätsmanagement

GitLab ist eigentlich eine Webapplikation, die zur Softwareentwicklung eingesetzt wird. Was hat so etwas denn im Qualitätsmanagement verloren? Nach genauerem hinsehen habe ich GitLab als Instrument für das QMS in meiner Abteilung eingeführt. Ich bin begeistert und das trifft auch auf die meisten meiner Mitarbeiterinnen und Mitarbeiter zu. Warum, möchte ich euch in diesem Artikel nahebringen.

Was ist GitLab?

GitLab ist ein Versionskontroll-System (Version Control System, VCS). Es kommt aus der Softwareentwicklung und basiert auf Git, einem Open-Source-VCS. Ziel einer solchen Software ist, Änderungen im Quellcode von Software zu dokumentieren, zu revisionieren und somit transparent zu halten. So kann nichts versehentlich gelöscht werden und man kann nachvollziehen, wer, was, wann und warum am Quellcode gemacht hat. Eine sehr gute Zusammenfassung zu GitLab findet man hier: https://www.mittwald.de/blog/arbeitsalltag/tools/gitlab

Wie setzen wir GitLab ein?

Softwareentwicklung hat ja erstmal nicht so viel mit einem Qualitätsmanagemenssystem nach DIN EN ISO 9001:2015 zu tun. Klar, QM ist auch bei Softwareentwicklung wichtig, mit unserer Anwendung von GitLab sind wir aber meilenweit von Softwareentwicklung oder Datenmanagement oder sowas entfernt. Und trotzdem haben wir einen sehr großen Nutzen von und mit GitLab. Das Ticketsystem in GitLab ist nämlich ein sehr mächtiges Instrument, dass in kürzester Zeit unser Qualitätsmanagmentsystem auf den Kopf gestellt hat. Ganz konkret haben wir als erste Anwendung unsere CaPa-Liste mit dem Ticketsystem ersetzt.

Unser Anwendungsszenario – CaPa

CaPa bedeutet Corrective Action Preventive Action. Damit lassen sich also Korrekturmaßnahmen und Vorbeugemaßnahmen lenken. Diese Maßnahmen dienen der strukturierten Vorgehensweise der Organisation, vor allem beim Umgang mit Fehlern. Ein Verfahren dafür zu haben ist in der Norm obligatorisch vorgesehen. Traditionell nutzen wir die CaPa-Liste aber auch für Verbesserungsvorschläge, Feedback, Empfehungen aus Audits, noch offenen Punkten aus Audit Maßnahmenplänen und eben alle anderen Sachen aus dem QMS, die nicht speziell durch andere Verfahren gelenkt werden. Wir haben das bisher mit einer Excel Tabelle gelöst, in der wir die entsprechenden Dinge erfasst haben und dann z.B. getroffene Vorbeugemaßnahmen oder eben die konkrete Fehlerbehebung und deren Überprüfung dokumentiert haben.

Zunehmend ist das aber an die Grenzen gekommen. Wir nutzen die ansonsten exzellente Software ConSense, um unser QMS zu organiseren. Für ein lebendes und gut genutztes QMS eine super Sachen. Der Nachteil ist allerdings, dass die Änderungen in der Datei zwar transparent dargestellt werden, nicht aber die Kommunikation zu den einzelnen Themen. Die läuft natürlich außerhalb von ConSense über Mail oder in Meetings ab. Dafür ist das Programm ConSense auch nicht gedacht. Zudem ist das System nur so transparent, wie man es als Anwender zulässt. Zunächst checkt man die Datei aus, bearbeitet sie und checkt sie wieder ein. Ändert man innerhalb der Excel Datei mehrere Dinge und mache das beim einchecken nicht kenntlich ist es für einen Dritten nicht direkt transparent. Man muss dann die verschiedenen Versionen vergleichen, was in der Praxis niemand tut, weil es zu aufwändig und unkomfortabel ist. Besonders nicht, wenn man wirklich viel über die Tabelle macht und eben viele Einträge darin sind. Einen Ausschnitt der Tabelle mitsamt Legende sehr ihr im Screenshot.

Bild: Screenshot (unkenntlicher Inhalt) eines Teiles der alten CaPa-Liste.

Dann kam noch Corona hinzu und plötzlich waren viele Kolleginnen und Kollegen zeitgleich im Homeoffice und benötigten Zugriff, oft ebenfalls zeitgleich. Was lesend ganz problemlos ist, stellte uns vor größere Probleme beim Schreibzugriff. Da wir ein offenes QMS haben, in denen sich praktisch alle Kolleginnen und Kollegen beteiligen, sind viele Schreibzugriffe erforderlich. Schlussendlich sind wir bei Revision 254 der CaPa Liste angelangt, mit schwindender Akzeptanz und immer länger werdenden Zeiten der Maßnahmenbearbeitung und auch mal "vergessenen" Maßnahmen.

Was sind die Vorteile von GitLab?

Wie man am Szenario erkennt musste eine Lösung her, die ubiqutär funktioniert, die möglichst die themenbezogene Kommunikation bündelt und die Tranzparenz für die im Homeoffice verstreuten Kolleginnen und Kollegen schafft. Das war die Stunde von GitLab.

Das GitLab System ist im Unternehmen schon eingeführt, weil viele unserer IT Spezialisten und Wissenschaftler GitLab zum Forschungsdatenmanagement und auch für Softwareentwicklung nutzen. Die CaPa-Liste selbst existiert auch weiterhin, aber eben nicht mehr als Excel Datei sondern als GitLab Projekt. Die wesenlichen Vorteile schauen wir uns jetzt an.

Das Ticketsystem

Die bisher über Email, Chat und Meetings abgewickelte Kommunikation zu unseren QM-Themen war ziemlich zerrissen und ist dadurch auf Dauer schwer nachzuvollziehen. Dadurch, auch im Hinblick auf Wissensmanagement (auch ein wichtiger Teil eines QMS), sehr anfällig. Das Ticketsystem von GitLab fängt genau dieses Problem auf, denn es wird transparent wo und warum genau die Abarbeitung des Tickets stockt. Insofern können alle Beteiligten entsprechende Maßnahmen einleiten, damit Fehler abgestellt werden oder Verbesserungsvorschläge umgesetzt werden können. Kommunikation und Inhalte sind also gebündelt und tragen aktiv zum Wissensmanagement und zur Geschwindigkeit und Agilität von Umsetzung bei.

Die erste Maßnahme ist also für jeden Eintrag, der sonst in die CaPa Liste eingetragen worden wäre (also eine Zeile in der Excel Tabelle), ein einzelnes Ticket anzulegen.

Bild: Screenshot Tickets (unkenntliche Inhalte) des neuen CaPa-Verfahrens.

Nachdem ein Ticket abgearbeitet ist wird es nicht gelöscht, sondern geschlossen und somit aus dem Fokus genommen:

Bild: Screenshot (unkenntliche Inhalte) mit Übersicht der offenen und geschlossenen Tickets.

Der Gesamte Sachstand mitsamt Kommunikation bleibt also transparent in einem System und man kann ganz einfach nachsehen was "damals" gelaufen ist bzw. sich als neuer Kollege oder neue Kollegin auch einlesen.

Bild: Screenshot (unkenntlicher Inhalt) eines einzelnen geschlossenen Tickets.

Wer welche Tickets erstellt oder wie bearbeitet hat hat bleibt ebenfalls transparent im System dokumentiert (1), (2), (3).

Labels

Wie man im Screenshot oben sehen kann, sind bei den einzelnen Tickes Label gesetzt (2). Diese Label markieren den Stand des Tickets. Ist zum Beispiel ein Fehler passiert wird dieser mit dem Label IF-Interner Fehler erfasst. Handelt es sich um eine Beschwerde wird das Label BS – Beschwerde gesetzt. Natürlich sind auch Kombinationen möglich.

Ist die Bearbeitung im Gange können – genau wie bei einer Liste in Excel, wo die entsprechenden Felder ausgefüllt wurden – Labels entsprechend des aktuellen Status gesetzt werden.

Und hier ist natürlich wichtig was bisher gemacht wurde. Eine Korrekturmaßnahme eine Vorbeugemaßnahme oder eine Überprüfung der Wirksamkeit der Maßnahme. Das Vorgehen unterscheides sich also nicht von unserer bisherigen Excel-Tabelle oder dem Vorgehen bei CaPa im allgemeinen. Es ist nur deutlich übersichtlicher und viel einfacher im Handling, grade bei einem "verstreuten" Team.

Die von uns genutzten Label und deren Beschreibung finden sich in den beiden folgenden Bildern und sollen eine Anregung darstellen, das geht sicherlich auch anders:

Bild(er): Screenshots der genutzten Label und deren Beschreibung.

Auch gibt es einige Label, die bei der Prioriosierung helfen. Ein potenzieller QuickWin ist natürlich was anderes als ein potenzieller LongRunner. Die konkrete Bewertung und weitere Vorgehensweise bei solchen Dingen erfolgt dann in unserer Arbeitsgruppe Qualitätsmanagement. Bei ganz schnellen QuickWins weise ich als Leitung die Aufgabe auch schon mal selbst einem spezifischen Mitarbeitenden zu, natürlich manchmal auch mir selbst.

Wer welche Label gesetzt und was an den Tickets geändert wurde hat bleibt transparent im System dokumentiert.

Meilensteine

Meilensteine nutzen wir in unserer CaPa-Liste derzeit noch nicht. Eine Idee ist aber, Meilensteine zu bestimmten Maßnahmenplänen anzulegen, damit deren vollständige Bearbeitung zu bestimmten Endterminen nachvollzogen werden kann.

Der Meilenstein wäre dann z.B. Maßnahmenplan vom Internen Audit am xx.xx.2020 und alle Inhalte des Maßnahmenplans würden als Ticket erfasst und dem Meilenstein zugeordnet.

Zuweisungen

Ich habe weiter oben schonmal etwas dazu geschrieben. Zuweisungen sind eine schöne Sache im GitLab. Ich kann Tickets direkt einer Person zuordnen (=Verantwortung übertragen) und auch Fälligkeitsdaten hinterlegen. Prinzipiell lassen sich auch Zeiten für einzelne Tickets erfassen, diese Funktion nutzen wir derzeit aber nicht.

Kommunikation

Die Kommunikation bezieht sich natürlich auf die Inhalte der Tickets . Man kann auf Tickets oder Beiträge in Tickets reagieren und z.B. Gefühle ausdrücken mit Emoticons oder Tickets/ Beiträge in Tickets up/downvoten. Auch kann man verschiedene Personen adressieren. Dazu muss man einfach in den Beiträgen die Person benennen und mit einem @ kennzeichnen z.B. @u.ivens. Das kann jeder tun, der Zugriff auf das Ticket hat und darin schreiben kann. Wenn ich also denke, dass ein Ticket oder ein Beitrag in einem Ticket für bestimmte Personen interessant adressiere ich diese Personen im Text mit @m.mustermann @e.meier oder auch @p.schmitz und diese Personen bekommen dann eine Email, mit dem Text des Beitrages und dem Link in’s GitLab. So gelingt auch eine Umstellung recht gut, weil nichts verloren geht und auch bestehende Kommunikationssysteme weiter angebunden sind. Innerhalb der Tickets kann man auch Querverweise zu anderen Tickets machen. Das ist wichtig, wenn man mit mehreren Projekten arbeitet.

Wie entwickelt sich das Ganze weiter?

• Die Labels entwickeln sich noch. Es fallen schonmal Dinge weg oder kommen hinzu. Beispielsweise ist das Label Textbaustein MR hinzugekommen. Hier erfasse ich als Leitung des QMS zu einzelnen Maßnahmen Texte, die ich mit meiner QMB bei der Vorbereitung des Management Reviews dann einfach nutzen kann. Ich schreibe das Managment Review also sozusagen parallel zum Prozess und muss am Ende des Betrachtungszeitraumes "nur noch" evaluieren und bewerten. Das spart Zeit und Ressourcen in der heißen Phase der Erstellung (die bei uns immer kurz vor dem externen Audit ist).
• Wir haben neben der CaPa-Liste angefangen das Verfahren "Planung von Änderungen" in GitLab zu überführen. Wir legen dazu Miniprojekte an, die wir dann systematisch abarbeiten. Dies ist immer dann relevant, wenn strukturierte Änderungen am QMS notwendig sind, die nicht unterhalb einer von uns definierten Grenze sind (und somit via CaPa abgearbeitet werden).
• Unsere Besprechungen werden größtenteils ebenfalls via GitLab vor- und nachbereitet. Das ist dank der Labels auch sehr einfach möglich und ermöglicht eine Arbeit an den Themen auch zwischen den Sitzungen.
• Man kann Vorlagen für bestimmte Tickets anlegen, z.B. Beschwerden, Fehler und so die strukturierte Abarbeitung weiter verbessern, weil man keine wichtigen Angaben vergisst.

GitLab ausprobieren?

Wenn ihr euch von GitLab angesprochen fühlt und das noch nicht im Unternehmen habt könnt ihr euch den GitLab Stack von Bitnami herunterladen. Der läuft z.B. in einer virtuellen Maschine: https://bitnami.com/stack/gitlab. Zum ausprobieren ideal!

Das war mein kurzer Einsatzbericht zu GiltLab im Use Case Qualitätsmanagment. Ich würde mich sehr freuen, wenn ihr auch Kommentare zu eurem GitLab UseCase macht.

---

Der Beitrag "GitLab Use Case: Qualitätsmanagement" von Ulrich Ivens steht unter der Lizenz CC BY-SA 4.0.

Beitragbild: Logo und Schriftart von Ty Wilkins, Download vom GitLab Press Kit, Lizenz CC BY-SA 4.0.