Erstgespräch
Passung, Problemrahmen, Klarheitsgrad, Umfang und nächster sinnvoller Schritt. Keine individuelle Tiefenanalyse.
Das Problem ist sichtbar. Aber noch ist offen, ob Prozessänderung, vorhandene Software, Standardlösung, Integration, Automatisierung oder Individualsoftware die richtige Antwort ist.
Der Kernhebel-Check schafft eine belastbare Entscheidungsgrundlage vor der Umsetzung.
Nach dem Check sollen Sie nicht einfach „eine Präsentation“ besitzen. Sie sollen eine Entscheidung treffen können.
Sie wissen:
Der Wert des Checks hängt nicht davon ab, ob danach ein WIRKLAUF-Softwareprojekt entsteht.
Der Kernhebel-Check passt, wenn:
Nicht der richtige Einstieg, wenn:
In diesen Fällen empfehle ich offen einen anderen Weg oder sage ab.
Der Check untersucht einen abgegrenzten Ablauf mit Start- und Endpunkt.
Beispiel:
Kundenanfrage eingegangen → Auftrag ist vollständig disponiert
Nicht:
Vertrieb, Service, Buchhaltung und Kundenportal komplett neu denken
Der Umfang muss klein genug sein, um tief zu analysieren, und groß genug, um eine relevante Entscheidung zu tragen.
Passung, Problemrahmen, Klarheitsgrad, Umfang und nächster sinnvoller Schritt. Keine individuelle Tiefenanalyse.
Realer IST-Ablauf, Reibung, Evidenz, Ursachenhypothesen, Kernhebel, Alternativen, Wirtschaftlichkeit und Empfehlung.
Diese Grenze schützt beide Seiten: relevante Analyse wird als Leistung behandelt statt als kostenlose Akquise versteckt.
Das verhindert, dass Schätzungen plötzlich wie Messwerte aussehen.
Nicht zwangsläufig der größte Schmerzpunkt und nicht die technisch spannendste Stelle.
Ein guter Hebel wird unter anderem nach Häufigkeit, Aufwand, Folgekosten, Geschäftswirkung, Abhängigkeit, Skalierungswirkung, Lösbarkeit, Umsetzungsaufwand, Risiko und Messbarkeit beurteilt.
Kein starres Punktesystem. Ein einzelnes kritisches Risiko kann eine Option ausschließen.
Nicht nur „Individualsoftware A vs Individualsoftware B“.
Mögliche Ergebnisse:
Nicht bauen ist ein valides Ergebnis.
Der Entscheidungsbrief dokumentiert:
Das Dokument soll intern weiterleitbar und ohne mündliche Begleiterklärung verständlich sein.
ILLUSTRATIVES BEISPIEL · KEIN KUNDENPROJEKT · KEINE GEMESSENEN ERGEBNISSE
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.
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.
Ein abgegrenzter Ablauf:
Betrachtete Rollen:
Von der eingehenden Serviceanfrage bis zur dokumentierten Rückmeldung des erledigten Auftrags an das bestehende ERP.
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
| 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 |
Vor einer Umsetzungsentscheidung werden nicht wahllos Kennzahlen gesammelt. Relevant sind die Größen, an denen die vermutete Wirkung später überprüft werden kann:
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.
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.
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.
ANFRAGE → STRUKTURIERTE ERFASSUNG → PFLICHTVALIDIERUNG → ERP-AUFTRAG → OPERATIVE ZUWEISUNG → BEARBEITUNG → DOKUMENTATION → FACHLICHER ABSCHLUSS → ERP-RÜCKMELDUNG
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 |
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.
Die Empfehlung ersetzt keine funktionierende kaufmännische Kernlogik. Sie baut nur die fehlende operative Schicht und Verbindung.
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:
| 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 |
Nur nach beobachteter Nutzung:
Wenn Umsetzung sinnvoll ist, übersetzt der Umsetzungsbrief die Entscheidung in eine belastbare Startgrundlage:
Er ist bewusst portabel. Sie können ihn mit WIRKLAUF, intern oder mit einem anderen Umsetzungspartner verwenden.
ILLUSTRATIVES BEISPIEL · KEIN KUNDENPROJEKT · KEINE GEMESSENEN ERGEBNISSE
Ein eingehender Servicebedarf wird vor der kaufmännischen Auftragsanlage strukturiert und fachlich geprüft. Das bestehende ERP bleibt kaufmännisches Kernsystem. Eine kleine operative Anwendung führt Zuweisung, Durchführung, Pflichtdokumentation, Klärfälle und technischen Rückmeldezustand.
| Rolle | Kernaufgabe |
|---|---|
| Büro / Disposition | Anfrage prüfen, Auftrag vorbereiten, zuweisen |
| Techniker | eigenen Auftrag bearbeiten, dokumentieren, Abschluss anstoßen |
| operative Leitung | fachliche Ausnahmen entscheiden |
| technisch Verantwortliche / Administration | Betrieb und technische Klärfälle betreuen |
| Integrationsdienst | technischer Abgleich und Wiederholversuche |
Mindestens:
Die endgültige Datenstruktur folgt erst nach der Machbarkeitsprüfung und den konkreten ERP-Feldern.
Vor dem Pilot konkret zu beziffern. Kategorien:
Dieser Musterbrief demonstriert den Anspruch des Kernhebel-Checks:
Nicht möglichst schnell eine Softwarelösung benennen, sondern belastbar entscheiden, welcher Eingriff den betrachteten Ablauf tatsächlich verbessern sollte.
ILLUSTRATIVES BEISPIEL · KEIN KUNDENPROJEKT · KEINE GEMESSENEN ERGEBNISSE
ILLUSTRATIVES BEISPIEL · KEIN KUNDENPROJEKT
Im gemeinsamen Service-Beispielszenario lautet die Empfehlung nicht „ERP ersetzen“. Das ERP bleibt. Der Hebel liegt im strukturierten Eingang und im operativen Zustand. Daraus entsteht eine kleinere Intervention: strukturierter Eingang + Validierung + gezielte Integration + operative Web-App.
Offen bleiben bewusst Dinge wie reale API-Möglichkeiten, Ausnahmequote und Pflichtdokumentation. Sie werden nicht erfunden, nur damit das Beispiel vollständiger wirkt.
Geprüft wird, ob ein Ablauf ausreichend klar eingegrenzt ist und der Check überhaupt passt.
Typisch ca. 90–120 Minuten mit den relevanten Beteiligten. Wir gehen den realen Ablauf durch, nicht nur den offiziellen Sollprozess.
Nur wenn konkrete Lücken geklärt werden müssen.
Evidenz ordnen, Ursachenbild, Kernhebel und ernsthafte Alternativen entwickeln.
Typisch ca. 60 Minuten. Empfehlung, Abwägungen, offene Fragen und nächste Schritte.
Entscheidungsbrief + Umsetzungsbrief.
Wenn innerhalb von 45 Tagen nach Übergabe ein WIRKLAUF-Umsetzungsprojekt von mindestens 10.000 € netto beauftragt wird, werden 750 € angerechnet.
Warum nicht vollständig? Weil der Check eigenständigen Wert besitzt und nicht wieder zu versteckter unbezahlter Akquise werden soll.
Keine Umsetzungspflicht. Kein automatisches Festpreisangebot als Ergebnisgarantie.
Wenn belastbare Daten existieren, können Zeit, Fehler, Nacharbeit, Wartezeit, Fallzahl oder andere Größen in die Entscheidung einfließen.
Wenn sie fehlen, werden Annahmen als Annahmen gekennzeichnet. Der Check erzeugt keine künstliche Renditerechnung, um eine Lösung verkaufbarer zu machen.
Dann hat der Check seinen Zweck erfüllt: eine unnötige Investition vermeiden oder zuerst andere Evidenz schaffen.
Wenn eine WIRKLAUF-Umsetzung sinnvoll und ausreichend klar ist, kann ein Folgeangebot entstehen. Es ist nicht automatisch Teil des Checks.
Nein.
Ja.
Dann wird die Rahmenprüfung erneut durchgeführt. Schleichende Ausweitung wird nicht still in denselben Check gezogen.
Bitte beschreiben Sie:
Ich prüfe zuerst, ob der Umfang für den Check passt.