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 verfügbar — die Windows-Version folgt in Kürze. Sagen Sie uns Bescheid, und wir melden uns, sobald sie da ist.