Digitale Dokumentenworkflows und DMS für Unternehmen

Ein DMS, also ein Dokumentenmanagementsystem, ordnet Dokumente, Zugriffsrechte, Versionen und Bearbeitungsschritte. Nicht jedes Unternehmen braucht ein vollständiges DMS. Manchmal genügen eine strukturierte Ablage, eine Verbindung vorhandener Programme oder ein kleineres Modul für einen bestimmten Ablauf.

Wann reichen E-Mail, Ordner und Tabellen nicht mehr aus?

Meist liegt das Problem nicht allein am Speicherort. Es entsteht, wenn ein Dokument weitere Arbeit auslöst, es dafür aber keinen einheitlichen und nachvollziehbaren Ablauf gibt.

Eine Prüfung des Dokumentenworkflows lohnt sich, wenn:

• dieselbe Datei in mehreren Nachrichten verschickt wird und die aktuelle Version unklar ist;
• Mitarbeitende nachfragen müssen, wer das Dokument gerade bearbeitet und was als Nächstes passiert;
• Freigaben in E-Mails, Chats oder außerhalb des Hauptsystems festgehalten werden;
• Daten aus Rechnungen, Verträgen, Anträgen oder Formularen manuell in ein anderes Programm übertragen werden;
• fehlende Anlagen oder falsche Angaben erst am Ende des Ablaufs auffallen;
• Personen auf mehr Dokumente zugreifen können, als sie für ihre Aufgabe benötigen;
• sich nur schwer nachvollziehen lässt, wer wann auf Grundlage welcher Version entschieden hat;
• der Status in einem Programm nicht mit den Auskünften der Mitarbeitenden übereinstimmt.

Diese Anzeichen bedeuten nicht automatisch, dass ein neues System gebaut werden muss. Zuerst klären wir, ob es um Ablage, Verantwortung, Entscheidungen, Datenaustausch oder mehrere dieser Punkte geht.

Ein Dokument vom Eingang bis zum Abschluss

Ein sinnvoller Workflow beschreibt den gesamten Weg eines Dokuments. Für einen Dokumenttyp prüfen wir:

1. Quelle. Das Dokument kommt per E-Mail, Formular, Kundenportal, Scanner oder API oder wird von einem Mitarbeitenden erstellt.
2. Erfassung und Beschreibung. Wir legen Kennung, Dokumenttyp, wichtige Daten und die Prüfung auf fehlende Angaben fest.
3. Vollständigkeitsprüfung. Das System kann Pflichtfelder und Anlagen kontrollieren. Entscheidungen, die eine Bewertung erfordern, bleiben bei der zuständigen Person.
4. Verantwortung. Das Dokument wird der Rolle oder Person zugewiesen, die den nächsten Schritt ausführt.
5. Entscheidung. Je nach vereinbartem Ablauf kann ein Nutzer freigeben, ablehnen, eine Korrektur anfordern oder den Vorgang weiterleiten.
6. Übergabe des Ergebnisses. Daten oder Entscheidungen können an CRM, ERP, Buchhaltung, B2B-Portal oder ein anderes vereinbartes System übergeben werden.
7. Status und Historie. Berechtigte Personen sehen den aktuellen Schritt, die ausgeführte Aktion und die für die Weiterarbeit benötigten Informationen.

Das System kann Reihenfolge, Pflichtangaben, Fristen und Informationsübergaben absichern. Es sollte keine geschäftliche Entscheidung selbst treffen, solange dafür keine klare Regel und Verantwortung festgelegt wurde.

Ablage, fertiges DMS, Integration oder eigenes Modul?

Die Lösung muss zum tatsächlichen Problem passen. Die teuerste oder umfangreichste Variante ist nicht automatisch die beste.

Wir helfen beim Vergleich dieser Richtungen, wählen die Technik aber nicht allein aufgrund des Begriffs „DMS“. Zuerst beschreiben wir einen Ablauf und prüfen, was er wirklich benötigt.

Was klären wir vor Projektbeginn?

Dokumenttypen und Quellen

Wir prüfen, welche Dokumente zum Prozess gehören, woher sie kommen, welche Formate sie haben und ob sie eine verlässliche gemeinsame Kennung besitzen. Rechnungen, Verträge, Anträge, Protokolle und Formulare können jeweils einen anderen Ablauf brauchen.

