In den meisten KMU kommt das erste Signal, dass etwas nicht stimmt, vom Kunden. Er ruft an, weil der Auftrag nicht versendet wurde. Er schreibt, weil er in der dritten Woche auf ein Angebot wartet. Er beschwert sich, weil eine Rechnung überfällig ist, obwohl er vor zwei Wochen bezahlt hat. Im ERP war das alles sichtbar — niemand hat hingeschaut, weil niemand einen Grund hatte, ausgerechnet an diesem Tag in diesen Bericht zu sehen.
Ein Geschäftsalarm dreht die Situation um. Jetzt sagt das System selbst: „Einkauf — dieser Artikel liegt seit 90 Tagen, und morgen hast du einen Termin mit dem Lieferanten." „Chef — die Marge beim Kunden X ist in diesem Monat um 15% gefallen." „Vertriebsmitarbeiter — Kunde Y wartet seit fünf Werktagen auf dein Angebot." Niemand muss sich ins ERP einloggen, niemand muss einen Bericht öffnen. Das Problem kommt zum Menschen, bevor der Kunde Zeit hat, sich zu ärgern.
Das Problem ist, dass der erste Reflex lautet: „gut, dann richten wir Alarme auf alles ein". Nach zwei Wochen stummt das ganze Team die Benachrichtigungen, weil Teams alle fünf Minuten summt und niemand mehr sagen kann, welcher Alarm wirklich etwas bedeutet.
Was ein Geschäftsalarm ist — und was nicht
Es ist kein IT-Monitoring. IT-Monitoring überwacht, ob der Server läuft, ob die Leitung steht, ob das Backup gelaufen ist — dazu haben wir separat geschrieben (siehe IT-Monitoring im KMU). Ein Geschäftsalarm überwacht etwas anderes: Ereignisse in Geschäftsprozessen, die eine menschliche Reaktion erfordern.
Der Unterschied ist praktisch. IT-Monitoring ruft den Admin um drei Uhr nachts an, weil ein Server ausgefallen ist. Ein Geschäftsalarm meldet sich am Dienstag um 9:15 beim Vertriebsmitarbeiter, weil ein Kunde seit fünf Tagen auf ein Angebot wartet. Das erste ist binär (läuft/läuft nicht). Das zweite ist schwellenwertbasiert (etwas läuft zu langsam, zu selten, unter der Norm).
Ein Geschäftsalarm hat drei Eigenschaften, die ein gewöhnlicher Bericht nicht hat:
- Er erreicht eine konkrete Person, nicht ein allgemeines Firmenpostfach. „Alarm an den Vertriebsmitarbeiter, der dieses Angebot betreut" — nicht „Alarm an den Vertrieb".
- Er ist auf eine Handlung ausgerichtet, nicht auf das Lesen. „Angebot OF/2026/0421 wartet seit 5 Tagen — ruf den Kunden an" ergibt Sinn; „im Anhang die Liste offener Angebote" nicht.
- Er hat einen Auslöseschwellenwert. Er feuert nicht jedes Mal, wenn etwas passiert.
Erfüllt er diese drei Bedingungen nicht, ist es kein Alarm, sondern Spam.
Was im typischen KMU tatsächlich zu überwachen ist
Die Liste der Alarme, die sich in Unternehmen mit 10–50 Mitarbeitern lohnt, ist nicht lang. Interessant ist, dass es keine ausgefeilten Dinge sind. Es sind einfache Signale, die jeder Inhaber ohnehin kennen möchte — nur hat er bisher davon zwei Tage zu spät erfahren.
- Angebot ohne Rückmeldung. Angebot vor mehr als X Tagen ausgestellt, kein Status „gewonnen" oder „verloren". Geht an den zuständigen Vertriebsmitarbeiter und seinen Vorgesetzten. Schwelle: in der Regel 5–7 Werktage.
- Blockierter Auftrag. Kundenauftrag seit mehr als X Tagen in einem anderen Status als „abgeschlossen" oder „storniert". Geht an die Kundenservice-Leitung. Schwelle: 3 Tage, wenn der Normalzyklus einer ist.
- Überfällige Rechnung ab Betragsschwelle. Nicht jede verspätete Zahlung — nur jene über einem Betrag, der wirklich schmerzt (z.B. 10.000 PLN) und mehr als 7 Tage überfällig. Geht an die Buchhaltung und den Vertriebsmitarbeiter.
- Lagerbestand unter dem Minimum bei A/B-Artikeln. Nicht auf allem — nur bei den Artikeln, die zum Kernangebot gehören und deren Fehlen der Kunde sofort sieht. ABC/XYZ-Analyse ist ein eigenes Thema.
- Vertrags-/Kundenmarge unter einer Schwelle. Position im Auftrag mit einer Marge unter X% — Alarm an die Vertriebsleitung, keine Systemsperre.
- Reklamation seit 24h nicht zugewiesen. Hat niemand die Sache innerhalb eines Werktages aufgegriffen — Alarm an die Service-/Support-Leitung.
Eine klassische Überlastung: ein Alarm nach jedem Admin-Login, nach jedem neuen Mitarbeiter, nach jeder Preisänderung. Das sind technische Ereignisse. Sie gehören ins Log, nicht in den Posteingang des Chefs.
Alarm Fatigue — die größte Falle
Bekommt ein Mensch mehr als 5–7 Alarme am Tag, beginnt er sie zu ignorieren. Nicht aus Faulheit. Sondern weil das menschliche Gehirn Rauschen filtert. Und Rauschen ist alles, was keine Handlung ist, die ich jetzt ausführen kann.
Anzeichen, dass die Alarme in Ihrem Unternehmen nicht mehr funktionieren:
- „Ach, das kommt jeden Tag, ich schaue nicht mehr hin." Einen Alarm, auf den niemand reagiert, sollte man abschalten — oder die Schwelle anpassen.
- Alarme gehen an einen gemeinsamen Posteingang („buero@", „auftraege@"), wo jemand sie „bei Gelegenheit" durchsieht. Das sind keine Alarme, das ist eine Mail-Warteschlange.
- Alarme sagen, was passiert ist, aber nicht, was zu tun ist. „Angebot ist 10 Tage alt" ist ein Bericht. „Angebot ist 10 Tage alt — ruf Kunden Y an oder markiere als verloren" ist ein Alarm.
- Dieselbe Benachrichtigung landet gleichzeitig auf fünf Kanälen (E-Mail + Teams + SMS + ERP-Popup + Anruf). Ein Kanal pro Alarm.
Eine gute Faustregel: Im ersten Monat bleiben 60–70% der eingerichteten Alarme bestehen. Der Rest muss entweder abgeschaltet oder präzisiert werden — sonst zieht er den Rest mit nach unten.
Werkzeuge: vom Filter in Optima bis Power Automate
Sie brauchen kein separates Alarmierungssystem. In den meisten KMU reichen drei Arten von Werkzeugen, die das Unternehmen ohnehin schon nutzt.
Option 1 — native ERP-Mechanismen. Comarch Optima, enova365, Subiekt, Microsoft Dynamics AX — jedes hat irgendeine Form von Filtern, gespeicherten Abfragen, Erinnerungen. Es sind keine vollwertigen Alarm-Engines, aber für einige Schlüsselereignisse (überfällige Rechnungen, Mindestbestände) reichen sie. Vorteil: keine Integration nötig. Nachteil: Der Alarm „sitzt" meist im ERP und springt ohne externe Hilfe nicht auf Teams/SMS.
Option 2 — Power Automate / Zapier / Make. Hat das ERP eine API oder zumindest einen SQL/CSV-Export, kann Power Automate (Teil von Microsoft 365, das Sie ohnehin haben) Alarme planmäßig ausführen: Jeden Morgen um 7:30 fragt es die Datenbank ab, verschickt eine E-Mail oder eine Nachricht an einen Teams-Kanal. Das ist das realistische Werkzeug für 90% der KMU — niedrige Einstiegshürde, alles in einem Microsoft-Mandanten, Logs verfügbar, läuft ab Tag eins.
Option 3 — SQL-Abfragen + ein kleines Skript. Haben Sie einen internen IT-Mitarbeiter oder einen externen ERP-Entwickler, ist der günstigste Weg eine SQL-Abfrage gegen die ERP-Datenbank, zyklisch per Skript ausgeführt, die eine E-Mail/Nachricht verschickt. Stabil, einmaliger Aufwand von wenigen Stunden, erfordert aber eine Hand, die das Datenbankschema kennt — und wer diese Person ablöst, muss wissen, wo die Skripte liegen (siehe Bus Factor in der KMU-IT).
Hat das ERP ein eigenes Workflow-Modul (Comarch DMS, enova365 Workflow), lohnt es sich, dort hinzuschauen, bevor man ein drittes Werkzeug danebenklebt — aber in einem 10-Personen-Unternehmen stellt sich oft heraus, dass der eingebaute Workflow überdimensioniert ist.
Ein konkretes Beispiel
Bei einem unserer Kunden — einem 24-Personen-Großhandel für Elektromaterial, der hauptsächlich Elektriker und kleine Installationsfirmen beliefert — haben wir mit 23 vorgeschlagenen Alarmen begonnen. „Das System soll uns alles sagen." Nach drei Wochen schrieb der Inhaber: „Die Leute schalten Teams stumm, sie können nicht arbeiten."
Sechs blieben übrig:
- Angebot ohne Rückmeldung >6 Werktage — an den zuständigen Vertriebsmitarbeiter mit Kopie an die Vertriebsleitung. Vor den Alarmen betrug die durchschnittliche „Zeit bis zum Abschluss eines Angebots" 18 Werktage, nach drei Monaten sank sie auf 11.
- Kundenauftrag >48 h im Status „zu kommissionieren" blockiert — an den Lagerleiter. Zuvor lag etwa einmal pro Woche ein Auftrag 4–5 Tage herum, weil „eine Position fehlt, bestellen wir gleich". Nach der Einführung — statistisch null solcher Fälle pro Quartal.
- Rechnung über 8.000 PLN, >7 Tage überfällig — an die Buchhalterin und den Vertriebsmitarbeiter. Mahnwesen (siehe Mahnwesen-Automatisierung im KMU) sah nicht mehr wie eine Rettungsaktion zum Monatsende aus.
- Lagerbestand unter Minimum bei den Top-50-Artikeln — einmal täglich um 7:00 an den Einkaufsleiter. Die restlichen 2.000 Artikel hat ein anderer Mechanismus (Reorder Point im ERP), weil sie keine menschliche Reaktion erfordern.
- Reklamation seit >24 h nicht zugewiesen — an die Service-Leitung. Zuvor gab es Reklamationen, die eine Woche lagen, weil sie „im gemeinsamen Posteingang landeten".
- Position im Auftrag mit Marge <12% — an die Vertriebsleitung, keine Systemsperre. Positionen unter der Schwelle sind meist bewusste Vertriebsentscheidungen, aber jemand in der Geschäftsführung sollte sie sehen.
Werkzeuge: Die ersten drei Alarme in Power Automate, das um 7:30 Optimas SQL abfragt und eine Nachricht in einem bestimmten Teams-Kanal postet. Der vierte und fünfte nativ im ERP plus E-Mail-Benachrichtigung. Der sechste — eine SQL-Abfrage, die auf der Datenbankseite ausgeführt wird. Einmalige Implementierungskosten: etwa 20 Stunden Integratorzeit, verteilt auf drei Wochen. Laufend: 1–2 Stunden im Monat für das Feintuning der Schwellenwerte.
Die Zeitersparnis war schwer genau zu messen, aber am Ende des Quartals fasste es der Inhaber anders zusammen: „Zum ersten Mal seit Langem habe ich von einem Problem nicht vom Kunden erfahren."
Wie Sie in zwei Wochen starten
Keine Revolution nötig. Die Reihenfolge, die sich bei Kunden bewährt:
- Woche 1 — Gespräch mit dem Team. Nicht mit dem Integrator, nicht mit der Geschäftsführung. Mit den Menschen, die täglich im ERP sitzen. „Was möchtest du früher wissen, als du es heute erfährst?" Daraus entsteht eine Liste von einem Dutzend Vorschlägen — so entstehen echte Alarme, nicht die aus den Folien.
- Woche 1 — die 5–7 wichtigsten festnageln. Nicht mehr. Der Rest wartet auf die zweite Runde. Für jeden: Wer bekommt ihn, über welchen Kanal, was er nach dem Empfang tun soll, wann der Alarm erlischt.
- Woche 2 — technische Umsetzung. Vorzugsweise in Werkzeugen, die Sie schon haben (ERP + Power Automate). Ein neues Werkzeug kaufen Sie nur, wenn etwas wirklich nicht klappt.
- Nach einem Monat — Review. Welche Alarme haben funktioniert? Welche werden ignoriert? Welche brauchen eine höhere Schwelle? Ein Dienstagnachmittag reicht.
Wenn Sie nicht wissen, mit welchen Alarmen in Ihrem Unternehmen zu beginnen ist — eine halbe Stunde mit jemandem, der ähnliche Listen schon ein Dutzend Mal aufgesetzt hat, erspart zwei Wochen Herumtasten.
Ein guter Alarm sagt nicht „etwas ist passiert". Ein guter Alarm sagt „tu das jetzt, sonst ist es in drei Tagen zu spät".
Lassen Sie uns über Geschäftsalarme in Ihrem Unternehmen sprechen →