Direkt zum Inhalt

26. April 2026ConsultingDigitalisierungTransformationUnternehmen

Prozessoptimierung im Mittelstand: Warum Systeme nicht schuld sindProcess Optimization in the Mittelstand: Why Systems Are Not to Blame

Wenn das System als Sündenbock herhalten muss „Das System ist schuld.“ Dieser Satz fällt in jedem zweiten Projektgespräch, wenn ein CRM zäh läuft oder ein ERP-Wechsel klemmt. Er ist bequem, weil er niemanden im Raum …The system is to blame is a common line in stalled CRM or ERP projects, but it is almost always wrong: the real issue is workflows that were introduced but never documented.

kurz gesagt

  • Das System ist fast nie schuld. Wenn ein CRM zäh läuft oder eine ERP-Einführung klemmt, liegt die Ursache meistens in Abläufen, die eingeführt, aber nie dokumentiert wurden.
  • Dokumentieren heißt entscheiden. Jede Prozessfrage, die im Laufe der Aufnahme auftaucht, ist eine Entscheidung, die bisher nie getroffen wurde.
  • Fünf Kernprozesse, je eine Seite. Mehr braucht es für den Anfang nicht. Wen es betrifft, in welcher Reihenfolge, und wer verantwortlich ist.

Wenn das System als Sündenbock herhalten muss

"Das System ist schuld." Dieser Satz fällt in jedem zweiten Projektgespräch, wenn ein CRM zäh läuft oder eine ERP-Einführung klemmt. Er ist bequem, weil er niemanden im Raum trifft. Und er ist fast immer falsch.

Die ehrliche Diagnose lautet in den meisten Fällen: Das Unternehmen hat Abläufe eingeführt, aber nie dokumentiert. Das System bildet dieses Durcheinander ab, und zwar gnadenlos sichtbar. Das macht die Software zum Spiegel, nicht zum Schuldigen.

Was undokumentierte Prozesse wirklich kosten

Wenn Abläufe nur in Köpfen existieren, führt jeder sie ein bisschen anders aus. Ein Mitarbeiter pflegt Kundendaten sofort ein, der andere sammelt sie am Freitag. Ein System kann diese Varianten nicht versöhnen. Es verlangt eine verbindliche Antwort auf die Frage, wie der Prozess läuft, und diese Antwort gibt es nicht.

Die Folgen sind bekannt: endlose Abstimmungsschleifen im Projekt, Sonderlösungen in der Konfiguration, Frust bei den Nutzern. Am Ende steht ein Werkzeug, das keiner mag, nicht weil die Software schlecht wäre, sondern weil sie Klarheit voraussetzt, die nie geliefert wurde.

Diese Konstellation beschreibt der Beitrag Prozessoptimierung im KMU: Erst Klarheit, dann Tools aus einem anderen Blickwinkel: Was vor der Softwareentscheidung stehen muss.

Dokumentieren heißt entscheiden

Prozessdokumentation klingt nach Bürokratie. Gemeint ist etwas anderes: die eine verbindliche Antwort darauf, wie ein Ablauf im Unternehmen funktioniert. Wer legt Kunden an, mit welchen Pflichtfeldern. Wann gilt ein Auftrag als erteilt. Wer darf Rabatte freigeben.

Jede dieser Fragen ist eine Entscheidung. Das Aufschreiben ist der leichte Teil. Der wertvolle Teil ist, dass die Entscheidung überhaupt einmal getroffen wird, statt täglich neu und jedes Mal anders. Dieser Moment, in dem eine Frage aufhört, immer wieder neu beantwortet werden zu müssen, ist der eigentliche Wert der Dokumentation.

Wie du pragmatisch vorgehst

  1. Fünf Prozesse auswählen. Nimm die Abläufe, die dein Geschäft tragen: vom Lead bis zur Rechnung.
  2. Für jeden Ablauf eine Seite anlegen. Auslöser, Schritte, Verantwortliche, Ergebnis. Mehr braucht es nicht für den Anfang.
  3. Mit den Ausführenden erstellen. Nicht für sie, sondern mit ihnen. Wer mitgeschrieben hat, trägt das Ergebnis mit.
  4. Für verbindlich erklären. Ein Dokument, das jeder ignorieren kann, ist kein Dokument. Es braucht eine Entscheidung, wer es pflegt und wie Abweichungen gehandhabt werden.
  5. Erst dann Software. Mit klaren Prozessen startet jede Einführung kürzer, mit weniger Reibung und schnellerer Akzeptanz im Team.

Wie du dabei Engpässe erkennst und einzeichnest, zeigt der Beitrag Prozessoptimierung: Abläufe visualisieren und Engpässe lösen.

Was das mit Führung zu tun hat

Prozessdokumentation ist keine IT-Aufgabe und keine Qualitätsmanagement-Aufgabe. Sie ist eine Führungsaufgabe. Die Fragen, die bei der Aufnahme auftauchen, zum Beispiel wer Rabatte freigeben darf oder ab wann ein Auftrag als verbindlich gilt, sind Entscheidungen, die die Geschäftsführung treffen muss.

