Projekte werden belegt, nicht behauptet.
WIRKLAUF veröffentlicht Kundennamen, Logos, Ergebnisse und Kennzahlen nur, wenn sie real, freigegeben und ausreichend belegt sind. Bis dahin ersetzt WIRKLAUF fehlende Referenzen nicht durch Fantasiekunden oder anonyme Erfolgszahlen.
Zum Start zeigt diese Seite deshalb vor allem Methoden- und Funktionsnachweise: wie WIRKLAUF einen betrieblichen Ablauf modelliert, Fachlogik baut und mit Fehlerzuständen umgeht.
WIRKLAUF Operations Demonstrator
Der Demonstrator bildet einen technischen Serviceablauf ab:
- ANFRAGE
- PRÜFUNG
- ERP-AUFTRAG
- ZUWEISUNG
- BEARBEITUNG
- DOKUMENTATION
- ABSCHLUSS
- SYNCHRONISIERUNG
Er zeigt bewusst nicht nur den Normalfall.
- Fachregel
Ein Auftrag kann nicht abgeschlossen werden, solange verpflichtende Dokumentation fehlt.
- Fachliche Ausnahme
Eine Abweichung vom vereinbarten Umfang erzeugt einen Klärfall, den eine verantwortliche Person entscheiden muss.
- Technischer Fehler
Scheitert die ERP-Synchronisierung vorübergehend, bleibt der fachliche Auftrag abgeschlossen. Nur die technische Übertragung erhält einen Wiederholversuch.
- Nachvollziehbarkeit
Änderungen und Zustandswechsel bleiben im Verlauf sichtbar.
Arbeitsliste · 1 Auftrag
A-1042
Technischer Service
In Bearbeitung
Zuständigkeit
Techniker
Zuweisung aktiv seit 09:48
Auftrag A-1042 · Beispielbetrieb
Prüfung und Wiederinbetriebnahme einer Anlage
Zeitfenster
Heute · 10:00–12:00
Fachlicher Status
In Bearbeitung
Integrationsstatus
Keine offene Integration
Auftrag in Bearbeitung
Nächste zulässige Aktion: Dokumentation vervollständigen
- Arbeitszusammenfassungoffen
- Ergebnisoffen
- Sicherheitsprüfungbestätigt
- Funktionsprüfungoffen
- Abschlussoffen
Historie
- 09:41FachlichAuftrag aus ERP übernommenBüro / Disposition
- 09:48FachlichTechniker zugewiesenBüro / Disposition
- 10:07FachlichBearbeitung gestartetTechniker
- 11:18PrüfungAbschluss versucht – Pflichtprüfung offenTechniker
- 11:26FachlichDokumentation vervollständigtTechniker
- 11:27TechnischERP-Rückmeldung fehlgeschlagenIntegration
- 11:29TechnischWiederholversuch erfolgreichIntegration
Technikeransicht · A-1042
Auftrag in Bearbeitung
Auftragskopf
A-1042
Nächster Schritt
Pflichtprüfung
Funktionsprüfung
Dokumentation
Abschluss
Musterbrief zum Kernhebel-Check
ILLUSTRATIVES BEISPIEL · KEIN KUNDENPROJEKT · KEINE GEMESSENEN ERGEBNISSE
01 — Entscheidung auf einen Blick
Entscheidung
Der betrachtete Serviceprozess sollte nicht durch den Ersatz des bestehenden ERP verändert werden. Der größte praktische Hebel liegt davor und daneben: Anfragen müssen strukturiert erfasst, Pflichtinformationen vor der Auftragsanlage geprüft und operative Arbeit nach der ERP-Auftragsanlage in einer kleinen, gezielten Anwendung geführt werden.
Empfohlene Intervention
- Strukturierte Erfassung + Pflichtvalidierung + bestehendes ERP + gezielte Integration + kleine operative Web-Anwendung.
Warum diese Intervention
Der heute sichtbare Aufwand entsteht nicht primär dadurch, dass das ERP kaufmännische Aufträge schlecht verwaltet. Er entsteht an den Übergängen: unstrukturierte Anfrage, mehrfaches Nachtragen, fehlende Pflichtinformationen, manuelle Übertragung, unklare operative Zuständigkeit und fehlender transparenter Fehler-/Ausnahmeweg.
Ein vollständiger Plattformersatz würde deshalb einen großen Teil funktionierender Logik neu bauen, ohne den Kern der beobachteten Reibung proportional besser zu lösen.
Nicht empfohlen
- vollständiger ERP-Ersatz;
- isolierte RPA-Automatisierung auf dem bestehenden E-Mail-/Excel-Ablauf;
- reine „KI-Automatisierung“ ohne stabile Daten- und Prozessbasis;
- neue Komplettplattform für CRM, ERP, Disposition und Service in einem Schritt.
Vor Umsetzung noch zu klären
- technische Integrationsmöglichkeiten des konkreten ERP;
- tatsächlich benötigte Pflichtdaten pro Serviceart;
- Häufigkeit und Typen fachlicher Ausnahmen;
- Rollen/Rechte für Disposition, Techniker und fachliche Freigabe;
- Baseline-Messung für spätere Wirkungsbewertung.
02 — Umfang
Im Check betrachtet
Ein abgegrenzter Ablauf:
Betrachtete Rollen:
- Büro / Disposition;
- operative Mitarbeitende / Techniker;
- fachlich verantwortliche Leitung;
- bestehendes ERP als kaufmännisches Kernsystem.
Von der eingehenden Serviceanfrage bis zur dokumentierten Rückmeldung des erledigten Auftrags an das bestehende ERP.
Nicht betrachtet
- Rechnungsstellung und Zahlungsprozess;
- Lager-/Materialwirtschaft;
- komplexe Touren- oder Schichtoptimierung;
- vollständige CRM-Funktion;
- Finanzbuchhaltung;
- HR;
- langfristige Produktstrategie des ERP-Anbieters.
03 — IST-Ablauf
Heutiger beispielhafter Ablauf
- Eine Kundenanfrage trifft per E-Mail oder Telefon ein.
- Ein Mitarbeiter liest und interpretiert die Angaben.
- Relevante Informationen werden in einer Excel-Liste erfasst.
- Fehlende Angaben werden per E-Mail oder Telefon nachgefordert.
- Die Excel-Zeile wird aktualisiert.
- Ein kaufmännischer Auftrag wird manuell im ERP angelegt.
- Termin und Zuständigkeit werden außerhalb des ERP abgestimmt.
- Der Techniker erhält die Informationen über Telefon, E-Mail oder weitergeleitete Unterlagen.
- Nach Durchführung wird die Dokumentation manuell zurückgespielt.
- Offene Punkte und technische Übertragungsprobleme sind nur teilweise transparent.
Prozessbild
Die Darstellung ist bewusst einfach. Für die Entscheidung zählt nicht die Anzahl gezeichneter Kästchen, sondern wo Reibung entsteht und wodurch sie verursacht wird.
ANFRAGE → E-MAIL/TELEFON → EXCEL → NACHFRAGE → EXCEL → ERP → DISPOSITION → TECHNIKER → DOKUMENTATION → ERP
04 — Reibungsbild
| Reibung | Beobachtung im illustrativen Szenario | Evidenzstatus |
|---|---|---|
| Doppelerfassung | dieselben Auftragsinformationen werden in E-Mail, Excel und ERP verarbeitet | BEOBACHTET |
| Wartezeit | fehlende Pflichtangaben werden erst nach manueller Prüfung erkannt | BEOBACHTET |
| Medienbruch | Informationen wechseln zwischen Mail, Excel, Telefon und ERP | BEOBACHTET |
| Übergabeverlust | operative Informationen erreichen den Techniker nicht immer strukturiert | HYPOTHESE |
| Statusblindheit | der aktuelle operative Stand ist nicht an einer Stelle zuverlässig sichtbar | KUNDENANGABE |
| Nacharbeit | unvollständige Erfassung erzeugt spätere Rückfragen und Korrekturen | HYPOTHESE |
| Personenabhängigkeit | Wissen über Sonderfälle liegt teilweise bei einzelnen Mitarbeitenden | KUNDENANGABE |
| Systemgrenze | ERP bildet kaufmännischen Auftrag ab, aber nicht den gesamten operativen Arbeitszustand | BEOBACHTET |
05 — Evidenz & Baseline
Was als Baseline erhoben werden sollte
Vor einer Umsetzungsentscheidung werden nicht wahllos Kennzahlen gesammelt. Relevant sind die Größen, an denen die vermutete Wirkung später überprüft werden kann:
- Bearbeitungszeit für Erfassung und Auftragsanlage;
- Wartezeit auf fehlende Angaben;
- gesamte Durchlaufzeit von Anfrage bis disponierbarem Auftrag;
- Anzahl manueller Übertragungen;
- Anzahl Rückfragen wegen fehlender oder widersprüchlicher Angaben;
- Nacharbeit/Korrekturen;
- offene Statusanfragen;
- Anteil fachlicher Ausnahmen;
- Anteil technischer Übertragungsfehler;
- verbleibende manuelle Arbeit nach einer möglichen Automatisierung.
Was noch offen ist
In diesem illustrativen Beispiel existieren keine belastbaren gemessenen Ausgangswerte. Deshalb werden weder Einsparungen noch Renditezahlen behauptet.
Das ist kein Mangel des Briefs, sondern eine Entscheidungsregel:
Wo die Baseline fehlt, bleibt sie OFFEN.
06 — Ursachenbild
Symptom 1: Informationen werden mehrfach übertragen
Symptom 2: Viele Rückfragen
Symptom 3: Status ist unklar
Symptom 4: Fehler bei der ERP-Rückmeldung verschwinden im Alltag
07 — Kernhebel
Kernhebel
Aus einer unstrukturierten Anfrage wird vor der kaufmännischen und operativen Weiterverarbeitung ein vollständiger, fachlich geprüfter Vorgang mit klarer Zuständigkeit und nachvollziehbarem Zustand.
Warum dieser Hebel höher priorisiert wird
Er beeinflusst mehrere Reibungen gleichzeitig:
Der Hebel ist damit nicht einfach „das größte Problem“, sondern der Punkt, an dem eine Änderung mehrere nachgelagerte Reibungen gleichzeitig adressiert.
- Doppelerfassung wird reduzierbar;
- fehlende Pflichtdaten werden früher erkannt;
- die ERP-Auftragsanlage kann gezielt integriert werden;
- die operative Übergabe erhält eine stabile Datenbasis;
- Status und Ausnahmen können explizit geführt werden;
- technische Fehler können vom fachlichen Zustand getrennt behandelt werden.
08 — Fachlicher SOLL-Ablauf
Wichtige Prinzipien
- Kunden- und kaufmännische Auftragsidentität bleiben im ERP führend.
- Die operative Anwendung hält nur die Fachlogik, die im bestehenden System fehlt.
- Ein Auftrag kann nur in zulässigen Zuständen weiterlaufen.
- Fehlende Pflichtdokumentation blockiert den Abschluss konkret.
- Fachliche Ausnahmen werden einem verantwortlichen Menschen zugewiesen.
- Technische Übertragungsfehler erzeugen einen Wiederanlaufpfad, keinen erfundenen Fachstatus.
- Jede produktive Automatisierung besitzt Verantwortung und Betriebsbeobachtung.
ANFRAGE → STRUKTURIERTE ERFASSUNG → PFLICHTVALIDIERUNG → ERP-AUFTRAG → OPERATIVE ZUWEISUNG → BEARBEITUNG → DOKUMENTATION → FACHLICHER ABSCHLUSS → ERP-RÜCKMELDUNG
09 — Interventionsvergleich
Entscheidungskriterium
Nicht „welche Lösung ist technisch am beeindruckendsten?“, sondern:
Welche Intervention löst den Kernhebel mit dem kleinsten vertretbaren Eingriff in den funktionierenden Bestand?
| Option | Was sie löst | Was offen bleibt | Einordnung |
|---|---|---|---|
| Prozess nur organisatorisch vereinfachen | Zuständigkeiten und Reihenfolge können klarer werden | unstrukturierter Eingang, Systembrüche, technische Übertragung | Teilmaßnahme – sinnvoll als Grundlage |
| bestehende ERP-Funktionen stärker nutzen | kann einzelne Erfassungs-/Statusprobleme reduzieren | operative Lücke bleibt, falls ERP sie fachlich nicht trägt | zuerst prüfen |
| Standard-Service-Software einführen | kann viele Anforderungen abdecken | Passung, Migration, ERP-Kopplung und unnötiger Funktionsumfang offen | ernsthaft prüfen, wenn sie gut passt |
| nur ERP-Schnittstelle bauen | reduziert manuelle Übertragung | unstrukturierte Anfrage und operative Zustände bleiben | zu eng als alleinige Maßnahme |
| Automatisierung auf die heutigen Werkzeuge setzen | kann einzelne Klicks reduzieren | automatisiert ggf. einen instabilen Ablauf und Excel-Abhängigkeit | nicht als erster Hebel |
| ERP vollständig ersetzen | könnte Systemlandschaft vereinheitlichen | großer Umfang, Migration, Risiko; kaufmännischer Kern funktioniert bereits | unverhältnismäßig |
| strukturierte Erfassung + ERP + kleine operative Anwendung + Integration | adressiert Eingang, Validierung, Übergabe, Status und Rückmeldung gezielt | erfordert saubere fachliche Regeln und Integrationsprüfung | bevorzugte Intervention |
10 — Empfehlung
Zielarchitektur
Pflichtinformationen abhängig von Serviceart; Plausibilitätsprüfung vor Auftragsanlage.
Bleibt führend für Kunden-/Auftragsidentität und kaufmännische Verarbeitung.
Erzeugt/referenziert ERP-Aufträge und synchronisiert dokumentierte Ergebnisse. Datenverantwortung und Fehlerpfad werden pro Objekt festgelegt.
Führt Zuweisung, Arbeitszustand, Pflichtdokumentation, fachliche Klärfälle und Verlauf.
Normale, regelklare Schritte können automatisch laufen; fachliche Ausnahmen bleiben bei der zuständigen Rolle.
Warum keine größere Plattform
Die Empfehlung ersetzt keine funktionierende kaufmännische Kernlogik. Sie baut nur die fehlende operative Schicht und Verbindung.
11 — Wirtschaftlichkeitsbetrachtung
Heutige Kosten / Aufwand
- manuelle Erfassungszeit;
- Wartezeit und Koordinationsaufwand;
- Nacharbeit durch fehlende Angaben;
- Status-/Rückfragen;
- Fehler-/Ausnahmebehandlung;
- Personenabhängigkeit.
Zukünftige laufende Kosten
- Softwarebetrieb/Hosting;
- mögliche Lizenzen;
- Integration/Schnittstelle;
- Betriebsüberwachung;
- Wartung und Änderungen;
- verbleibende menschliche Arbeit für Ausnahmen;
- interne Verantwortung.
Entscheidungsregel
Die Umsetzung ist wirtschaftlich dann plausibel, wenn der erwartete betriebliche Nutzen über einen sinnvollen Betrachtungszeitraum die Investition und laufende Folgekosten rechtfertigt und die relevanten Annahmen messbar gemacht werden können.
Ein positives Projektgefühl ersetzt keine Baseline.
Dieser Musterbrief enthält bewusst keine erfundenen Einsparungszahlen. Eine echte Wirtschaftlichkeitsrechnung würde mindestens folgende Größen vergleichen:
12 — Risiken & offene Fragen
| Thema | Status | Bedeutung vor Umsetzung |
|---|---|---|
| ERP-Schnittstelle / offizielle Integrationsmöglichkeit | OFFEN | Machbarkeit prüfen; keine Integrationsfähigkeit behaupten |
| Pflichtdaten je Serviceart | OFFEN | fachlich mit Disposition/Technik definieren |
| Ausnahmequote | OFFEN | beeinflusst Automatisierungsgrad und Wirtschaftlichkeit |
| Datenqualität der Stammdaten | OFFEN | beeinflusst Zuordnung und Validierung |
| Rollen/Rechte | HYPOTHESE | mit realer Organisation abgleichen |
| technisch Verantwortliche im Betrieb | OFFEN | vor dem Go-live benennen |
| Baseline-Messwerte | OFFEN | vor/zu Beginn der Umsetzung erfassen |
| Eignung von Standardsoftware | OFFEN | vor einer Eigenentwicklung ernsthaft prüfen |
13 — Fahrplan
Phase A — Machbarkeit & Regeln
- ERP-Zugriff, Schnittstelle, Import und Export prüfen;
- Pflichtdaten und Fachregeln festlegen;
- führendes System je Objekt/Feld festlegen;
- Ausnahmefälle priorisieren;
- Baseline starten.
Phase B — kleiner produktiver Kern
- strukturierte Erfassung;
- Pflichtvalidierung;
- ERP-Auftragsreferenz/-anlage;
- operative Arbeitsliste und Zuweisung;
- Technikerdokumentation;
- Abschlussregel;
- technische Rückmeldung mit Wiederholversuch.
Phase C — Pilot
- begrenzte Nutzergruppe;
- Normalfälle und Ausnahmen beobachten;
- Fehler- und Betriebsweg testen;
- Prozessmetriken gegen Baseline prüfen.
Phase D — gezielte Weiterentwicklung
Nur nach beobachteter Nutzung:
- weitere Servicearten;
- zusätzliche Automatisierungen;
- mobile/offline Funktionen, falls betrieblich nötig;
- zusätzliche Integrationen;
- Auswertungen/Wirkungsmessung.
Was der Demonstrator beweist
Er beweist, dass WIRKLAUF Software nicht als lose Sammlung von Screens denkt, sondern als Zusammenspiel aus:
- Fachobjekten;
- Rollen und Rechten;
- Zuständen;
- Regeln;
- Daten;
- Integrationen;
- Ausnahmen;
- Fehlerbehandlung;
- Betrieb.
Was der Demonstrator nicht beweist
Er ist kein reales Kundenprojekt und keine Aussage über reale Einsparungen. Er beweist keine Branche, Kundenanzahl oder gemessene Wirkung.
Seine Testdaten sind deterministisch und illustrativ.
Reale Projekte werden später ergänzt
Kundenprojekte erscheinen hier nur, wenn mindestens folgende Voraussetzungen erfüllt sind:
- öffentliche Nutzung ist freigegeben;
- Kontext kann ohne falsche Verkürzung erklärt werden;
- behauptete Ergebnisse sind belegt;
- Zahlen besitzen Einheit, Bezug und Messzeitraum;
- der Kunde wird durch die Darstellung nicht unnötig offengelegt.
Fehlt eine dieser Voraussetzungen, bleibt das Projekt intern.
Ein Projekt besprechen
Wenn Sie eine ähnliche betriebliche Herausforderung haben, beschreiben Sie nicht die gewünschte Technologie, sondern zunächst den Ablauf und die Reibung. Daraus lässt sich der sinnvollste Lösungsweg besser bestimmen.