Rollen und Berechtigungen

Wir legen fest, wer ein Dokument sehen oder ändern darf, wer entscheidet und wer nur das Ergebnis einsehen kann. Berechtigungen müssen zur Rolle und zum Prozessschritt passen. Das bloße Ausblenden einer Schaltfläche reicht nicht aus.

Status, Entscheidungen und Ausnahmen

Wir beschreiben den normalen Weg ebenso wie fehlende Angaben, Korrekturen, zusätzliche Freigaben und Situationen, in denen der Vorgang nicht fortgesetzt werden kann. Ein klarer Umgang mit Ausnahmen ist genauso wichtig wie der Hauptablauf.

Versionen und Historie

Wir bestimmen, wann eine neue Version entsteht, welche Version aktuell ist und welche Aktionen in der Historie bleiben. Umfang der Historie sowie Regeln zum Ändern oder Löschen richten sich nach den Anforderungen des Unternehmens.

Quell- und Zielsysteme

Wir benennen das System, das Dokument, Daten, Status und endgültige Entscheidung führt. Wenn mehrere Programme dieselbe Information ändern können, braucht es eine eindeutige Datenquelle und klare Synchronisationsregeln.

Aufbewahrung, Export und Sicherungen

Aufbewahrungsfristen, Export, Löschung, Datensicherung und Wiederherstellung müssen für das konkrete Projekt vereinbart werden. Ein System ist nicht automatisch rechtskonform, nur weil es eine Historie speichert oder den Zugriff einschränkt.

Mit einem Workflow beginnen

Der erste Schritt muss nicht alle Dokumente des Unternehmens umfassen. Häufig ist es sinnvoller, einen Dokumenttyp von seiner Quelle bis zum abgeschlossenen Ergebnis zu führen.

Ein erster Abschnitt kann umfassen:

• eine Dokumentquelle;
• notwendige Daten und eine Vollständigkeitsprüfung;
• zwei oder drei Rollen;
• Freigabe, Ablehnung und Rückgabe zur Korrektur;
• ein Zielsystem oder eine manuelle Bestätigung des Ergebnisses;
• einen klaren Status und eine grundlegende Aktionshistorie;
• vereinbarte Testfälle und Abnahmekriterien.

Ein kleiner Umfang ist nur sinnvoll, wenn daraus ein nutzbarer, geschlossener Prozess entsteht. Er sollte nicht dort enden, wo Mitarbeitende weiterhin dieselben Daten übertragen müssen oder ein Dokument ohne Verantwortlichen bleibt.

Wie prüfen wir den ersten Abschnitt?

Abnahmekriterien ergeben sich aus dem Prozess, nicht nur aus der Darstellung der Oberfläche. Beispielsweise prüfen wir, ob:

• das Dokument eine eindeutige Kennung erhält und in den richtigen Workflow gelangt;
• fehlende Pflichtangaben die Übergabe stoppen und verständlich gemeldet werden;
• jede Rolle nur erlaubte Dokumente und Aktionen sieht;
• Freigabe, Ablehnung und Korrekturanforderung zum richtigen nächsten Schritt führen;
• erneutes Senden oder eine unterbrochene Verbindung keine unkontrollierte Kopie erzeugt;
• an ein anderes Programm übergebene Daten dem Quelldokument zugeordnet werden können;
• ein Integrationsfehler einen Status und die für eine Reaktion nötigen Informationen hinterlässt;
• die Historie den Ablauf des getesteten Falls nachvollziehbar macht.

Diese Kriterien vereinbaren wir vor der Abnahme. Das Ergebnis ist damit aussagekräftiger als die bloße Feststellung, dass eine Datei gespeichert oder ein Formular abgeschickt wurde.

Integration mit vorhandenen Programmen

Ein digitaler Dokumentenworkflow kann mit CRM, ERP, Buchhaltung, B2B-Portal, Lagerverwaltung oder einer anderen Anwendung zusammenarbeiten. Eine Integration bestätigen wir erst nach Prüfung von Dokumentation, Berechtigungen, Datenformaten und Bedingungen des Anbieters.

