Wissen
QMS auf Git-Basis: warum es meist scheitert — und was easo anders macht.
Die Idee liegt nahe, gerade in technischen Firmen: Dokumente als Dateien, Versionierung mit Git, fertig ist das QMS. Praktiker, die solche Versuche begleitet haben, raten deutlich ab — und trotzdem ist an der Idee fast alles richtig. Eine ehrliche Einordnung.
Die Instinkte dahinter sind richtig
Wer sein QMS in Git legen will, will die richtigen Dinge: eine lückenlose, fälschungssichere Historie statt „final_v2_neu_FINAL.docx". Einfache Dateien statt eines Datenbank-Silos. Die eigenen Dokumente auf der eigenen Infrastruktur statt beim Software-Anbieter. Und einen Exit ohne Verhandlung — wer geht, nimmt alles mit. Jeder dieser Instinkte ist berechtigt, und keiner davon ist das Problem.
Woran die Versuche wirklich scheitern
-
Am Menschen
Commits, Branches, Merge-Konflikte: Wer nicht täglich mit Git arbeitet, kann ein Git-QMS nicht bedienen. Ein QMS lebt aber nur, wenn alle es benutzen — die Fertigung, der Vertrieb, die Geschäftsführung. Ein System, das nur die IT anfassen kann, veraltet ab Tag eins.
-
An der Lenkung
ISO 9001 (Abschnitt 7.5) verlangt Freigabe vor Veröffentlichung, Schutz vor unbeabsichtigter Änderung, gelenkte Verteilung. Git versioniert perfekt — aber es kennt keinen Freigabe-Workflow und keine eingebauten Signaturen. Was bleibt, sind Bastellösungen, die im Audit erklärt werden müssen.
-
An der Führung
Ein Dateibaum sagt nie: „Für Abschnitt 7.2 fehlt ein Dokument" oder „das interne Audit ist überfällig". Versionierung ist kein Qualitätsmanagement — die Pflichten der Norm (Audits, Korrekturmaßnahmen, Managementbewertung) muss jemand kennen, planen und nachhalten. Genau dort reißen DIY-Systeme ab.
Was Praktiker berichten
Das ist keine theoretische Sorge. OpenRegulatory — eine Berliner Regulatory-Firma, die mehrere Unternehmen bei genau solchen Versuchen beobachtet hat — rät in ihrer Analyse von Open-Source-QMS-Wegen ausdrücklich davon ab; die Versuche endeten in ihren Worten als „major catastrophies". Die öffentlich auffindbaren Git-QMS-Projekte sind entsprechend verwaist oder nie fertig geworden. Zur Ehrlichkeit gehört auch die Gegenstimme: Es gibt dokumentierte Wiki-QMS, die Audits bestehen und jahrelang gelebt werden — Auditoren prüfen das System, nicht das Werkzeug. Aber auch ein Wiki liefert weder Vollständigkeits-Führung noch Audit- und CAPA-Workflows. Und: Kein Werkzeug — auch easo nicht — garantiert das Zertifikat. Das QMS besteht das Audit, nicht die Software.
easo behält, was richtig ist — und baut, was gefehlt hat
easo ist die Antwort auf genau diese drei Scheiterpunkte — ohne die richtigen Instinkte aufzugeben. Ihre Dokumente bleiben einfache Dateien in Ihrem Git; easo liegt als Werkzeug darüber:
Für die Menschen: eine Büro-Oberfläche ohne ein einziges Git-Wort — ein Handbuch als Prozesslandkarte, ein Editor wie ein Textprogramm, Kommentare statt Merge-Konflikte. Für die Lenkung: geführte Freigaben nach dem Vier-Augen-Prinzip, kryptographisch signiert und — das ist der Unterschied zu jeder Bastellösung — ohne easo prüfbar, mit Standard-Werkzeugen, direkt auf dem exportierten PDF beschrieben. Für die Führung: ein Normmodell mit ehrlichem Bereitschafts-Wert, das sagt, was fehlt, und geführte Abläufe für Audit, CAPA und Managementbewertung.
Und der Exit-Instinkt bleibt vollständig intakt: Der Weg hinein ist der Weg hinaus — wer easo verlässt, behält alles: Dateien, Historie, prüfbare Signaturen.
Häufige Fragen zu QMS und Git
Kann ich mein ISO-9001-QMS einfach direkt in Git führen?
Technisch ja — praktisch raten Praktiker, die solche Versuche begleitet haben, deutlich davon ab. Git liefert perfekte Versionierung, aber keine Freigabe-Workflows, keine eingebauten Signaturen und keine Führung durch die Norm. Und vor allem: Nicht-technische Kolleginnen und Kollegen können es nicht bedienen — ein QMS, das nur die IT benutzen kann, lebt nicht.
Woran scheitern Git-basierte QMS-Versuche konkret?
An drei Punkten: Erstens am Menschen — Commits, Branches und Merge-Konflikte gehören nicht in den Büroalltag. Zweitens an der Lenkung — ISO 9001 verlangt Freigabe vor Veröffentlichung, Git kennt keinen Freigabe-Workflow und keine Signaturen. Drittens an der Führung — Git sagt nie, welche Pflichtdokumente fehlen oder wann ein Audit fällig ist.
Akzeptieren Auditoren ein QMS in Git oder einem Wiki?
Auditoren prüfen das gelebte System, nicht das Werkzeug — es gibt dokumentierte Fälle von Wiki-basierten QMS, die Audits bestehen. Entscheidend ist, dass Lenkung, Nachvollziehbarkeit und Nachweise stimmen. Genau diese Punkte muss ein Roh-Git-Ansatz mühsam nachbauen — und daran scheitert er in der Praxis.
Was macht easo anders als ein QMS direkt in Git?
easo benutzt Git als Fundament, zeigt es aber niemandem: Büro-Oberfläche statt Kommandozeile, geführte Freigaben mit kryptographischen Signaturen statt Bastellösungen, und ein Normmodell, das sagt, was fehlt und was fällig ist. Die Stärken von Git — lückenlose Historie, Manipulationssicherheit, eigene Dateien — bleiben vollständig erhalten.
Behalte ich mit easo die Vorteile von Git — eigene Daten, kein Lock-in?
Ja, genau das ist der Punkt. Ihre Dokumente sind einfache Dateien in Ihrem eigenen Repository (GitHub, GitLab oder selbst gehostet). easo speichert Ihre Inhalte nicht auf fremden Servern — und wenn Sie easo verlassen, behalten Sie alles, inklusive der kompletten Historie und der prüfbaren Signaturen.
Bleiben Sie auf dem Laufenden
easo ist für macOS und Windows verfügbar. Im Newsletter erfahren Sie, was dazukommt — neue Versionen und neue Inhalte, sonst nichts.