Ich erlebe in Projekten regelmäßig, dass diese Entscheidungen jahrelang offen waren. Nicht weil sie niemanden interessierten, sondern weil das Tagesgeschäft sie nie erzwungen hat. Die Aufnahme erzwingt sie. Das macht sie unbequem und nützlich.

Drei Fragen für deinen nächsten Schritt

  • Welche Entscheidung in deinem Unternehmen wird täglich neu und jedes Mal anders getroffen, weil sie nie verbindlich festgehalten wurde?
  • Gibt es für deine fünf wichtigsten Prozesse jeweils eine Seite, die beschreibt, wie der Ablauf tatsächlich funktioniert?
  • Wer in deinem Unternehmen hat die Autorität, diese Entscheidungen zu treffen und als verbindlich zu erklären?

Mehr zum Vorgehen findest du unter Consulting und unter core+.

in short

  • The system is almost never to blame. When a CRM runs slowly or an ERP rollout stalls, the cause is usually workflows that were introduced but never documented.
  • Documenting means deciding. Every process question that surfaces during mapping is a decision that was never made.
  • Five core processes, one page each. That is all that is needed to start. Who is involved, in which order, and who is responsible.

When the system takes the blame

"The system is to blame." That sentence comes up in every second project conversation when a CRM runs slowly or an ERP rollout stalls. It is comfortable because it targets no one in the room. And it is almost always wrong.

The honest diagnosis in most cases: the company introduced workflows but never documented them. The system maps this disorder, and it does so mercilessly. That makes the software a mirror, not a culprit.

What undocumented processes actually cost

When workflows exist only in people's heads, everyone executes them slightly differently. One employee enters customer data immediately; another batches it on Fridays. A system cannot reconcile these variants. It requires a definitive answer to how the process runs, and that answer does not exist.

The consequences are predictable: endless coordination loops in the project, special configurations, frustration among users. The result is a tool nobody likes, not because the software is poor but because it requires clarity that was never provided.

This pattern is described from a different angle in Process Optimization in SMEs: Clarity Before Tools: what must come before any software decision.

Documenting means deciding

Process documentation sounds like bureaucracy. It means something different: the one definitive answer to how a workflow runs in this company. Who creates customer records and with which required fields. When is an order considered confirmed. Who may approve discounts.

Each of these is a decision. Writing it down is the easy part. The valuable part is that the decision gets made once, instead of being made differently every day. That moment when a question stops needing to be answered repeatedly is the real value of documentation.

How to proceed pragmatically

  1. Select five processes. Pick the workflows that carry the business: from lead to invoice.
  2. Create one page per process. Trigger, steps, responsible persons, outcome. That is enough to start.
  3. Create with the people who run it. Not for them, with them. Those who helped write it will support the result.
  4. Declare it binding. A document everyone can ignore is not a document. Someone needs to own it and handle deviations.
  5. Only then consider software. Starting an implementation with clear processes shortens it, reduces friction, and speeds up team acceptance.

How to identify and mark bottlenecks during that mapping is shown in Process Optimization: Visualizing Workflows, Fixing Bottlenecks.

What this has to do with leadership

Process documentation is not an IT task or a quality management task. It is a leadership task. The questions that come up during the mapping, such as who may approve discounts or when an order counts as binding, are decisions that management must make.

In projects I regularly find that these decisions have been open for years. Not because no one cared, but because daily operations never forced them. The mapping forces them. That makes it uncomfortable and useful.

Three questions for your next step

  • Which decision in your company gets made differently every day because it was never written down as binding?
  • For each of your five most important processes, is there a page that describes how the workflow actually runs?
  • Who in your company has the authority to make those decisions and declare them binding?

More on the approach at Consulting and core+.

Häufige FragenFrequently asked questions

Wie ausführlich muss eine Prozessdokumentation sein?How detailed does process documentation need to be?

Für den Anfang reicht eine Seite je Prozess: Auslöser, Schritte, Verantwortliche, Ergebnis. Ausführlichkeit hilft erst, wenn ein Ablauf stabil läuft und neue Mitarbeitende eingearbeitet werden sollen.One page per process is enough to start: trigger, steps, responsible persons, outcome. More detail only helps once a workflow runs stably and new employees need to be onboarded.

Wer pflegt die Prozessdokumentation?Who maintains process documentation?

Der namentliche Eigentümer des Prozesses. Nicht die IT, nicht das Qualitätsmanagement. Wer den Ablauf verantwortet, aktualisiert die Beschreibung, wenn sich etwas ändert.The named owner of the process. Not IT, not quality management. Whoever is accountable for the workflow updates the description when something changes.

Was passiert, wenn Prozesse nicht dokumentiert sind?What happens when processes are not documented?

Jede Person führt sie ein bisschen anders aus. Systeme, die eingeführt werden sollen, stoßen auf viele Varianten statt auf einen klaren Ablauf. Abstimmungsschleifen verlängern das Projekt, und die Akzeptanz sinkt.Each person runs them slightly differently. Systems introduced later encounter many variants instead of one clear workflow. Coordination loops extend the project, and acceptance by the team falls.

WeiterlesenKeep reading

← zurück zum herrlichblog← back to the herrlichblog