Programme, die ihre Kernaufgaben gut erfüllen, müssen nicht automatisch ersetzt werden. Eine kontrollierte Verbindung kann die richtige Lösung sein. Manchmal fehlen jedoch nicht Schnittstellen, sondern klare Verantwortlichkeiten und Entscheidungen. Das lässt sich durch eine Integration allein nicht beheben.

Lesen Sie auch über Systemintegrationen und APIs sowie individuelle CRM- und ERP-Systeme.

Erfahrung: HUB.ITM.PL

Um 2018 entwickelten wir ein System für eine große Steuerkanzlei, die Daten aus mehreren Programmen und Dateiformaten erhielt. Es verarbeitete unter anderem rechnungsbezogene Daten aus Comarch ERP Optima, Sage Symfonia ERP, JPK-FA und UBER-Quellen sowie XML-, XLS- und CSV-Dateien.

Das System las, ordnete und prüfte die Daten und erstellte anschließend EDI++-Dateien für den Import in Subiekt GT und Subiekt nexo. Dadurch musste die Kanzlei Daten aus Tausenden Rechnungen nicht mehr vollständig manuell übertragen und konnte weitere Mandanten ohne proportional steigenden manuellen Aufwand betreuen.

Das historische System wird nicht mehr genutzt, weil sich Formate und Austauschwege geändert haben. HUB.ITM.PL war kein vollständiges DMS, sondern eine Import- und Transformationsschicht für Dokumentendaten. Deshalb dient es nicht als Nachweis für Versionierung, Freigaben, Aufbewahrung oder Dokumentenspeicherung.

Lesen Sie die vollständige Fallstudie zu HUB.ITM.PL.

Sicherheit, Historie und rechtliche Anforderungen

Dokumente können personenbezogene Daten, Geschäftsbedingungen, Finanzinformationen und andere vertrauliche Inhalte enthalten. Deshalb sollte das Projekt unter anderem festlegen:

• Rollen und das Prinzip der minimal erforderlichen Rechte;
• die Anmeldung der Nutzer;
• den benötigten Verlauf von Aktionen und Änderungen;
• Regeln für Export, Sicherung und Wiederherstellung;
• den Transfer von Dokumenten zwischen Systemen;
• Aufbewahrungsfristen und die Verantwortung für ihre Festlegung;
• den Entzug von Zugriffsrechten bei Rollenwechsel oder Ende der Zusammenarbeit.

Eine technische Lösung garantiert nicht automatisch die Einhaltung von DSGVO, KSeF, Buchführungsregeln oder branchenspezifischen Anforderungen. Diese Vorgaben müssen vor der Bestätigung des Umfangs benannt, geprüft und verantwortlichen Stellen zugeordnet werden.

Senden Sie über das Kontaktformular keine echten Rechnungen, Verträge, Kundendaten, Passwörter, API-Schlüssel oder Datenbankkopien. Für den Anfang genügt ein sicheres Muster ohne personenbezogene und vertrauliche Angaben oder eine Beschreibung seiner Struktur.

Wie beginnen wir die Zusammenarbeit?

1. Wir klären den Bedarf kurz. Wir stellen fest, welches Dokument Probleme verursacht, woher es kommt und was danach geschehen soll. Ein kurzes Gespräch ersetzt keine Analyse eines komplexen Prozesses.
2. Wir beschreiben einen Workflow. Wir erfassen Rollen, Entscheidungen, Daten, Ausnahmen, vorhandene Programme und das erwartete Ergebnis.
3. Wir wählen die Richtung. Wir prüfen, ob Ablage, fertiges DMS, Integration, kleineres Modul oder eine prozessspezifische Lösung passt.
4. Wir definieren den ersten Abschnitt. Wir vereinbaren Umfang, Abnahmekriterien, Risiken, Termin und individuellen Preis.
5. Wir entwickeln und testen den gesamten Ablauf. Wir prüfen Normalfall, fehlende Daten, Korrektur, Ablehnung, Wiederholung und Verbindungsfehler.
6. Wir planen weitere Workflows. Zusätzliche Dokumenttypen, Rollen und Integrationen werden als getrennt vereinbarte Abschnitte umgesetzt.

Umfasst der Prozess viele Abteilungen, Dokumenttypen, Ausnahmen oder unklare Integrationen, kann eine Business-Analyse mit Festlegung des MVP-Umfangs der erste bezahlte Abschnitt sein.

Häufige Fragen

Benötigen wir ein vollständiges DMS?

Nicht immer. Geht es vor allem um Benennung, Zugriff und Auffindbarkeit, kann eine strukturierte Ablage genügen. Durchläuft ein Dokument Entscheidungen, Ausnahmen und mehrere Systeme, sollten DMS, Integration oder eigenes Modul geprüft werden.

Mit welchem Dokument sollten wir beginnen?

Am besten mit einem Dokument, das einen klaren Anfang und ein klares Ende hat, häufig manuell bearbeitet wird und wiederkehrende Probleme verursacht. Der erste Workflow braucht einen Verantwortlichen, bekannte Rollen und ein messbares Abnahmekriterium.

Lässt sich der Workflow mit unserem CRM, ERP oder Buchhaltungsprogramm verbinden?

Das ist häufig möglich. Zuvor müssen jedoch das konkrete Programm, seine Dokumentation, Berechtigungen, Datenformate und Lizenzbedingungen geprüft werden. Vor dieser Prüfung bestätigen wir keine Integration.

Kann das System Freigaben, Korrekturen und Ablehnungen abbilden?

Ja, wenn Rollen, mögliche Entscheidungen und der nächste Schritt für jedes Ergebnis klar festgelegt sind. Den genauen Umfang vereinbaren wir für den ausgewählten Workflow.

Können Entscheidungsverlauf und rollenbasierter Zugriff erhalten bleiben?

Diese Anforderungen können eingeplant werden. Dafür muss feststehen, welche Aktionen in der Historie bleiben, wer sie sehen darf und ob oder wann Daten geändert oder gelöscht werden können.

Gehören OCR, elektronische Signatur oder KSeF zum Projekt?

Sie sind kein automatischer Bestandteil jedes Projekts. Wir können den Bedarf prüfen, der Umfang hängt jedoch von Anbieter, Dokumentqualität, Dokumentation, Berechtigungen, Kosten und rechtlichen Anforderungen ab.

Müssen wir unsere bestehenden Systeme ersetzen?

Nein. Erfüllen sie ihre Hauptaufgaben, kann eine Integration oder ein kleineres Modul genügen. Ein Austausch wird erst relevant, wenn ihre Grenzen den vereinbarten Workflow blockieren.

Wie bereiten wir ein Beispieldokument vor?

Entfernen Sie personenbezogene Daten, Kontonummern, vertrauliche Beträge, Unterschriften, Kundendaten und Geschäftsgeheimnisse. Alternativ können Sie die Felder, die Quelle und die erforderlichen Entscheidungen beschreiben.

Wovon hängen Kosten und Termin ab?

Entscheidend sind Dokumenttypen, Rollen, Entscheidungen, Ausnahmen, Integrationen, Datenmigration, Sicherheitsanforderungen, Historie und Wartung. Umfang, Termin und Preis vereinbaren wir individuell, nachdem die nötigen Informationen vorliegen.

Was sollten Sie zuerst senden?

Beschreiben Sie in Ihrer ersten Nachricht:

• einen Dokumenttyp, mit dem Sie beginnen möchten;
• Quelle und Form des Dokuments;
• wer prüft, freigibt, korrigiert oder ablehnt;
• wo der aktuelle Status geführt wird;
• welche Daten heute manuell übertragen werden;
• welche Programme im Prozess bleiben müssen;
• die häufigste Ausnahme oder Fehlerart;
• woran Sie erkennen, dass der erste Abschnitt richtig funktioniert.

Eine technische Spezifikation oder echte Dokumente sind zunächst nicht erforderlich. Anhand der Beschreibung prüfen wir, ob eine Schätzung möglich ist oder zunächst eine Prozessanalyse benötigt wird.

CTA: Lassen Sie uns den ersten Dokumentenworkflow besprechen

Wenn Sie die grundlegenden Informationen zunächst selbst ordnen möchten, nutzen Sie das kostenlose Werkzeug zur Projektbeschreibung.

Lesen Sie auch über Systemintegrationen und APIs, individuelle CRM- und ERP-Systeme, B2B-Portale und Bestellsysteme sowie Business-Analyse und MVP-Umfang.