Was: Der Sachbearbeiter wählt einen Stichtag, um die zur Abrechnung anstehenden Verträge zeitlich einzugrenzen. Standardmäßig ist das heutige Datum voreingestellt.

Warum: Nur Verträge, deren Abrechnungszeitpunkt erreicht ist, sollen im aktuellen Lauf berücksichtigt werden. Dies ermöglicht Nachabrechnungen für vergangene Perioden ebenso wie Vorschauen auf künftige Abrechnungsläufe.

Ergebnis: Die Vertragsliste zeigt ausschließlich Verträge an, deren nächster Abrechnungstermin vor oder am gewählten Stichtag liegt.

1.1.2 Verträge nach Kunde filtern

Was: Der Sachbearbeiter wählt über eine Multi-Select-Liste einen oder mehrere Kunden aus, für die abgerechnet werden soll. Pro Kunde wird die Anzahl der zugehörigen Verträge angezeigt.

Warum: Es ist regelmäßig notwendig, Abrechnungen nur für bestimmte Kunden durchzuführen – etwa wenn ein einzelner Kunde eine Sonderabrechnung oder eine Nachabrechnung benötigt.

Ergebnis: Nur Verträge der ausgewählten Kunden erscheinen in der Abrechnungsliste. Wird kein Kunde gewählt, werden keine Verträge angezeigt.

1.1.3 Verträge nach Vertragsart filtern

Was: Der Sachbearbeiter grenzt die Abrechnung auf bestimmte Vertragsarten ein, z. B. Wartungsverträge, Mietverträge oder Lizenzverträge. Die Multi-Select-Liste zeigt pro Vertragsart die Anzahl betroffener Verträge.

Warum: Verschiedene Vertragsarten haben unterschiedliche Abrechnungslogiken und werden häufig in getrennten Läufen verarbeitet, um Übersichtlichkeit und Nachvollziehbarkeit zu gewährleisten.

Ergebnis: Die Vertragsliste wird auf Verträge der gewählten Vertragsarten eingeschränkt.

1.1.4 Verträge nach Filiale filtern

Was: Der Sachbearbeiter wählt eine oder mehrere Filialen/Standorte aus, für die abgerechnet werden soll. Pro Filiale wird die Vertragsanzahl angezeigt.

Warum: In Unternehmen mit mehreren Standorten werden Abrechnungen oft filialweise durchgeführt, um regionale Zuständigkeiten und getrennte Ergebnisauswertungen zu ermöglichen.

Ergebnis: Nur Verträge der ausgewählten Filialen werden in den Abrechnungslauf einbezogen.

1.1.5 Nach Kalkulationsart filtern

Was: Der Sachbearbeiter wählt, ob automatisch, manuell oder bedarfsgesteuert abzurechnende Verträge berücksichtigt werden sollen. Bedarfsgesteuerte Verträge umfassen Klick-Zähler-, Kontingent- und dynamische Abrechnungen.

Warum: Automatische Verträge laufen standardmäßig durch, während manuelle und bedarfsgesteuerte Verträge gesondert behandelt werden müssen, da sie individuelle Prüfungen oder aktuelle Verbrauchsdaten erfordern.

Ergebnis: Die Vertragsliste zeigt nur Verträge der gewählten Kalkulationsart an.

1.1.6 Nach Vertragskategorie filtern

Was: Der Sachbearbeiter wählt zwischen Easy-Verträgen (pauschale Wiederkehr), Klick-Zähler-Verträgen (verbrauchsbasiert) und Kontingent-Verträgen (volumenbasiert) als Abrechnungskategorie.

Warum: Jede Vertragskategorie erfordert unterschiedliche Daten und Prüfungen: Easy-Verträge brauchen nur den Preis, Klick-Verträge aktuelle Zählerstände und Kontingent-Verträge den Restbestand.

Ergebnis: Die Vertragsliste wird auf die ausgewählte Kategorie eingeschränkt, sodass nur passende Verträge angezeigt werden.

1.1.7 Nach Abrechnungsintervall filtern

Was: Der Sachbearbeiter aktiviert den Intervallfilter und wählt eine Abrechnungsfrequenz aus – z. B. monatlich, quartalsweise oder jährlich.

Warum: Unternehmen rechnen verschiedene Vertragsarten in unterschiedlichen Zyklen ab. Ein separater monatlicher Lauf für Wartungsverträge und ein quartalsweiser für Lizenzverträge ist gängige Praxis.

Ergebnis: Nur Verträge mit dem gewählten Abrechnungsintervall erscheinen in der Liste.

1.1.8 Nach Vorauszahlung/Nachberechnung filtern

Was: Der Sachbearbeiter wählt, ob nur Vorauskasse- oder nur Nachkasse-Verträge abgerechnet werden sollen.

Warum: Vorauszahlungsverträge werden vor Leistungserbringung fakturiert, Nachberechnungsverträge erst nach erbrachter Leistung. Die getrennte Verarbeitung sichert korrekte Buchungszuordnungen und Erlösabgrenzung.

Ergebnis: Die Vertragsliste zeigt ausschließlich Verträge der gewählten Zahlungsart (Vorauskasse oder Nachkasse).

1.1.9 Sammelrechnungen filtern

Was: Der Sachbearbeiter filtert gezielt nach Verträgen, die als Sammelrechnung zusammengefasst werden, oder schließt diese aus.

Warum: Sammelrechnungen fassen mehrere Verträge eines Kunden auf einem Beleg zusammen. Sie erfordern eine gesonderte Verarbeitung, da Einzelverträge dabei gruppiert und zusammengeführt werden.

Ergebnis: Die Vertragsliste zeigt entweder nur Sammelrechnungs-Verträge oder nur Einzelrechnungs-Verträge.

1.1.10 Aktuelle Zählerstände laden

Was: Das System ruft die aktuellen Zählerlesungen aller Klick-Zähler-Geräte (Drucker, Kopierer, Multifunktionsgeräte) für die ausgewählten Verträge ab.

Warum: Für die nutzungsbasierte Abrechnung müssen die aktuellen Zählerstände bekannt sein, um die tatsächlich verbrauchten Einheiten (z. B. Schwarz/Weiß-Seiten, Farbseiten) berechnen zu können.

Ergebnis: Zu jedem Vertrag mit Klick-Zähler werden die aktuellen Zählerwerte angezeigt, bereit für die Abrechnungsberechnung.

1.1.11 Zählerhistorie abrufen

Was: Der Sachbearbeiter ruft die historischen Zählerlesungen eines Geräts über mehrere Abrechnungsperioden hinweg ab.

Warum: Die Zählerhistorie dient der Trendanalyse und Anomalieerkennung – ungewöhnlich hohe oder niedrige Verbrauchswerte fallen dadurch auf und können vor der Abrechnung überprüft werden.

Ergebnis: Eine chronologische Liste aller bisherigen Zählerlesungen mit Datum, Wert und Abweichung zum Durchschnitt wird angezeigt.

1.1.12 Zählerwerte aktualisieren

Was: Der Sachbearbeiter gibt neue Zählerlesungen manuell ein oder importiert sie. Solange geänderte Zählerwerte nicht gespeichert sind, wird die Abrechnung automatisch gesperrt.

Warum: Vor der Abrechnung müssen aktuelle Verbrauchswerte vorliegen. Die Sperrung verhindert, dass mit veralteten oder ungespeicherten Zählerständen abgerechnet wird.

Ergebnis: Die neuen Zählerwerte sind gespeichert, die Abrechnungssperre wird aufgehoben und die Verträge können abgerechnet werden.

1.1.13 Zähler per Barcode abrufen

Was: Der Sachbearbeiter scannt den Barcode am Gerät, um den zugehörigen Zähler schnell zu identifizieren.

Warum: Bei einer großen Anzahl von Geräten beschleunigt die Barcode-Suche die Zählererfassung erheblich gegenüber der manuellen Suche.

Ergebnis: Die Zählerinformationen des gescannten Geräts werden sofort angezeigt und können bearbeitet werden.

1.1.14 Zählerwerte importieren (Rivebird-Integration)

Was: Das System importiert automatisch Zählerlesungen aus der Rivebird-IoT-Plattform, die Geräte remote überwacht.

Warum: Der automatische Import spart manuelle Erfassungsarbeit und reduziert Eingabefehler, insbesondere bei großen Geräteflotten mit vielen Zählerständen.

Ergebnis: Alle über Rivebird angebundenen Geräte haben aktuelle Zählerstände im System, die direkt für die Abrechnung verwendet werden können.

1.1.15 Zählertypen verwalten

Was: Der Administrator definiert und pflegt Zählerkategorien wie Schwarz/Weiß, Farbe, Scan oder Fax. Hierfür ist die Berechtigung „Zählertypen" erforderlich.

Warum: Die Zuordnung von Zählern zu Typen steuert, welche Verbrauchsarten getrennt erfasst und separat berechnet werden – z. B. unterschiedliche Seitenpreise für Farbe und Schwarz/Weiß.

Ergebnis: Die Zählertyp-Stammdaten sind aktualisiert und stehen bei der Konfiguration neuer Verträge und Geräte zur Verfügung.

1.1.16 Zählerarten abrufen

Was: Das System ruft die verfügbaren Zählertyp-Definitionen als Liste ab, z. B. zur Anzeige in Auswahlfeldern.

Warum: Bei der Zuordnung von Zählern zu Verträgen und Geräten benötigt der Sachbearbeiter eine aktuelle Übersicht aller verfügbaren Zählertypen.

Ergebnis: Eine vollständige Liste aller definierten Zählertypen wird zur Auswahl bereitgestellt.

1.1.17 Zähler-Abweichungsgründe abrufen

Was: Das System liefert eine Liste vordefinierter Gründe für Abweichungen bei Zählerständen.

Warum: Wenn ein Zählerstand vom erwarteten Wert abweicht, muss der Sachbearbeiter den Grund dokumentieren – etwa Gerätewechsel, Reparatur oder Fehleingabe – um die Abrechnung nachvollziehbar zu halten.

Ergebnis: Die Abweichungsgründe stehen als Auswahlliste zur Dokumentation bei der Zählererfassung bereit.

1.1.18 Zählerstände mit Filter abfragen

Was: Der Sachbearbeiter sucht Zählerstände mit erweiterten Filtern wie Datumsbereich, Gerätetyp, Kunde oder Standort.

Warum: Für die gezielte Analyse einzelner Gerätegruppen oder Zeiträume reicht die Standardansicht nicht aus – erweiterte Filter ermöglichen eine präzise Recherche.

Ergebnis: Eine gefilterte Liste von Zählerständen wird angezeigt, die genau den Suchkriterien entspricht.

1.1.19 Stammdaten aus Import erstellen

Was: Beim erstmaligen Import von Zählerständen für ein neues Gerät werden automatisch die zugehörigen Geräte-Stammdaten angelegt.

Warum: Neue Geräte, die über eine externe Quelle (z. B. Rivebird) erstmals Zählerdaten liefern, sollen ohne manuellen Stammdaten-Pflegeaufwand ins System integriert werden.

Ergebnis: Für jedes noch nicht erfasste Gerät wird ein neuer Stammdatensatz mit den importierten Informationen angelegt.

1.1.20 Vertragspositionen abrufen

Was: Der Sachbearbeiter ruft alle Einzelpositionen eines Vertrags ab – Artikel, Mengen, Preise und Beschreibungen.

Warum: Vor der Abrechnung muss der Inhalt eines Vertrags überprüfbar sein, um sicherzustellen, dass alle Positionen korrekt konfiguriert und abrechnungsbereit sind.

Ergebnis: Eine vollständige Positionsliste des Vertrags wird angezeigt, inklusive Einzelpreis, Menge und Gesamtbetrag pro Position.

1.1.21 Positionen ohne Menge prüfen

Was: Das System identifiziert Vertragspositionen, bei denen keine Mengenangabe hinterlegt ist, und zeigt diese als Warnung an.

Warum: Positionen ohne Mengenangabe würden in der Abrechnung einen Nullbetrag erzeugen oder zu Fehlern führen. Die Prüfung vor dem Abrechnungslauf verhindert fehlerhafte Rechnungen.

Ergebnis: Eine Liste aller betroffenen Positionen wird angezeigt. Der Abrechnungslauf wird blockiert, bis die fehlenden Mengen ergänzt sind.

1.1.22 Positionsdefizit per Barcode ermitteln

Was: Das System prüft die Barcode-Zuordnungen der Vertragspositionen und identifiziert fehlende oder abweichende Zuordnungen.

Warum: Bei Verträgen mit Geräten müssen Barcode-Zuordnungen vollständig sein, um die korrekte Zuordnung von Verbrauchsdaten zu Vertragspositionen sicherzustellen.

Ergebnis: Positionen mit fehlenden oder abweichenden Barcode-Zuordnungen werden aufgelistet und können korrigiert werden.

1.1.23 Teilbare Artikelpositionen abrufen

Was: Das System identifiziert Vertragspositionen, die teilweise abgerechnet werden können, d. h. bei denen nur der tatsächlich verbrauchte Anteil fakturiert wird.

Warum: Bei bestimmten Artikeln (z. B. Verbrauchsmaterial) soll nicht die gesamte Vertragsmenge, sondern nur der tatsächliche Verbrauch im Abrechnungszeitraum berechnet werden.

Ergebnis: Eine Liste teilbarer Positionen mit Gesamtmenge und bereits verbrauchter Menge wird angezeigt.

1.1.24 Rechnungen aus Verträgen erstellen

Was: Der Sachbearbeiter startet die Rechnungsgenerierung für alle selektierten Verträge. Das System erstellt pro Vertrag (bzw. pro Sammelrechnungsgruppe) eine Rechnung mit allen zugehörigen Positionen.

Warum: Die automatische Rechnungserstellung aus Verträgen ist der Kernprozess der Vertragsabrechnung und ersetzt die manuelle Rechnungslegung für wiederkehrende Leistungen.

Ergebnis: Für jeden ausgewählten Vertrag wird eine Rechnung erstellt. Das Ergebnis zeigt die Anzahl erfolgreicher und fehlgeschlagener Rechnungen, den Gesamtbetrag und eventuelle Fehlermeldungen.

1.1.25 Belegdatum setzen

Was: Der Sachbearbeiter legt das Rechnungsdatum für den gesamten Abrechnungslauf fest. Standardmäßig wird das heutige Datum vorgeschlagen.

Warum: Das Belegdatum bestimmt den buchhalterischen Erfassungszeitpunkt, die Fälligkeit der Zahlung und die Zuordnung zur Abrechnungsperiode.

Ergebnis: Alle im Lauf erstellten Rechnungen tragen das gewählte Belegdatum.

1.1.26 Rechnungsvorschau anzeigen

Was: Der Sachbearbeiter kann vor der endgültigen Rechnungserstellung eine Vorschau der zu generierenden Rechnungen einsehen.

Warum: Die Vorschau ermöglicht eine letzte Kontrolle der Beträge, Positionen und Empfänger, bevor die Rechnungen unwiderruflich erstellt und ggf. versendet werden.

Ergebnis: Eine Vorschau-Darstellung aller geplanten Rechnungen mit Betrag, Kunde und Positionen wird angezeigt.

1.1.27 Abrechnung sperren/freigeben

Was: Der Sachbearbeiter kann die Abrechnungsausführung manuell sperren oder freigeben, um versehentliche Abrechnungsläufe zu verhindern.

Warum: Bei laufenden Vorbereitungen (z. B. Zählererfassung, Positionsprüfung) soll sichergestellt werden, dass kein Abrechnungslauf unbeabsichtigt gestartet wird.

Ergebnis: Im gesperrten Zustand ist der Abrechnungsbutton deaktiviert; nach Freigabe kann die Abrechnung durchgeführt werden.

1.1.28 Abrechnungsfreigabe prüfen

Was: Das System validiert vor dem Start der Abrechnung, ob alle Voraussetzungen erfüllt sind – insbesondere ob keine ungespeicherten Zähleränderungen vorliegen.

Warum: Die automatische Prüfung verhindert, dass Abrechnungen mit unvollständigen oder inkonsistenten Daten durchgeführt werden.

Ergebnis: Die Abrechnung wird entweder freigegeben oder mit einer konkreten Fehlermeldung (z. B. „Zählerstände nicht gespeichert") blockiert.

1.1.29 Versandart wählen

Was: Der Sachbearbeiter wählt die Zustellmethode für die generierten Rechnungen: Druck, E-Mail, Post oder Kundenportal. Standardmäßig ist „Druck" voreingestellt.

Warum: Kunden bevorzugen unterschiedliche Empfangswege. Die zentrale Auswahl der Versandart steuert, wie die Rechnungen nach der Generierung verarbeitet werden.

Ergebnis: Die gewählte Versandart wird für den gesamten Abrechnungslauf als Standard gesetzt und bestimmt die Weiterverarbeitung der Rechnungen.

1.1.30 Versandart pro Vertrag überschreiben

Was: Der Sachbearbeiter erzwingt eine bestimmte Zustellmethode für einzelne Verträge, unabhängig von der im Kundenstamm hinterlegten Präferenz.

Warum: In Ausnahmefällen – z. B. bei einer fehlerhaften Kunden-E-Mail-Adresse oder bei besonderer Versandanforderung – muss die Standard-Versandart übersteuert werden können.

Ergebnis: Die überschriebene Versandart gilt nur für den aktuellen Abrechnungslauf und ändert nicht die Kundenstammdaten.

1.1.31 Drucker auswählen

Was: Der Sachbearbeiter wählt den Zieldrucker aus den verfügbaren Netzwerk- und lokalen Druckern für den Druckversand der Rechnungen.

Warum: Verschiedene Druckaufträge können unterschiedliche Drucker erfordern, z. B. einen Farblaserdrucker für Rechnungen mit Logo oder einen dedizierten Rechnungsdrucker.

Ergebnis: Der gewählte Drucker wird für die Rechnungsausgabe im aktuellen Abrechnungslauf verwendet.

1.1.32 Direkter E-Mail-Versand

Was: Das System versendet generierte Rechnungen sofort per E-Mail, ohne dass der Sachbearbeiter jeden Versand einzeln bestätigen muss. Diese Option ist standardmäßig aktiviert.

Warum: Bei großen Abrechnungsläufen mit vielen Rechnungen wäre eine einzelne Bestätigung pro E-Mail unpraktikabel und würde den Prozess erheblich verlangsamen.

Ergebnis: Alle Rechnungen mit E-Mail-Versandart werden automatisch an die hinterlegten Empfänger versendet.

1.1.33 E-Mail-Empfänger festlegen

Was: Der Sachbearbeiter definiert die Empfänger (An, CC, BCC) für den E-Mail-Versand der Rechnungen.

Warum: Rechnungen müssen an die korrekte Empfängeradresse gesendet werden, wobei interne Kopien (CC an Vertrieb, BCC an Buchhaltung) häufig benötigt werden.

Ergebnis: Die definierten Empfänger werden für den E-Mail-Versand der Rechnungen im aktuellen Abrechnungslauf verwendet.

1.1.34 E-Mail-Betreff setzen

Was: Der Sachbearbeiter passt die Betreffzeile der Rechnungs-E-Mails an, z. B. mit Abrechnungsperiode und Kundennamen.

Warum: Ein aussagekräftiger Betreff erleichtert dem Empfänger die Zuordnung und verhindert, dass Rechnungs-E-Mails als Spam eingestuft werden.

Ergebnis: Alle Rechnungs-E-Mails des aktuellen Laufs tragen den angepassten Betreff.

1.1.35 E-Mail-Text setzen

Was: Der Sachbearbeiter erstellt den Nachrichtentext für Rechnungs-E-Mails, z. B. mit Begrüßung, Zahlungshinweisen und Kontaktdaten.

Warum: Ein individueller und professioneller E-Mail-Text verbessert die Kundenkommunikation und enthält relevante Zahlungsinformationen direkt im E-Mail-Text.

Ergebnis: Der erstellte Text wird als Nachrichteninhalt in den Rechnungs-E-Mails verwendet.

1.1.36 E-Mail-Anhänge hinzufügen

Was: Der Sachbearbeiter fügt den Rechnungs-E-Mails zusätzliche Dokumente bei, z. B. Allgemeine Geschäftsbedingungen, Vertragsübersichten oder ergänzende Unterlagen.

Warum: Neben der Rechnung selbst erfordern geschäftliche Vorgänge oft die Mitlieferung ergänzender Dokumente.

Ergebnis: Alle ausgewählten Anhänge werden den Rechnungs-E-Mails beigefügt.

1.1.37 Sonderartikel aus Import erstellen

Was: Der Sachbearbeiter importiert dynamische Vertragspositionen – z. B. aktuelle Nutzungsdaten, Lizenzzahlen oder variable Gebühren – aus einer externen Quelle.

Warum: Verträge mit variablen Leistungsbestandteilen (z. B. Managed-Service-Monitoring, Lizenzänderungen) benötigen regelmäßig aktualisierte Positionsdaten, die nicht statisch im Vertrag hinterlegt sind.

Ergebnis: Die importierten Sonderartikel werden als zusätzliche Vertragspositionen angelegt und in die nächste Abrechnung einbezogen.

1.1.38 Sonderartikel-Köpfe speichern/aktualisieren

Was: Der Sachbearbeiter speichert oder aktualisiert die Konfiguration von Sonderartikeln, die dynamisch zu Verträgen hinzugefügt werden.

Warum: Sonderartikel-Konfigurationen müssen persistent vorgehalten werden, damit sie bei wiederkehrenden Abrechnungsläufen automatisch berücksichtigt werden.

Ergebnis: Die Sonderartikel-Konfiguration ist gespeichert und wird beim nächsten Abrechnungslauf automatisch berücksichtigt.

1.1.39 Sonderartikel-Köpfe löschen

Was: Der Sachbearbeiter entfernt nicht mehr benötigte Sonderartikel-Konfigurationen aus einem oder mehreren Verträgen.

Warum: Auslaufende oder fehlerhafte Sonderartikel müssen entfernt werden können, damit sie in künftigen Abrechnungsläufen nicht mehr fakturiert werden.

Ergebnis: Die ausgewählten Sonderartikel-Konfigurationen sind gelöscht und werden in künftigen Abrechnungsläufen nicht mehr berücksichtigt.

1.1.40 Sonderartikel suchen

Was: Der Sachbearbeiter sucht in den vorhandenen Sonderartikel-Konfigurationen mit Filtern nach Vertrag, Artikel oder Zeitraum.

Warum: Bei vielen Verträgen mit Sonderartikeln ist eine gezielte Suche notwendig, um bestimmte Konfigurationen zu finden, zu prüfen oder zu bearbeiten.

Ergebnis: Eine gefilterte Liste der Sonderartikel-Konfigurationen wird angezeigt.

1.1.41 Import aus MSP-Auswertung

Was: Das System erstellt Sonderartikel-Positionen automatisch aus den Auswertungsdaten des Managed-Service-Provider-Monitorings (Hardware, Lizenzen, Überwachungsdaten).

Warum: MSP-Verträge beinhalten häufig variable Komponenten (z. B. Anzahl überwachter Geräte, Lizenznutzung), die sich monatlich ändern und automatisiert in die Abrechnung einfließen sollen.

Ergebnis: Die MSP-Auswertungsdaten werden als abrechnungsfertige Sonderartikel-Positionen in den zugehörigen Verträgen angelegt.

1.1.42 Abrechnungsergebnisse anzeigen

Was: Der Sachbearbeiter prüft nach einem Abrechnungslauf die Ergebnisse – erstellte Rechnungen, Beträge, Status (Erfolg/Fehler) und eventuelle Warnungen.

Warum: Nach jedem Abrechnungslauf ist eine Kontrolle der Ergebnisse notwendig, um Fehler zu erkennen, den Gesamtbetrag zu verifizieren und bei Bedarf Nachbearbeitungen einzuleiten.

Ergebnis: Eine Übersicht aller erstellten Rechnungen mit Status, Betrag und Fehlermeldungen wird in der Abrechnungshistorie angezeigt.

1.1.43 Abrechnungsergebnisse speichern

Was: Der Sachbearbeiter exportiert die Abrechnungsergebnisse für die externe Weiterverarbeitung, z. B. für die Buchhaltung oder das Controlling.

Warum: Die Ergebnisse eines Abrechnungslaufs müssen oft in externen Systemen weiterverarbeitet oder archiviert werden.

Ergebnis: Die Abrechnungsergebnisse stehen als exportierte Datei zur Verfügung.

1.1.44 Abrechnungslog speichern

Was: Das System protokolliert jeden Schritt der Rechnungserstellung – Zeitpunkt, Beleg, Versandart und Ergebnis – als Audit-Trail-Eintrag.

Warum: Für die Nachvollziehbarkeit und Compliance muss dokumentiert sein, wann welche Rechnungen erstellt und wie sie versendet wurden.

Ergebnis: Ein vollständiges Protokoll des Abrechnungslaufs ist persistent gespeichert und kann jederzeit abgerufen werden.

1.1.45 Abrechnungsergebnis-Status speichern

Was: Das System dokumentiert pro Vertrag den Erfolgs- oder Fehlerstatus des Abrechnungslaufs, ergänzt um einen optionalen Kommentar.

Warum: Die detaillierte Statusdokumentation ermöglicht die gezielte Nachbearbeitung fehlgeschlagener Abrechnungen und die Auswertung der Erfolgsquote.

Ergebnis: Jeder Vertrag hat einen dokumentierten Abrechnungsstatus (Erfolg/Fehler) mit Kommentar.

1.1.46 Historische Abrechnungsergebnisse laden

Was: Der Sachbearbeiter ruft vergangene Abrechnungsläufe ab, gefiltert nach Zeitraum und optional nach bestimmten Verträgen.

Warum: Für Rückfragen, Korrekturen oder Auswertungen müssen die Ergebnisse früherer Abrechnungsläufe jederzeit abrufbar sein.

Ergebnis: Eine Liste vergangener Abrechnungsläufe mit Datum, Vertragsanzahl, Gesamtbetrag und Status wird angezeigt.

1.1.47 Reports nach Versandart abrufen

Was: Das System liefert die verfügbaren Rechnungsvorlagen je nach gewählter Zustellmethode (Druck, E-Mail, Portal).

Warum: Verschiedene Versandwege erfordern unterschiedliche Report-Layouts – z. B. ein Drucklayout mit Briefpapier oder ein PDF-Layout für den E-Mail-Versand.

Ergebnis: Die passenden Rechnungsvorlagen für die gewählte Versandart stehen zur Auswahl bereit.

1.1.48 Report-Parameter abrufen

Was: Das System liefert die konfigurierbaren Eingabeparameter einer Rechnungsvorlage, z. B. Logo, Sprache oder Zusatzfelder.

Warum: Rechnungsvorlagen können variable Parameter enthalten, die vor der Rechnungserstellung angepasst werden müssen.

Ergebnis: Die Parameter der gewählten Vorlage werden angezeigt und können vom Sachbearbeiter angepasst werden.

1.1.49 Vertragsarten anzeigen

Was: Der Administrator öffnet die Verwaltung der Vertragsarten. Der Zugriff erfordert die Berechtigung „Vertragsarten".

Warum: Vertragsarten definieren die Abrechnungslogik, Laufzeiten und Konditionen und müssen bei Bedarf angepasst oder erweitert werden.

Ergebnis: Die Vertragsarten-Verwaltung wird geöffnet und die bestehenden Vertragsarten werden angezeigt.

1.1.50 Zählertypen anzeigen

Was: Der Administrator öffnet die Verwaltung der Zählertypen. Der Zugriff erfordert die Berechtigung „Zählertypen".

Warum: Zählertypen steuern die Kategorisierung der Verbrauchserfassung und müssen bei neuen Gerätetypen oder Abrechnungsarten erweitert werden.

Ergebnis: Die Zählertypen-Verwaltung wird geöffnet und die bestehenden Typen werden angezeigt.

1.1.51 Kündigungsarten anzeigen

Was: Der Administrator öffnet die Verwaltung der Kündigungsgründe. Der Zugriff erfordert die Berechtigung „Kündigungsarten".

Warum: Standardisierte Kündigungsgründe ermöglichen eine einheitliche Dokumentation und Auswertung von Vertragskündigungen.

Ergebnis: Die Kündigungsarten-Verwaltung wird geöffnet und die bestehenden Gründe werden angezeigt.

1.1.52 Kunden-Rechnungsinfo anzeigen

Was: Der Sachbearbeiter zeigt kundenspezifische Abrechnungshinweise an, die im Kundenstamm als formatiertes Textfeld hinterlegt sind.

Warum: Kunden können besondere Abrechnungsanforderungen haben (z. B. „Nur per Post an Buchhaltung", „Bestellnummer angeben"), die der Sachbearbeiter vor der Abrechnung kennen muss.

Ergebnis: Die kundenbezogenen Rechnungshinweise werden als formatierter Text angezeigt.

1.1.53 Konzern-Abrechnung handhaben

Was: Der Sachbearbeiter aktiviert die Konzern-Abrechnung für Verträge, die einer Unternehmensgruppe mit mehreren Gesellschaften zugeordnet sind.

Warum: In Konzernstrukturen müssen Verträge verschiedener Gesellschaften korrekt den jeweiligen Rechnungsempfängern und Kostenstellen zugeordnet und ggf. konsolidiert abgerechnet werden.

Ergebnis: Die Abrechnung berücksichtigt die Konzernstruktur und erstellt Rechnungen gemäß den internen Zuordnungen der Unternehmensgruppe.

1.1.54 Rechnungsinfo-Flag umschalten

Was: Der Sachbearbeiter aktiviert oder deaktiviert die Anzeige von Kunden-Rechnungshinweisen im Abrechnungs-Wizard.

Warum: Erfahrene Sachbearbeiter, die die Kunden-Besonderheiten kennen, können die Hinweise ausblenden, um die Oberfläche übersichtlicher zu halten.

Ergebnis: Die Rechnungshinweise werden ein- oder ausgeblendet, ohne dass die hinterlegten Informationen verändert werden.

1.1.55 Vertrags-Schriftart aktualisieren

Was: Der Administrator ändert die Schriftfamilie für Vertragsdokumente – global für alle Verträge oder für einzelne Verträge gezielt.

Warum: Unternehmens-CI-Änderungen oder die Umstellung auf barrierefreie Schriften erfordern die Anpassung der Dokumenten-Schriftart.

Ergebnis: Die betroffenen Vertragsdokumente werden mit der neuen Schriftart generiert.

1.1.56 Fehlenden Richtext reparieren

Was: Das System bereinigt korrupte oder fehlende Rich-Text-Felder in Vertragspositionen.

Warum: Bei Datenmigrationen oder Systemupdates können Rich-Text-Felder beschädigt werden, was zu Darstellungsfehlern in Rechnungen und Vertragsdokumenten führt.

Ergebnis: Alle korrupten Rich-Text-Felder sind bereinigt und die Vertragspositionen werden korrekt dargestellt.

1.1.57 Zähler-Importquellen abrufen

Was: Das System listet alle verfügbaren Quellen für den Zähler-Import auf, z. B. Rivebird, manueller Import oder andere IoT-Plattformen.

Warum: Der Sachbearbeiter muss wissen, welche Importquellen konfiguriert sind, um die richtige Datenquelle für den Zähler-Import auszuwählen.

Ergebnis: Eine Liste aller verfügbaren Importintegrationen mit Status (aktiv/inaktiv) wird angezeigt.

1.1.58 Artikel-I3D nach Codes auflösen

Was: Das System wandelt Artikelcodes (z. B. Artikelnummern aus einem externen System) in die internen Artikelkennungen um.

Warum: Beim Import von Daten aus Fremdsystemen müssen Artikelcodes den internen Artikeln zugeordnet werden, um eine korrekte Verarbeitung sicherzustellen.

Ergebnis: Zu jedem übermittelten Artikelcode wird die interne Artikelkennung aufgelöst, oder ein Fehler gemeldet, wenn keine Zuordnung existiert.

1.1.59 Zwischen Wizard-Seiten navigieren

Was: Der Sachbearbeiter navigiert durch den Abrechnungs-Wizard, der aus mehreren aufeinanderfolgenden Schritten besteht: Vertragsauswahl mit Datum- und Filtereinstellungen, Versandeinstellungen, Übersicht mit Validierung und Abrechnungsdurchführung, sowie die Abrechnungshistorie.

Warum: Der mehrstufige Wizard-Aufbau führt den Sachbearbeiter strukturiert durch den komplexen Abrechnungsprozess und stellt sicher, dass alle notwendigen Einstellungen und Prüfungen in der richtigen Reihenfolge durchlaufen werden.

Ergebnis: Der Sachbearbeiter kann zwischen den Wizard-Seiten vorwärts und rückwärts navigieren, wobei dynamisch ein- und ausgeblendete Schaltflächen die jeweils erlaubte Navigation anzeigen.

1.1.60 Auto-Start-Modus

Was: Beim Öffnen des Abrechnungsmoduls werden die zur Abrechnung stehenden Verträge automatisch geladen, ohne dass der Sachbearbeiter manuell eine Suche anstoßen muss.

Warum: In den meisten Fällen möchte der Sachbearbeiter sofort mit den aktuell anstehenden Verträgen arbeiten. Der automatische Ladevorgang spart einen Arbeitsschritt.

Ergebnis: Die Vertragsliste ist beim Modulstart bereits befüllt und zeigt die aktuell zur Abrechnung anstehenden Verträge.

1.1.61 Filteränderungs-Erkennung

Was: Das System erkennt automatisch, wenn der Sachbearbeiter Filtereinstellungen geändert hat, und zeigt an, dass die Vertragsliste neu geladen werden muss.

Warum: Nach Filteränderungen muss die Vertragsliste aktualisiert werden. Die Erkennung verhindert, dass der Sachbearbeiter mit veralteten Daten arbeitet.

Ergebnis: Nach einer Filteränderung wird der Sachbearbeiter informiert, dass ein Neuladen der Daten erforderlich ist. Die Vertragsliste wird nach Bestätigung aktualisiert.

1.1.62 Wizard-Seiten-Eigenschafts-Handler

Was: Der Abrechnungs-Wizard blendet Navigationsschaltflächen (Weiter, Zurück, Überspringen) abhängig von der aktuellen Seite dynamisch ein oder aus.

Warum: Nicht jede Seite erlaubt alle Navigationsoptionen – z. B. kann die erste Seite nicht „zurück" gehen und bestimmte Pflichtseiten dürfen nicht übersprungen werden.

Ergebnis: Die Navigationsschaltflächen passen sich automatisch an die aktuelle Wizard-Seite an.

1.1.63 Modul mit vorausgewählten Verträgen öffnen

Was: Der Sachbearbeiter startet das Abrechnungsmodul aus einem anderen Modul heraus (z. B. aus der Vertrags- oder Kundenverwaltung), wobei bestimmte Verträge bereits vorselektiert sind.

Warum: Wenn ein Sachbearbeiter aus der Vertragsverwaltung heraus direkt die Abrechnung eines bestimmten Vertrags starten möchte, soll er nicht erneut filtern und suchen müssen.

Ergebnis: Das Abrechnungsmodul öffnet sich mit den übergebenen Verträgen vorselektiert, bereit für die Abrechnung.

1.1b Automatische Abrechnung

1.1b.1 Abrechnungsjob konfigurieren

Was: Der Administrator richtet einen zeitgesteuerten Abrechnungslauf ein und definiert den Zeitplan (täglich, wöchentlich, monatlich) sowie die betroffenen Verträge, Vertragsarten oder Filialen.

Warum: Wiederkehrende Abrechnungen sollen ohne manuelles Eingreifen regelmäßig und zuverlässig ausgeführt werden, um den Personalbedarf zu reduzieren und die Pünktlichkeit der Rechnungsstellung sicherzustellen.

Ergebnis: Ein Abrechnungsjob ist konfiguriert und wird gemäß dem Zeitplan automatisch ausgeführt.

1.1b.2 MSP-Gebühren automatisch fakturieren

Was: Das System erstellt monatlich automatisch Rechnungen für Managed-Service-Verträge, die Hardware-Wartung, Lizenzen und Monitoring-Gebühren umfassen.

Warum: MSP-Kunden erhalten monatliche Gesamtrechnungen über alle Servicekomponenten. Die automatische Fakturierung stellt sicher, dass keine Verträge vergessen werden und die Rechnungen pünktlich erstellt werden.

Ergebnis: Für jeden MSP-Vertrag wird eine monatliche Rechnung erstellt, die alle Vertragspositionen (Monitoring, Server-Wartung, Lizenzen etc.) zusammenfasst.

1.1b.3 Vertragsgebundene Abrechnung nach Intervall ausführen

Was: Das System führt die Abrechnung zeitgesteuert basierend auf dem im Vertrag hinterlegten Abrechnungsintervall aus – monatlich, quartalsweise oder jährlich.

Warum: Verschiedene Verträge haben unterschiedliche Abrechnungsrhythmen. Die automatische Steuerung über das Vertragsintervall stellt sicher, dass jeder Vertrag zum richtigen Zeitpunkt abgerechnet wird.

Ergebnis: Alle Verträge, deren Abrechnungstermin erreicht ist, werden automatisch fakturiert und die nächsten Abrechnungstermine werden fortgeschrieben.

1.1b.4 Ergebnis-Benachrichtigung an Sachbearbeiter

Was: Nach Abschluss eines automatischen Abrechnungslaufs versendet das System eine Zusammenfassung an den zuständigen Sachbearbeiter per E-Mail.

Warum: Auch bei automatischer Abrechnung muss der Sachbearbeiter über das Ergebnis informiert werden, um bei Fehlern zeitnah reagieren zu können.

Ergebnis: Der Sachbearbeiter erhält eine E-Mail mit der Anzahl erstellter Rechnungen, dem Gesamtbetrag und ggf. aufgetretenen Fehlern.

1.1b.5 Fehlerhafte automatische Abrechnungen nachbearbeiten

Was: Der Sachbearbeiter sieht fehlgeschlagene Abrechnungen aus dem automatischen Lauf mit Fehlergrund und kann diese manuell korrigieren und erneut ausführen.

Warum: Nicht alle Fehler lassen sich automatisch beheben (z. B. fehlende Zählerstände, ungültige Kontonummern). Eine manuelle Nachbearbeitung mit erneutem Lauf ist dann erforderlich.

Ergebnis: Die fehlerhaften Abrechnungen sind korrigiert und die Rechnungen werden erfolgreich erstellt.

1.2 Pauschalabrechnung

1.2.1 Aufträge für Pauschalabrechnung laden

Was: Der Sachbearbeiter ruft alle Aufträge ab, die Pauschalpositionen enthalten und mit Saldo-Elementen (verbrauchte Leistungen) verknüpft sind.

Warum: Pauschalverträge enthalten ein Budget, gegen das Einzelleistungen gebucht werden. Der Sachbearbeiter benötigt die Übersicht, um den Verbrauchsstand pro Auftrag zu prüfen.

Ergebnis: Eine Liste aller Aufträge mit Pauschalpositionen wird angezeigt, inklusive verknüpfter Saldo-Elemente.

1.2.2 Pauschalpositionen anzeigen

Was: Der Sachbearbeiter klappt die Pauschalpositionen eines Auftrags auf und sieht die einzelnen Saldo-Items mit den jeweiligen Beträgen und den berechneten Restbetrag.

Warum: Die detaillierte Saldo-Ansicht zeigt, wie viel vom Pauschalbudget bereits verbraucht ist und welche Einzelleistungen gebucht wurden.

Ergebnis: Die Pauschalpositionen werden mit aufklappbaren Saldo-Items angezeigt: Pauschalbetrag, verbrauchte Einzelposten und Restsaldo.

1.2.3 Helpdesk-Timer zuordnen

Was: Der Sachbearbeiter verknüpft Support-Timer (erfasste Arbeitszeiten aus dem Helpdesk) mit bestimmten Pauschalpositionen zur Verbrauchserfassung.

Warum: Die tatsächlich geleisteten Support-Stunden müssen den Pauschalpositionen zugeordnet werden, um den Verbrauch korrekt gegen das Pauschalbudget zu buchen.

Ergebnis: Die ausgewählten Helpdesk-Timer sind den Pauschalpositionen zugeordnet und der Saldo wird entsprechend aktualisiert.

1.2.4 Saldo berechnen

Was: Das System berechnet den aktuellen Saldo: Pauschalbetrag minus Summe aller verbrauchten Positionen ergibt den Restsaldo.

Warum: Der Restsaldo zeigt, wie viel Budget noch verfügbar ist. Bei negativem Saldo entsteht eine Nachberechnung, bei positivem Saldo ein Restguthaben.

Ergebnis: Der aktuelle Restsaldo pro Pauschalposition wird berechnet und angezeigt.

1.2.5 Auftragssperre anzeigen

Was: Das System zeigt den Sperrstatus eines Auftrags an, wenn dieser gerade von einem anderen Benutzer bearbeitet wird.

Warum: Parallele Bearbeitung desselben Auftrags kann zu Dateninkonsistenzen führen. Die Sperranzeige warnt den Sachbearbeiter und verhindert gleichzeitige Änderungen.

Ergebnis: Der Sperrstatus wird angezeigt, inklusive des sperrenden Benutzers und des Sperrzeitpunkts.

1.2.6 Neue Version erstellen

Was: Der Sachbearbeiter erstellt eine neue Version eines Pauschalauftrags, wenn sich Konditionen, Umfang oder Preise ändern.

Warum: Änderungen an laufenden Pauschalverträgen müssen versioniert werden, um die Nachvollziehbarkeit der Vertragshistorie zu gewährleisten.

Ergebnis: Eine neue Auftragsversion wird erstellt, die bisherige Version bleibt als Archiv erhalten.

1.2.7 Saldoberechnungen speichern

Was: Der Sachbearbeiter speichert die aktualisierten Saldowerte nach der Berechnung.

Warum: Die berechneten Salden müssen persistent gespeichert werden, damit sie bei der nächsten Abrechnung oder Auswertung als Basis dienen.

Ergebnis: Die aktuellen Saldowerte aller bearbeiteten Pauschalpositionen sind gespeichert.

1.3 Provisionsauswertung

1.3.1 Provisionssummen pro Mitarbeiter anzeigen

Was: Der Sachbearbeiter öffnet die Provisionsauswertung und sieht die Gesamtprovisionen je Vertriebsmitarbeiter in einer Drei-Panel-Übersicht (Mitarbeiterliste, Detaildaten, Belege).

Warum: Die Provisionsübersicht dient der Abrechnung und Kontrolle der Vertriebsvergütung und bildet die Basis für die Gehaltsabrechnung des Vertriebs.

Ergebnis: Eine Übersicht der Provisionssummen pro Mitarbeiter wird angezeigt, mit Möglichkeit zum Drill-Down in Einzelbelege.

1.3.2 Monatsziele setzen

Was: Der Vertriebsleiter definiert die monatlichen Verkaufsziele pro Mitarbeiter als Soll-Werte.

Warum: Verkaufsziele bilden die Grundlage für den Soll/Ist-Vergleich und die leistungsbezogene Provisionsberechnung.

Ergebnis: Die Monatsziele sind pro Mitarbeiter hinterlegt und stehen für den Soll/Ist-Vergleich zur Verfügung.

1.3.3 Soll/Ist-Vergleich

Was: Das System vergleicht die tatsächlich erzielten Provisionen mit den definierten Monatszielen und hebt Abweichungen farblich hervor (grün: über Plan, rot: unter Plan).

Warum: Der Soll/Ist-Vergleich macht die Zielerreichung jedes Vertriebsmitarbeiters auf einen Blick sichtbar und unterstützt die Vertriebssteuerung.

Ergebnis: Pro Mitarbeiter wird die Zielerreichung in Prozent angezeigt, ergänzt um eine farbliche Kennzeichnung der Abweichung.

1.3.4 Detaillierte Provisionsaufschlüsselung anzeigen

Was: Der Sachbearbeiter klappt die Provisionsdetails eines Mitarbeiters auf und sieht die Berechnung für jeden einzelnen Beleg – Basiswert, Provisionssatz und errechneter Betrag.

Warum: Für die Transparenz und Nachvollziehbarkeit der Provisionsabrechnung muss jeder einzelne Provisionsanspruch beleggenau nachvollziehbar sein.

Ergebnis: Eine Einzelpositions-Darstellung aller Provisionsberechnungen pro Beleg wird angezeigt.

1.3.5 Nach Zeitraum filtern

Was: Der Sachbearbeiter grenzt die Provisionsauswertung auf einen bestimmten Zeitraum ein (z. B. Monat, Quartal, Jahr).

Warum: Provisionsabrechnungen werden periodengerecht erstellt. Die Zeitraumfilterung ermöglicht die Auswertung für die jeweilige Abrechnungsperiode.

Ergebnis: Die Provisionsauswertung zeigt nur Belege und Provisionen innerhalb des gewählten Zeitraums.

1.3.6 Nach Excel exportieren

Was: Der Sachbearbeiter exportiert die Provisionsauswertung als Excel-Datei mit konfigurierbaren Spalten.

Warum: Die exportierten Daten werden für die Lohnbuchhaltung, für Controlling-Auswertungen oder als Basis für Mitarbeitergespräche benötigt.

Ergebnis: Eine Excel-Datei mit den Provisionsdaten wird erstellt und zum Download bereitgestellt.

1.3.7 Verknüpfung zur Schema-Verwaltung

Was: Der Sachbearbeiter springt direkt aus der Provisionsauswertung in die Provisionsschema-Konfiguration, um ein Schema zu prüfen oder anzupassen.

Warum: Bei Auffälligkeiten in der Provisionsberechnung muss der Sachbearbeiter schnell prüfen können, welches Schema zugrunde liegt und ob es korrekt konfiguriert ist.

Ergebnis: Die Provisionsschema-Verwaltung wird im Kontext des aktuell betrachteten Schemas geöffnet.

1.4 Provisionsschemas verwalten

1.4.1 Alle Provisionsschemas anzeigen

Was: Der Administrator öffnet die Provisionsschema-Verwaltung und sieht eine Übersicht aller definierten Provisionsvorlagen mit deren Konfigurationsdetails.

Warum: Provisionsschemas definieren die Berechnungsregeln für Vertriebsprovisionen. Die Gesamtübersicht ermöglicht die Verwaltung und den Vergleich aller vorhandenen Modelle.

Ergebnis: Alle Provisionsschemas werden mit Empfängertyp, Provisionssatz, Gültigkeitszeitraum und Einkommensquelle tabellarisch angezeigt.

1.4.2 Nachfolge-Schema setzen (NextSchema)

Was: Der Administrator verknüpft ein Provisionsschema mit einem Nachfolge-Schema, das automatisch nach Ablauf des aktuellen Schemas aktiv wird.

Warum: Zeitlich gestaffelte Provisionsmodelle (z. B. höhere Provision im ersten Jahr, danach Standardsatz) erfordern eine automatische Abfolge von Schemas.

Ergebnis: Das Nachfolge-Schema ist verknüpft und wird nach Ablauf des aktuellen Schemas automatisch angewendet.

1.4.3 Ablaufdatum setzen

Was: Der Administrator legt das Ablaufdatum eines Provisionsschemas fest, nach dem es nicht mehr für neue Berechnungen herangezogen wird.

Warum: Provisionsmodelle ändern sich im Laufe der Zeit. Das Ablaufdatum steuert den automatischen Übergang zum Nachfolge-Schema und verhindert die Verwendung veralteter Modelle.

Ergebnis: Das Schema wird nach dem Ablaufdatum nicht mehr für neue Provisionsberechnungen verwendet.

1.4.4 Empfängertyp auswählen

Was: Der Administrator wählt den Provisionsempfänger aus 11 verschiedenen Empfängertypen – z. B. Verkäufer, Innendienst, Teamleiter, Vertriebsleiter oder externer Partner.

Warum: Provisionen werden an verschiedene Beteiligte im Vertriebsprozess ausgeschüttet. Der Empfängertyp bestimmt, wer die Provision erhält.

Ergebnis: Der gewählte Empfängertyp ist im Schema hinterlegt und steuert die Zuordnung bei der Provisionsberechnung.

1.4.5 Anteilsprozentsatz konfigurieren

Was: Der Administrator legt den prozentualen Anteil fest, den der Provisionsempfänger an der Gesamtprovision erhält.

Warum: Wenn mehrere Beteiligte am Verkaufserfolg partizipieren (z. B. Verkäufer 60 %, Teamleiter 40 %), muss die Aufteilung pro Schema konfiguriert werden.

Ergebnis: Der Anteilsprozentsatz ist im Schema hinterlegt und wird bei der Provisionsberechnung angewendet.

1.4.6 Provisionsprozentsatz konfigurieren

Was: Der Administrator legt den Provisionssatz fest, z. B. 5 % vom Umsatz oder 10 % vom Ertrag.

Warum: Der Provisionssatz ist die zentrale Berechnungsgrundlage für die Vertriebsprovision und variiert je nach Produktkategorie, Umsatzvolumen oder Vertragstyp.

Ergebnis: Der Provisionsprozentsatz ist im Schema hinterlegt und wird bei jeder Provisionsberechnung angewendet.

1.4.7 Einkommensquelle auswählen

Was: Der Administrator definiert die Umsatzquelle für die Provisionsberechnung: Alle Umsätze, nur Services, nur Produkte oder bestimmte Materialgruppen.

Warum: Nicht immer soll die Provision auf den gesamten Umsatz berechnet werden – z. B. können Hardware-Verkäufe eine andere Provisionsregel haben als Dienstleistungen.

Ergebnis: Das Schema wird nur auf Belege der gewählten Umsatzquelle angewendet.

1.4.8 Wertberechnung konfigurieren

Was: Der Administrator wählt die Berechnungsmethode: Automatisch (System entscheidet), auf Basis des Ertrags (Marge) oder auf Basis des Umsatzes (Bruttowert).

Warum: Je nach Vertriebsstrategie können Provisionen am Ertrag (fördert margenstarke Verkäufe) oder am Umsatz (fördert Volumen) gemessen werden.

Ergebnis: Die gewählte Berechnungsmethode ist im Schema hinterlegt und bestimmt die Berechnungsbasis.

1.4.9 Schema-Zyklen erkennen

Was: Das System prüft die Nachfolge-Schema-Ketten auf zirkuläre Verweise (A → B → C → A) und warnt den Administrator.

Warum: Zirkuläre Schema-Ketten würden zu Endlosschleifen bei der Provisionsberechnung führen und müssen erkannt und verhindert werden.

Ergebnis: Bei Erkennung eines Zyklus wird eine Warnung angezeigt und die Speicherung der zirkulären Kette wird verhindert.

1.4.10 Batch-Anwendung auf Belege

Was: Der Administrator wendet ein Provisionsschema nachträglich auf eine große Anzahl bestehender Belege (über 200) in einem Durchgang an.

Warum: Bei der Einführung neuer Provisionsmodelle oder bei Korrekturen müssen bestehende Belege rückwirkend mit dem neuen Schema berechnet werden.

Ergebnis: Alle ausgewählten Belege werden mit dem neuen Provisionsschema berechnet und die Provisionswerte aktualisiert.

1.5 Provisionsschema-Kundenzuordnung

1.5.1 Kunden mit Zuordnungen auflisten

Was: Der Administrator sieht eine Übersicht aller Kunden mit ihren zugeordneten Provisionsschemas.

Warum: Die Gesamtübersicht ermöglicht die Prüfung und Verwaltung der Kunden-Schema-Zuordnungen und zeigt, welche Kunden bereits ein Schema haben und welche das Standard-Schema verwenden.

Ergebnis: Eine tabellarische Übersicht aller Kunden-Schema-Verknüpfungen wird angezeigt.

1.5.2 Schema pro Filiale zuordnen

Was: Der Administrator konfiguriert filialspezifische Provisionsschemas, wobei für jede Filiale eine eigene Spalte in der Zuordnungsmatrix generiert wird.

Warum: Verschiedene Standorte können unterschiedliche Provisionsmodelle haben – z. B. höhere Provisionen in Regionen mit stärkerem Wettbewerb.

Ergebnis: Die filialspezifischen Schema-Zuordnungen sind konfiguriert und werden bei der Provisionsberechnung berücksichtigt.

1.5.3 Globales Fallback-Schema setzen

Was: Der Administrator definiert ein Standard-Provisionsschema, das für alle Kunden gilt, denen kein spezifisches Schema zugeordnet ist.

Warum: Nicht für jeden Kunden wird ein individuelles Schema benötigt. Das Fallback-Schema stellt sicher, dass auch ohne explizite Zuordnung eine Provisionsberechnung erfolgt.

Ergebnis: Das Fallback-Schema ist gesetzt und wird automatisch auf Kunden ohne individuelle Zuordnung angewendet.

1.5.4 Kundenbezogene Schema-Zuordnung

Was: Der Administrator überschreibt das Standard-Schema für einen bestimmten Kunden mit einem kundenspezifischen Provisionsschema.

Warum: Strategisch wichtige Kunden oder besondere Vertragskonstellationen erfordern individuelle Provisionsregeln, die vom Standard abweichen.

Ergebnis: Das kundenspezifische Schema hat die höchste Priorität und übersteuert sowohl das Fallback- als auch das Filial-Schema.

1.5.5 Massenzuordnung bearbeiten

Was: Der Administrator bearbeitet Schema-Zuordnungen für mehrere Kunden gleichzeitig über ein Kontextmenü mit Multi-Row-Bearbeitung.

Warum: Bei der Umstellung von Provisionsmodellen müssen viele Kunden gleichzeitig ein neues Schema erhalten, was einzeln unpraktikabel wäre.

Ergebnis: Alle ausgewählten Kunden haben die neue Schema-Zuordnung erhalten.

1.5.6 Auf Belege anwenden (Batch)

Was: Der Administrator aktualisiert bestehende Rechnungen mit den neuen Provisionsschema-Zuordnungen in einem Batch-Vorgang.

Warum: Nach Änderung der Schema-Zuordnungen müssen bestehende, noch nicht abgerechnete Belege die neuen Zuordnungen berücksichtigen.

Ergebnis: Die Provisionen der betroffenen Belege werden gemäß den neuen Zuordnungen neu berechnet.

1.5.7 Provisionsschemas cachen

Was: Das System speichert die Provisionsschema-Daten für die aktuelle Sitzung im Arbeitsspeicher zwischen.

Warum: Da Provisionsschemas bei jeder Belegbearbeitung abgefragt werden, verbessert das Caching die Antwortzeiten erheblich, insbesondere bei vielen Belegen.

Ergebnis: Schema-Abfragen werden aus dem Cache beantwortet, was die Verarbeitungsgeschwindigkeit deutlich erhöht.

1.6 Vereinfachte Ticketabrechnung

1.6.1 Timer filtern (15+ Kriterien)

Was: Der Sachbearbeiter filtert die abzurechnenden Support-Timer mit über 15 kombinierbaren Kriterien, z. B. nach Kunde, Ticket, Zeitraum, Mitarbeiter, Status, Vertragsart und Abrechnungsstatus.

Warum: Die Ticketabrechnung erfordert eine präzise Vorauswahl der zu fakturierenden Timer, da nicht alle Timer abrechenbar sind (z. B. Kulanzleistungen, interne Aufwände).

Ergebnis: Eine gefilterte Timer-Liste zeigt nur die abzurechnenden Einträge an.

1.6.2 Inline-Timer-Bearbeitung

Was: Der Sachbearbeiter bearbeitet die Beschreibungstexte der Timer direkt in der Abrechnungsliste, ohne den Timer einzeln öffnen zu müssen.

Warum: Timer-Texte werden häufig vor der Abrechnung für den Kunden aufbereitet – z. B. um interne Vermerke zu entfernen oder die Beschreibung verständlicher zu formulieren.

Ergebnis: Die Timer-Texte sind direkt in der Liste editiert und werden so auf der Rechnung erscheinen.

1.6.3 KI-Textbewertung

Was: Das System bewertet die Qualität der Timer-Texte mittels KI-Analyse (Beta-Funktion) und gibt einen Qualitätsscore zurück. Das Timeout beträgt 30 Sekunden.

Warum: Schlecht formulierte Timer-Texte auf Kundenrechnungen wirken unprofessionell. Die automatische Bewertung hilft, qualitativ unzureichende Texte vor der Fakturierung zu identifizieren.

Ergebnis: Jeder Timer-Text erhält einen Qualitätsscore, der die Textqualität als Prozentwert anzeigt.

1.6.4 Qualitätsschwelle setzen

Was: Der Sachbearbeiter legt einen Mindest-Qualitätsscore fest und filtert Timer heraus, deren Textqualität unter dieser Schwelle liegt.

Warum: Nur Timer mit ausreichender Textqualität sollen auf die Kundenrechnung übernommen werden. Timer unter der Schwelle müssen vorher nachbearbeitet werden.

Ergebnis: Timer mit unzureichender Textqualität werden herausgefiltert oder markiert und können gezielt nachbearbeitet werden.

1.6.5 Texteinfügungs-Optionen

Was: Der Sachbearbeiter konfiguriert, wie Timer-Texte in die Rechnungspositionen übernommen werden – z. B. als Einzelpositionen, zusammengefasst oder mit bestimmter Formatierung.

Warum: Je nach Kundenwunsch sollen die Leistungsbeschreibungen detailliert (pro Timer) oder zusammengefasst (pro Ticket oder Kunde) auf der Rechnung erscheinen.

Ergebnis: Die Textformatierungskonfiguration wird auf alle Timer des aktuellen Abrechnungslaufs angewendet.

1.6.6 Timer gruppieren

Was: Der Sachbearbeiter gruppiert die Timer nach Kunde, Ticket oder Auftrag, um die Übersicht zu verbessern und die Abrechnung logisch zu strukturieren.

Warum: Bei großen Timer-Mengen ist eine Gruppierung notwendig, um zusammengehörige Leistungen gebündelt zu überprüfen und abzurechnen.

Ergebnis: Die Timer-Liste wird nach dem gewählten Kriterium gruppiert angezeigt.

1.6.7 Timer sortieren

Was: Der Sachbearbeiter ändert die Sortierreihenfolge der Timer-Liste, z. B. nach Datum, Kunde, Dauer oder Status.

Warum: Je nach Arbeitsschritt ist eine andere Sortierung hilfreich – z. B. nach Kunde für die Prüfung oder nach Datum für die chronologische Übersicht.

Ergebnis: Die Timer-Liste wird in der gewählten Reihenfolge angezeigt.

1.6.8 Tickets automatisch schließen

Was: Der Sachbearbeiter aktiviert die Option, dass Tickets nach erfolgreicher Abrechnung aller zugehörigen Timer automatisch geschlossen werden.

Warum: Tickets, deren gesamter Aufwand abgerechnet ist, sind inhaltlich abgeschlossen und sollen nicht mehr in der offenen Ticket-Liste erscheinen.

Ergebnis: Nach der Rechnungserstellung werden die vollständig abgerechneten Tickets automatisch auf den Status „Geschlossen" gesetzt.

1.6.9 Auf Auftragspositionen zuordnen

Was: Der Sachbearbeiter verknüpft die Timer mit spezifischen Einzelpositionen eines Auftrags, gegen die der Zeitaufwand gebucht werden soll.

Warum: Bei auftragsgebundener Abrechnung muss der Zeitaufwand den korrekten Auftragspositionen zugeordnet werden, um eine positionsgenaue Fakturierung zu ermöglichen.

Ergebnis: Die Timer sind den Auftragspositionen zugeordnet und werden bei der Rechnungserstellung positionsgenau berücksichtigt.

1.6.10 Preisquelle auswählen

Was: Der Sachbearbeiter wählt die Preisberechnungsmethode für die Ticketabrechnung: Stundensatz aus dem Kundenstamm, aus dem Mitarbeiterprofil, aus dem Vertrag oder manuell.

Warum: Verschiedene Kunden und Verträge haben unterschiedliche Verrechnungssätze. Die richtige Preisquelle stellt die korrekte Berechnung sicher.

Ergebnis: Die gewählte Preisquelle wird für alle Timer des aktuellen Abrechnungslaufs als Berechnungsbasis verwendet.

1.6.11 Zusammenfassungsstatistik anzeigen

Was: Das System zeigt eine Übersicht mit Kunden-, Ticket- und Timer-Zählern sowie den Gesamtstunden und geschätzten Beträgen.

Warum: Die Zusammenfassung gibt dem Sachbearbeiter einen schnellen Überblick über den Umfang des aktuellen Abrechnungslaufs, bevor die Rechnungen generiert werden.

Ergebnis: Die Statistik wird mit Anzahl Kunden, Tickets, Timer, Gesamtstunden und geschätztem Gesamtbetrag angezeigt.

1.6.12 Rechnungsvorschau

Was: Der Sachbearbeiter prüft die generierten Rechnungen in einer Vorschau, bevor sie endgültig erstellt werden.

Warum: Die letzte Kontrolle vor der Rechnungserstellung ermöglicht die Identifikation von Fehlern oder unvollständigen Daten.

Ergebnis: Eine Vorschau der geplanten Rechnungen mit Positionen und Beträgen wird angezeigt.

1.6.13 Batch verarbeiten

Was: Das System erstellt die Rechnungen in einer Stapelverarbeitung mit automatischem Speicher-Management für große Datenmengen.

Warum: Bei vielen Kunden und Timern kann die Rechnungserstellung ressourcenintensiv sein. Die Batch-Verarbeitung optimiert den Speicherverbrauch und verhindert Systemüberlastung.

Ergebnis: Alle Rechnungen werden im Batch erstellt, der Fortschritt wird angezeigt.

1.6.14 Verarbeitung abbrechen

Was: Der Sachbearbeiter bricht einen laufenden Batch-Abrechnungsvorgang ab.

Warum: Bei erkannten Fehlern oder falscher Konfiguration soll der Sachbearbeiter den Vorgang stoppen können, bevor weitere fehlerhafte Rechnungen erstellt werden.

Ergebnis: Die Verarbeitung wird gestoppt. Bereits erstellte Rechnungen bleiben bestehen, weitere werden nicht erzeugt.

1.6.15 Rechnungsergebnisse anzeigen

Was: Der Sachbearbeiter sieht nach Abschluss des Abrechnungslaufs eine Zusammenfassung der erstellten Rechnungen mit Anzahl, Gesamtbetrag und Status.

Warum: Die Ergebnisübersicht gibt Aufschluss über den Erfolg des Abrechnungslaufs und zeigt ggf. fehlgeschlagene Rechnungen zur Nachbearbeitung an.

Ergebnis: Eine Zusammenfassung mit Anzahl erstellter Rechnungen, Gesamtbetrag, Erfolgs- und Fehlerrate wird angezeigt.

2. Administration

2.1 Aufschläge Stundensätze

2.1.1 Stundenzuschläge für Mitarbeitertypen definieren

Was: Der Administrator definiert prozentuale oder feste Zuschläge auf Stundensätze für verschiedene Mitarbeitertypen (z. B. Techniker, Berater, Projektleiter) mit einem Gültigkeitszeitraum.

Warum: Unterschiedliche Qualifikationen und Einsatzarten rechtfertigen verschiedene Zuschläge, die korrekt und periodengerecht auf die Verrechnungssätze angewendet werden müssen.

Ergebnis: Die Stundenzuschläge sind pro Mitarbeitertyp und Gültigkeitszeitraum hinterlegt und werden bei der Zeiterfassung automatisch berücksichtigt.

2.1.2 Zuschlagsregeln pro Vertrag oder Projekt

Was: Der Administrator erstellt spezifische Zuschlagsregeln auf Vertrags- oder Projektebene, die von den Standardzuschlägen abweichen können, mit optionaler Obergrenze.

Warum: Bestimmte Verträge oder Projekte haben individuelle Preisvereinbarungen, die eigene Zuschlagsregeln erfordern – z. B. ein Festpreis-Projekt ohne Nachtzuschlag.

Ergebnis: Die vertrags- oder projektspezifischen Zuschlagsregeln übersteuern die Standardzuschläge und werden bei der Abrechnung angewendet.

2.1.3 Urlaubszuschläge und Krankheitszuschläge konfigurieren

Was: Der Administrator hinterlegt Zuschläge für Urlaubs- und Krankheitstage. Das System wendet diese automatisch an, wenn entsprechende Einträge im Stundenzettel vorhanden sind.

Warum: Bei der Verrechnung von Fehlzeiten auf Projekte oder Kostenstellen müssen die korrekten Zuschläge (z. B. Urlaubsgeld-Anteil) automatisch berücksichtigt werden.

Ergebnis: Urlaubs- und Krankheitszuschläge werden automatisch bei der Zeiterfassung und Abrechnung angewendet.

2.1.4 Zeitbasierte Zuschlagsmodelle

Was: Der Administrator verwaltet Spät-, Nacht- und Wochenendzuschläge mit konfigurierbaren Übergangsbereichen (z. B. Nachtzuschlag ab 22:00 Uhr, Wochenendzuschlag am Samstag ab 13:00 Uhr).

Warum: Gesetzliche und tarifvertragliche Regelungen erfordern die korrekte Berechnung von Zeitzuschlägen, die je nach Tageszeit und Wochentag variieren.

Ergebnis: Die zeitbasierten Zuschlagsmodelle sind konfiguriert und werden bei der Erfassung von Arbeitszeiten außerhalb der Regelarbeitszeit automatisch angewendet.

2.1.5 Zuschlag-Verlauf und Änderungsverfolgung

Was: Das System dokumentiert alle Änderungen an Zuschlagskonfigurationen mit Audit-Trail (wer, wann, was) und ermöglicht die Wiederherstellung vorheriger Konfigurationen.

Warum: Zuschlagsänderungen können erhebliche finanzielle Auswirkungen haben. Die lückenlose Dokumentation dient der Nachvollziehbarkeit und Compliance.

Ergebnis: Alle Zuschlagsänderungen sind historisiert und können bei Bedarf zurückgesetzt werden.

2.1.6 Zuschlag-Simulation und Vorschau

Was: Der Administrator simuliert die Auswirkungen geplanter Zuschlagsänderungen auf bestehende Stundenzettel und sieht die finanziellen Auswirkungen vor der Aktivierung.

Warum: Vor der Aktivierung neuer Zuschlagsmodelle müssen die finanziellen Auswirkungen bekannt sein, um unbeabsichtigte Kostenänderungen zu vermeiden.

Ergebnis: Eine Vorschau zeigt die Differenz zwischen aktuellem und neuem Zuschlagsmodell für alle betroffenen Stundenzettel.

2.2 c-entron DSGVO

2.2.1 Datenverarbeitungsvorgaben und -verträge verwalten

Was: Der Datenschutzbeauftragte verwaltet Auftragsverarbeitungsverträge (AVVs) mit Kategorien, Datentypen, Verarbeitungszweck und Speicherdauer.

Warum: Die DSGVO erfordert die Dokumentation aller Datenverarbeitungsvorgänge und die Pflege zugehöriger Verträge mit Auftragsverarbeitern.

Ergebnis: Alle AVVs sind mit ihren Rahmenbedingungen erfasst und können bei Anfragen oder Audits vorgelegt werden.

2.2.2 Datenlösch-Regeln und -Fristen konfigurieren

Was: Der Datenschutzbeauftragte konfiguriert automatisierte Löschregeln mit DSGVO-konformen Fristen, Löschmethoden und Ausnahmen.

Warum: Personenbezogene Daten müssen nach Ablauf des Verarbeitungszwecks gelöscht werden. Automatisierte Regeln stellen die fristgerechte Löschung sicher.

Ergebnis: Die Löschregeln sind konfiguriert und das System führt die Löschung automatisch nach Fristablauf durch.

2.2.3 Datenschutz-Einwilligungen verwalten

Was: Der Sachbearbeiter verwaltet und verfolgt Datenschutz-Einwilligungen mit Vorlagen, Datum, IP-Adresse und Kommunikationskanal.

Warum: Die Einholung und Dokumentation von Einwilligungen ist Voraussetzung für die rechtmäßige Verarbeitung personenbezogener Daten.

Ergebnis: Alle Einwilligungen sind mit Zeitstempel und Quelle dokumentiert und können jederzeit nachgewiesen werden.

2.2.4 Datensubjekt-Anfragen (Auskunft, Berichtigung, Löschung)

Was: Der Sachbearbeiter verwaltet Betroffenenanfragen gemäß DSGVO mit automatischer Datensammlung aus allen relevanten Modulen und Überwachung der 30-Tage-Frist.

Warum: Die DSGVO gibt Betroffenen das Recht auf Auskunft, Berichtigung und Löschung. Anfragen müssen fristgerecht innerhalb von 30 Tagen bearbeitet werden.

Ergebnis: Die Betroffenenanfrage ist bearbeitet, alle relevanten Daten sind zusammengestellt und die Antwort innerhalb der Frist dokumentiert.

2.2.5 Datenschutz-Folgeabschätzung (DPIA)

Was: Der Datenschutzbeauftragte dokumentiert und führt Datenschutz-Folgeabschätzungen für riskante Verarbeitungen durch, mit Risikobewertung und Gegenmaßnahmen.

Warum: Für Verarbeitungen mit hohem Risiko für Betroffene ist eine DPIA gesetzlich vorgeschrieben (Art. 35 DSGVO).

Ergebnis: Die DPIA ist dokumentiert, Risiken sind bewertet und Gegenmaßnahmen sind definiert.

2.2.6 Datenschutzverletzungen melden

Was: Der Datenschutzbeauftragte registriert und meldet Sicherheitsvorfälle an die Aufsichtsbehörde gemäß Art. 33 DSGVO, mit Schweregradbeurteilung und betroffenen Daten.

Warum: Datenschutzverletzungen müssen innerhalb von 72 Stunden an die zuständige Behörde gemeldet werden. Die strukturierte Erfassung beschleunigt die Meldung.

Ergebnis: Der Vorfall ist dokumentiert, der Schweregrad bewertet und die Meldung an die Behörde vorbereitet oder abgesetzt.

2.3 Einstellungen

2.3.1 Globale Systemparameter konfigurieren

Was: Der Administrator legt grundlegende Systemeinstellungen fest: Sprache, Zahlenformat, Datumsformat und regionale Standards.

Warum: Das System muss an die regionalen Gegebenheiten des Unternehmens angepasst sein, damit Daten korrekt dargestellt und verarbeitet werden.

Ergebnis: Die globalen Systemparameter sind gesetzt und wirken auf alle Module.

2.3.2 UI-Theme und Darstellung anpassen

Was: Der Benutzer passt sein persönliches Erscheinungsbild an: Theme (Hell/Dunkel), Schriftgröße, Ribbon-Position und Startbildschirm.

Warum: Individuelle Darstellungspräferenzen verbessern die Arbeitseffizienz und den Komfort bei der täglichen Nutzung.

Ergebnis: Die UI-Einstellungen sind benutzerspezifisch gespeichert und werden beim nächsten Login automatisch angewendet.

2.3.3 Logging und Debugging aktivieren

Was: Der Administrator konfiguriert Log-Level, Log-Ziel, Rotation-Richtlinie und Performance-Tracing für die Systemdiagnose.

Warum: Bei Fehlern oder Performance-Problemen sind detaillierte Logs zur Diagnose und Fehlerbehebung unerlässlich.

Ergebnis: Das Logging ist konfiguriert und Diagnosedaten werden gemäß den Einstellungen protokolliert.

2.3.4 E-Mail und Benachrichtigungen konfigurieren

Was: Der Administrator richtet den SMTP-Server mit Port, Authentifizierung, SSL/TLS und Benachrichtigungsfiltern ein.

Warum: Alle E-Mail-Funktionen des Systems (Rechnungsversand, Mahnungen, Benachrichtigungen) benötigen eine korrekte SMTP-Konfiguration.

Ergebnis: Der E-Mail-Versand ist konfiguriert und funktionsfähig.

2.3.5 Datenbank-Verbindung konfigurieren

Was: Der Administrator verwaltet Verbindungsparameter wie Connection Pool, Timeout und Backup-Konfiguration.

Warum: Die Datenbankverbindung ist die Grundlage des gesamten Systems. Korrekte Einstellungen sichern Stabilität und Performance.

Ergebnis: Die Datenbankverbindung ist konfiguriert und das System kann stabil auf die Daten zugreifen.

2.3.6 Lizenzen verwalten und Feature-Flags setzen

Was: Der Administrator aktiviert oder deaktiviert Modullizenzen, überwacht Verfallsdaten und verwaltet Testlizenzen.

Warum: Die Lizenzierung steuert, welche Module und Funktionen dem Unternehmen zur Verfügung stehen. Abgelaufene Lizenzen müssen rechtzeitig erneuert werden.

Ergebnis: Der Lizenzstatus ist aktuell, verfügbare Module sind aktiviert und Ablaufwarnungen sind konfiguriert.

2.3.7 Benutzerverwaltung und Authentifizierung

Was: Der Administrator konfiguriert Authentifizierungsmethoden (SSO über Azure AD, lokale Anmeldung), Passwort-Richtlinien, Session-Timeout, Zwei-Faktor-Authentifizierung und API-Keys.

Warum: Die Zugriffssicherheit des Systems erfordert sichere Authentifizierungsmethoden und klare Richtlinien für Passwörter und Sitzungen.

Ergebnis: Die Authentifizierung ist konfiguriert und alle Benutzer können sich gemäß den Richtlinien anmelden.

2.3.8 Berichterstellung und Export konfigurieren

Was: Der Administrator richtet den Report-Server ein, definiert das PDF-Export-Standardformat und konfiguriert die automatische Generierung und Archivierung.

Warum: Berichte und Exporte sind zentrale Ausgabemethoden des Systems. Die korrekte Konfiguration stellt die Verfügbarkeit und das Format sicher.

Ergebnis: Berichte können generiert, exportiert und archiviert werden.

2.3.9 Sprach- und Lokalisierungseinstellungen

Was: Der Administrator konfiguriert die Mehrsprachigkeit, Zahlen-Lokalisierung, Währung, Land/Region und den Feiertagskalender.

Warum: Ein ERP-System für deutsche KMU muss korrekt lokalisiert sein – von der Währung über das Datumsformat bis hin zu Feiertagen für Fristberechnungen.

Ergebnis: Alle Lokalisierungseinstellungen sind korrekt konfiguriert.

2.3.10 Sicherheits- und Compliance-Einstellungen

Was: Der Administrator konfiguriert Audit-Logging, Verschlüsselung ruhender Daten, Passwort-Historie und IP-Whitelist.

Warum: Compliance-Anforderungen (GoBD, DSGVO) erfordern Audit-Trails, Verschlüsselung und Zugriffskontrolle als Mindeststandard.

Ergebnis: Die Sicherheitseinstellungen sind aktiviert und das System erfüllt die Compliance-Anforderungen.

2.4 Kontenrahmen

2.4.1 Standard-Kontenrahmen importieren

Was: Der Administrator importiert einen Standard-Kontenrahmen (SKR03 oder SKR04) aus einer vordefinierten Vorlage mit allen Kontonummern und Steuerklassen.

Warum: Der Kontenrahmen ist die Grundlage für alle Buchungsvorgänge. Ein Import aus Vorlagen beschleunigt die Einrichtung und stellt die Konformität mit deutschen Buchhaltungsstandards sicher.

Ergebnis: Der gewählte Standard-Kontenrahmen ist importiert und alle Konten stehen für Buchungen zur Verfügung.

2.4.2 Benutzerdefinierte Konten hinzufügen

Was: Der Administrator erweitert den Standard-Kontenrahmen um firmenspezifische Konten mit individuellem Steuerschlüssel.

Warum: Nicht alle Geschäftsvorfälle eines Unternehmens lassen sich über Standard-Konten abbilden – z. B. für spezielle Erlös- oder Aufwandsarten.

Ergebnis: Die neuen Konten sind im Kontenrahmen verfügbar und können für Buchungen verwendet werden.

2.4.3 Konten-Mapping für verschiedene Mandanten

Was: Der Administrator konfiguriert unterschiedliche Kontenrahmen pro Mandant für die Multi-Mandanten-Fähigkeit.

Warum: Verschiedene Gesellschaften innerhalb eines Unternehmens können unterschiedliche Kontenrahmen (z. B. SKR03 und SKR04) verwenden.

Ergebnis: Jeder Mandant hat seinen eigenen Kontenrahmen, der bei Buchungen automatisch verwendet wird.

2.4.4 Konten-Status verwalten (Aktiv/Inaktiv)

Was: Der Administrator deaktiviert nicht benötigte Konten, wobei das System auf offene Buchungen prüft und eine Deaktivierung nur bei buchungsfreien Konten erlaubt.

Warum: Nicht mehr genutzte Konten sollen nicht in Auswahlfeldern erscheinen, um Fehlbuchungen zu vermeiden, ohne dass historische Buchungsdaten verloren gehen.

Ergebnis: Das Konto ist deaktiviert und erscheint nicht mehr in Auswahllisten, bleibt aber für historische Auswertungen erhalten.

2.5 Leasing/Service

2.5.1 Leasing-Rate konfigurieren

Was: Der Administrator definiert standardisierte Leasing-Konditionen mit Laufzeit, Ratenintervall, Leasing-Faktor und Produktkategorien.

Warum: Leasing-Angebote erfordern einheitliche Konditionen, die automatisch in Angebote und Verträge übernommen werden, um konsistente Kalkulationen sicherzustellen.

Ergebnis: Die Leasing-Rate ist konfiguriert und kann bei der Angebots- und Vertragserstellung automatisch angewendet werden.

2.5.2 Wartungsvertrag-Vorlage anlegen

Was: Der Administrator erstellt SLA-Vorlagen mit Reaktionszeit, Entstörungszeit, Verfügbarkeitsgarantie und Verknüpfung zum Ticketprozess.

Warum: Standardisierte Wartungsvertragsvorlagen beschleunigen die Vertragserstellung und stellen einheitliche Servicequalität sicher.

Ergebnis: Die SLA-Vorlage ist angelegt und kann bei der Erstellung neuer Wartungsverträge verwendet werden.

2.5.3 Gemischte Verträge (Leasing + Service)

Was: Der Administrator erstellt kombinierte Vertragsvorlagen, die sowohl Hardware-Leasing als auch Wartungsleistungen umfassen, mit automatischer Gesamtraten-Berechnung.

Warum: In der IT-Branche sind kombinierte Verträge (z. B. Drucker-Leasing inklusive Wartung) üblich. Die automatische Berechnung der Gesamtrate spart Zeit und verhindert Rechenfehler.

Ergebnis: Die gemischte Vertragsvorlage kalkuliert automatisch die Gesamtrate aus Leasing- und Servicekomponente.

2.5.4 Preisaktualisierung für bestehende Sätze

Was: Der Administrator führt eine Inflationsanpassung durch, sieht die Auswirkung auf aktive Verträge und übernimmt die neuen Sätze optional.

Warum: Vertragsklauseln mit Preisanpassungsmöglichkeiten erfordern regelmäßige Aktualisierungen der Basis-Sätze.

Ergebnis: Die aktualisierten Sätze sind gespeichert; bei aktiven Verträgen wird die Anpassung nach Bestätigung übernommen.

2.6 Mailvorlagen

2.6.1 Standard-Mailvorlage erstellen

Was: Der Administrator erstellt eine wiederverwendbare E-Mail-Vorlage mit HTML-Formatierung und Platzhaltern für dynamische Inhalte (Kundenname, Belegnummer, Betrag).

Warum: Standardisierte E-Mail-Vorlagen sichern einheitliche Kundenkommunikation und sparen Zeit bei wiederkehrenden Geschäftsvorgängen.

Ergebnis: Die Mailvorlage ist gespeichert und steht in allen Modulen zur Auswahl bereit.

2.6.2 Mailvorlage mit Anhang-Logik

Was: Der Administrator konfiguriert automatische Anhänge, die beim Versand basierend auf Bedingungen (Belegtyp, Kunde, Betrag) beigefügt werden.

Warum: Bestimmte Geschäftsvorgänge erfordern standardmäßig Anhänge – z. B. AGB bei Erstaufträgen oder Kontoverbindungen bei Rechnungen.

Ergebnis: Die Anhang-Logik ist konfiguriert und die Dokumente werden beim E-Mail-Versand automatisch beigefügt.

2.6.3 Mehrsprachige Mailvorlagen

Was: Der Administrator erstellt Mailvorlagen in Deutsch und Englisch, wobei die Sprache automatisch anhand der Kundenstammdaten gewählt wird.

Warum: Internationale Kunden sollen Kommunikation in ihrer Sprache erhalten, ohne dass der Sachbearbeiter manuell die richtige Vorlage auswählen muss.

Ergebnis: Beim E-Mail-Versand wird automatisch die Vorlage in der Kundensprache verwendet.

2.6.4 Ereignisbasierte Mailvorlagen

Was: Der Administrator konfiguriert automatische Benachrichtigungen bei Systemereignissen (z. B. Vertrag läuft aus, Rechnung überfällig) mit definiertem Auslöser und Empfängerlogik.

Warum: Proaktive Benachrichtigungen bei wichtigen Geschäftsereignissen ermöglichen zeitnahes Handeln und verbessern die Kundenbindung.

Ergebnis: Die ereignisbasierte Vorlage wird bei Eintritt des konfigurierten Auslösers automatisch versendet.

2.7 Mandanten

2.7.1 Neuen Mandanten anlegen

Was: Der Administrator erstellt einen neuen Mandanten als separate Geschäftseinheit mit isolierten Datenbereichen für Kunden, Artikel, Rechnungen und Einstellungen.

Warum: Unternehmen mit mehreren Gesellschaften oder Geschäftsbereichen benötigen getrennte Datenbereiche bei zentraler Verwaltung.

Ergebnis: Der neue Mandant ist angelegt und kann mit eigenen Daten und Einstellungen befüllt werden.

2.7.2 Mandanten-Wechsel für Benutzer

Was: Der Benutzer wechselt den aktiven Mandanten, wobei alle Daten und Einstellungen neu geladen werden.

Warum: Mitarbeiter, die für mehrere Gesellschaften arbeiten, müssen zwischen Mandanten wechseln können, um im richtigen Datenkontext zu arbeiten.

Ergebnis: Der Benutzer arbeitet im Kontext des gewählten Mandanten mit dessen spezifischen Daten und Einstellungen.

2.7.3 Mandanten-spezifische Einstellungen

Was: Der Administrator konfiguriert individuelle Einstellungen pro Mandant: Logo, Geschäftszeiten, Zahlungsbedingungen und Briefpapier.

Warum: Jede Gesellschaft hat eigene CI-Vorgaben, Geschäftszeiten und Standardkonditionen, die in Belegen und der Kommunikation korrekt abgebildet werden müssen.

Ergebnis: Die mandantenspezifischen Einstellungen sind gespeichert und werden in allen zugehörigen Dokumenten und Prozessen verwendet.

2.7.4 Mandanten-übergreifende Auswertungen

Was: Der Controller erstellt konsolidierte Berichte über alle Mandanten mit aggregierten Umsätzen, Kosten und Gewinnen, mit Drill-Down-Möglichkeit auf Einzelmandanten.

Warum: Die Unternehmensleitung benötigt eine Gesamtsicht über alle Gesellschaften für die strategische Steuerung.

Ergebnis: Ein konsolidierter Bericht über alle Mandanten wird angezeigt, mit der Möglichkeit, in einzelne Mandanten hineinzunavigieren.

2.8 Mitarbeiter

2.8.1 Mitarbeiter-Stammdaten anlegen

Was: Der Personalverantwortliche erfasst einen neuen Mitarbeiter mit Personalien, Vertragsdetails und optional einem Systembenutzerkonto mit Berechtigungen.

Warum: Mitarbeiterstammdaten sind die Basis für Zeiterfassung, Provisionsberechnung, Projektplanung und Systemzugriff.

Ergebnis: Der Mitarbeiter ist im System angelegt und kann – falls ein Benutzerkonto erstellt wurde – das System nutzen.

2.8.2 Arbeitszeiten und Abwesenheiten pflegen

Was: Der Sachbearbeiter verwaltet Urlaubstage, Krankheitszeiten und Arbeitszeitmodelle mit Genehmigungsworkflow.

Warum: Korrekte Arbeitszeitdaten sind für die Kapazitätsplanung, Zuschlagsberechnung und Lohnabrechnung erforderlich.

Ergebnis: Die Arbeitszeiten und Abwesenheiten sind erfasst, genehmigt und stehen für die Weiterverarbeitung bereit.

2.8.3 Stundensätze und Qualifikationen hinterlegen

Was: Der Administrator hinterlegt Verrechnungssätze, Kostensätze und Zertifizierungen für jeden Mitarbeiter.

Warum: Für die korrekte Projekt- und Kundenabrechnung müssen die mitarbeiterspezifischen Sätze und Qualifikationen gepflegt sein.

Ergebnis: Die Stundensätze und Qualifikationen sind hinterlegt und werden bei der Zeiterfassung und Projektplanung verwendet.

2.8.4 Mitarbeiter-Austritte und Archivierung

Was: Der Personalverantwortliche deaktiviert den Systembenutzer eines austretenden Mitarbeiters, verteilt offene Tickets und Aufgaben um und markiert den Mitarbeiter als inaktiv.

Warum: Beim Austritt eines Mitarbeiters müssen offene Vorgänge übergeben und der Systemzugang gesperrt werden, ohne historische Daten zu verlieren.

Ergebnis: Der Mitarbeiter ist deaktiviert, seine offenen Vorgänge sind umverteilt und der Systemzugang ist gesperrt.

2.8.5 Mitarbeiter einer Abteilung zuweisen

Was: Der Administrator ordnet einen Mitarbeiter einer Abteilung zu, was Voraussetzung für Kapazitätsplanung und Abteilungsberichte ist.

Warum: Die Abteilungszuordnung steuert Berichtsstrukturen, Genehmigungswege und die Ressourcenplanung.

Ergebnis: Der Mitarbeiter ist der Abteilung zugeordnet und erscheint in deren Auswertungen und Planungen.

2.8.6 Mitarbeiter einer Filiale zuweisen

Was: Der Administrator ordnet einen Mitarbeiter einem Standort zu, was Voraussetzung für Filialberichte und regionale Zuständigkeiten ist.

Warum: Die Filialzuordnung bestimmt die regionale Verantwortung und ermöglicht standortbezogene Auswertungen.

Ergebnis: Der Mitarbeiter ist dem Standort zugeordnet und wird in Filialberichten berücksichtigt.

2.8.7 Mitarbeiter Qualifikationen/Skills zuweisen

Was: Der Administrator ordnet einem Mitarbeiter Fähigkeiten und Spezialisierungen zu, z. B. bestimmte Zertifizierungen, Produktkenntnisse oder Technologie-Schwerpunkte.

Warum: Bei der Zuweisung von Tickets, Projekten und Serviceeinsätzen werden Techniker anhand ihrer Skills ausgewählt, um die richtige Kompetenz einzusetzen.

Ergebnis: Die Skills sind zugeordnet und werden bei der automatischen und manuellen Ressourcenzuweisung berücksichtigt.

2.9 Rechteverwaltung

2.9.1 Rechtegruppe erstellen

Was: Der Administrator erstellt vordefinierte Rechte-Sets (z. B. „Vertrieb Innendienst", „Buchhaltung", „Helpdesk") aus dem hierarchischen Rechte-Baum.

Warum: Statt jedem Benutzer einzelne Rechte zuzuweisen, werden typische Rollenprofile als Gruppen angelegt, was die Verwaltung erheblich vereinfacht.

Ergebnis: Die Rechtegruppe ist mit den ausgewählten Berechtigungen angelegt und kann Benutzern zugewiesen werden.

2.9.2 Benutzer zu Rechtegruppe zuweisen

Was: Der Administrator ordnet einen Benutzer einer oder mehreren Rechtegruppen zu, wobei alle Gruppenrechte addiert werden.

Warum: Die Gruppenzuordnung vereinfacht die Berechtigungsverwaltung und stellt sicher, dass Benutzer mit gleicher Rolle identische Rechte erhalten.

Ergebnis: Der Benutzer verfügt über alle Rechte der zugewiesenen Gruppen.

2.9.3 Einzelrechte gezielt erteilen oder entziehen

Was: Der Administrator erteilt oder entzieht einem Benutzer einzelne Berechtigungen, die immer Vorrang vor Gruppenrechten haben.

Warum: Für Ausnahmen – z. B. wenn ein Mitarbeiter zusätzlich ein bestimmtes Modul nutzen soll oder ein Recht trotz Gruppenmitgliedschaft nicht erhalten darf – sind Einzelrechte notwendig.

Ergebnis: Das Einzelrecht ist erteilt oder entzogen und übersteuert die Gruppenrechte.

2.9.4 Rechte-Audit und Compliance-Bericht

Was: Der Administrator erstellt einen Bericht über kritische Berechtigungen aller Benutzer, exportierbar nach Excel für die Compliance-Prüfung.

Warum: Regelmäßige Rechte-Audits sind für die IT-Sicherheit und Compliance-Anforderungen (z. B. ISO 27001, DSGVO) erforderlich.

Ergebnis: Ein vollständiger Rechte-Bericht aller Benutzer mit deren Berechtigungen steht als Excel-Export zur Verfügung.

2.10 Textbaustein-Verwaltung

2.10.1 Standard-Textbaustein erstellen

Was: Der Sachbearbeiter erstellt einen wiederverwendbaren Textbaustein mit Kürzel und Platzhaltern, der in Belegen und E-Mails eingefügt werden kann.

Warum: Standardtexte (Zahlungshinweise, Garantiebedingungen, Haftungsausschlüsse) sollen einheitlich und schnell per Kürzel eingefügt werden können.

Ergebnis: Der Textbaustein ist angelegt und kann in allen Modulen per Kürzel eingefügt werden.

2.10.2 Kategorisierung und Verschlagwortung

Was: Der Sachbearbeiter ordnet Textbausteine thematischen Kategorien zu und versieht sie mit Schlagwörtern für die kontextbasierte Suche.

Warum: Bei vielen Textbausteinen ist eine thematische Ordnung notwendig, damit das System automatisch passende Bausteine vorschlagen kann.

Ergebnis: Die Textbausteine sind kategorisiert und werden bei der Dokumentenerstellung kontextbasiert vorgeschlagen.

2.10.3 Mehrsprachige Textbausteine

Was: Der Administrator erstellt Textbausteine in Deutsch und Englisch, wobei die Sprachversion automatisch nach Kundenstammdaten gewählt wird.

Warum: Internationale Kunden sollen Belege und Korrespondenz in ihrer Sprache erhalten, ohne dass der Sachbearbeiter manuell übersetzen muss.

Ergebnis: Textbausteine werden automatisch in der Kundensprache eingefügt.

2.10.4 Textbausteine in Vorlagen einbetten

Was: Der Administrator bettet Textbausteine in Dokumentvorlagen ein, sodass Änderungen am Baustein automatisch in allen Vorlagen wirksam werden.

Warum: Zentrale Textänderungen (z. B. neue AGB-Klausel) sollen automatisch in allen betroffenen Vorlagen übernommen werden, ohne jede Vorlage einzeln anpassen zu müssen.

Ergebnis: Der Textbaustein ist in die Vorlage eingebettet und Änderungen wirken sich automatisch auf alle Dokumente aus.

2.11 Ticketprozess-Vorlagen

2.11.1 Standard-Ticketprozess definieren

Was: Der Administrator erstellt einen vordefinierten Workflow mit einzelnen Schritten, verantwortlicher Rolle, geschätzter Dauer und Pflichtfeldern pro Schritt.

Warum: Standardisierte Ticketprozesse stellen sicher, dass Support-Anfragen systematisch und qualitativ einheitlich bearbeitet werden.

Ergebnis: Die Ticketprozess-Vorlage ist angelegt und wird bei neuen Tickets des zugehörigen Typs automatisch angewendet.

2.11.2 SLA-Zeiten in Prozessvorlage

Was: Der Administrator hinterlegt Reaktions- und Lösungszeiten in der Prozessvorlage, die automatisch überwacht und bei Überschreitung eskaliert werden.

Warum: Vertraglich zugesicherte SLAs müssen eingehalten werden. Die automatische Überwachung und Eskalation verhindert SLA-Verletzungen.

Ergebnis: Die SLA-Zeiten sind hinterlegt, werden automatisch überwacht und lösen bei Überschreitung eine Eskalation aus.

2.11.3 Checklisten in Prozessschritten

Was: Der Administrator definiert Prüfpunkte als Bedingung für den Abschluss eines Prozessschritts.

Warum: Checklisten stellen sicher, dass bei jedem Prozessschritt alle notwendigen Prüfungen durchgeführt werden, bevor zum nächsten Schritt übergegangen wird.

Ergebnis: Der Prozessschritt kann erst abgeschlossen werden, wenn alle Prüfpunkte der Checkliste abgehakt sind.

2.11.4 Automatische Ticket-Klassifizierung

Was: Das System ordnet neue Tickets automatisch einer Prozessvorlage zu, basierend auf Betreff-Keywords, Priorität und Kundenkategorie.

Warum: Die automatische Klassifizierung beschleunigt die Ticketbearbeitung und stellt sicher, dass der richtige Prozess vom ersten Moment an angewendet wird.

Ergebnis: Neue Tickets werden automatisch dem passenden Prozess zugeordnet und der Bearbeitungs-Workflow startet sofort.

2.12 Vertragsarten

2.12.1 Vertragsart für Wartungsverträge definieren

Was: Der Administrator erstellt eine Vertragsart für Wartungsverträge mit Standard-Laufzeit, Verlängerungsoptionen, Kündigungsfristen und Abrechnungsintervall.

Warum: Wartungsverträge folgen standardisierten Konditionen. Die Vertragsart-Definition beschleunigt die Vertragserstellung und stellt Einheitlichkeit sicher.

Ergebnis: Die Vertragsart ist angelegt und steht bei der Neuanlage von Wartungsverträgen als Vorlage zur Verfügung.

2.12.2 Leasing-Vertragsart mit Rückgabebedingungen

Was: Der Administrator definiert eine Vertragsart für Hardware-Leasing mit Rückgabepflicht, Restwert-Berechnung und automatischen Verlängerungsoptionen.

Warum: Leasing-Verträge erfordern spezielle Konditionen wie Restwertberechnung und Rückgabemanagement, die standardisiert in der Vertragsart hinterlegt werden.

Ergebnis: Die Leasing-Vertragsart ist konfiguriert und enthält alle Regeln für Restwert und Rückgabe.

2.12.3 SLA-Vertragsart mit Reaktionszeiten

Was: Der Administrator erstellt eine Vertragsart mit garantierten Antwort- und Lösungszeiten, Verknüpfung zum Ticketprozess und optionalen Strafklauseln bei SLA-Verletzung.

Warum: IT-Systemhäuser bieten ihren Kunden SLA-basierte Serviceverträge an, deren Konditionen klar definiert und automatisch überwacht werden müssen.

Ergebnis: Die SLA-Vertragsart ist mit Reaktionszeiten und Ticketprozess-Verknüpfung konfiguriert.

2.12.4 Vertragsarten-Genehmigungsworkflow

Was: Der Administrator konfiguriert einen mehrstufigen Genehmigungsprozess für hochwertige Verträge mit Schwellenwerten und Genehmigungskette.

Warum: Verträge ab einem bestimmten Wert sollen nicht ohne Genehmigung durch Vorgesetzte oder Geschäftsführung abgeschlossen werden können.

Ergebnis: Der Genehmigungsworkflow ist konfiguriert und wird bei Verträgen über dem Schwellenwert automatisch ausgelöst.

2.13 Filialverwaltung

2.13.1 Filiale erstellen

Was: Der Administrator legt eine neue Filiale/einen neuen Standort an mit Name, Adresse und Verantwortlichem.

Warum: Filialen werden als Filterkriterium in Vertrags-, Provisions- und Kalkulationsmodulen referenziert und müssen im System angelegt sein.

Ergebnis: Die Filiale ist im System angelegt und kann in Verträgen, Mitarbeiterzuordnungen und Auswertungen verwendet werden.

2.13.2 Filiale bearbeiten

Was: Der Administrator ändert Filialdaten wie Adresse, Kontaktdaten und Öffnungszeiten.

Warum: Standortdaten ändern sich – z. B. bei Umzug, neuen Kontaktdaten oder geänderten Öffnungszeiten.

Ergebnis: Die aktualisierten Filialdaten sind gespeichert und werden in allen referenzierenden Modulen verwendet.

2.13.3 Filiale deaktivieren/löschen

Was: Der Administrator deaktiviert eine Filiale, wobei das System auf verknüpfte aktive Verträge und Mitarbeiter prüft.

Warum: Geschlossene Standorte sollen nicht mehr in Auswahllisten erscheinen, aber erst deaktiviert werden können, wenn alle Verknüpfungen aufgelöst sind.

Ergebnis: Die Filiale ist deaktiviert (oder die Deaktivierung wird mit Verweis auf bestehende Verknüpfungen abgelehnt).

2.14 Abteilungsverwaltung

2.14.1 Abteilung erstellen und verwalten

Was: Der Administrator legt eine neue Abteilung an mit Bezeichnung und Abteilungsleiter.

Warum: Abteilungen strukturieren die Organisation und werden für Kapazitätsplanung, Berichtsstrukturen und Genehmigungswege benötigt.

Ergebnis: Die Abteilung ist angelegt und kann Mitarbeitern und Standorten zugeordnet werden.

2.14.2 Abteilung einem Standort/Filiale zuordnen

Was: Der Administrator verknüpft eine Abteilung mit einem physischen Standort.

Warum: Die Standortzuordnung ermöglicht standortbezogene Abteilungsauswertungen und Kapazitätsplanungen.

Ergebnis: Die Abteilung ist dem Standort zugeordnet und erscheint in den Filialberichten.

2.15 Abteilungstätigkeiten

2.15.1 Tätigkeitsprofil definieren

Was: Der Administrator legt Tätigkeitstypen pro Abteilung an (z. B. „Vertrieb Innendienst", „Service Außendienst", „Projektleitung") mit Beschreibung und Qualifikationsanforderungen.

Warum: Tätigkeitsprofile bilden die Grundlage für die Ressourcenplanung und die Zuordnung von Mitarbeitern zu passenden Aufgaben.

Ergebnis: Das Tätigkeitsprofil ist definiert und kann Mitarbeitern zugeordnet werden.

2.15.2 Mitarbeiter Tätigkeiten zuordnen

Was: Der Administrator weist einem Mitarbeiter eine oder mehrere Tätigkeiten zu, jeweils mit Gültigkeitszeitraum und prozentualem Anteil an der Gesamtarbeitszeit.

Warum: Mitarbeiter arbeiten oft in mehreren Funktionen. Die prozentuale Zuordnung ermöglicht eine realistische Kapazitätsplanung.

Ergebnis: Die Tätigkeitszuordnungen sind gespeichert und fließen in die Kapazitätsplanung ein.

2.15.3 Tätigkeiten für Kapazitätsplanung nutzen

Was: Die Tätigkeitsprofile dienen als Grundlage für die Ressourcen- und Kapazitätsplanung: Welche Tätigkeiten sind wie stark ausgelastet?

Warum: Ohne Kenntnis der Tätigkeitsverteilung kann die Kapazitätsplanung nicht ermitteln, in welchen Bereichen Engpässe oder Überkapazitäten bestehen.

Ergebnis: Die Auslastung pro Tätigkeitstyp wird angezeigt und Engpässe werden sichtbar.

3. Adressen/CRM

3.1 Adressstamm

3.1.1 Neue Kundenadresse erfassen

Was: Der Sachbearbeiter legt einen neuen Kundenstamm an mit Firmenname, Adressdaten, Kontaktinformationen und Adresstyp (Kunde, Lieferant, Kontakt). Die Kundennummer wird automatisch vergeben.

Warum: Neue Geschäftsbeziehungen erfordern die Erfassung der Stammdaten als Basis für Angebote, Aufträge, Rechnungen und die gesamte Kundenkommunikation.

Ergebnis: Der Kundenstamm ist angelegt, eine eindeutige Kundennummer ist vergeben und der Kunde steht in allen Modulen zur Auswahl bereit.

3.1.2 Kontaktperson zu Adresse hinzufügen

Was: Der Sachbearbeiter erfasst einen Ansprechpartner mit Vorname, Nachname, Titel, Telefon, E-Mail und Markierung als Primärkontakt.

Warum: Für die Kommunikation, die Anrede in Belegen und die Zustellung von Dokumenten wird ein konkreter Ansprechpartner benötigt.

Ergebnis: Die Kontaktperson ist der Adresse zugeordnet und wird als Ansprechpartner in Belegen und E-Mails verwendet.

3.1.3 Adresse aktualisieren

Was: Der Sachbearbeiter ändert Kundenadressdaten, wobei das System eine Duplikatprüfung durchführt und alle Änderungen im Audit-Trail dokumentiert.

Warum: Adressänderungen (Umzug, Firmenumfirmierung) müssen zeitnah eingepflegt werden, um korrekte Belegzustellung und Kommunikation sicherzustellen.

Ergebnis: Die Adressdaten sind aktualisiert, die Änderung ist dokumentiert und bereits existierende Belege behalten ihre historischen Adressdaten (Snapshot-Prinzip).

3.1.4 Adresse mit Aktivitätshistorie anzeigen

Was: Der Sachbearbeiter öffnet die Aktivitätshistorie einer Adresse und sieht eine zeitlich sortierte Übersicht aller Interaktionen: Anrufe, E-Mails, Treffen, Verkaufschancen und Rechnungen.

Warum: Für eine qualifizierte Kundenbetreuung muss der Sachbearbeiter die gesamte Interaktionshistorie auf einen Blick sehen können.

Ergebnis: Die vollständige Aktivitätshistorie der Adresse wird chronologisch angezeigt.

3.1.5 Duplicate-Check und Adress-Merge

Was: Das System erkennt automatisch bei Neueingabe potenzielle Duplikate und bietet die Option, die Datensätze zusammenzuführen.

Warum: Doppelte Kundenstämme führen zu inkonsistenten Daten, fehlerhaften Auswertungen und doppelter Ansprache. Die automatische Erkennung verhindert dies.

Ergebnis: Potenzielle Duplikate werden angezeigt, und bei Bestätigung werden die Datensätze unter Beibehaltung aller Verknüpfungen zusammengeführt.

3.1.6 Adresse löschen oder archivieren

Was: Der Sachbearbeiter archiviert (Soft Delete) oder löscht eine Adresse, nachdem das System auf verknüpfte Datensätze (Belege, Verträge, Tickets) geprüft hat.

Warum: Nicht mehr benötigte Adressen sollen die aktive Datenbasis nicht belasten, dürfen aber bei bestehenden Verknüpfungen nicht gelöscht werden.

Ergebnis: Die Adresse ist archiviert oder gelöscht. Bei Archivierung ist sie in historischen Daten weiterhin verfügbar.

3.1.7 Kunde einer Filiale zuordnen

Was: Der Sachbearbeiter weist einen Kunden einer betreuenden Filiale zu.

Warum: Die Filialzuordnung bestimmt die regionale Zuständigkeit und ermöglicht filialbasierte Auswertungen und Provisionsberechnungen.

Ergebnis: Der Kunde ist der Filiale zugeordnet und wird in deren Auswertungen und Zuständigkeitsbereichen berücksichtigt.

3.1.8 Kunde einer Kundengruppe/Segment zuordnen

Was: Der Sachbearbeiter klassifiziert einen Kunden in ein Segment (z. B. A/B/C-Kunde, Branche, Firmengröße).

Warum: Die Segmentierung ist Basis für zielgerichtete Kampagnen, Preisdifferenzierung und Provisionsschema-Zuordnungen.

Ergebnis: Der Kunde ist dem Segment zugeordnet und wird bei Kampagnen und Auswertungen entsprechend berücksichtigt.

3.1.9 Kunde Zahlungsbedingungen zuweisen

Was: Der Sachbearbeiter legt die Standard-Zahlungsbedingungen für einen Kunden fest, z. B. Netto 30 Tage, 2 % Skonto bei Zahlung innerhalb 14 Tagen.

Warum: Die kundenbezogenen Zahlungsbedingungen werden automatisch in neue Belege übernommen und steuern die Fälligkeitsberechnung und das Mahnwesen.

Ergebnis: Die Zahlungsbedingungen sind hinterlegt und werden bei neuen Belegen automatisch vorbelegt.

3.1.10 Kunde Lieferbedingungen zuweisen

Was: Der Sachbearbeiter ordnet einem Kunden Standard-Lieferbedingungen (Incoterms) zu.

Warum: Lieferbedingungen regeln die Verantwortlichkeiten bei Transport und Versicherung und werden in Aufträgen und Lieferscheinen benötigt.

Ergebnis: Die Lieferbedingungen sind hinterlegt und werden bei neuen Belegen automatisch vorbelegt.

3.1.11 Kunde eine Preisliste zuordnen

Was: Der Sachbearbeiter verknüpft eine kundenspezifische Preisliste mit dem Kundenstamm für individuelle Konditionen.

Warum: Verschiedene Kunden erhalten unterschiedliche Preise – Großkunden erhalten z. B. Sonderkonditionen, die über eine eigene Preisliste abgebildet werden.

Ergebnis: Die Preisliste ist dem Kunden zugeordnet und wird bei der Preisfindung in Angeboten und Aufträgen automatisch herangezogen.

3.1.12 Kunde SEPA-Mandat zuordnen

Was: Der Sachbearbeiter erfasst ein SEPA-Lastschrift-Mandat mit IBAN, BIC, Mandatsdatum und Unterschrift und verknüpft es mit dem Kundenstamm.

Warum: Für den automatischen Einzug von Rechnungsbeträgen per SEPA-Lastschrift ist ein gültiges Mandat des Kunden erforderlich.

Ergebnis: Das SEPA-Mandat ist dem Kunden zugeordnet und steht für SEPA-Lastschriftdateien zur Verfügung.

3.1b CRM-Aktivitäten

3.1b.1 Anruf protokollieren

Was: Der Sachbearbeiter erfasst ein Telefonat mit einem Kunden: Datum, Dauer, Gesprächspartner, Zusammenfassung und Ergebnis. Die Verknüpfung zum Kundenstamm erfolgt automatisch.

Warum: Die lückenlose Dokumentation aller Kundenkontakte ist Grundlage für eine professionelle Kundenbetreuung und ermöglicht Vertretungen.

Ergebnis: Der Anruf ist als Aktivität im Kundenstamm dokumentiert und in der Aktivitätshistorie sichtbar.

3.1b.2 Kundenbesuch dokumentieren

Was: Der Sachbearbeiter protokolliert einen Vor-Ort-Termin mit Besuchsbericht, besprochenen Themen und vereinbarten nächsten Schritten.

Warum: Besuchsberichte dokumentieren Vereinbarungen und offene Punkte und dienen als Grundlage für Follow-up-Aktivitäten.

Ergebnis: Der Besuchsbericht ist dem Kundenstamm zugeordnet und die vereinbarten nächsten Schritte sind dokumentiert.

3.1b.3 E-Mail-Korrespondenz verknüpfen

Was: Der Sachbearbeiter ordnet relevante E-Mails einem Kundenstamm oder CRM-Projekt als Aktivitätseintrag zu.

Warum: Wichtige E-Mail-Korrespondenz soll in der Kundenakte sichtbar sein, damit alle Beteiligten den aktuellen Stand der Kommunikation kennen.

Ergebnis: Die E-Mail ist als Aktivität dem Kundenstamm zugeordnet und in der Aktivitätshistorie abrufbar.

3.1b.4 Notiz/Vermerk erstellen

Was: Der Sachbearbeiter erstellt eine interne Notiz zu einem Kunden, z. B. Besonderheiten, Reklamationshistorie oder persönliche Präferenzen.

Warum: Interne Informationen, die keiner Aktivitätskategorie zuordenbar sind, müssen ebenfalls dokumentiert werden können.

Ergebnis: Die Notiz ist dem Kundenstamm zugeordnet und für alle berechtigten Mitarbeiter sichtbar.

3.1b.5 Wiedervorlage/Follow-up planen

Was: Der Sachbearbeiter plant eine zukünftige Aktivität (Rückruf, Besuch, E-Mail) mit Fälligkeitsdatum und Erinnerung an den zuständigen Mitarbeiter.

Warum: Vereinbarte Rückrufe, Nachfass-Aktionen und Termine dürfen nicht vergessen werden. Automatische Erinnerungen stellen die Einhaltung sicher.

Ergebnis: Die Wiedervorlage ist geplant und der zuständige Mitarbeiter erhält zum Fälligkeitszeitpunkt eine Erinnerung.

3.1b.6 Aktivitäten einem Kunden zuordnen

Was: Der Sachbearbeiter verknüpft beliebige Aktivitätstypen (Anruf, Besuch, Mail, Notiz) mit einem Kundenstamm für die vollständige Interaktionshistorie.

Warum: Alle Kundeninteraktionen sollen an einem zentralen Ort zusammenlaufen, damit die Kundenakte vollständig ist und keine Informationen verloren gehen.

Ergebnis: Die Aktivität ist dem Kunden zugeordnet und in dessen Interaktionshistorie sichtbar.

3.2 Audit

3.2.1 Neues Audit erstellen

Was: Der Auditor legt ein Kundenaudit an, wählt ein standardisiertes Checklisten-Template und plant Datum, Dauer und Verantwortlichen.

Warum: Regelmäßige Kundenaudits (z. B. IT-Sicherheitsaudits, Infrastruktur-Checks) sind Bestandteil vieler Serviceverträge und dienen der Qualitätssicherung.

Ergebnis: Das Audit ist angelegt, die Checkliste ist zugeordnet und der Termin ist geplant.

3.2.2 Audit durchführen und Fragen beantworten

Was: Der Auditor bearbeitet die Checkliste vor Ort und beantwortet jede Frage mit Ja/Nein/Nicht Anwendbar/Mit Mängel, ergänzt um Freitext und optional Fotos.

Warum: Die strukturierte Erfassung der Audit-Ergebnisse ermöglicht eine objektive Bewertung und den Vergleich über mehrere Audits hinweg.

Ergebnis: Alle Checklistenpunkte sind beantwortet und die Ergebnisse sind dokumentiert.

3.2.3 Audit-Report erstellen

Was: Das System generiert einen professionellen Audit-Bericht mit Befunden, Empfehlungen, Fotos und Trend-Analyse im Vergleich zu vorherigen Audits.

Warum: Der Audit-Report ist das Ergebnis-Dokument für den Kunden und die interne Dokumentation. Er muss professionell und vollständig sein.

Ergebnis: Ein vollständiger Audit-Bericht liegt als PDF vor und kann an den Kunden übergeben werden.

3.2.4 Abweichungen managen

Was: Der Auditor verfolgt identifizierte Abweichungen mit Schweregrad-Bewertung (kritisch, wichtig, geringfügig) und Status-Workflow (offen, in Bearbeitung, behoben).

Warum: Gefundene Mängel müssen nachverfolgt und behoben werden. Der Schweregrad priorisiert die Bearbeitung.

Ergebnis: Alle Abweichungen sind mit Schweregrad und Status dokumentiert und können bis zur Behebung nachverfolgt werden.

3.2.5 Audit-History und Trend-Analyse

Was: Der Sachbearbeiter verfolgt wiederholte Audits über Zeiträume hinweg mit Trend-Charts und Berechnung der Verbesserungsrate.

Warum: Die Trend-Analyse zeigt, ob sich die Situation beim Kunden verbessert oder verschlechtert und ob Maßnahmen wirken.

Ergebnis: Eine Trend-Darstellung über mehrere Audits wird angezeigt, mit Entwicklung der Bewertung und Mängelquote.

3.2.6 Audit-Templates verwalten

Was: Der Administrator erstellt und pflegt standardisierte Checklisten-Vorlagen mit gewichteten Fragen und Versionierung.

Warum: Einheitliche Checklisten stellen sicher, dass alle Auditoren die gleichen Prüfpunkte abarbeiten und die Ergebnisse vergleichbar sind.

Ergebnis: Die Audit-Templates sind versioniert gespeichert und stehen für neue Audits zur Verfügung.

3.3 CRM-Projekte

3.3.1 Neues CRM-Projekt erstellen

Was: Der Vertriebsmitarbeiter legt ein neues Vertriebsprojekt an mit Projektname, Projektleiter, Startdatum, Budget und Projekttyp.

Warum: Vertriebsprojekte strukturieren den Akquiseprozess von der ersten Kontaktaufnahme bis zum Vertragsabschluss und ermöglichen die Umsatzprognose.

Ergebnis: Das CRM-Projekt ist angelegt und erscheint in der Vertriebspipeline.

3.3.2 Projektteam zusammenstellen

Was: Der Projektleiter weist Mitarbeiter dem Projekt zu mit Rolle, prozentualem Auslastungsanteil und Zugehörigkeitszeitraum.

Warum: Die Teamzusammenstellung steuert die Kapazitätsplanung und stellt sicher, dass die richtigen Kompetenzen im Projekt verfügbar sind.

Ergebnis: Das Projektteam ist zusammengestellt und die Mitarbeiter sind mit ihren Rollen und Auslastungen hinterlegt.

3.3.3 Projekt-Phasen definieren

Was: Der Projektleiter gliedert das Projekt in verschachtelte Phasen mit eigenem Budget, Meilensteinen und Abhängigkeiten.

Warum: Die Phasenstruktur ermöglicht die schrittweise Planung, Durchführung und Kontrolle des Projekts.

Ergebnis: Die Projektphasen sind definiert, mit Meilensteinen und Abhängigkeiten, und der Projektfortschritt kann phasenweise verfolgt werden.

3.3.4 Budget und Kosten-Tracking

Was: Das System überwacht Projektkosten und warnt bei 80 %, 95 % und 100 % Budget-Ausschöpfung. Zeiterfassungen der Projektmitarbeiter werden automatisch aggregiert.

Warum: Budget-Überschreitungen müssen frühzeitig erkannt werden, um gegensteuern zu können. Die automatische Aggregation von Zeitdaten verhindert manuelle Fehler.

Ergebnis: Der aktuelle Budgetverbrauch wird in Echtzeit angezeigt und Warnungen werden bei Schwellenwertüberschreitung ausgelöst.

3.3.5 Projekt-Status und Fortschritt

Was: Das System berechnet den Projektfortschritt basierend auf abgeschlossenen Phasen und Aufgaben und sendet automatische Benachrichtigungen bei Statusänderungen.

Warum: Die automatische Fortschrittsberechnung gibt Projektleiter und Auftraggeber jederzeit einen aktuellen Überblick über den Projektstatus.

Ergebnis: Der Projektfortschritt wird als Prozentwert angezeigt und Statusänderungen werden automatisch kommuniziert.

3.3.6 Projekt-Abschluss und Archivierung

Was: Der Projektleiter schließt das Projekt formal ab, wobei das System auf vollständige Phasen, finalisiertes Budget und Dokumentation prüft.

Warum: Ein formaler Projektabschluss stellt sicher, dass alle Liefergegenstände erbracht, alle Kosten verbucht und alle Erfahrungen dokumentiert sind.

Ergebnis: Das Projekt ist abgeschlossen und archiviert. Offene Posten werden gemeldet, falls vorhanden.

3.3.7 CRM-Projekt als verloren markieren

Was: Der Vertriebsmitarbeiter markiert ein Vertriebsprojekt als verloren und dokumentiert den Verlustgrund und Lessons Learned.

Warum: Die Dokumentation von Verlustgründen ermöglicht die Analyse, warum Projekte verloren werden, und die Ableitung von Verbesserungsmaßnahmen.

Ergebnis: Das Projekt ist als verloren markiert, der Grund ist dokumentiert und das Projekt erscheint in der Win/Loss-Analyse.

3.3.8 CRM-Projekt-Lifecycle: Opportunity → Proposal

Was: Der Vertriebsmitarbeiter überführt ein qualifiziertes Vertriebsprojekt von der Anfangsphase (Opportunity) in die Angebotsphase (Proposal).

Warum: Der Phasenübergang dokumentiert, dass die Anfrage qualifiziert wurde und konkret ein Angebot erstellt werden soll.

Ergebnis: Das Projekt befindet sich im Status „Proposal" und der Angebotsworkflow kann gestartet werden.

3.3.9 CRM-Projekt-Lifecycle: Proposal → Negotiation

Was: Der Vertriebsmitarbeiter überführt das Projekt nach Angebotsabgabe in die Verhandlungsphase mit Tracking von Verhandlungsrunden und Anpassungen.

Warum: Die Verhandlungsphase erfordert oft mehrere Angebotsanpassungen. Der Status-Tracking dokumentiert den Verhandlungsverlauf.

Ergebnis: Das Projekt befindet sich im Status „Negotiation" und Verhandlungsrunden können dokumentiert werden.

3.3.10 CRM-Projekt-Lifecycle: Negotiation → Won

Was: Der Vertriebsmitarbeiter schließt ein Vertriebsprojekt als gewonnen ab, erstellt den Vertrag und übergibt an die Auftragsabwicklung.

Warum: Der erfolgreiche Abschluss muss dokumentiert und die Übergabe an die operative Abwicklung eingeleitet werden.

Ergebnis: Das Projekt ist als gewonnen markiert, der Vertrag ist erstellt und die Auftragsabwicklung ist informiert.

3.3.11 Pipeline-Ansicht aller CRM-Projekte

Was: Der Vertriebsleiter sieht eine visuelle Darstellung aller aktiven CRM-Projekte nach Status (Opportunity, Proposal, Negotiation, Won, Lost) mit Umsatzprognose pro Phase.

Warum: Die Pipeline-Ansicht gibt einen Überblick über die Vertriebsaussichten und ermöglicht die Steuerung der Vertriebsaktivitäten.

Ergebnis: Die Pipeline wird mit Projektanzahl, Gesamtvolumen und Umsatzprognose pro Phase angezeigt.

3.3.12 Win/Loss-Analyse

Was: Der Vertriebsleiter wertet gewonnene und verlorene Projekte aus – nach Verlustgründen, Wettbewerbern, Produktkategorien und Zeiträumen.

Warum: Die Win/Loss-Analyse identifiziert Muster und Verbesserungspotenziale im Vertriebsprozess.

Ergebnis: Ein Analysebericht mit Gewinn-/Verlustquoten, häufigsten Verlustgründen und Wettbewerber-Vergleich wird angezeigt.

3.3.13 Automatische Eskalation bei Inaktivität

Was: Das System benachrichtigt den Projektverantwortlichen, wenn ein CRM-Projekt über einen konfigurierbaren Zeitraum keine Statusänderung aufweist.

Warum: Inaktive Vertriebsprojekte deuten auf vernachlässigte Chancen hin und sollten entweder reaktiviert oder als verloren markiert werden.

Ergebnis: Der Projektverantwortliche erhält eine Benachrichtigung und muss den Projektstatus aktualisieren.

3.4 Kampagnen/Mailing

3.4.1 Neue Kampagne erstellen

Was: Der Marketing-Mitarbeiter initialisiert eine Marketing-Kampagne mit Kampagnentyp (E-Mail, Brief, Telefon), Zielgruppe und Verantwortlichen.

Warum: Strukturierte Kampagnen ermöglichen die gezielte Kundenansprache und die Messung des Marketing-Erfolgs.

Ergebnis: Die Kampagne ist angelegt und bereit für die Zielgruppen-Definition und Inhaltserstellung.

3.4.2 Zielgruppe definieren

Was: Der Marketing-Mitarbeiter segmentiert die Zielgruppe nach Kundentyp, Branche, Region und Kaufhistorie. Das System zeigt die Echtzeit-Trefferzahl und ermöglicht Ausschlusslisten.

Warum: Die präzise Zielgruppen-Definition stellt sicher, dass die Kampagne die richtigen Empfänger erreicht und Streuverluste minimiert werden.

Ergebnis: Die Zielgruppe ist definiert, die Empfängeranzahl ist bekannt und Ausschlüsse sind berücksichtigt.

Was: Der Marketing-Mitarbeiter erstellt den E-Mail-Inhalt im WYSIWYG/HTML-Editor mit Personalisierung, Client-Vorschau und optionalen A/B-Test-Varianten.

Warum: Professionelle E-Mail-Kampagnen erfordern ansprechendes Design, Personalisierung und die Möglichkeit, verschiedene Varianten zu testen.

Ergebnis: Die E-Mail-Vorlage ist erstellt, personalisiert und bereit für den Versand.

3.4.4 Kampagne planen und starten

Was: Der Marketing-Mitarbeiter aktiviert die Kampagne zeitgesteuert mit gestaffeltem Versand (Staggered Release), Bounce-Handling und automatischer Abmeldung (Unsubscribe).

Warum: Der gestaffelte Versand schützt vor Server-Überlastung und Spam-Klassifizierung. Automatisches Bounce-Handling und Unsubscribe sind gesetzlich erforderlich.

Ergebnis: Die Kampagne wird zum geplanten Zeitpunkt gestartet und die E-Mails werden gestaffelt versendet.

3.4.5 Kampagnen-Performance tracken

Was: Der Marketing-Mitarbeiter verfolgt die Kampagnen-Performance in Echtzeit: Öffnungsrate, Klicks, Conversions, geographische Verteilung und Link-Performance.

Warum: Die Performance-Messung ermöglicht die Bewertung des Kampagnen-Erfolgs und die Optimierung laufender und zukünftiger Kampagnen.

Ergebnis: Ein Live-Dashboard mit allen relevanten Kampagnen-Metriken wird angezeigt.

3.4.6 Mailing-Kampagne abschließen und Report

Was: Der Marketing-Mitarbeiter schließt die Kampagne ab und erstellt einen Abschlussbericht mit Gesamt-ROI, Kosteneffizienz und Conversions.

Warum: Der Abschlussbericht dokumentiert den Erfolg der Kampagne und liefert Erkenntnisse für zukünftige Marketing-Maßnahmen.

Ergebnis: Die Kampagne ist archiviert und der Abschlussbericht steht zur Verfügung.

3.4.7 Kampagne pausieren

Was: Der Marketing-Mitarbeiter unterbricht eine laufende Kampagne temporär, z. B. bei festgestellten Fehlern oder externen Ereignissen.

Warum: Fehler im Kampagneninhalt oder unvorhergesehene Ereignisse können eine sofortige Unterbrechung erfordern, ohne die gesamte Kampagne löschen zu müssen.

Ergebnis: Die Kampagne ist pausiert, der Versand ist gestoppt und kann jederzeit wieder aufgenommen werden.

3.4.8 Kampagne reaktivieren

Was: Der Marketing-Mitarbeiter nimmt eine pausierte Kampagne wieder auf, wobei das Tracking fortgesetzt wird.

Warum: Nach Behebung des Grundes für die Pausierung soll die Kampagne nahtlos weitergeführt werden.

Ergebnis: Die Kampagne wird fortgesetzt und der Versand an noch nicht erreichte Empfänger wird wiederaufgenommen.

3.4b Lead-Management

3.4b.1 Anfrage/Lead erfassen

Was: Der Sachbearbeiter erfasst eine Kundenanfrage aus verschiedenen Quellen (Webformular, Telefon, Messe, E-Mail) als Lead mit Kontaktdaten und Interessensgebiet.

Warum: Alle Kundenanfragen sollen zentral erfasst werden, um keine Verkaufschance zu verlieren und den Vertriebstrichter systematisch zu befüllen.

Ergebnis: Der Lead ist im System erfasst und steht für die weitere Qualifizierung bereit.

3.4b.2 Lead qualifizieren

Was: Der Vertriebsmitarbeiter bewertet den Lead nach Interessensprofil, Budget, Dringlichkeit und Abschlusswahrscheinlichkeit (z. B. nach BANT-Methodik).

Warum: Nicht alle Anfragen sind gleichwertig. Die Qualifizierung priorisiert die Vertriebsaktivitäten auf die aussichtsreichsten Leads.

Ergebnis: Der Lead ist qualifiziert und mit einer Bewertung versehen, die die weitere Bearbeitungspriorität bestimmt.

3.4b.3 Lead-Status tracken

Was: Der Sachbearbeiter verfolgt den Lead-Fortschritt über Statusübergänge: Neu → Kontaktiert → Qualifiziert → Angebot erstellt → Gewonnen/Verloren.

Warum: Das Status-Tracking macht den Fortschritt jedes Leads transparent und ermöglicht Engpass-Analysen im Vertriebstrichter.

Ergebnis: Der Lead-Status ist aktualisiert und in der Pipeline-Übersicht sichtbar.

3.4b.4 Lead einem Mitarbeiter zuweisen

Was: Der Vertriebsleiter weist einen Lead einem Vertriebsmitarbeiter zu, basierend auf Region, Produktkategorie oder Verfügbarkeit.

Warum: Eine klare Zuständigkeit stellt sicher, dass jeder Lead zeitnah bearbeitet wird und kein Lead ohne Verantwortlichen bleibt.

Ergebnis: Der Lead ist einem Mitarbeiter zugewiesen und dieser wird über die neue Zuordnung benachrichtigt.

3.4b.5 Lead zu Angebot konvertieren

Was: Der Vertriebsmitarbeiter wandelt einen qualifizierten Lead in ein Angebot um, wobei die Kundendaten automatisch übernommen werden.

Warum: Bei erfolgreicher Qualifizierung soll der Übergang zum Angebot nahtlos erfolgen, ohne dass Daten manuell übertragen werden müssen.

Ergebnis: Ein neues Angebot ist erstellt, vorbelegt mit den Daten des Leads.

3.4b.6 Lead zu Kunde konvertieren

Was: Der Vertriebsmitarbeiter erstellt aus einem Lead einen neuen Kundenstamm-Eintrag mit Übernahme aller erfassten Daten.

Warum: Qualifizierte Leads, die zu Kunden werden, sollen ohne erneute Dateneingabe als vollwertiger Kundenstamm angelegt werden.

Ergebnis: Ein neuer Kundenstamm ist aus den Lead-Daten erstellt und der Lead ist als konvertiert markiert.

3.4b.7 Lead-Auswertung und Vertriebstrichter

Was: Der Vertriebsleiter analysiert die Lead-Pipeline nach Status, Quelle, Mitarbeiter und Zeitraum mit Conversion-Rate und Durchlaufzeiten.

Warum: Die Auswertung zeigt, welche Lead-Quellen erfolgreich sind, wo Engpässe bestehen und wie lange die Konvertierung dauert.

Ergebnis: Ein Vertriebstrichter-Bericht mit Conversion-Raten pro Phase, Lead-Quellen-Analyse und Durchlaufzeiten wird angezeigt.

Was: Der Marketing-Mitarbeiter verbindet Social-Media-Konten (Facebook, Twitter/X, LinkedIn) mit dem CRM-System für zentrales Management.

Warum: Die Integration ermöglicht die zentrale Steuerung aller Social-Media-Aktivitäten ohne Wechsel zwischen verschiedenen Plattformen.

Ergebnis: Die Social-Media-Konten sind verknüpft und können aus dem CRM heraus verwaltet werden.

Was: Das System überwacht Erwähnungen, Kommentare und Nachrichten über die verknüpften Social-Media-Kanäle.

Warum: Das Monitoring ermöglicht zeitnahes Reagieren auf Kundenanfragen, Beschwerden und Erwähnungen der Marke.

Ergebnis: Relevante Social-Media-Aktivitäten werden im CRM-Dashboard angezeigt.

3.4c.3 Posts planen und veröffentlichen

Was: Der Marketing-Mitarbeiter erstellt und plant Social-Media-Beiträge über mehrere Kanäle hinweg mit zeitlicher Steuerung.

Warum: Regelmäßige und geplante Veröffentlichungen sichern eine konsistente Online-Präsenz ohne täglichen manuellen Aufwand.

Ergebnis: Die geplanten Beiträge werden automatisch zum definierten Zeitpunkt auf den ausgewählten Kanälen veröffentlicht.

3.4c.4 Kommentare und Interaktionen verwalten

Was: Der Marketing-Mitarbeiter beantwortet Kommentare, Nachrichten und Anfragen direkt aus dem CRM heraus.

Warum: Die zentrale Bearbeitung aller Social-Media-Interaktionen spart Zeit und stellt sicher, dass keine Anfrage übersehen wird.

Ergebnis: Kommentare und Nachrichten sind beantwortet und die Interaktionen sind in der Kundenakte dokumentiert.

3.4c.5 Engagement-Metriken analysieren

Was: Der Marketing-Mitarbeiter wertet Reichweite, Likes, Shares, Kommentare und Click-Through-Rates pro Kanal und Beitrag aus.

Warum: Die Messung des Social-Media-Engagements ermöglicht die Optimierung der Content-Strategie und die Bewertung des ROI.

Ergebnis: Ein Analyse-Dashboard mit allen Engagement-Metriken pro Kanal und Zeitraum wird angezeigt.

Was: Der Marketing-Mitarbeiter erstellt Leads aus Social-Media-Interaktionen (Anfragen, Kommentare, Direktnachrichten) mit automatischer Quellenmarkierung.

Warum: Social-Media-Kanäle sind eine zunehmend wichtige Lead-Quelle. Die automatische Erfassung mit Quellenmarkierung ermöglicht die Erfolgsanalyse.

Ergebnis: Ein neuer Lead ist aus der Social-Media-Interaktion erstellt und mit der Quelle markiert.

3.5 Lieferanten-Verträge

3.5.1 Neuen Lieferantenvertrag erstellen

Was: Der Einkäufer erstellt einen neuen Lieferantenvertrag mit Bezeichnung, Vertragstyp, Zahlungsbedingungen und Verantwortlichen.

Warum: Lieferantenverträge sichern Einkaufskonditionen und sind die Basis für Bestellungen, Preisverhandlungen und Lieferantenbewertungen.

Ergebnis: Der Lieferantenvertrag ist angelegt und bereit für den Genehmigungsprozess.

3.5.2 Vertrag genehmigen und aktivieren

Was: Der Lieferantenvertrag durchläuft einen mehrstufigen Genehmigungs-Workflow: Ersteller, Abteilungsleiter, Management.

Warum: Lieferantenverträge binden das Unternehmen finanziell und rechtlich. Die mehrstufige Genehmigung stellt die Prüfung durch zuständige Entscheider sicher.

Ergebnis: Der Vertrag ist genehmigt, aktiviert und die vereinbarten Konditionen werden bei Bestellungen herangezogen.

3.5.3 Vertragskonditionen und SLA definieren

Was: Der Einkäufer hinterlegt Service-Level-Agreements mit Verfügbarkeit, Reaktionszeit, Lösungszeit und optionalen Strafklauseln.

Warum: SLAs sichern die vereinbarte Servicequalität vertraglich ab und ermöglichen die automatische Überwachung der Lieferanten-Performance.

Ergebnis: Die SLA-Konditionen sind im Vertrag hinterlegt und können automatisch überwacht werden.

3.5.4 Vertrag überwachen und Performance-Tracking

Was: Das System zeigt ein Dashboard mit Verfügbarkeit, Reaktionszeit und Kundenzufriedenheits-Score des Lieferanten, ergänzt um Trend-Warnungen.

Warum: Die kontinuierliche Überwachung der Lieferanten-Performance zeigt Abweichungen von den vereinbarten SLAs frühzeitig auf.

Ergebnis: Das Performance-Dashboard zeigt aktuelle und historische Lieferanten-Kennzahlen mit Trend-Indikatoren.

3.5.5 Vertrag erneuern oder beenden

Was: Das System identifiziert automatisch ablaufende Verträge, benachrichtigt den Verantwortlichen und bietet Erneuerungsoptionen an.

Warum: Ablaufende Verträge müssen rechtzeitig verlängert werden, um Lieferunterbrechungen zu vermeiden.

Ergebnis: Der Vertrag ist erneuert oder planmäßig beendet, und der Verantwortliche wurde rechtzeitig informiert.

3.5.6 Vertragsrisiken und Compliance-Checks

Was: Das System führt automatische Checks durch (DSGVO-Konformität, Versicherungsnachweis, Audit-Rechte) und berechnet ein Risikolevel pro Vertrag.

Warum: Compliance-Anforderungen und Risikomanagement erfordern regelmäßige Prüfungen aller Lieferantenverträge.

Ergebnis: Jeder Vertrag hat ein aktuelles Risikolevel und offene Compliance-Punkte werden angezeigt.

3.6 PLM (Product Lifecycle Management)

3.6.1 Neues Produkt im PLM erstellen

Was: Der Produktmanager initialisiert ein neues Produkt mit Lebenszyklus-Template, automatischer Produktnummer und Kanban-Board für die Entwicklung.

Warum: Die strukturierte Produktanlage stellt sicher, dass alle Lebenszyklus-Phasen von Anfang an geplant werden.

Ergebnis: Das Produkt ist angelegt und der Lebenszyklus-Workflow ist initialisiert.

3.6.2 Produktversionen und Revisionen managen

Was: Der Produktmanager verwaltet Produktversionen mit Status-Workflow: Entwurf, In Prüfung, QA, Freigegeben, Veraltet. Eigenschaften werden von Version zu Version vererbt.

Warum: Produkte durchlaufen mehrere Iterationen. Die Versionierung stellt sicher, dass jeder Stand nachvollziehbar und der aktuelle Stand eindeutig ist.

Ergebnis: Die neue Produktversion ist angelegt und die Eigenschaften der Vorversion sind übernommen.

3.6.3 Konfigurationen und Varianten definieren

Was: Der Produktmanager definiert Konfigurationsoptionen mit Abhängigkeits-Regelwerk und eigener Artikelnummer (SKU) pro Variante.

Warum: Viele Produkte existieren in verschiedenen Varianten (z. B. Speichergrößen, Farben). Die systematische Verwaltung vermeidet Wildwuchs und sichert korrekte Bestellungen.

Ergebnis: Die Produktvarianten sind definiert, jede mit eigener SKU und korrekten Abhängigkeiten.

3.6.4 Technische Dokumentation und Spezifikationen

Was: Der Produktmanager verwaltet versionierte technische Dokumente und Spezifikationen mit Status: Entwurf, Gültig, Veraltet.

Warum: Aktuelle technische Dokumentation ist für Vertrieb, Support und Kunden unerlässlich. Die Versionierung stellt sicher, dass nur gültige Dokumente verwendet werden.

Ergebnis: Die technischen Dokumente sind versioniert abgelegt und der aktuelle Stand ist eindeutig gekennzeichnet.

3.6.5 Qualitätskontrolle und Zertifizierungen

Was: Der Qualitätsmanager erstellt QA-Test-Pläne mit Test-Kriterien und überwacht die Gültigkeit von Produktzertifizierungen.

Warum: Qualitätsstandards und Zertifizierungen sind häufig Voraussetzung für den Verkauf und müssen laufend überwacht werden.

Ergebnis: Test-Pläne sind dokumentiert und Zertifizierungs-Ablaufdaten werden überwacht.

3.6.6 End-of-Life Planung und Ausmusterung

Was: Der Produktmanager plant das Produktende mit Einstellungsdatum, Support-Ende und automatischen Kundenbenachrichtigungen zur Migration.

Warum: Produkte am Lebensende müssen geplant ausgesteuert werden, damit Kunden rechtzeitig über Alternativen informiert werden und Support-Ressourcen umgeplant werden können.

Ergebnis: Das End-of-Life ist geplant, Kunden sind benachrichtigt und die Migration auf Nachfolgeprodukte ist eingeleitet.

3.7 Stammblätter

3.7.1 Stammdatenlisten anzeigen und filtern

Was: Der Sachbearbeiter sieht eine Übersicht aller Stammdatenlisten (Geräte, Zähler, Inventar) mit Name, Eintragsanzahl, letzter Änderung und Status.

Warum: Die Übersicht ermöglicht die schnelle Navigation zu der gewünschten Liste und die Prüfung des Aktualitätsstands.

Ergebnis: Die Stammdatenlisten werden tabellarisch mit Metadaten angezeigt und können gefiltert werden.

3.7.2 Neue Stammdatenliste erstellen

Was: Der Sachbearbeiter definiert eine neue Listenstruktur mit Spalten, Datentypen und optionalen Standard-Einträgen.

Warum: Für neue Gerätetypen, Zählerkategorien oder andere Stammdaten werden flexible Listen benötigt, die an den Bedarf angepasst werden können.

Ergebnis: Die neue Stammdatenliste ist angelegt und kann mit Einträgen befüllt werden.

3.7.3 Einträge zu Stammdatenlisten hinzufügen/bearbeiten

Was: Der Sachbearbeiter bearbeitet Einträge in einer Grid-Ansicht mit Duplikat-Prüfung, Datentyp-Validierung und sofortiger Audit-Dokumentation.

Warum: Stammdaten müssen korrekt und eindeutig sein. Die Inline-Bearbeitung mit Validierung stellt die Datenqualität sicher.

Ergebnis: Die Einträge sind gespeichert, validiert und die Änderungen sind im Audit-Trail dokumentiert.

3.7.4 Stammdaten-Import aus Dateien

Was: Der Sachbearbeiter importiert Stammdaten aus Excel- oder CSV-Dateien mit automatischer Spalten-Zuordnung und Import-Vorschau.

Warum: Bei großen Datenmengen (z. B. Gerätelisten eines neuen Kunden) ist der manuelle Eintrag nicht praktikabel.

Ergebnis: Die importierten Daten sind als Stammdateneinträge angelegt, nach Vorschau und Bestätigung durch den Benutzer.

3.7.5 Stammdaten-Export und Reporting

Was: Der Sachbearbeiter exportiert Stammdaten in Excel, CSV oder JSON mit konfigurierbaren Report-Templates.

Warum: Stammdaten werden für externe Auswertungen, Kundenpräsentationen oder die Weitergabe an Dritte benötigt.

Ergebnis: Die Stammdaten sind im gewählten Format exportiert.

3.7.6 Stammdaten-Versionierung und Audit-Trail

Was: Das System dokumentiert alle Änderungen an Stammdaten als Timeline mit optionaler Wiederherstellungsmöglichkeit.

Warum: Für Compliance und Nachvollziehbarkeit müssen Stammdatenänderungen lückenlos protokolliert und bei Bedarf rückgängig gemacht werden können.

Ergebnis: Alle Änderungen sind historisiert und können bei Bedarf auf einen früheren Stand zurückgesetzt werden.

3.8 Kundengruppen/Segmente

3.8.1 Kundengruppen/Segmente verwalten

Was: Der Administrator erstellt, bearbeitet und löscht Kundensegmente (z. B. A/B/C-Kunden, Branchen, Regionen), die in Kampagnen-Zielgruppen und Provisionsschemas referenziert werden.

Warum: Die Segmentierung ist die Grundlage für differenzierte Kundenansprache, Preisgestaltung und Provisionsberechnung.

Ergebnis: Die Kundensegmente sind gepflegt und stehen in allen referenzierenden Modulen zur Verfügung.

4. Automatisierung

4.1 Erwartete Events

4.1.1 Erwartetes Event definieren

Was: Der Administrator erstellt eine Regel für eine automatische Aktion bei einem bestimmten Ereignis: Er wählt den Ereignistyp (z. B. Ticket-Statusänderung, Zahlungseingang), definiert Bedingungen und konfiguriert die auszuführende Aktion.

Warum: Routineaufgaben, die regelmäßig bei bestimmten Ereignissen anfallen, sollen automatisiert werden, um Personal zu entlasten und Reaktionszeiten zu verkürzen.

Ergebnis: Das Event ist definiert und wird bei Eintritt der Bedingungen automatisch die konfigurierte Aktion auslösen.

4.1.2 Event-Bedingungen mit Logik kombinieren

Was: Der Administrator kombiniert komplexe Bedingungen mit UND/ODER-Logik im Bedingungseditor und kann diese vor der Aktivierung testen.

Warum: Einfache Einzelbedingungen reichen für komplexe Geschäftsregeln nicht aus – z. B. „Wenn Priorität = Hoch UND Kunde = A-Kunde ODER SLA-Verletzung droht".

Ergebnis: Die kombinierten Bedingungen sind konfiguriert und das Event reagiert nur bei Erfüllung der gesamten Bedingungslogik.

4.1.3 Automatische Aktionen konfigurieren

Was: Der Administrator definiert die Maßnahmen bei Event-Eintritt: Statusänderung, Benachrichtigung, Zuweisung an Mitarbeiter, Datenfeld-Update. Mehrere Aktionen können in Reihenfolge verknüpft werden.

Warum: Automatische Aktionen beschleunigen Prozesse und stellen sicher, dass definierte Geschäftsregeln konsistent angewendet werden.

Ergebnis: Die Aktionskette ist konfiguriert und wird bei Event-Eintritt in der definierten Reihenfolge ausgeführt.

4.1.4 Event-Test durchführen und aktivieren

Was: Der Administrator simuliert das Event und sieht, welche Datensätze betroffen wären und welche Auswirkungen die Aktionen hätten – ohne produktive Daten zu verändern.

Warum: Fehlkonfigurierte Events können unbeabsichtigte Massenänderungen auslösen. Die Simulation verhindert dies durch vorherige Prüfung.

Ergebnis: Die Simulation zeigt die geschätzten Auswirkungen und das Event kann nach Prüfung aktiviert werden.

4.2 Erwartete Events Auswertung

4.2.1 Event-Auslösungshistorie anzeigen

Was: Der Administrator sieht eine tabellarische Übersicht aller durchgeführten automatischen Aktionen mit Event-Typ, Trigger-Datum, betroffenen Datensätzen und Status.

Warum: Die Auslösungshistorie ermöglicht die Nachvollziehbarkeit aller automatischen Aktionen und die Identifikation von Fehlauslösungen.

Ergebnis: Die vollständige Event-Historie wird tabellarisch angezeigt und kann nach Event-Typ und Zeitraum gefiltert werden.

4.2.2 Effektivität von Events messen

Was: Das System vergleicht Metriken vor und nach der Event-Aktivierung (z. B. durchschnittliche Reaktionszeit, Ticket-Bearbeitungsdauer) und berechnet einen Effektivitätsprozentsatz.

Warum: Die Messung zeigt, ob die automatisierten Events tatsächlich die gewünschte Verbesserung bringen oder ob Anpassungen notwendig sind.

Ergebnis: Ein Effektivitätsbericht pro Event wird mit Vorher/Nachher-Vergleich angezeigt.

4.2.3 Event-Fehler und fehlgeschlagene Aktionen

Was: Das System erstellt einen Fehlerbericht mit fehlgeschlagenen Aktionen, Fehlertyp und -nachricht zur Diagnose.

Warum: Fehlgeschlagene automatische Aktionen können Geschäftsprozesse beeinträchtigen und müssen schnell identifiziert und behoben werden.

Ergebnis: Eine Liste fehlgeschlagener Aktionen mit Fehlerdetails wird angezeigt.

4.2.4 Event-Performance und Auslastung

Was: Das System zeigt ein Dashboard mit Event-Läufen pro Stunde, durchschnittlicher Verarbeitungszeit und identifizierten Engpässen.

Warum: Zu viele gleichzeitige Events können die Systemperformance beeinträchtigen. Das Performance-Dashboard hilft bei der Optimierung.

Ergebnis: Das Performance-Dashboard zeigt Auslastung, Verarbeitungszeiten und Engpässe.

4.2b Workflow-Engine

4.2b.1 Workflow-Trigger definieren

Was: Der Administrator konfiguriert Auslöser für automatische Workflows: Beleg-Statusänderungen, Datumsregeln (z. B. 30 Tage nach Rechnungsdatum), Betragsschwellen oder manuelle Auslösung.

Warum: Workflows automatisieren mehrstufige Geschäftsprozesse, die bisher manuell koordiniert werden mussten.

Ergebnis: Der Workflow-Trigger ist konfiguriert und der Workflow wird bei Eintritt der Auslöse-Bedingung automatisch gestartet.

4.2b.2 Workflow-Aktionen konfigurieren

Was: Der Administrator definiert die auszuführenden Aktionen: E-Mail senden, Report generieren, Datenfeld ändern, Aufgabe erstellen, Benachrichtigung auslösen oder Beleg weiterleiten.

Warum: Automatisierte Aktionen ersetzen manuelle Routine-Schritte und stellen die konsistente Ausführung von Geschäftsprozessen sicher.

Ergebnis: Die Workflow-Aktionen sind definiert und werden bei Workflow-Auslösung in der konfigurierten Reihenfolge ausgeführt.

4.2b.3 Bedingungslogik erstellen

Was: Der Administrator baut Wenn-Dann-Sonst-Regeln innerhalb eines Workflows auf, z. B. „Wenn Rechnungsbetrag > 10.000 €, dann Freigabe durch Geschäftsführung erforderlich, sonst automatische Freigabe".

Warum: Geschäftsprozesse erfordern Verzweigungen, bei denen unterschiedliche Aktionen je nach Datenlage ausgeführt werden sollen.

Ergebnis: Die Bedingungslogik ist im Workflow hinterlegt und steuert den Ablauf abhängig von den Daten.

4.2b.4 Workflow-Ketten definieren

Was: Der Administrator verkettet mehrere Aktionen zu einem mehrstufigen Workflow, bei dem der Abschluss einer Aktion die nächste Aktion auslöst.

Warum: Komplexe Geschäftsprozesse bestehen aus aufeinanderfolgenden Schritten, die automatisiert in der richtigen Reihenfolge ablaufen sollen.

Ergebnis: Die Workflow-Kette ist definiert und die Aktionen werden sequenziell ausgeführt.

4.2b.5 Workflow testen und aktivieren

Was: Der Administrator führt einen Testmodus des Workflows durch, der die Auslösung und Aktionsausführung simuliert, ohne produktive Daten zu verändern.

Warum: Fehlkonfigurierte Workflows können unbeabsichtigte Änderungen an Geschäftsdaten verursachen. Die Simulation sichert die korrekte Konfiguration ab.

Ergebnis: Der Workflow ist getestet und kann nach erfolgreicher Simulation aktiviert werden.

4.2b.6 Workflow-Ausführungshistorie anzeigen

Was: Das System protokolliert alle Workflow-Ausführungen mit Zeitstempel, ausgelöstem Trigger, ausgeführten Aktionen und Ergebnis (Erfolg/Fehler).

Warum: Die Ausführungshistorie ermöglicht die Nachvollziehbarkeit aller automatisierten Prozesse und die Diagnose bei Problemen.

Ergebnis: Die vollständige Workflow-Ausführungshistorie wird angezeigt und kann nach Zeitraum und Status gefiltert werden.

4.3 Reportserver

4.3.1 Report-Template definieren

Was: Der Administrator erstellt Report-Vorlagen mit Parametern, Layout-Konfiguration und Datenquellen.

Warum: Standardisierte Report-Templates ermöglichen die wiederkehrende Berichtserstellung mit konsistentem Layout und Inhalt.

Ergebnis: Die Report-Vorlage ist gespeichert und kann für manuelle und automatische Berichtsgenerierung verwendet werden.

4.3.2 Report-Versand zeitlich planen

Was: Der Administrator konfiguriert den automatischen Versand von Reports nach Zeitplan (täglich, wöchentlich, monatlich) mit definierten Empfängern und Frequenz.

Warum: Regelmäßige Berichte (z. B. tägliche Umsatzübersicht, monatliche Kundenliste) sollen ohne manuellen Aufwand automatisch erstellt und versendet werden.

Ergebnis: Der Report wird gemäß Zeitplan automatisch generiert und an die definierten Empfänger versendet.

4.3.3 Report-Filter und Dimensionen anpassen

Was: Der Sachbearbeiter passt Report-Filter an: Kunde, Region, Produkt, Zeitraum und Verdichtungsstufe (Tag/Woche/Monat/Quartal/Jahr).

Warum: Unterschiedliche Empfänger benötigen unterschiedliche Sichten auf die gleichen Daten – z. B. der Vertriebsleiter eine Regionssicht, der Controller eine Produktsicht.

Ergebnis: Der Report wird mit den angepassten Filtern und Dimensionen generiert.

4.3.4 Report-Versand-Historie und Fehlerbehandlung

Was: Das System protokolliert alle versendeten Reports mit Status (erfolgreich/fehlgeschlagen), Fehlermeldungen und Möglichkeit zum manuellen Nachversand.

Warum: Fehlgeschlagene Report-Versendungen müssen erkannt und nachgeholt werden können, um die Informationsversorgung sicherzustellen.

Ergebnis: Die Versand-Historie wird angezeigt und fehlgeschlagene Reports können manuell neu versendet werden.

5. Buchhaltung/Finanzen

5.1 Buchhaltungsexport/-import

5.1.1 Rechnungen und Gutschriften exportieren

Was: Der Buchhalter exportiert alle erstellten Rechnungen und Gutschriften zur Verbuchung in der Finanzbuchhaltung (DATEV, Abacus, SAP) mit Belegnummer, Betrag, Kontierung und Steuerschlüssel.

Warum: Das ERP-System erstellt die Belege, die Verbuchung erfolgt im Finanzbuchhaltungssystem. Der Export ist die Schnittstelle zwischen beiden Systemen.

Ergebnis: Die Belege sind als Exportdatei im Format des Zielsystems erstellt und können dort importiert werden.

5.1.2 Zahlungseingänge in Buchhaltung verbuchen

Was: Das System exportiert eingegangene Zahlungen automatisch als Buchungszeilen (Debitor-Konto an Bank-Konto) nach erfolgreichem Matching zu offenen Rechnungen.

Warum: Zahlungseingänge müssen in der Finanzbuchhaltung als Buchungen erfasst werden, um die offenen Posten korrekt auszugleichen.

Ergebnis: Die Zahlungsbuchungen sind als Exportdatei erstellt und können in der Finanzbuchhaltung importiert werden.

5.1.3 Kontoauszüge importieren und abstimmen

Was: Der Buchhalter importiert Bankauszüge und gleicht sie automatisch gegen offene Posten ab. Nicht zuordenbare Zahlungen werden zur manuellen Zuordnung markiert.

Warum: Der tägliche Abgleich zwischen Bankbewegungen und offenen Posten ist eine zentrale Aufgabe der Buchhaltung, die durch Automatisierung erheblich beschleunigt wird.

Ergebnis: Automatisch zuordenbare Zahlungen sind gematcht, nicht zuordenbare sind für die manuelle Bearbeitung markiert.

5.1.4 Lagerbestandsveränderungen exportieren

Was: Das System exportiert Lagermutationen (Einkauf, Verkauf, Umbuchung) mit automatischer Buchung auf die entsprechenden Lagerkonten.

Warum: Lagerbestandsänderungen müssen in der Finanzbuchhaltung auf den korrekten Konten (Wareneingang, Warenausgang, Bestandskonto) verbucht werden.

Ergebnis: Die Lagermutationen sind als Buchungsdatei exportiert.

5.1.5 Provisionsabrechnungen und Kostenverteilungen exportieren

Was: Das System exportiert berechnete Vertriebsprovisionen und interne Kostenverteilungen als Buchungszeilen auf Provisions- und Kostenträgerkonten.

Warum: Provisionen und interne Kostenverteilungen müssen buchhalterisch korrekt auf den zugehörigen Konten erfasst werden.

Ergebnis: Die Provisions- und Kostenverteilungsbuchungen sind exportiert.

5.1.6 Debitorenrechnungen im Debitorenstamm registrieren

Was: Das System legt automatisch neue Debitorenkonten in der Buchhaltung an, wenn ein neuer Kunde seine erste Rechnung erhält.

Warum: Für die ordnungsgemäße Buchführung muss jeder Kunde als Debitor im Finanzbuchhaltungssystem existieren.

Ergebnis: Der Debitor ist in der Buchhaltung angelegt und Rechnungen können korrekt gebucht werden.

5.1.7 Fehlerhafte Exporte korrigieren und neu exportieren

Was: Der Buchhalter behebt Validierungsfehler (fehlende Kontierungen, ungültige Kontonummern) und startet den Export erneut.

Warum: Fehlerhafte Exporte können in der Finanzbuchhaltung nicht verarbeitet werden. Die Korrektur und der erneute Export stellen die vollständige Übergabe sicher.

Ergebnis: Die korrigierten Belege sind erfolgreich exportiert.

5.1.8 Export-Status und Audit-Trail prüfen

Was: Der Buchhalter prüft den Export-Status aller Belege: Export-Datum, Format, Empfänger-System und Verarbeitungsstatus.

Warum: Die lückenlose Dokumentation der Exporte ist für die Nachvollziehbarkeit und die Abstimmung zwischen ERP und Finanzbuchhaltung notwendig.

Ergebnis: Ein Statusbericht aller Exporte wird mit Datum, Format und Verarbeitungsstatus angezeigt.

5.1.9 Batch-Export mit Zeitplan automatisieren

Was: Der Administrator konfiguriert automatische Exporte (täglich oder wöchentlich) mit Zeitplan und Benachrichtigung über Erfolg oder Fehler.

Warum: Regelmäßige Exporte sollen ohne manuellen Eingriff durchgeführt werden, um die Aktualität der Finanzbuchhaltung sicherzustellen.

Ergebnis: Die automatischen Exporte laufen gemäß Zeitplan und der Buchhalter wird über das Ergebnis benachrichtigt.

5.1.10 Import-Validierung und Konflikt-Auflösung

Was: Das System prüft beim Import auf Duplikate, Betragsabweichungen und Währungskonvertierungen und zeigt Konflikte zur manuellen Auflösung an.

Warum: Importierte Daten können Konflikte mit bestehenden Datensätzen verursachen, die manuell geprüft und aufgelöst werden müssen.

Ergebnis: Konflikte sind identifiziert und der Buchhalter kann sie einzeln oder als Batch auflösen.

5.2 DATEV Belegtransfer

5.2.1 Rechnung als PDF zu DATEV hochladen

Was: Das System überträgt erstellte Rechnungen digital als PDF an DATEV über die Connect-Schnittstelle mit zugehörigen Metadaten (Belegnummer, Datum, Betrag).

Warum: Die digitale Belegübertragung ersetzt den Papierversand an den Steuerberater und ermöglicht die automatische Zuordnung in DATEV.

Ergebnis: Die Rechnung ist als PDF mit Metadaten bei DATEV verfügbar und kann dort verbucht werden.

5.2.2 Eingangsrechnungen von DATEV importieren

Was: Der Buchhalter importiert Lieferantenrechnungen aus DATEV mit automatischer Zuordnung zum Lieferantenstamm.

Warum: Eingangsrechnungen, die beim Steuerberater in DATEV erfasst werden, sollen im ERP-System für die Warenwirtschaft und Kostenrechnung verfügbar sein.

Ergebnis: Die importierten Eingangsrechnungen sind den Lieferanten zugeordnet und im System verfügbar.

5.2.3 Belegscans und Anhänge speichern

Was: Der Buchhalter ordnet gescannte Originalbelege über OCR-Erkennung den digitalen Dokumenten im ERP-System zu.

Warum: Die Zuordnung von Papierbelegen zu digitalen Vorgängen ist für die revisionssichere Archivierung und schnelle Recherche notwendig.

Ergebnis: Die Belegscans sind den zugehörigen Vorgängen zugeordnet und durchsuchbar archiviert.

5.2.4 Belegverwaltung und Langzeitarchivierung (10 Jahre)

Was: Das System archiviert Belege revisionssicher in einem unveränderlichen Archiv mit vollständigem Audit-Trail, konform zu den gesetzlichen Aufbewahrungsfristen.

Warum: Die gesetzliche Aufbewahrungspflicht für Geschäftsbelege beträgt in Deutschland 10 Jahre (GoBD). Die Unveränderbarkeit ist dabei Pflicht.

Ergebnis: Alle Belege sind revisionssicher archiviert und für 10 Jahre unveränderbar gespeichert.

5.2.5 Volltext-Suche in archivierten Belegen

Was: Der Buchhalter durchsucht archivierte Belege nach Belegnummer, Lieferant, Betreff, OCR-erkanntem Text und Zeitraum.

Warum: Bei Rückfragen, Prüfungen oder Rechtsstreitigkeiten muss schnell auf archivierte Belege zugegriffen werden können.

Ergebnis: Die Suchergebnisse werden mit Vorschau angezeigt und der gesuchte Beleg kann direkt geöffnet werden.

5.2.6 Belegverwerfung und Wiederherstellung

Was: Der Buchhalter verwirft fehlerhafte Belege logisch (Soft Delete) mit einer 30-tägigen Recovery-Option.

Warum: Fehlerhafte Belege sollen entfernt werden können, ohne sofort unwiderruflich gelöscht zu werden, falls die Verwerfung irrtümlich war.

Ergebnis: Der Beleg ist als verworfen markiert und kann innerhalb von 30 Tagen wiederhergestellt werden.

5.2.7 Belegfreigabe und Genehmigungsprozesse

Was: Belege durchlaufen einen Freigabe-Workflow: Hochgeladen → Prüfung → Freigabe/Ablehnung → Verbuchung.

Warum: Eingangsrechnungen müssen vor der Verbuchung geprüft und freigegeben werden, um Fehlbuchungen und Betrug zu verhindern.

Ergebnis: Der Beleg ist freigegeben oder abgelehnt, und bei Freigabe wird er zur Verbuchung weitergeleitet.

5.2.8 Belegsperrung und Compliance-Hold

Was: Der Beleg wird für Audit- oder Rechtsstreit-Zwecke gesperrt und ist bis zur Freigabe unveränderbar.

Warum: Im Rahmen von Audits oder Rechtsstreitigkeiten müssen bestimmte Belege vor Veränderung oder Löschung geschützt werden.

Ergebnis: Der Beleg ist gesperrt und kann nicht verändert oder gelöscht werden, bis die Sperre aufgehoben wird.

5.2.9 Batch-Belegverarbeitung

Was: Der Buchhalter verarbeitet mehrere Belege gleichzeitig: Hochladen, Archivieren und Genehmigen in einem Durchgang.

Warum: Bei großen Mengen (z. B. Monatsabschluss) ist die Einzelverarbeitung ineffizient. Die Batch-Verarbeitung spart erheblich Zeit.

Ergebnis: Alle ausgewählten Belege sind verarbeitet und im jeweiligen Status dokumentiert.

5.2.10 GDPdU Compliance und Audit-Trail

Was: Das System stellt die Einhaltung der GDPdU-Richtlinien sicher: 10 Jahre Aufbewahrung, Unveränderbarkeit, lückenlose Zugriffskontrolle und vollständiger Audit-Trail.

Warum: Die Einhaltung der GDPdU (Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen) ist gesetzlich vorgeschrieben und wird bei Betriebsprüfungen kontrolliert.

Ergebnis: Das System ist GDPdU-konform konfiguriert und der Nachweis kann bei Prüfungen erbracht werden.

5.3 Kalkulation pro Filiale

5.3.1 Filial-Kostenrechnung erstellen und anzeigen

Was: Der Controller erstellt eine finanzielle Performance-Übersicht pro Filiale: Umsatz, Kosten, EBIT und Ergebnis für einen gewählten Zeitraum.

Warum: Die Filial-Kostenrechnung zeigt die wirtschaftliche Leistung jedes Standorts und ist Grundlage für Steuerungsentscheidungen.

Ergebnis: Die Filial-Kostenrechnung wird mit allen Kennzahlen für den gewählten Zeitraum angezeigt.

5.3.2 Gemeinkostenverteilung nach Schlüssel

Was: Der Controller verteilt zentrale Kosten (Miete, Verwaltung, IT) auf Filialen nach konfigurierbaren Schlüsseln: Mitarbeiterzahl, Umsatz, Fläche oder benutzerdefiniert.

Warum: Gemeinkosten müssen verursachungsgerecht auf die Standorte verteilt werden, um die tatsächliche Rentabilität zu ermitteln.

Ergebnis: Die Gemeinkosten sind gemäß dem gewählten Schlüssel auf die Filialen verteilt.

5.3.3 Deckungsbeitrag pro Filiale berechnen

Was: Das System berechnet den Deckungsbeitrag pro Standort: Umsatz minus variable Kosten.

Warum: Der Deckungsbeitrag zeigt, wie viel jede Filiale zur Deckung der Fixkosten und zum Gewinn beiträgt.

Ergebnis: Der Deckungsbeitrag pro Filiale wird berechnet und im Filialvergleich angezeigt.

5.3.4 Vergleichsanalyse zwischen Filialen

Was: Der Controller vergleicht Rentabilität, Break-Even-Point und Kostenquote zwischen den Standorten.

Warum: Der Vergleich identifiziert leistungsstarke und -schwache Standorte und liefert Handlungsempfehlungen.

Ergebnis: Eine Vergleichsdarstellung mit Ranking der Filialen nach den gewählten Kennzahlen wird angezeigt.

5.3.5 Budgets pro Filiale definieren und kontrollieren

Was: Der Controller definiert Jahresbudgets pro Filiale und vergleicht laufend die Soll- und Ist-Werte mit Abweichungsanalyse.

Warum: Die Budgetkontrolle stellt sicher, dass die Standorte innerhalb des geplanten Rahmens wirtschaften und Abweichungen frühzeitig erkannt werden.

Ergebnis: Der aktuelle Budgetverbrauch wird pro Filiale angezeigt, mit Abweichungen und Prognose für das Gesamtjahr.

5.3.6 Investitionsrentabilität pro Filiale

Was: Das System berechnet die Kapitalrendite (ROI) pro Standort: (Gewinn / Investition) × 100.

Warum: Die ROI-Berechnung zeigt, ob Investitionen in einen Standort wirtschaftlich sinnvoll waren oder sind.

Ergebnis: Der ROI pro Filiale wird berechnet und mit Benchmarks verglichen.

5.3.7 Filialen-Ranking und Performance-Dashboard

Was: Das System erstellt ein Ranking der Filialen nach Umsatz, Rentabilität und Wachstum mit Top/Bottom-Kennzeichnung.

Warum: Das Ranking gibt der Geschäftsleitung einen schnellen Überblick über die leistungsstärksten und -schwächsten Standorte.

Ergebnis: Ein Performance-Dashboard mit Filial-Ranking und Kennzahlen wird angezeigt.

5.3.8 Kostenmodelle für Szenarien-Analysen

Was: Der Controller erstellt Was-wenn-Szenarien, z. B. Auswirkung von Mietreduktion, Personalanpassung oder Umsatzsteigerung auf die Rentabilität einer Filiale.

Warum: Strategische Entscheidungen (Standortschließung, Expansion) erfordern eine Vorab-Simulation der finanziellen Auswirkungen.

Ergebnis: Die Szenario-Ergebnisse werden im Vergleich zur aktuellen Situation angezeigt.

5.4 Mahnung

5.4.1 Überfällige Rechnungen identifizieren und Mahnprozess starten

Was: Das System erfasst automatisch alle Rechnungen, deren Zahlungsziel überschritten ist, und initiiert den Mahnlauf.

Warum: Überfällige Forderungen müssen zeitnah eingetrieben werden, um die Liquidität zu sichern und den Forderungsbestand zu reduzieren.

Ergebnis: Alle überfälligen Rechnungen sind identifiziert und der Mahnprozess ist für jede Rechnung gemäß der Mahnstufe gestartet.

5.4.2 Mahnstufen-Regeln konfigurieren

Was: Der Administrator konfiguriert die Mahnregeln: Tage bis Stufe 1 bis 4, Mahngebühren pro Stufe, Verzugszinsen und Ausnahmen für Kleinbeträge.

Warum: Ein standardisierter Mahnprozess stellt die konsistente Behandlung überfälliger Forderungen sicher und berücksichtigt gesetzliche Vorgaben.

Ergebnis: Die Mahnstufen-Regeln sind konfiguriert und werden bei jedem Mahnlauf automatisch angewendet.

5.4.3 Personalisierte Mahnbriefe generieren

Was: Das System erstellt automatisch Mahnschreiben basierend auf Vorlagen mit Empfänger-Daten, Forderungssumme, Fälligkeitsdatum und aktueller Mahnstufe.

Warum: Personalisierte Mahnschreiben sind professioneller und effektiver als Standardbriefe, da sie den Kunden mit seinen konkreten Daten ansprechen.

Ergebnis: Die Mahnbriefe sind generiert und bereit für den Versand per Post oder E-Mail.

5.4.4 Zahlungserinnerungen per E-Mail versenden

Was: Das System versendet automatisch Zahlungserinnerungen per E-Mail, wobei die Vorlage abhängig von der Mahnstufe ausgewählt wird. Optional wird die Rechnung als PDF-Anhang beigefügt.

Warum: E-Mail-Versand ist schneller und kostengünstiger als Briefpost und erreicht den Kunden in der Regel noch am selben Tag.

Ergebnis: Die Zahlungserinnerungen sind per E-Mail versendet und der Versand ist dokumentiert.

5.4.5 Mahnungen manuell anpassen und neu versenden

Was: Der Buchhalter korrigiert Zahlungsbetrag, Mahnstufe, Verzugszinsen oder Versandkanal einer bereits erstellten Mahnung und versendet sie erneut.

Warum: In Einzelfällen (z. B. Teilzahlung erfolgt, Kulanzregelung, falscher Betrag) muss eine Mahnung manuell angepasst werden.

Ergebnis: Die korrigierte Mahnung ist erstellt und versendet.

5.4.6 Zahlungseingänge matching und Mahnprozess stoppen

Was: Das System beendet den Mahnprozess automatisch bei Eingang der vollständigen Zahlung, wobei der Audit-Trail erhalten bleibt.

Warum: Der Mahnprozess muss bei Zahlungseingang sofort gestoppt werden, um ungerechtfertigte Folge-Mahnungen zu vermeiden.

Ergebnis: Der Mahnprozess ist beendet, die Rechnung ist als bezahlt markiert und die Mahnhistorie bleibt dokumentiert.

5.4.7 Zinsberechnung und Verzugszinsen

Was: Das System berechnet Verzugszinsen automatisch gemäß § 288 BGB (5 Prozentpunkte über Basiszins bei B2C, 9 Prozentpunkte bei B2B) ab dem ersten Tag nach Zahlungsziel.

Warum: Die korrekte Berechnung von Verzugszinsen ist gesetzlich geregelt und muss bei Mahnungen ausgewiesen werden.

Ergebnis: Die Verzugszinsen sind berechnet und in der Mahnung ausgewiesen.

5.4.8 Inkasso-Übergabe vorbereiten und exportieren

Was: Der Buchhalter exportiert Debitor-Informationen, Rechnungs-Details und die vollständige Mahnhistorie für die Übergabe an ein Inkasso-Unternehmen.

Warum: Bei fruchtlosen Mahnungen muss die Forderung an ein Inkasso-Unternehmen übergeben werden, das alle relevanten Informationen benötigt.

Ergebnis: Die Inkasso-Unterlagen sind als Export erstellt und können an das Inkasso-Unternehmen übergeben werden.

5.4.9 Mahnhistorie und Audit-Trail anzeigen

Was: Der Buchhalter sieht die vollständige Mahnhistorie einer Forderung: alle Mahnaktionen, Versand-Datum, -Kanal, Empfänger, Gebühren und Zahlungseingänge.

Warum: Die lückenlose Dokumentation ist für Rückfragen, Rechtsstreitigkeiten und die Zusammenarbeit mit Inkasso-Unternehmen unerlässlich.

Ergebnis: Die vollständige Mahnhistorie wird chronologisch angezeigt.

5.4.10 Mahnungen stornieren oder Prozess abbrechen

Was: Der Buchhalter storniert einzelne Mahnungen, erlässt Forderungen aus Kulanz, erstellt eine Gutschrift oder bricht den gesamten Mahnprozess ab.

Warum: Kulanzregelungen, fehlerhafte Rechnungen oder Kundenbeschwerden können eine Stornierung oder einen Abbruch des Mahnprozesses erfordern.

Ergebnis: Die Mahnung ist storniert oder der Prozess ist abgebrochen, mit entsprechender Dokumentation im Audit-Trail.

5.5 OPOS (Offene Posten)

5.5.1 Offene Posten anzeigen und filtern

Was: Der Buchhalter filtert offene Posten nach Kunde, Lieferant, Zeitraum, Überfälligkeit (über 30/60/90 Tage) und Betrag.

Warum: Die Übersicht offener Posten ist zentral für das Forderungs- und Verbindlichkeitsmanagement und die Liquiditätssteuerung.

Ergebnis: Die gefilterten offenen Posten werden mit Betrag, Fälligkeitsdatum und Überfälligkeitsstatus angezeigt.

5.5.2 Zahlungseingänge matching zu offenen Posten

Was: Das System ordnet eingehende Zahlungen automatisch offenen Rechnungen zu, basierend auf Betrag, Referenztext und Verwendungszweck.

Warum: Die automatische Zuordnung beschleunigt den Abgleich erheblich und reduziert manuelle Fehler bei der Zahlungszuordnung.

Ergebnis: Automatisch zuordenbare Zahlungen sind den offenen Posten zugewiesen, Restbeträge und Nicht-Matches sind markiert.

5.5.3 Bank-Kontoauszüge als OPOS importieren

Was: Der Buchhalter importiert Kontoauszüge in verschiedenen Formaten (CSV, OFX, MT940, SEPA-XML) als offene Posten.

Warum: Bankbewegungen müssen im System erfasst werden, um den Abgleich mit offenen Posten durchführen zu können.

Ergebnis: Die Bankbewegungen sind als offene Posten importiert und stehen für das Matching bereit.

5.5.4 Teilzahlungen und Storno handhaben

Was: Das System aktualisiert den Restbetrag bei Teilzahlungen und erstellt bei Stornierungen einen neuen OPOS mit dem Differenzbetrag.

Warum: Teilzahlungen und Stornierungen sind häufige Geschäftsvorfälle, die den offenen Posten korrekt fortschreiben müssen.

Ergebnis: Der offene Posten zeigt den korrekten Restbetrag nach Teilzahlung oder Storno.

5.5.5 OPOS-Report für Buchhaltung/Management

Was: Das System erstellt einen detaillierten Bericht der offenen Posten mit Kunde, Rechnungsnummer, Betrag, Überfälligkeit und Mahnstatus als Excel oder PDF.

Warum: Der OPOS-Report ist ein zentrales Steuerungsinstrument für die Finanzbuchhaltung und das Management.

Ergebnis: Der OPOS-Report ist erstellt und kann als Excel oder PDF heruntergeladen werden.

5.5.6 OPOS-Abstimmung und Abweichungs-Analyse

Was: Der Buchhalter vergleicht die offenen Posten im ERP-System mit den Salden in der Finanzbuchhaltung (DATEV, Abacus) und identifiziert Differenzen.

Warum: Regelmäßige Abstimmungen zwischen den Systemen stellen die Datenkonsistenz sicher und identifizieren Buchungsfehler.

Ergebnis: Differenzen zwischen ERP und Finanzbuchhaltung werden angezeigt und können analysiert werden.

5.5.7 Automatische OPOS-Bereinigung (aged debt)

Was: Das System markiert automatisch offene Posten, die älter als 2 Jahre sind, und schlägt eine Abschreibung mit zugehöriger Buchung vor.

Warum: Sehr alte Forderungen sind in der Regel nicht mehr einbringlich und sollten buchhalterisch bereinigt werden.

Ergebnis: Alte offene Posten sind markiert und der Abschreibungsvorschlag kann übernommen werden.

5.5.8 Export für Buchhaltung und Schnittstellen

Was: Der Buchhalter exportiert offene Posten an Finanzbuchhaltungssysteme (DATEV, Abacus, SAP, Lexware) in verschiedenen Formaten (CSV, XML, OFX).

Warum: Die offenen Posten müssen für Abstimmung und Weiterverarbeitung in der Finanzbuchhaltung verfügbar sein.

Ergebnis: Die offenen Posten sind im gewählten Format exportiert.

5.6 SEPA

5.6.1 SEPA-Mandate von Kunden verwalten

Was: Der Buchhalter erfasst und archiviert SEPA-Lastschrift-Mandate mit IBAN, BIC, Mandatsdatum und Unterschriftsinformation.

Warum: Für SEPA-Lastschrifteinzüge ist ein gültiges Mandat des Kunden rechtlich zwingend erforderlich.

Ergebnis: Die SEPA-Mandate sind erfasst und stehen für die Erstellung von Lastschriftdateien zur Verfügung.

5.6.2 SEPA-Lastschrift-Datei (XML) generieren

Was: Das System fasst fällige Rechnungen von Kunden mit gültigem SEPA-Mandat zusammen und generiert eine SEPA-Lastschrift-XML-Datei (pain.008.003.02) für die Bankübermittlung.

Warum: SEPA-Lastschriften automatisieren den Zahlungseinzug und sichern die pünktliche Zahlung von Kundenforderungen.

Ergebnis: Die SEPA-Lastschrift-Datei ist generiert und kann an die Hausbank übermittelt werden.

5.6.3 Bank-Rückmeldungen zu Lastschriften verarbeiten

Was: Das System verarbeitet Rückmeldungen der Bank zu fehlgeschlagenen Lastschriften (ungültige IBAN, gekündigtes Konto, Widerspruch) und ermöglicht Korrektur und Wiederholung.

Warum: Fehlgeschlagene Lastschriften müssen analysiert, korrigiert (z. B. neue IBAN einholen) und erneut eingereicht werden.

Ergebnis: Fehlgeschlagene Lastschriften sind mit Fehlergrund dokumentiert und können nach Korrektur erneut eingereicht werden.

5.6.4 SEPA Credit Transfer für Lieferanten-Zahlungen

Was: Das System erstellt SEPA-Überweisungsdateien für Lieferantenzahlungen mit Genehmigungsworkflow und XML-Generierung.

Warum: Lieferantenrechnungen werden per SEPA-Überweisung bezahlt. Die automatisierte Erstellung spart Zeit und reduziert Fehler.

Ergebnis: Die SEPA-Überweisungsdatei ist genehmigt, generiert und bereit für die Bankübermittlung.

5.6.5 SEPA-Gebühren und Kosten verwalten

Was: Das System erfasst Bank-Gebühren pro Lastschrift, Rückbuchung und Mandatverwaltung für die Kostenübersicht.

Warum: SEPA-Transaktionen verursachen Bankgebühren, die transparent erfasst und ggf. an Kunden weiterberechnet werden.

Ergebnis: Die SEPA-Gebühren sind pro Transaktion erfasst und in der Kostenübersicht sichtbar.

5.6.6 SEPA-Status und Audit-Trail

Was: Das System dokumentiert alle verarbeiteten Lastschriften und Überweisungen mit Dateiname, Datum, Transaktionsanzahl und Verarbeitungsstatus.

Warum: Die lückenlose Dokumentation ist für die Nachvollziehbarkeit und die Abstimmung mit der Bank erforderlich.

Ergebnis: Der vollständige SEPA-Verarbeitungsverlauf wird mit allen Details angezeigt.

5.6.7 SEPA-Validierung und Fehlerprüfung

Was: Das System prüft vor der Dateierstellung: IBAN-Format, Mandatsvorhandensein, positiver Betrag und korrekte Vorfälligkeitsfrist.

Warum: Fehlerhaft generierte SEPA-Dateien werden von der Bank abgelehnt. Die Vorab-Validierung verhindert dies.

Ergebnis: Alle Transaktionen sind validiert, Fehler werden angezeigt und müssen vor der Dateierstellung korrigiert werden.

5.7 Zahlungseingang

5.7.1 Bankauszüge hochladen und importieren

Was: Der Buchhalter importiert tägliche Bankbewegungen aus verschiedenen Formaten (CSV, MT940, SEPA-XML, OFX) oder über die automatische FinAPI-Anbindung.

Warum: Die tägliche Erfassung von Zahlungseingängen ist Voraussetzung für die aktuelle offene-Posten-Verwaltung und die Liquiditätsübersicht.

Ergebnis: Die Bankbewegungen sind importiert und stehen für das automatische und manuelle Matching bereit.

5.7.2 Automatisches Matching zu Rechnungen

Was: Das System ordnet eingehende Zahlungen automatisch offenen Rechnungen zu, basierend auf Betragsvergleich, Referenztexterkennung und Fuzzy-Matching mit einer Quote von über 90 % automatischen Zuordnungen.

Warum: Das automatische Matching reduziert den manuellen Aufwand bei der Zahlungszuordnung erheblich und beschleunigt den täglichen Abgleich.

Ergebnis: Automatisch zuordenbare Zahlungen sind gematcht, Nicht-Matches sind für die manuelle Bearbeitung markiert.

5.7.3 Manuelle Zahlungs-Zuordnung bei Nicht-Matches

Was: Der Buchhalter ordnet nicht automatisch zuordenbare Zahlungen manuell den offenen Rechnungen zu.

Warum: Zahlungen ohne eindeutige Referenz (z. B. fehlender Verwendungszweck, abweichender Betrag) müssen manuell zugeordnet werden.

Ergebnis: Die Zahlung ist manuell der korrekten Rechnung zugeordnet.

5.7.4 Teilzahlungen und Zahlungsrückgaben handhaben

Was: Das System erstellt bei Teilzahlungen automatisch einen neuen offenen Posten mit dem Restbetrag. Bei Zahlungsrückgaben wird die Transaktion mit Referenz storniert.

Warum: Teilzahlungen und Rückgaben sind häufige Geschäftsvorfälle, die korrekt verarbeitet werden müssen.

Ergebnis: Der Restbetrag ist als neuer offener Posten erfasst bzw. die Rückgabe ist storniert und dokumentiert.

5.7.5 Bank-Abstimmung und Diskrepanz-Analyse

Was: Der Buchhalter führt monatlich den Abgleich zwischen dem Bankbestand im System und dem tatsächlichen Bankkontostand durch.

Warum: Die regelmäßige Bankabstimmung identifiziert Differenzen und stellt die Korrektheit der Buchhaltungsdaten sicher.

Ergebnis: Differenzen zwischen Systembestand und tatsächlichem Bankbestand werden angezeigt.

5.7.6 Zahlungs-Status und Reporting

Was: Der Buchhalter erstellt Berichte über tägliche/wöchentliche Zahlungseingänge, Ausstände nach Kunde und Trend-Analyse.

Warum: Die Zahlungsübersicht unterstützt die Liquiditätsplanung und die Identifikation von Zahlungsverzügen.

Ergebnis: Ein Zahlungseingangs-Report mit Statusübersicht und Trend-Darstellung wird angezeigt.

5.7.7 FinAPI-Integration für Automatisierung

Was: Das System importiert vollautomatisch tägliche Bankbewegungen über die FinAPI-Bankanbindung, ohne dass der Buchhalter manuell Dateien hochladen muss.

Warum: Die vollautomatische Integration eliminiert den manuellen Import-Schritt und stellt sicher, dass Zahlungseingänge tagesaktuell verfügbar sind.

Ergebnis: Die täglichen Bankbewegungen werden automatisch importiert und stehen für das Matching bereit.

5.7.8 Zahlungseingang verbuchen in Buchhaltung

Was: Das System exportiert erfolgreich gematchte Zahlungen als Buchungszeilen (Debitor-Konto an Bank-Konto) an das Finanzbuchhaltungssystem.

Warum: Gematchte Zahlungen müssen als Buchungen in der Finanzbuchhaltung erfasst werden, um die offenen Posten auszugleichen.

Ergebnis: Die Zahlungsbuchungen sind exportiert und können im Finanzbuchhaltungssystem verbucht werden.

5.8 Bankkonten

5.8.1 Bankkonten verwalten

Was: Der Administrator verwaltet die Firmen-Bankkonten mit IBAN, BIC und Verwendungszweck. Die Konten werden in den Modulen SEPA und Zahlungseingang referenziert.

Warum: Bankkonten sind die Grundlage für SEPA-Transaktionen, Zahlungsimporte und die Bankabstimmung.

Ergebnis: Die Bankkonten sind gepflegt und stehen in allen relevanten Modulen zur Verfügung.

6. Controlling/Analytics

6.1 Analytics

6.1.1 Verkaufsstatistik nach Artikel erstellen

Was: Der Controller erstellt eine Analyse der Verkaufsleistung einzelner Artikel: Absatzmenge, Umsatz und Gewinn über einen definierten Zeitraum.

Warum: Die Artikel-Analyse zeigt, welche Produkte profitabel sind und welche nicht, und liefert Grundlagen für Sortimentsentscheidungen.

Ergebnis: Die Verkaufsstatistik wird pro Artikel mit Menge, Umsatz, Gewinn und Marge angezeigt.

6.1.2 Kundenstatistik mit Jahresvergleich

Was: Der Controller analysiert die Umsatzentwicklung pro Kunde über mehrere Jahre und identifiziert steigende und fallende Trends.

Warum: Der Jahresvergleich zeigt die Entwicklung der Kundenbeziehung und hilft, abwandernde Kunden frühzeitig zu erkennen.

Ergebnis: Die Kundenstatistik wird mit Jahresvergleich und Trend-Indikatoren angezeigt.

6.1.3 Mitarbeiterleistung nach Verkauf vergleichen

Was: Der Vertriebsleiter vergleicht die Verkaufsleistung pro Mitarbeiter: Verkaufsmenge, Umsatz, Gewinn und Erfolgsquote gegen Durchschnitt und Plan.

Warum: Der Mitarbeitervergleich unterstützt die Vertriebssteuerung und die leistungsgerechte Beurteilung.

Ergebnis: Ein Vergleichsbericht der Mitarbeiter-Verkaufsleistung wird angezeigt.

6.1.4 Ticket-Statistik (Support-Leistung)

Was: Der Serviceleiter wertet die Support-Leistung aus: Ticket-Anzahl, durchschnittliche Bearbeitungszeit, Eskalationsrate, Kundenzufriedenheit und SLA-Einhaltung pro Mitarbeiter.

Warum: Die Ticket-Statistik zeigt die Effizienz des Supportteams und identifiziert Schulungsbedarf oder Kapazitätsengpässe.

Ergebnis: Die Ticket-Statistik wird pro Mitarbeiter mit allen Kennzahlen angezeigt.

6.1.5 Einkaufsstatistik und Lieferanten-Leistung

Was: Der Einkäufer analysiert das Bestellvolumen, die Gesamtausgaben, die Liefertreue und die Rückmeldequote pro Lieferant, ergänzt um ein Ranking.

Warum: Die Lieferantenbewertung unterstützt Verhandlungen, Lieferantenauswahl und die Optimierung der Beschaffung.

Ergebnis: Ein Lieferanten-Ranking mit Kennzahlen wird angezeigt.

6.1.6 Gewinn-Analyse nach Materialgruppe

Was: Der Controller analysiert die Profitabilität pro Produktkategorie: Marge, Gewinner (über 25 %) und Problemgruppen (unter 5 %).

Warum: Die Materialgruppen-Analyse zeigt, in welchen Produktbereichen die höchsten Margen erzielt werden und wo Handlungsbedarf besteht.

Ergebnis: Die Gewinn-Analyse wird pro Materialgruppe mit Marge und Kategorisierung (Gewinner/Problemgruppe) angezeigt.

6.1.7 Filialvergleich und Standort-Performance

Was: Der Controller vergleicht die Standorte nach Tagesverkauf, Umsatz, Personalkostenquote, Gewinn und Rendite mit Ranking.

Warum: Der Filialvergleich identifiziert Best-Practice-Standorte und zeigt Verbesserungspotenziale bei schwächeren Filialen.

Ergebnis: Ein Filialvergleichs-Dashboard mit Ranking und allen Kennzahlen wird angezeigt.

6.1.8 Lagerbestands-Entwicklung und Umschlag

Was: Der Controller analysiert die Lagerentwicklung: Anfangsbestand, Zu- und Abgänge, Endbestand, Lagertage und Umschlaggeschwindigkeit, ergänzt um eine Slow-/Fast-Mover-Analyse.

Warum: Die Lageranalyse optimiert die Kapitalbindung und identifiziert Artikel mit zu geringem oder zu hohem Lagerumschlag.

Ergebnis: Die Lagerbestands-Entwicklung wird mit Umschlagskennzahlen und Slow-/Fast-Mover-Markierung angezeigt.

6.1b Lagerwert-Report

6.1b.1 Gesamtlagerwert berechnen

Was: Das System ermittelt den aktuellen Lagerwert: Bestände multipliziert mit dem Einstandspreis, aufgeschlüsselt nach Lagerort und Warengruppe sowie als Gesamtsumme.

Warum: Der Lagerwert ist eine zentrale Bilanzposition und muss für die Buchhaltung und das Controlling jederzeit abrufbar sein.

Ergebnis: Der Gesamtlagerwert wird mit Aufschlüsselung nach Lagerort und Warengruppe angezeigt.

6.1b.2 Lagerbewertungsmethode anwenden

Was: Das System bewertet den Lagerbestand wahlweise nach FIFO (First In First Out) oder gewichtetem Durchschnitt, mit Vergleichsansicht beider Methoden.

Warum: Die Bewertungsmethode beeinflusst die Bilanz und die Gewinn-/Verlustrechnung. Der Vergleich zeigt die Auswirkung der Methodenwahl.

Ergebnis: Der Lagerwert wird nach beiden Methoden berechnet und im Vergleich angezeigt.

6.1b.3 Slow-Mover-Identifikation

Was: Das System identifiziert Artikel mit geringem Lagerumschlag: Keine Bewegung seit einer konfigurierbaren Anzahl Monaten, gebundenes Kapital und Empfehlung für Abverkauf oder Abschreibung.

Warum: Slow-Mover binden Kapital und Lagerfläche. Die frühzeitige Identifikation ermöglicht Gegenmaßnahmen wie Sonderaktionen oder Abschreibungen.

Ergebnis: Eine Liste der Slow-Mover wird mit Lagerdauer, gebundenem Kapital und Handlungsempfehlung angezeigt.

6.1b.4 Lagerwert-Abweichungsanalyse

Was: Das System vergleicht den Soll-Lagerwert (Buchhaltung) mit dem Ist-Lagerwert (Bestand × Preis) und identifiziert Bewertungsdifferenzen.

Warum: Differenzen zwischen buchhalterischem und physischem Lagerwert deuten auf Buchungsfehler, Schwund oder Bewertungsprobleme hin.

Ergebnis: Die Abweichungen werden angezeigt und können nach Artikeln oder Warengruppen analysiert werden.

6.1b.5 Lagerwert-Entwicklung über Zeit

Was: Das System erstellt eine Zeitreihen-Darstellung des Lagerwerts über Monate oder Quartale mit Trend-Linie und Veränderungsraten.

Warum: Die Entwicklung des Lagerwerts zeigt Trends bei der Kapitalbindung und hilft bei der Optimierung der Beschaffung.

Ergebnis: Ein Zeitreihen-Diagramm des Lagerwerts mit Trend-Linie wird angezeigt.

6.1c Aufwand/Kosten-Analyse

6.1c.1 Zeitaufwand pro Kunde aggregieren

Was: Das System fasst alle erfassten Arbeitszeiten (Helpdesk-Timer, Projekt-Stunden) pro Kunde für einen wählbaren Zeitraum zusammen.

Warum: Die Kenntnis des tatsächlichen Zeitaufwands pro Kunde ist Grundlage für die Profitabilitätsanalyse und die Preisgestaltung.

Ergebnis: Der aggregierte Zeitaufwand wird pro Kunde mit Stunden, Kosten und Vergleich zum Vertragswert angezeigt.

6.1c.2 Kostenvergleich: Geplant vs. Tatsächlich

Was: Das System stellt geplante Kosten (Budget, Vertragswert) den tatsächlich angefallenen Kosten (Zeiterfassung, Material) pro Projekt oder Kunde gegenüber.

Warum: Der Soll/Ist-Vergleich zeigt, ob Projekte und Kunden im Rahmen des Budgets liegen oder ob Nachverhandlungen oder Maßnahmen notwendig sind.

Ergebnis: Eine Gegenüberstellung von Plan- und Ist-Kosten wird pro Projekt oder Kunde angezeigt, mit Abweichung in absoluten Zahlen und Prozent.

6.1c.3 Gewinnmarge pro Projekt/Kunde berechnen

Was: Das System ermittelt die Gewinnmarge: Umsatz minus Kosten (Personal, Material, Fremdleistung) pro Projekt oder Kunde.

Warum: Die Gewinnmargen-Berechnung zeigt die tatsächliche Profitabilität einzelner Projekte und Kunden und ist die Basis für strategische Entscheidungen.

Ergebnis: Die Gewinnmarge wird pro Projekt oder Kunde mit Umsatz, Kosten und Marge in Prozent angezeigt.

6.1c.4 Aufwand/Kosten-Report exportieren

Was: Der Controller exportiert die Aufwands- und Kostenanalyse als Excel-Datei mit konfigurierbaren Dimensionen (Kunde, Projekt, Mitarbeiter, Zeitraum).

Warum: Die exportierten Daten werden für Management-Präsentationen, externe Beratung oder die Weiterverarbeitung in Controlling-Tools benötigt.

Ergebnis: Der Report ist als Excel-Datei mit den gewählten Dimensionen exportiert.

6.2 Leistungsnachweise

6.2.1 Wochenauslastung pro Mitarbeiter anzeigen

Was: Die Teamleitung ruft eine Wochenübersicht auf, die für jeden Mitarbeiter die tagesaktuelle Auslastung von Montag bis Freitag in Prozent darstellt. Per Klick auf einen Mitarbeiter werden gebuchte Projekte und Aufgaben mit Stundenanteil sichtbar.

Warum: Die Auslastungsübersicht dient der schnellen Identifikation von überlasteten oder unterbeschäftigten Teammitgliedern und ermöglicht eine gezielte Umverteilung von Aufgaben innerhalb der Woche. Freie Kapazitäten werden so unmittelbar für neue Projekteinplanungen sichtbar.

Ergebnis: Eine tabellarische Übersicht mit Farbkennzeichnung: Grün unter 70%, Gelb 70-90%, Rot über 90% Auslastung pro Mitarbeiter und Tag. Die Woche kann vor- und zurücknavigiert werden.

6.2.2 Monatsauslastung und Abwesenheiten berücksichtigen

Was: Der Benutzer wählt einen Monat und erhält für jeden Mitarbeiter eine Berechnung aus Sollstunden (Arbeitstage mal 8 Stunden minus Abwesenheitszeiten) gegenüber den tatsächlich gebuchten Stunden, inklusive Trend-Chart über die letzten 12 Monate.

Warum: Die monatliche Auslastungsplanung unter Berücksichtigung von Urlaub und Krankheit dient der Kontrolle von Personalkosten, der Analyse von Fehlzeitenquoten und als Datengrundlage für Mitarbeitergespräche.

Ergebnis: Eine Monatsübersicht mit Name, Sollstunden, Ist-Stunden, Auslastung in Prozent, Urlaubstagen und Abweichung pro Mitarbeiter. Export als PDF-Report für Personalgespräche ist möglich.

6.2.3 Jahresauslastung und Leistungstrends

Was: Der Benutzer wählt einen Mitarbeiter und Vergleichsjahre aus. Das System aggregiert die monatliche Auslastung pro Jahr und zeigt Tabelle sowie Kurvenverläufe aller Jahre überlagert, inklusive Durchschnittsauslastung und Standardabweichung.

Warum: Die Jahresbetrachtung ermöglicht es, langfristige Leistungstrends zu erkennen (steigend oder fallend), die Mitarbeiterentwicklung nachzuverfolgen und Gehaltserhöhungen oder Beförderungen datengestützt zu begründen.

Ergebnis: Eine Vergleichstabelle mit Monat, Auslastung pro Jahr, Trend und Durchschnitt. Werte unter 80% oder über 120% werden rot markiert, ein Vergleich mit dem Team-Durchschnitt wird angeboten.

6.2.4 Projektauslastung und Team-Kapazität

Was: Der Benutzer filtert nach einem Projekt und erhält eine Übersicht aller zugeordneten Mitarbeiter mit geplanten Stunden (Soll), gebuchten Stunden (Ist), Abweichung und dem prozentualen Anteil der Zeit auf diesem Projekt.

Warum: Die projektbezogene Ressourcenauslastung hilft, Kapazitätsengpässe frühzeitig zu erkennen, Projektpläne realistisch zu gestalten und Ressourcen-Konflikte zwischen parallelen Projekten zu vermeiden.

Ergebnis: Eine Tabelle mit Gesamtauslastung des Projekts als Durchschnitt über alle Team-Mitglieder, Warnung bei Mitarbeitern über 100% Auslastung und einem Trend über die Projektdauer (Ramping-up/down).

6.2.5 Abteilungs-Kapazitätsverlauf

Was: Der Benutzer wählt eine Abteilung (z.B. Entwicklung, Support, Sales) und erhält aggregierte Kennzahlen: Durchschnitts-Auslastung, minimale und maximale Auslastung im Team sowie die Kapazitätsreserve in Stunden, dargestellt als Heatmap pro Mitarbeiter.

Warum: Der Abteilungsüberblick liefert die Datengrundlage, um Neueinstellungen zu begründen, Outsourcing-Bedarf zu erkennen und das Abteilungsbudget realistisch zu planen.

Ergebnis: Ein Dashboard mit Heatmap-Balken pro Mitarbeiter, Trend-Chart über die letzten 6 Monate und Warnung bei kritischer Überauslastung von durchschnittlich über 95%.

6.2.6 Expertisen und Spezialisierungen visualisieren

Was: Der Benutzer filtert nach einer bestimmten Expertise (z.B. Datenbankdesign, UI/UX) und erhält eine Liste aller Mitarbeiter mit dieser Fähigkeit, deren Expertise-Level (Junior/Senior/Lead), aktueller Auslastung und verfügbarer Kapazität.

Warum: Die Skill-Übersicht identifiziert kritische Kompetenzen im Unternehmen und verhindert Single-Points-of-Failure. Engpässe bei Lead-Spezialisten mit über 95% Auslastung werden sichtbar, ebenso Nachfolger in Ausbildung.

Ergebnis: Eine tabellarische Darstellung mit Warnung vor Bottlenecks bei stark ausgelasteten Spezialisten, Anzeige von Junior-Mitarbeitern in Training und Export-Möglichkeit für Trainings- und Succession-Planung.

6.2.7 Überauslastung und Burnout-Risiko erkennen

Was: Das System berechnet pro Mitarbeiter einen Risiko-Score basierend auf Auslastung über 90% in den letzten 3 Monaten, Überstunden über 10 Stunden pro Woche, fehlendem Urlaub seit über 12 Monaten und steigenden Fehlzeiten.

Warum: Durch die präventive Erkennung von Burnout-Risiken können Personalverantwortliche rechtzeitig Gegenmaßnahmen einleiten, bevor Mitarbeiter ausfallen, die Krankheitsrate steigt oder Fluktuation zunimmt.

Ergebnis: Eine Risiko-Kategorisierung in Grün (OK), Gelb (Warnung) und Rot (Kritisch) mit Detailanalyse pro Mitarbeiter, Maßnahmen-Empfehlungen und einem Bericht für Personalleiter und Betriebsrat.

6.2.8 Wissenstransfer und Mentoring-Effektivität

Was: Der Benutzer definiert Mentoring-Pairs (Senior-Junior) und verfolgt über einen Zeitraum Indikatoren wie steigende Junior-Auslastung, sinkende Senior-Auslastung durch erfolgreiche Delegation und sinkende Fehlerquote des Juniors.

Warum: Das Tracking zeigt, ob Mentoring-Initiativen tatsächlich funktionieren, welche Mentorships erfolgreich sind und welche angepasst werden müssen, um Nachwuchsentwicklung gezielt zu optimieren.

Ergebnis: Ein Mentoring-Dashboard mit Verlaufsanzeige pro Pair, Empfehlungen zum Anpassen oder Beenden von Mentorships und Export für die HR-Entwicklungsplanung.

6.3 Management Info

6.3.1 Dashboard mit Echtzeit-Geschäftszahlen öffnen

Was: Die Geschäftsführung öffnet das Management-Info-Dashboard und erhält die wichtigsten Tages-Kennzahlen als große Karten: Tagesverkauf (Euro und Menge), Tagesgewinn, aktive Aufträge, ausstehende Zahlungen, Lagerbestand und Personalkosten mit Vergleich zum Vortag und Vorjahr.

Warum: Der Echtzeit-Überblick ermöglicht schnelle Entscheidungen im Tagesgeschäft, das sofortige Erkennen von Anomalien und die Automatisierung von Tagesrapporten. Alle Zahlen werden alle 5 Minuten automatisch aktualisiert.

Ergebnis: Ein KPI-Dashboard mit Trend-Pfeilen (Vortag/Vorjahr in Prozent) und Durchschnittswerten der letzten 7 und 30 Tage zum Vergleich.

6.3.2 Filialvergleich mit Heatmap-Visualisierung

Was: Der Benutzer betrachtet eine Heatmap, in der die Spalten den Filialen und die Zeilen den KPIs entsprechen. Farbcodierung zeigt: Grün gleich über Plan, Gelb gleich ungefähr Plan, Rot gleich unter Plan. Per Klick auf eine Filiale wird ein Drill-Down zu den Departments dieser Filiale angeboten.

Warum: Der gleichzeitige Vergleich aller Filialen macht Performance transparent, identifiziert Best Practices und ermöglicht ein gezieltes Benchmarking zur Optimierung der Ressourcenallokation.

Ergebnis: Eine farbcodierte Heatmap mit KPIs pro Filiale (Tagesverkauf, Gewinn, Conversion, Durchschnittseinkauf) und Export als PNG oder PDF für Filial-Manager-Meetings.

6.3.3 Materialgruppen-Rentabilität visualisieren

Was: Der Benutzer wählt einen Zeitraum und erhält eine Materialgruppen-Analyse als Tabelle und Balken-Chart, sortiert nach Marge in Prozent. Top 3 und Bottom 3 Gruppen werden grün bzw. rot hervorgehoben, Trend-Pfeile zeigen die Marge im Vergleich zum Vormonat.

Warum: Die Rentabilitätsvisualisierung ermöglicht schnelles Erkennen von Preisschwächen, gezielte Sortimentsoptimierung und strategische Entscheidungen über Delistung oder Fokussierung von Produktgruppen.

Ergebnis: Tabelle und Balken-Chart mit Materialgruppe, verkaufter Menge, Umsatz, Kosten, Gewinn und Marge in Prozent. Klick auf eine Gruppe zeigt die meistverkauften Artikel darin.

6.3.4 Umsatzziele und Abweichungen anzeigen

Was: Das System stellt den aktuellen Umsatzplan (Budget) dem Ist-Umsatz gegenüber, aufgeschlüsselt auf mehreren Ebenen: Gesamt, pro Filiale, pro Team und pro Kategorie. Ein tägliches Fortschrittsdiagramm zeigt Soll-Linie gegen Ist-Linie.

Warum: Die kontinuierliche Überwachung der Umsatzziele erlaubt rechtzeitiges Gegensteuern, wenn der aktuelle Trend vom Plan abweicht, und motiviert Mitarbeiter durch sichtbaren Fortschritt.

Ergebnis: Farbcodierte Darstellung (Grün ab 100% Plan, Gelb 95-99%, Rot unter 95%) mit Trend-Forecast bis Monatsende und Prognose wie "Bei aktuellem Trend erreichen Sie X% des Plans".

6.3.5 Gewinn-Vergleich: Aktuell vs. Plan vs. Vorjahr

Was: Im Dashboard-Bereich "Profitabilität" werden drei Spalten nebeneinander gezeigt: aktueller Monat bisher (Ist), Plan für diesen Monat (Budget-Target) und Vorjahr gleiche Periode. Zu jeder Spalte werden Gewinn in Euro, Gewinnmarge in Prozent und Prognose für den Gesamtmonat angezeigt.

Warum: Der Drei-Spalten-Vergleich erlaubt eine Abweichungs-Analyse nach Volumen, Marge und Kosten, um gezielt Kosteneinsparungen zu priorisieren und den Preis-/Volumen-Mix zu optimieren.

Ergebnis: Eine Vergleichsdarstellung mit Trend-Charts über die letzten 12 Monate und Export für Geschäftsbesprechungen.

6.3.6 Lagerbestands-Wertentwicklung und Verfallsrisiken

Was: Das Dashboard zeigt den Gesamtlagerwert (heute vs. gestern vs. 30-Tage-Durchschnitt), die Top 20 Artikel nach Lagerwert, Slow-Mover (über 180 Tage ohne Verkauf) und einen Verfallsdatum-Kalender für die nächsten 30 und 90 Tage.

Warum: Die Überwachung des Lagervermögens verhindert Vermögensverschwendung, verbessert die Liquidität und erkennt Abschreibungsrisiken frühzeitig. Steigender Lagerwert ohne Verkaufssteigerung wird als Risiko gewarnt.

Ergebnis: Eine Lagerbestandssektion mit Warnungen, Empfehlungen (Abverkauf initiieren, Rückvergütungen prüfen) und Vergleich mit dem budgetierten Lagerwert.

6.3.7 Personalkosten-Analyse (Quotenvergleich)

Was: Das Dashboard zeigt die Personalkosten-Quote (Personalkosten geteilt durch Umsatz) mit Vergleich zu Plan, Branchendurchschnitt und Vorquartalen. Die Aufschlüsselung erfolgt nach Gehalt, Sozialabgaben, Schulung und Sozialleistungen, jeweils pro Filiale und Abteilung.

Warum: Die Quote zeigt, ob Personalkosten im Plan und wirtschaftlich sind. Ein Trend über 12 Monate und ein Forecast bis Jahresende ermöglichen proaktive Steuerung des Personalbudgets und die Erkennung von Überbesetzung.

Ergebnis: Eine Quotendarstellung mit Warnung und Optimierungsvorschlägen bei zu hoher Quote sowie Berechnung der Produktivität pro Mitarbeiter.

6.3.8 Echtzeit-Warnungen und Anomalien-Erkennung

Was: Das System definiert Schwellwerte basierend auf Branchenstandards und löst automatische Warnungen aus, wenn z.B. der Tagesverkauf um mehr als 20% sinkt, die Retourenquote über 5% steigt oder die Fehlerquote im Ticket-System über 10% liegt.

Warum: Automatische Anomalien-Erkennung ermöglicht proaktives statt reaktives Handeln, entlastet die Geschäftsführung von manueller Überwachung und erkennt Risiken frühzeitig.

Ergebnis: Ein Ampel-System (Rot/Gelb/Grün) im Dashboard mit Klick-Drill-Down zur Ursachenanalyse, optionaler E-Mail-/SMS-Benachrichtigung an die Geschäftsführung und einem historischen Warnungs-Log.

6.4 Mitarbeiterauslastung

6.4.1 Tagesübersicht Mitarbeiterkapazität anzeigen

Was: Der Disponent oder Projektleiter öffnet das Mitarbeiterauslastungs-Modul und sieht für jeden Mitarbeiter Name, Abteilung, geplante Stunden, bereits gebuchte Stunden und verbleibende Verfügbarkeit. Status-Icons kennzeichnen: im Urlaub, krank, auswärts oder verfügbar.

Warum: Die Tagesübersicht optimiert die tägliche Ressourcenplanung, ermöglicht die Nutzung verfügbarer Kapazitäten und hilft, kurzfristige Übergangslösungen bei Ausfällen zu finden.

Ergebnis: Eine farbcodierte Liste (Grün: viel frei, Gelb: teilweise ausgelastet, Rot: voll ausgelastet) mit Drag-und-Drop-Möglichkeit zur schnellen Aufgabenzuordnung.

6.4.2 Wochenplanungsmodus mit Auslastungs-Wärmebild

Was: In der Wochenansicht werden Spalten als Tage (Montag bis Freitag) und Zeilen als Mitarbeiter oder Teams dargestellt. Jede Zelle zeigt die Auslastung in Prozent mit Farbcodierung: Blau unter 50%, Grün 50-80%, Gelb 80-100%, Rot über 100%.

Warum: Das Wärmebild gibt den gesamten Wochenüberblick und zeigt, wo Engpässe liegen. Automatische Vorschläge wie "Verschieben Sie Mitarbeiter X von Mittwoch auf Dienstag" helfen bei der proaktiven Optimierung.

Ergebnis: Ein interaktives Wärme-Grid mit Klick auf Zellen für Detailanzeige (welche Projekte/Aufgaben) und Export als Planungsbericht.

6.4.3 Abteilungs-Kapazitätsplanung und Prognose

Was: Der Benutzer wählt eine Abteilung und erhält einen Vergleich von Sollkapazität (Mitarbeiterzahl mal 8 Stunden) mit der verfügbaren Kapazität heute, diese Woche und diesen Monat, gegenüber der geplanten Arbeitslast.

Warum: Die abteilungsbezogene Kapazitätsplanung begründet Personalbedarf, erkennt chronische Überbelastung und liefert einen Forecast auf Basis geplanter Projekte für 3 und 6 Monate im Voraus.

Ergebnis: Eine Kapazitätsdarstellung mit Warnung und Empfehlungen bei Überlast (Zusatzzeit, Outsourcing, Priorisierung), Trend über die letzten 12 Monate und Export für die Budgetplanung.

6.4.4 Urlaubs- und Abwesenheitsplanung

Was: Der Benutzer sieht eine Kalenderansicht mit allen Abwesenheitsarten (Urlaub, Krank, Schulung, Sabbatical) und für jeden Mitarbeiter genehmigte vs. noch verfügbare Urlaubstage.

Warum: Die koordinierte Abwesenheitsplanung vermeidet Urlaubskonflikte, stellt faire Urlaubsverteilung sicher und warnt vor kritischen Engpässen wie z.B. "2 von 3 Spezialisten sind nächste Woche gleichzeitig im Urlaub".

Ergebnis: Eine Kalenderdarstellung mit automatischen Warnungen, Vorschlägen zur Engpass-Vermeidung und einem Urlaubsverteilungsbericht zur Fairness-Prüfung.

6.4.5 Überstunden und Mehrarbeit erfassen und tracken

Was: Das System zeigt pro Mitarbeiter die monatlichen Überstunden (über 8 Stunden pro Tag hinaus), einen Trend über 6 bis 12 Monate und eine Gesamtübersicht, welche Mitarbeiter viele Überstunden leisten.

Warum: Das Tracking dient der Burnout-Prävention, realistischen Personalplanung und der Abrechnung von Überstunden (Freizeitausgleich oder Bezahlung). Warnungen ab 10 Stunden Überstunden pro Woche lösen automatische Benachrichtigungen an den Vorgesetzten aus.

Ergebnis: Eine Überstundenübersicht mit Trend, Warnung bei übermäßiger Mehrarbeit und Report der Überstundenquote gegenüber dem Budget.

6.4.6 Spezialist-Kapazität und kritische Fähigkeiten

Was: Der Benutzer filtert nach Fähigkeiten und erhält Experten dieser Fähigkeit mit Expertise-Level, aktueller Auslastung und verfügbaren Stunden. Warnungen werden angezeigt bei nur einem vorhandenen Experten oder einer Auslastung über 95%.

Warum: Die Identifikation kritischer Spezialisten verhindert Single-Points-of-Failure und ermöglicht eine gezielte Succession-Planung. Es wird sichtbar, welche Juniors als Backup trainiert werden.

Ergebnis: Eine Spezialistenliste mit Warnung vor Risiko-Situationen, Empfehlungen zum Training von Backup-Mitarbeitern und einer Prognose, wie lange Ersatz bei Kündigung eines Experten dauern würde.

6.4.7 Abteilungs-Vergleich und Benchmarking

Was: Das System zeigt einen Side-by-Side-Vergleich mehrerer Abteilungen mit KPIs wie Durchschnittsauslastung, Überstundenquote, Fehlerquote und Produktivität (Output pro Person).

Warum: Das Benchmarking identifiziert Best Practices effizienter Abteilungen und gibt Empfehlungen, wie weniger effiziente Abteilungen deren Planungssysteme übernehmen können. Ein Ranking nach Effizienz wird erstellt.

Ergebnis: Ein Vergleichsreport mit Ranking, Identifikation von Best Practices und Export für Abteilungsleiter-Meetings.

6.4.8 Szenarien-Planung: Was-wenn-Analysen

Was: Der Benutzer simuliert verschiedene Personalszenarien wie "Wenn Mitarbeiter X kündigt", "Wenn 2 neue Projekte starten" oder "Wenn Mitarbeiter Y 3 Monate in Training geht". Das System kalkuliert automatisch die Auswirkungen.

Warum: Was-wenn-Analysen ermöglichen datengestützte Personalentscheidungen, frühzeitige Risikoerkennung und bessere strategische Planung durch Vergleich mehrerer Szenarien parallel.

Ergebnis: Eine Simulationsdarstellung mit neuer Auslastung, Überstundenprognose, gefährdeten Projekten und Lösungsvorschlägen. Export der Analyse für die Entscheidungsfindung.

6.5 MSP-Auswertung

6.5.1 MSP-Lizenz-Datenimport und Vergleich

Was: Der Benutzer importiert Lizenzdaten aus MSP-Plattformen (z.B. Microsoft CSP, AWS, Azure) per CSV, XML oder direkter API-Integration und vergleicht den Lizenzbestand in der MSP-Plattform mit der c-entron-Datenbank.

Warum: Der Vergleich deckt Diskrepanzen auf wie z.B. "In MSP 50 Lizenzen, aber nur 40 in c-entron erfasst" und verhindert Über- oder Unter-Lizenzierung, minimiert Compliance-Risiken und verbessert die Abrechnungsgenauigkeit.

Ergebnis: Eine Vergleichsübersicht mit identifizierten Diskrepanzen, Lizenz-Details (Typ, Laufzeit, Kosten, Nutzerzuordnung) und Empfehlungen zum Abgleich.

6.5.2 Lizenz-Nutzungsvergleich: Soll vs. Ist

Was: Das System zeigt pro Lizenztyp die Anzahl gekaufter vs. tatsächlich genutzter Lizenzen mit Nutzer-Zuordnung. Idle-Lizenzen (gekauft, aber seit über 30 Tagen nicht verwendet) und Übernutzung werden erkannt.

Warum: Die Nutzungsanalyse senkt Lizenzkosten durch Optimierung, identifiziert ungenutzte Lizenzen für die Freigabe und berechnet den ROI pro Lizenztyp. Der Langzeittrend zeigt, ob die Lizenznutzung steigt oder fällt.

Ergebnis: Eine Übersicht mit Empfehlungen wie "Geben Sie 10 Office-Lizenzen frei, diese werden nicht genutzt" mit monatlicher Ersparnis.

6.5.3 Kostenvergleich und Budget-Planung

Was: Das Dashboard zeigt das monatliche Lizenz-Budget gegenüber den aktuellen Ausgaben, detailliert nach Lizenz-Kategorie (Office, ERP, Cloud etc.) mit Vergleich zu Vormonaten und einem 12-Monats-Trend-Chart.

Warum: Die Kostenkontrolle vermeidet Budget-Überraschungen und unterstützt Vertragsverhandlungen. Ein Forecast zeigt die prognostizierten Gesamtkosten am Jahresende und warnt bei drohendem Budget-Überschuss.

Ergebnis: Eine Budgetdarstellung mit Warnung bei Trendüberschreitung, Maßnahmen-Empfehlungen (Anzahl reduzieren, günstigerer Anbieter, Bundling-Rabatte) und CFO-Report-Export.

6.5.4 Service-Level und Performance-Metriken

Was: Das System importiert Verfügbarkeitsdaten vom MSP-Provider und zeigt Uptime in Prozent, SLA-Ziele (z.B. 99,9%), tatsächliche Verfügbarkeit, Ausfallzeiten-Analyse und eine Bewertung der Provider-Leistung.

Warum: Die Service-Level-Überwachung kontrolliert die Dienstqualität des MSP-Providers, dokumentiert SLA-Verletzungen und berechnet zustehende Service-Credits. Die Ergebnisse bilden die Grundlage für Vertragsverhandlungen.

Ergebnis: Eine Bewertung in Grün (über 99%), Gelb (95-99%), Rot (unter 95%) mit Incident-Historie, Credit-Berechnung und Report für Vertragsverhandlungen.

6.5.5 Multi-Provider-Vergleich

Was: Der Benutzer zeigt mehrere Provider-Quellen an (z.B. Microsoft, AWS, Google Cloud). Das System normalisiert die Daten und macht sie vergleichbar in einer Tabelle mit Lizenztyp, Kosten, Verfügbarkeit, Support und Vertragsbedingungen.

Warum: Der normalisierte Vergleich der Gesamtkosten (TCO Total Cost of Ownership) stärkt die Verhandlungsposition und ermöglicht kostenoptimierte Entscheidungen über Provider-Wechsel.

Ergebnis: Ein Ranking der Provider nach Kosteneffizienz, Szenarien-Rechnung "Was kostet Migration zu Provider X?" und Export für Einkaufsentscheidungen.

6.5.6 Compliance und Lizenz-Audit

Was: Das System prüft gekaufte Lizenzen gegen tatsächliche Nutzer und Installationen, warnt bei Übernutzung (Compliance-Risiko) und bei verfallenen oder ungültigen Lizenzen. Änderungen an Lizenz-Zuordnungen werden lückenlos getrackt.

Warum: Lizenzverstöße können zu empfindlichen Bußgeldern führen. Der Compliance-Bericht vereinfacht Audit-Prozesse und dokumentiert Nachweise für externe Prüfungen.

Ergebnis: Ein Compliance-Bericht mit Dokumentation (wer hat welche Lizenz, seit wann, bis wann gültig), Audit-Trail und Empfehlungen zur Risikominderung.

6.6 MSP-Collector

6.6.1 MSP-Daten-Import aus verschiedenen Quellen

Was: Der Benutzer wählt eine Datenquelle (Microsoft CSP, AWS, Google Cloud oder manuelles CSV/XML-Upload), definiert das Mapping der Spalten zu c-entron-Feldern und führt den Import durch. Das System validiert auf Duplikate, ungültige Formate und fehlende Felder.

Warum: Die automatisierte Normalisierung und der Import von Lizenzdaten aus verschiedenen Plattformen eliminieren manuelle Dateneingabe und reduzieren Fehlerquoten erheblich.

Ergebnis: Eine Import-Zusammenfassung mit Angaben zu neuen, aktualisierten und fehlerhaften Lizenzen sowie die Möglichkeit, den Import zu bestätigen oder zurückzuweisen.

6.6.2 Artikel-Referenzen und Verknüpfungen

Was: Nach dem Import zeigt das System pro MSP-Lizenz ähnliche c-entron-Artikel an. Der Benutzer ordnet manuell zu oder nutzt Algorithmus-Vorschläge. Die Zuordnung wird für zukünftige Importe gespeichert.

Warum: Die korrekte Zuordnung zwischen MSP-Lizenzen und c-entron-Artikeln ist Voraussetzung für eine präzise Abrechnung und konsistentes Reporting über alle Systeme hinweg.

Ergebnis: Eine Artikel-Zuordnungsansicht mit Algorithmus-Vorschlägen, gespeichertem Mapping und Report über noch nicht zugeordnete MSP-Lizenzen.

6.6.3 Kundliche Verknüpfungen und Organisationen

Was: Der Benutzer ordnet MSP-Datensätze den entsprechenden c-entron-Kunden zu, entweder manuell oder per Algorithmus-Vorschlag. Warnungen werden bei fehlender Zuordnung angezeigt.

Warum: Die Kundenzuordnung ist Voraussetzung für eine korrekte Kunden-Abrechnung und ermöglicht transparente Auswertungen der Lizenznutzung pro Kunde.

Ergebnis: Eine Kunden-Zuordnungsansicht mit Warnungen bei nicht zugeordneten Datensätzen, Reports zur Customer-Usage und Export für die Kundenabrechnung.

6.6.4 MSP-Reports und Datenansichten

Was: Das System bietet vordefinierte Reports zu Lizenz-Typ nach Anzahl/Kosten, Top-Kunden nach Lizenzvolumen, Lizenz-Trend über Monate, ungemappte Datensätze und Import-Fehler. Jeder Report hat Filter-Optionen und Drill-Down-Möglichkeiten.

Warum: Die automatisierten Reports schaffen Transparenz über das MSP-Portfolio, ermöglichen Management-Reporting und helfen, Abweichungen schnell zu erkennen.

Ergebnis: Diagramme und Tabellen mit Export in Excel, PDF und CSV sowie Möglichkeit, Reports automatisch per E-Mail zu versenden.

6.6.5 Import-Fehlerbehandlung und Validierung

Was: Während des Imports führt das System Validierungen durch (Pflichtfelder, Datentypen, Duplikate, Wertebereiche). Fehler werden gesammelt und dem Benutzer zur Inline-Korrektur angezeigt, um den Import erneut zu versuchen.

Warum: Systematische Fehlerbehandlung stellt die Datenqualität sicher, deckt fehlerhafte Prozesse bei Lieferanten auf und reduziert manuellen Nacharbeitsaufwand.

Ergebnis: Ein Fehler-Report mit Klassifizierung, Inline-Korrekturmöglichkeit, konfigurierbaren Validierungsregeln und Option zum Rollback bei zu vielen Fehlern.

6.6.6 Datenquelle Konfiguration und Verbindung

Was: Der Administrator konfiguriert MSP-Datenquellen mit API-Key, Tenant-ID, Credentials und Endpoint, testet die Verbindung und richtet automatische Import-Zeitpläne (täglich, wöchentlich) ein.

Warum: Die zentrale Verwaltung der Datenquellen ermöglicht vollautomatisierte Importe ohne manuellen Aufwand. Fehler-Benachrichtigungen bei fehlgeschlagenen Auto-Importen informieren den Administrator sofort.

Ergebnis: Eine konfigurierte Datenquelle mit Verbindungstest, automatischem Import-Zeitplan, Fehler-Benachrichtigungssystem und Verbindungs-Historie.

6.7 MSP-Dashboard

6.7.1 MSP-Leistungs-Dashboard öffnen

Was: Die Geschäftsführung öffnet das MSP-Dashboard und erhält Top-Level KPIs: MSP-Gesamtumsatz diesen Monat (in Euro und Trend), Anzahl aktiver Lizenzen/Services, durchschnittliche Lizenzkosten, Kundenzahl mit MSP-Services und Durchschnittsmarge.

Warum: Das Dashboard gibt einen schnellen Überblick über den MSP-Geschäftsbereich, zeigt ob das MSP-Business wächst oder schrumpft und ermöglicht datengestützte Entscheidungen.

Ergebnis: Ein KPI-Dashboard mit Vergleich zu Budget und Vormonat, 12-Monats-Trend-Charts und Auto-Refresh alle 10 Minuten.

6.7.2 Drill-Down nach Kunden

Was: Der Benutzer klickt auf die "Top-Kunden"-Sektion und sieht die Top-20 Kunden nach MSP-Umsatz mit Lizenzanzahl, monatlichem Umsatz, Marge und Trend. Per Klick auf einen Kunden wird eine Detailansicht mit Services, Zahlungshistorie und Service-Level geöffnet.

Warum: Die kundenspezifische Analyse hilft, Problemkunden schnell zu identifizieren, Up-Sell-Chancen zu erkennen und den Kundenservice gezielt zu verbessern.

Ergebnis: Eine Kunden-Detailansicht mit Lizenz-Details, Zahlungshistorie, Service-Level und Kontaktdaten sowie Export als Kundenbericht.

6.7.3 Service-Performance und Verfügbarkeit

Was: Das Dashboard zeigt die Service-Performance: Gesamtverfügbarkeit in Prozent (Ziel 99,9%), Incident-Anzahl dieser Woche, mittlere Lösungszeit (MTTR) und Kundenzufriedenheit als Durchschnittsbewertung.

Warum: Die Überwachung der Service-Qualität stellt Compliance mit SLA-Vereinbarungen sicher, verhindert finanzielle Strafen bei Unterschreitung und bewahrt das Kundenvertrauen.

Ergebnis: Ein 12-Monats-Trend (wird Service besser oder schlechter?), Vergleich mit SLA-Vereinbarung und Alarm bei Verfügbarkeit unter 99%.

6.7.4 Profitabilität nach Service-Typ

Was: Das Dashboard zeigt Umsatz, Kosten, Gewinn und Marge in Prozent pro Service-Kategorie mit Farbcodierung: Grün über 25% Marge, Gelb 15-25%, Rot unter 15%. Top-3 und Bottom-3 Services werden identifiziert.

Warum: Die Service-Profitabilitätsanalyse erkennt unrentable Services und liefert Empfehlungen wie "Preis anheben oder einstellen". Der Portfolio-Mix kann gezielt optimiert werden.

Ergebnis: Eine Tabelle mit Trend-Chart über 12 Monate, Identifikation der profitabelsten und unrentabelsten Services und Handlungsempfehlungen.

6.7.5 Wachstums-Analyse und Prognose

Was: Das System zeigt Wachstumsmetriken: Umsatz-Wachstum in Prozent gegenüber Vorjahr, neue Kunden pro Monat, Churn-Rate und Net-New-ARR (Annual Recurring Revenue). Szenarien werden als Best-Case, Worst-Case und Most-Likely berechnet.

Warum: Die Wachstumsanalyse bildet die Grundlage für strategische Planung, Investitionsentscheidungen und Personalplanung im MSP-Bereich. Wachstums-Treiber werden identifiziert.

Ergebnis: Eine Trend-Extrapolation für 6 und 12 Monate, Branchen-Benchmark und Empfehlungen zur Beschleunigung des Wachstums.

6.7.6 Ressourcen-Auslastung im MSP-Team

Was: Das Dashboard zeigt die Auslastung des MSP-Support-Teams: Tickets pro Mitarbeiter, Durchschnitts-Bearbeitungszeit, offene Tickets und Überstundenquote, jeweils mit Farbcodierung (Grün unter 80%, Rot über 100%).

Warum: Die Team-Auslastungsanalyse zeigt, ob das Support-Team angemessen besetzt ist, und liefert einen Forecast, wie viele Mitarbeiter bei gleicher Ticket-Rate fehlen. Steigende MTTR signalisiert Überlastung.

Ergebnis: Eine Auslastungsdarstellung pro Mitarbeiter mit Forecast, Trend und Empfehlungen (Neueinstellung, Automatisierung, Outsourcing).

6.7.7 Lizenz-Optimierungs-Opportunities

Was: Das System scannt nach Einspar-Potenzial: Kunden mit hoher Lizenzquote, ungenutzten Lizenzen, alten Verträgen mit Neuverhandlungspotenzial und Bundle-Möglichkeiten. Pro Opportunity wird das Einspar-Potenzial in Euro berechnet.

Warum: Systematisches Erkennen von Optimierungsmöglichkeiten verbessert die Kosteneffizienz, erhöht Margen und liefert konkrete Action-Items für das Vertragsmanagement.

Ergebnis: Eine priorisierte Liste mit Einspar-Potenzial, konkreten Handlungsanweisungen und Tracking, welche Opportunities bereits umgesetzt wurden.

6.7.8 Alerts und Eskalationen

Was: Das System definiert Eskalationsregeln: Verfügbarkeit unter 95%, Incident-Response über 4 Stunden, Zahlungsausfallrisiko über 30 Tage, Umsatzabweichung über 20% gegenüber Budget. Alerts werden prominent im Dashboard angezeigt.

Warum: Automatische Alerts und mehrstufige Eskalation (nach X Stunden nächste Ebene) ermöglichen proaktives Management kritischer MSP-Ereignisse und schnellere Problemlösung.

Ergebnis: Dashboard-Alerts mit automatischer E-Mail-/SMS-Benachrichtigung an Manager, Eskalations-Kette und Alert-History für Trendanalyse.

6.8 Vertragsauswertung

6.8.1 Vertrags-Status-Übersicht

Was: Der Benutzer öffnet die Vertragsauswertung und sieht eine Tabelle mit Vertragsnummer, Kunde, Laufzeit, Status, monatlichen Gebühren, Abrechnungsrhythmus und nächstem sowie letztem Abrechnungsdatum. Filter nach Status, Kunde und Abrechnungstyp sind verfügbar.

Warum: Die Übersicht aller Verträge verhindert das Vergessen von Ablaufterminen, ermöglicht schnelles Auffinden fehlerhafter Verträge und bietet Kontrolle über das gesamte Vertragsportfolio.

Ergebnis: Eine farbcodierte Tabelle: Grün (aktiv, korrekt), Gelb (bald auslaufend), Rot (abgelaufen oder fehlerhaft) mit Klick-Drill-Down zu Vertragsdetails.

6.8.2 Automatische Abrechnungs-Kontrolle

Was: Das System vergleicht Verträge mit tatsächlich gestellten Rechnungen. Pro Vertrag wird geprüft, ob die nächste Rechnung fristgerecht gestellt wurde und ob der Rechnungsbetrag mit dem Vertragsbetrag übereinstimmt.

Warum: Die automatische Kontrolle reduziert Abrechnungsfehler, verhindert Umsatzverluste durch vergessene Rechnungen und zeigt, welche Verträge häufig falsch abgerechnet werden.

Ergebnis: Warnungen bei fehlenden Rechnungen und Betragsabweichungen, Fehler-Häufigkeitsanalyse und Empfehlung zur Aktivierung automatischer Abrechnung für korrekte Verträge.

6.8.3 Vertrags-Abrechnungs-Analyse

Was: Das System berechnet die prognostizierten monatlichen Einnahmen aus allen Verträgen unter Berücksichtigung der Laufzeiten und bereits auslaufender Verträge (Churn) und vergleicht die Prognose mit den tatsächlichen Einnahmen.

Warum: Die Revenue-Prognose ermöglicht eine datengestützte Finanzplanung, vermeidet Überraschungen beim Cash-Flow und identifiziert Anomalien in den Einnahmen.

Ergebnis: Eine Prognose für die nächsten 3, 6 und 12 Monate mit Soll-Ist-Vergleich, Anomalien-Erkennung und Bewertung der Forecast-Genauigkeit.

6.8.4 Vertrags-Laufzeitverwaltung und Renewals

Was: Ein Renewal-Calendar zeigt Verträge sortiert nach Ablaufdatum mit Warnungen 90 und 30 Tage vor Ablauf. Pro ablaufendem Vertrag werden Kunde, Vertragswert und eine prognostizierte Renewal-Wahrscheinlichkeit angezeigt.

Warum: Rechtzeitige Kontaktaufnahme zur Vertragsverlängerung verhindert Kundenabgang, sichert Umsätze und minimiert die Churn-Rate. Frühes Handeln (90 Tage vorher) erhöht die Renewal-Quote.

Ergebnis: Ein Renewal-Calendar mit Action-Items ("Kontaktieren Sie Kunde X"), historischer Churn-Analyse und Empfehlung zum frühzeitigen Start der Renewal-Gespräche.

6.8.5 Vertrags-Abweichungs-Analyse

Was: Das System vergleicht die vertragliche Leistungszusage mit der tatsächlich erbrachten Leistung und identifiziert Abweichungen wie z.B. "24/7 Support vereinbart, aber nur Montag bis Freitag erbracht" oder "99,9% Verfügbarkeit vereinbart, aber nur 97% erreicht".

Warum: Die Abweichungsanalyse zeigt Risiken für Strafzahlungen und Reputationsverlust und liefert die Grundlage für Entscheidungen: Service verbessern oder Vertrag anpassen.

Ergebnis: Eine Liste von Abweichungen mit Auswirkung auf den Gewinn, Priorisierung nach Kritikalität, Maßnahmen-Empfehlungen und Tracking der Umsetzung.

6.8.6 Kundenspezifische Verträge und Multi-Contract-Management

Was: Der Benutzer filtert nach einem Kunden und sieht alle Verträge dieses Kunden, den Portfolio-Gesamtwert und Cross-Vertrag-Analysen: Redundanzen, Bundle-Opportunities und Upsell-Potential.

Warum: Die konsolidierte Kundensicht maximiert den Customer-Lifetime-Value, identifiziert Bundling-Rabatt-Möglichkeiten und erkennt frühzeitig Churn-Risiken.

Ergebnis: Ein Customer-Portfolio-Report mit Portfolio-Wert, Redundanz-Erkennung, Upsell-Möglichkeiten und Churn-Risk-Bewertung für Account-Manager.

6.8.7 Gewinn-Optimierung und Preis-Analyse

Was: Das System berechnet pro Vertrag den Gewinn (Einnahmen minus direkte und indirekte Kosten), die Gewinnmarge in Prozent und erstellt ein Ranking der profitabelsten und unrentabelsten Verträge.

Warum: Die Gewinnanalyse identifiziert Verträge mit unter 5% Marge oder negativem Ergebnis und liefert Empfehlungen: Preiserhöhung bei Renewal, Kosten senken oder Vertrag kündigen.

Ergebnis: Ein Vertrags-Ranking (Top-20 profitabelste, Top-20 unrentabelste) mit Kostenaufschlüsselung, Preis-Empfehlungen und Szenarien-Rechnung.

6.8.8 Abrechnungs-Automatisierung und Fehlerfreie Fakturierung

Was: Der Administrator konfiguriert pro Vertrag Abrechnungsregeln (Rhythmus, Betrag, Bedingungen, Rechnungs-Template und Empfänger). Das System führt die automatische Abrechnung durch, prüft vor Rechnungsstellung die Übereinstimmung mit dem Vertrag und sendet Rechnungen automatisch.

Warum: Die vollständige Automatisierung der Vertragsabrechnung eliminiert manuellen Aufwand, reduziert Abrechnungsfehler auf nahezu null und beschleunigt den Cash-Flow durch schnellere Rechnungsstellung.

Ergebnis: Automatisch generierte und versandte Rechnungen, Fehler-Handling mit Admin-Benachrichtigung bei Fehlschlag und Reporting der Abrechnungs-Fehlerquote.

7. Einkauf

7.1 Belegerfassung

7.1.1 Lieferantenbeleg scannen und einlesen

Was: Der Benutzer scannt Papierbelege (Rechnungen, Lieferscheine, Begleitzettel) über einen Multi-Page-Scanner. Das System führt eine optische Zeichenerkennung (OCR) durch und extrahiert automatisch Lieferantennummer, Rechnungsnummer, Betrag und Datum.

Warum: Die OCR-Digitalisierung reduziert die manuelle Dateneingabe um bis zu 80%, senkt die Fehlerquote und verkürzt die Verarbeitungszeit pro Beleg von Minuten auf Sekunden.

Ergebnis: Vorausgefüllte Eingabefelder mit den extrahierten Daten, der gescannte Beleg als digitales Attachment und ein papierloses Archiv.

7.1.2 Automatisch extrahierte Daten validieren und korrigieren

Was: Das System zeigt eine Scan-Vorschau mit den extrahierten Feldern und einem Vertrauens-Score pro Feld. Bei niedriger Konfidenz wird der Benutzer zur manuellen Korrektur aufgefordert. Korrekturen fließen als Training in das OCR-System zurück.

Warum: Die Validierung mit Vertrauens-Score stellt sicher, dass nur korrekte Daten übernommen werden. Durch das lernende OCR-System verbessern sich zukünftige Extraktionen kontinuierlich.

Ergebnis: Validierte und ggf. korrigierte Belegdaten mit Markierung der korrigierten Felder und steigender Erkennungsgenauigkeit über die Zeit.

7.1.3 Beleg mit Bestellung abgleichen

Was: Das System sucht automatisch über Lieferantennummer und Rechnungsnummer nach einer passenden Bestellung und führt einen Mengen- und Preisvergleich durch. Abweichungen werden gekennzeichnet und lösen Genehmigungsprozesse aus.

Warum: Der automatische 3-Way-Match (Bestellung, Rechnung, Wareneingang) vermeidet Doppelzahlungen, wendet Lieferantenrabatte automatisch an und beschleunigt die Rechnungsfreigabe erheblich.

Ergebnis: Eine verknüpfte Beleg-Bestell-Zuordnung mit Abweichungsanzeige (Überlieferung, Preisdifferenz) und automatischer Weitergabe an den Genehmigungsworkflow.

7.1.4 Rechnungen mit automatischer Kategorisierung

Was: Das System gleicht Rechnungspositionen mit dem Lagerkatalog ab, identifiziert Serviceleistungen und schlägt Kostenstellen und Sachkonten automatisch vor. Der Benutzer validiert oder passt die Kategorisierung an.

Warum: Die automatische Zuordnung von Positionen zu Kostenstellen und Konten beschleunigt die Rechnungsverarbeitung und ermöglicht automatische Buchungen mit geringerer Fehlerquote bei der Kategorisierung.

Ergebnis: Kategorisierte Rechnungspositionen mit Sachkonto-Zuordnung, bereit für die Rechnungsfreigabe und automatische Verbuchung.

7.1.5 Duplikate erkennen und zusammenführen

Was: Bei jedem neuen Beleg prüft das System auf Duplikate anhand von Lieferant, Rechnungsnummer und Betrag. Bei Verdacht wird eine Warnung mit dem bereits erfassten Beleg angezeigt. Falls bereits bezahlt, wird die Kreditorenbuchhaltung benachrichtigt.

Warum: Die automatische Duplikat-Erkennung verhindert Doppelzahlungen und stellt sicher, dass eine bereits bezahlte Rechnung nicht erneut angewiesen wird.

Ergebnis: Warnung bei verdächtigen Duplikaten mit Option zur Prüfung, Markierung als Duplikat oder Bestätigung als neuer Beleg und vollständiger Audit-Trail.

7.1.6 Beleg-Workflow und Genehmigung

Was: Der erfasste Beleg durchläuft einen definierten Statusfluss: Erfasst, Validiert, Abgeglichen, Genehmigt, Gebucht. Jede Stufe hat einen oder mehrere Genehmiger (Sachbearbeiter, Abteilungsleiter, Controller), die den Beleg mit Scan, extrahierten Daten und Abweichungen sehen.

Warum: Die mehrstufige Genehmigungskette stellt Compliance-konforme Freigabe sicher, dokumentiert jeden Schritt lückenlos im Audit-Trail und automatisiert nach finaler Genehmigung die Buchung und Zahlungserinnerung.

Ergebnis: Ein freigegebener und automatisch in die Buchhaltung gebuchter Beleg mit vollständiger Genehmigungshistorie und automatisch generierter Zahlungserinnerung.

7.2 Bestellvorschlagsliste

7.2.1 Bestellvorschläge automatisch generieren

Was: Das System berechnet für jede Artikel-Lieferant-Kombination die optimale Bestellmenge basierend auf aktuellem Lagerbestand, durchschnittlichem Verbrauch der letzten Monate, Wiederbeschaffungszeit, Sicherheitsbestand und Mindestbestellmenge.

Warum: Die automatisierte Berechnung nach dem Economic-Order-Quantity-Prinzip macht manuelle Bestellplanung überflüssig, optimiert Lagerbestände und senkt die Kapitalbindung.

Ergebnis: Eine Liste generierter Bestellvorschläge mit Artikel, Bestand, Lieferant, vorgeschlagener Menge und Filtermöglichkeiten (z.B. nur kritische Artikel).

7.2.2 Bestellvorschläge prüfen und anpassen

Was: Der Benutzer öffnet die generierten Vorschläge in einer Grid-Ansicht und kann Mengen erhöhen oder senken, Lieferanten wechseln oder Artikel aus der Liste entfernen. Das System berechnet die Auswirkungen auf Lagerkosten und Lagerdauer und warnt bei großen Abweichungen vom Systemvorschlag.

Warum: Die manuelle Prüfung integriert Benutzerexpertise und besondere Situationen (z.B. geplante Kampagnen) in den automatischen Vorschlag und verbessert so die Bestellgenauigkeit.

Ergebnis: Angepasste und gespeicherte Bestellvorschläge mit Abweichungsdokumentation und Berücksichtigung von Rabatten und Skonti.

7.2.3 Bestellvorschläge in Bestellungen umwandeln

Was: Der Benutzer wählt genehmigte Vorschläge aus und konvertiert sie in verbindliche Bestellungen. Das System validiert Lieferant, Artikel und Budget, erstellt pro Lieferant eine Bestellung mit automatischen Konditionen und berechnet das Lieferdatum basierend auf der Wiederbeschaffungszeit.

Warum: Die Konvertierung beschleunigt die Bestellungserstellung von Stunden auf Minuten, sorgt für realistische Lieferdaten und nutzt automatisch die besten Lieferantenkonditionen.

Ergebnis: Erstellte Bestellungen im Status Entwurf, bereit zur Prüfung und Freigabe an den Lieferanten.

7.2.4 Lieferanten und Preismatrix verwenden

Was: Das System nutzt eine Preismatrix pro Artikel-Lieferant mit Mengen-Rabatten, lieferzeitabhängigen Preisen und saisonalen Preisen, um automatisch die beste Kombination aus Preis, Rabatt, Lieferdauer und Zuverlässigkeit zu wählen.

Warum: Die automatische Lieferantenoptimierung nutzt die Konkurrenz zwischen Lieferanten, minimiert die Gesamtkosten (TCO) und stärkt die Verhandlungsposition.

Ergebnis: Optimale Lieferantenauswahl mit angezeigten Alternativen, konfigurierbaren Vorzugslieferanten und Dokumentation jedes Lieferanten-Wechsels.

7.2.5 Bestellvorschläge-Report und Analytics

Was: Das System bietet Reports zu Bestellvolumen nach Lieferant, Kostenentwicklung durch Bestellvorschläge, Lagerbestandsoptimierung und Lieferanten-Diversifizierung mit Diagrammen, Tabellen und Trend-Berechnung.

Warum: Die Analysen liefern Daten für strategische Einkaufsentscheidungen, genauere Budgetplanung und optimiertes Lieferantenmanagement.

Ergebnis: Reports mit Trend-Angaben (z.B. "Bestellvolumen steigt um 15%") in Excel und PDF, optional als Scheduled Reports automatisch per E-Mail versendbar.

7.2.6 Bestellvorschläge-Verwerfung und Archivierung

Was: Der Benutzer markiert einen Vorschlag als "Verwerfen" und gibt einen Grund ein (z.B. "Artikel veraltet", "Lieferant nicht verfügbar"). Verworfene Vorschläge werden in eine separate Ansicht verschoben und nach 30 Tagen automatisch archiviert.

Warum: Die strukturierte Verwerfung mit Begründung verhindert Systemüberlastung mit veralteten Vorschlägen und liefert durch Analyse der Verwerfungsgründe wertvolle Einblicke für Prozessverbesserungen.

Ergebnis: Archivierte Vorschläge im Nur-Lese-Modus mit Report über Verwerfungsquote und -gründe. Audit-Trail bleibt erhalten.

7.3 EDI-Verwaltung

7.3.1 EDI-Beleg empfangen und importieren

Was: Das System empfängt elektronische Lieferantendokumente automatisch per FTP, E-Mail oder Portal, erkennt das EDI-Format (OpenTrans, ZUGFeRD, proprietär), validiert die Dateistruktur und gleicht den Beleg mit der entsprechenden Bestellung ab.

Warum: Die automatische EDI-Verarbeitung eliminiert manuelles Kopieren, senkt Fehlerquoten drastisch und stellt Lieferantendokumente sofort nach Empfang zur Verarbeitung bereit.

Ergebnis: Importierter EDI-Beleg mit Status (erfolgreich, teilweise, Fehler), Bestellabgleich und dokumentiertem Import-Log für den Audit.

7.3.2 EDI-Rechnungen verarbeiten und buchen

Was: Das System führt einen automatischen 3-Way-Match durch (Bestellung, EDI-Rechnung, Wareneingang), extrahiert Rechnungsdaten und bucht gültige Rechnungen automatisch in die Buchhaltung. Bei Abweichungen unter einem konfigurierten Limit erfolgt automatische Freigabe.

Warum: Die vollautomatische Rechnungsverarbeitung eliminiert manuelle Dateneingabe, erreicht eine Fehlerquote nahe null und verkürzt den Buchungszyklus von Tagen auf Stunden.

Ergebnis: Automatisch gebuchte Rechnungen mit terminierter Zahlung basierend auf Zahlungsbedingungen. Größere Abweichungen werden zur manuellen Überprüfung markiert.

7.3.3 EDI-Bestellbestätigungen verarbeiten

Was: Das System empfängt EDI-Bestellbestätigungen, extrahiert die bestätigten Mengen und Lieferdaten und gleicht diese mit der gesendeten Bestellung ab. Abweichungen (Teilbestätigung, verzögertes Lieferdatum) werden erkannt und der Bestellstatus wird aktualisiert.

Warum: Die automatische Verarbeitung von Bestellbestätigungen erhöht Bestätigungsquoten, macht die Lieferplanung genauer und erkennt Überraschungslieferungen oder Verspätungen frühzeitig.

Ergebnis: Aktualisierter Bestellstatus (Bestellt zu Bestätigt), Alert an Einkaufsmanagement bei Abweichungen und Berücksichtigung der bestätigten Lieferdaten in der Verfügbarkeitsplanung.

7.3.4 Lieferanten-spezifische EDI-Integrationen verwalten

Was: Der Administrator konfiguriert pro Lieferant (ALSO, Alltron, Komsa etc.) das EDI-Format, den Übertragungskanal (FTP, E-Mail, API), den Zeitplan und die Authentifizierung. Neue Lieferanten können schnell integriert und Verbindungen getestet werden.

Warum: Die standardisierte Multi-Lieferant-EDI-Konfiguration ermöglicht konsistente Fehlerbehandlung und dokumentierte Compliance. Neue Lieferanten lassen sich schnell anbinden.

Ergebnis: Konfigurierte EDI-Lieferanten mit getesteter Verbindung, automatischem Übertragungsplan und konsistenter Fehlerbehandlung.

7.3.5 EDI-Fehler und Abweichungen handling

Was: Bei EDI-Fehlern (Parser-Fehler, Formatfehler) speichert das System die fehlgeschlagene Datei, dokumentiert den Fehler im EDI-Log, benachrichtigt den Administrator und versucht automatische Fehlerbehebung (alternative Parser, Warnings ignorieren).

Warum: Systematische Fehlerbehandlung minimiert die EDI-Fehlerquote, reduziert manuellen Aufwand und informiert Lieferanten über chronische Probleme durch Eskalation.

Ergebnis: Fehler-Report mit Quote fehlgeschlagener Importe pro Lieferant, Korrekturmöglichkeit mit erneutem Import und Rollback-Option bei zu vielen Fehlern.

7.3.6 EDI-Bestätigung und Reporting

Was: Nach erfolgreicher EDI-Verarbeitung generiert das System Empfangsbestätigungen (APERAK) an den Lieferanten. Ein Performance-Report zeigt Metriken wie Anzahl Belege pro Tag, Erfolgsquote und durchschnittliche Verarbeitungszeit pro Lieferant.

Warum: Empfangsbestätigungen und Performance-Reports machen die Lieferantenqualität transparent und liefern die Datengrundlage für Lieferantenoptimierung.

Ergebnis: Versendete Empfangsbestätigungen, Lieferantenvergleich (z.B. "ALSO: 99,5% vs. Alltron: 98,2%") und Export der Reports per E-Mail oder manuell.

7.4 Eingang/Kalkulation

7.4.1 Wareneingang erfassen

Was: Der Benutzer gibt die Bestellnummer ein oder scannt einen Barcode. Das System lädt die bestellten Artikel und der Benutzer erfasst pro Artikel die eingegangene Menge und den Lagerlocation. Abweichungen (Überlieferung, Fehlmengen, Beschädigungen) werden automatisch markiert.

Warum: Die strukturierte Wareneingangserfassung hält Lagerbestände in Echtzeit aktuell, erkennt Abweichungen sofort und triggert bei Unterlieferung automatische Nachbestellungen.

Ergebnis: Gebuchter Wareneingang mit aktualisiertem Lagerbestand, Abweichungsdokumentation und Aktualisierung des Bestellsystems.

7.4.2 Preis-Kalkulation und Kostenübernahme

Was: Das System zeigt eine Kostenaufschlüsselung (Brutto-Materialkosten, Transport, Versicherung, Zölle) und kalkuliert automatisch den Einstandspreis pro Artikel. Der Benutzer kann zwischen Kalkulationsmethoden wählen: Durchschnitt, FIFO oder LIFO.

Warum: Die präzise Einstandspreiskalkulation unter Berücksichtigung aller Nebenkosten stellt korrekte Lagerbewertung sicher, ermöglicht realistische Gewinnmargenberechnung und erzeugt korrekte Finanzbuchungen.

Ergebnis: Kalkulierte und gespeicherte Einstandspreise, aktualisierte Lagerbewertung basierend auf der gewählten Methode und automatisch erstellte Finanzbuchungen für Materialkosten.

7.4.3 Annahmeprüfung und Qualitätskontrolle

Was: Der Prüfer führt nach dem Wareneingang eine Sichtprüfung durch (Verpackung, sichtbare Beschädigungen, Verfallsdatum). Bei Auffälligkeiten wird ein Mangelbeleg mit Beschreibung, Fotos und Schweregrad erstellt. Das System erzeugt automatisch einen RMA- oder Gutschrift-Vorschlag.

Warum: Die Qualitätskontrolle dokumentiert Lieferantenqualität, leitet Rücklieferungen schnell ein und ermöglicht gezielte Optimierung der Lieferantenwahl auf Basis der Mängelquoten.

Ergebnis: Dokumentierter Qualitäts-Report mit akzeptierten oder abgelehnten Waren, Quarantäne-Verschiebung bei Ablehnung und automatischem RMA-Vorschlag.

7.4.4 Rechnungsabgleich und Diskrepanzbehandlung

Was: Das System führt einen 3-Way-Match durch (Bestellung: Soll-Menge/Preis, Wareneingang: Ist-Menge/Zeitpunkt, Rechnung: Rechnungsmenge/Preis) und klassifiziert Diskrepanzen als automatisch auflösbar (z.B. Rundungsfehler) oder manuell zu klären.

Warum: Der automatische Dreifach-Abgleich garantiert Rechnungskorrektheit, verhindert Doppelzahlungen und minimiert Streitfälle mit Lieferanten.

Ergebnis: Freigegebene Rechnungen zur Bezahlung bei Übereinstimmung, oder Benachrichtigung an den Benutzer bei Diskrepanzen mit Optionen zum Akzeptieren, Ablehnen oder Klären.

7.4.5 Varianten und Austausch-Artikel handhaben

Was: Bei Lieferung eines abweichenden Artikels (Variante oder Austausch) zeigt das System einen Abweichungsdialog mit Optionen: Variante akzeptieren mit Preisanpassung, ablehnen mit RMA-Erstellung oder als Alternative buchen.

Warum: Die flexible Handhabung von Lieferabweichungen löst kleine Abweichungen schnell, verkürzt RMA-Prozesse und hält die Lagerbestände genau.

Ergebnis: Dokumentierte Varianten-Entscheidung mit entsprechender Buchung, Preis-Anpassung bei Akzeptanz und Kundenbenachrichtigung bei Auswirkung auf den Verkauf.

7.4.6 Lieferanten-Leistungskennzahlen und Bonifikation

Was: Das System verfolgt automatisch Lieferantenmetriken (Liefertreue, Mängelquote, Preiseinhaltung) und kalkuliert Boni/Malus basierend auf konfigurierten Bonifikationsverträgen. Ein Lieferanten-Ranking wird erstellt.

Warum: Leistungsbasierte Bonifikationen motivieren Lieferanten zu besserer Performance, ermöglichen datengestützte Lieferantenauswahl und stärken langfristige Lieferantenpartnerschaften.

Ergebnis: Lieferanten-Performance-Report mit Leistungsübersicht, Trend-Visualisierung, automatischer Berücksichtigung von Bonifikationen bei Rechnungsfreigabe und Ranking (Top-Performer vs. Problem-Lieferanten).

7.5 Bestellungs-Lifecycle

7.5.1 Bestellung manuell erstellen

Was: Der Einkäufer erstellt eine Lieferantenbestellung, wählt Artikel und Mengen aus dem Artikelkatalog und legt Lieferkonditionen fest.

Warum: Die manuelle Bestellerstellung wird benötigt, wenn keine Bestellvorschläge vorliegen oder Sonderbestellungen außerhalb des regulären Prozesses erforderlich sind.

Ergebnis: Eine neue Lieferantenbestellung im Status Entwurf mit Artikeln, Mengen und Konditionen, bereit zur Freigabe.

7.5.2 Bestellung aus Bestellvorschlag erstellen

Was: Der Einkäufer konvertiert einen genehmigten Bestellvorschlag in eine verbindliche Lieferantenbestellung, wobei Konditionen und Lieferdaten automatisch übernommen werden.

Warum: Die direkte Übernahme aus dem Bestellvorschlag spart Zeit und stellt sicher, dass die berechneten optimalen Mengen und Konditionen korrekt übertragen werden.

Ergebnis: Eine verbindliche Bestellung mit Referenz zum ursprünglichen Bestellvorschlag und aktualisierten Lieferdaten.

7.5.3 Bestellung: Entwurf zu Bestellt

Was: Der Einkäufer gibt eine Bestellung im Entwurfsstatus frei und versendet sie an den Lieferanten per EDI, E-Mail oder über ein Lieferantenportal.

Warum: Die formale Freigabe und der Versand wandeln den internen Entwurf in eine verbindliche Bestellzusage um und starten den Lieferprozess.

Ergebnis: Die Bestellung wechselt in den Status "Bestellt", der Lieferant erhält das Bestelldokument und der Bestellvorgang wird im System dokumentiert.

7.5.4 Bestellung: Bestellt zu Teilweise geliefert

Was: Bei einer Teillieferung durch den Lieferanten erfasst das System die erhaltene Menge und trackt die ausstehende Restmenge pro Bestellposition.

Warum: Das Reststücke-Tracking ermöglicht transparente Nachverfolgung offener Liefermengen und stellt sicher, dass keine Positionen vergessen werden.

Ergebnis: Der Bestellstatus wechselt auf "Teilweise geliefert" mit Anzeige der erhaltenen und noch ausstehenden Mengen.

7.5.5 Bestellung: Teilweise geliefert zu Vollständig geliefert

Was: Nach Eingang aller ausstehenden Positionen wird die Bestellung als vollständig geliefert abgeschlossen.

Warum: Der formale Abschluss bestätigt, dass alle bestellten Positionen eingegangen sind und die Bestellung zur Rechnungsprüfung freigegeben werden kann.

Ergebnis: Die Bestellung wechselt in den Status "Vollständig geliefert" und wird zur weiteren Rechnungsbearbeitung bereitgestellt.

7.5.6 Bestellung stornieren

Was: Der Einkäufer storniert eine offene Bestellung. Der Lieferant wird automatisch über die Stornierung benachrichtigt.

Warum: Die Stornierung ermöglicht die Rücknahme von Bestellungen vor der Lieferung, z.B. bei geändertem Bedarf oder Lieferantenwechsel.

Ergebnis: Die Bestellung erhält den Status "Storniert", der Lieferant wird informiert und reservierte Budgets werden freigegeben.

8. Verkauf und Belegwesen

8.1 Angebote

8.1.1 Angebot erstellen

Was: Der Vertriebsmitarbeiter erstellt ein Kundenangebot mit Positionen (Artikel, Dienstleistungen), Preisen, Konditionen und Gültigkeitsdauer. Lieferadresse, Rechnungsadresse und Lizenznehmer-Adresse werden als Snapshot aus dem Kundenstamm übernommen.

Warum: Das formale Angebot dokumentiert die Geschäftsbedingungen, dient als verbindliche Preiszusage und ist der Einstiegspunkt der Belegkette (Angebot zu Auftrag zu Rechnung).

Ergebnis: Ein Angebot im Status "Aktiv" mit automatisch berechnetem Netto-, MwSt.- und Bruttobetrag, Konditionen und Druckvorschau.

8.1.2 Angebot bearbeiten

Was: Der Benutzer ändert ein bestehendes Angebot (Positionen, Preise, Mengen, Konditionen). Das System erstellt eine neue Version und behält die vorherige Version als Verlauf.

Warum: Die Versionierung dokumentiert die Angebotshistorie vollständig und macht spätere Änderungen transparent nachvollziehbar.

Ergebnis: Ein aktualisiertes Angebot mit erhöhter Versionsnummer und vollständiger Änderungshistorie.

8.1.3 Angebot nachverfolgen

Was: Der Vertriebsmitarbeiter verfolgt den Status von Angeboten (Offen, Nachgefasst, Gewonnen, Verloren) und kann Wiedervorlagen für die Nachfassung setzen. Abschlusswahrscheinlichkeit und Abschlussgrund werden dokumentiert.

Warum: Die systematische Nachverfolgung erhöht die Konversionsrate, ermöglicht eine Pipeline-Analyse und liefert Erkenntnisse über Verlustgründe (z.B. "Preis zu hoch", "Wettbewerber").

Ergebnis: Eine aktualisierte Angebots-Pipeline mit Statusverfolgung, Wiedervorlage-Terminen und Analyse der Abschlussquoten.

8.1.4 Angebot aus Ticket erstellen

Was: Der Support-Mitarbeiter generiert direkt aus einem Service-Ticket heraus ein Angebot, wobei Kundendaten und Problembeschreibung automatisch übernommen werden.

Warum: Die direkte Angebotserstellung aus dem Ticket beschleunigt den Prozess, vermeidet Medienbrüche und stellt sicher, dass Kundendaten korrekt übertragen werden.

Ergebnis: Ein neues Angebot mit vorausgefüllten Kundendaten und Verweis auf das auslösende Ticket.

8.2 Aufträge

8.2.1 Auftrag erstellen

Was: Der Vertriebsmitarbeiter legt einen Kundenauftrag an mit Positionen, Mengen, Lieferdatum, Zahlungsbedingungen und Lieferkonditionen.

Warum: Der Auftrag ist der verbindliche Vertriebsbeleg und Ausgangspunkt für Lieferung und Fakturierung. Er dokumentiert die Vereinbarung zwischen Unternehmen und Kunde.

Ergebnis: Ein neuer Auftrag mit berechneten Beträgen, Konditionen und optionaler Bestandsreservierung.

8.2.2 Auftrag bearbeiten

Was: Der Benutzer ändert einen bestehenden Auftrag (Positionen, Mengen, Termine) vor dem Versand. Änderungen werden versioniert.

Warum: Auftragsänderungen vor Versand ermöglichen Reaktion auf Kundenwünsche oder Verfügbarkeitsänderungen, während die vollständige Änderungshistorie nachvollziehbar bleibt.

Ergebnis: Ein aktualisierter Auftrag mit Versionierung und dokumentierter Änderungshistorie.

8.2.3 Auftrag aus Angebot erstellen

Was: Der Vertriebsmitarbeiter konvertiert ein genehmigtes Angebot in einen verbindlichen Auftrag. Positionen, Konditionen und Adressen werden übernommen und die Belegverknüpfung wird bidirektional hergestellt.

Warum: Die automatische Überführung spart Zeit, verhindert Übertragungsfehler und stellt die Nachvollziehbarkeit der gesamten Belegkette sicher.

Ergebnis: Ein neuer Auftrag mit Referenz zum Ausgangsangebot und bidirektionaler Belegverknüpfung.

8.2.4 Auftrag: Entwurf zu Bestätigt

Was: Ein Auftragsentwurf wird durch den Kunden oder intern bestätigt und wechselt damit in den verbindlichen Status.

Warum: Die Bestätigung markiert den Übergang von der Planung zur verbindlichen Zusage und startet die Auftragsbearbeitung.

Ergebnis: Der Auftrag im Status "Bestätigt", bereit für Kommissionierung oder Produktion.

8.2.5 Auftrag: Bestätigt zu In Bearbeitung

Was: Die Auftragsbearbeitung wird gestartet (Kommissionierung, Produktion, Dienstleistungserbringung).

Warum: Der Statuswechsel signalisiert allen beteiligten Abteilungen, dass der Auftrag aktiv bearbeitet wird.

Ergebnis: Der Auftrag im Status "In Bearbeitung" mit laufender Kommissionierung oder Produktion.

8.2.6 Auftrag: In Bearbeitung zu Teilgeliefert

Was: Ein Teilversand erfolgt, weil nicht alle Positionen vollständig verfügbar sind. Die gelieferten und ausstehenden Mengen werden pro Position getrackt.

Warum: Teillieferungen ermöglichen zeitnahe Auslieferung verfügbarer Positionen und transparentes Tracking der Reststücke.

Ergebnis: Der Auftrag im Status "Teilgeliefert" mit Lieferschein für die ausgelieferten Positionen und Backorder für ausstehende Mengen.

8.2.7 Auftrag: Teilgeliefert zu Vollständig geliefert

Was: Nach Eingang und Versand aller ausstehenden Positionen wird der Auftrag als vollständig geliefert abgeschlossen.

Warum: Der formale Abschluss bestätigt die vollständige Auftragserfüllung und gibt den Auftrag für die Fakturierung frei.

Ergebnis: Der Auftrag im Status "Vollständig geliefert" mit komplettem Lieferschein.

8.2.8 Auftrag stornieren

Was: Der Benutzer storniert einen Auftrag in jedem Status vor "Geliefert". Bereits reservierte Bestände werden automatisch zurückgebucht.

Warum: Die Stornierung ermöglicht die Rückabwicklung bei Stornierungswünschen des Kunden, mit automatischer Bestandsrückbuchung.

Ergebnis: Der Auftrag im Status "Storniert" mit zurückgebuchten Beständen und dokumentiertem Stornierungsgrund.

8.3 Lieferscheine und Rechnungen

8.3.1 Lieferschein aus Auftrag erstellen

Was: Das System generiert einen Lieferschein basierend auf den kommissionierten Auftragspositionen. Die Belegverknüpfung zum Auftrag wird bidirektional hergestellt.

Warum: Der Lieferschein dokumentiert die physische Warenübergabe, löst die Lagerausbuchung aus und ist Voraussetzung für die nachfolgende Rechnungsstellung.

Ergebnis: Ein Lieferschein mit Positionen, Mengen und Sendungsverfolgungsinformationen.

8.3.2 Rechnung aus Auftrag erstellen

Was: Das System generiert eine Rechnung basierend auf einem abgeschlossenen Auftrag oder Lieferschein mit automatischer MwSt-Berechnung und Zahlungsbedingungen aus dem Kundenstamm.

Warum: Die automatische Rechnungserstellung stellt korrekte Beträge, Steuersätze und Zahlungskonditionen sicher und beschleunigt den Fakturierungsprozess.

Ergebnis: Eine Rechnung mit korrekter Berechnung, Belegverknüpfung zum Auftrag/Lieferschein und automatisch angewendeten Kundenkonditionen.

8.3.3 Rechnung manuell erstellen

Was: Der Benutzer erstellt eine Rechnung manuell für Sonderleistungen, die nicht aus einem Vertrag oder Auftrag stammen.

Warum: Manuelle Rechnungen sind für Einmalleistungen, Nachberechnungen oder Sondervereinbarungen erforderlich, die nicht im regulären Belegfluss abgebildet sind.

Ergebnis: Eine eigenständige Rechnung ohne Belegvorgänger, mit allen erforderlichen Positionen und Konditionen.

8.3.4 Gutschrift zu Rechnung erstellen

Was: Der Benutzer erstellt eine Gutschrift mit Referenz auf eine bestehende Rechnung. Beträge und Positionen können vollständig oder teilweise übernommen werden.

Warum: Gutschriften korrigieren fehlerhafte Rechnungen, dokumentieren Rückerstattungen oder Preisnachlässe und stellen die buchhalterische Korrektheit sicher.

Ergebnis: Eine Gutschrift mit Referenz zur Originalrechnung, korrekter Gegenbuchung und optional automatischer Bestandsrückbuchung.

8.3.5 Rechnung: Entwurf zu Freigegeben

Was: Der Benutzer prüft die Rechnung auf Korrektheit und gibt sie zur Versendung frei.

Warum: Die Freigabe stellt sicher, dass Rechnungen vor dem Versand geprüft werden und verhindert den Versand fehlerhafter Dokumente.

Ergebnis: Die Rechnung im Status "Freigegeben", bereit für Druck, E-Mail-Versand oder Portal-Bereitstellung.

8.3.6 Rechnung: Freigegeben zu Versendet

Was: Die Rechnung wird per Druck, E-Mail oder Kundenportal an den Kunden zugestellt und als "Versendet" markiert.

Warum: Die Zustelldokumentation belegt den Versand und startet die Zahlungsfrist.

Ergebnis: Die Rechnung im Status "Versendet" mit Zustelldatum und -methode.

8.3.7 Rechnung stornieren/gutschreiben

Was: Der Benutzer storniert eine Rechnung, wobei automatisch eine Gutschrift erstellt wird. Die Gegenbuchung wird im System verarbeitet.

Warum: Die formale Stornierung stellt die buchhalterische Korrektheit sicher und dokumentiert den Vorgang lückenlos.

Ergebnis: Eine stornierte Rechnung mit automatisch erstellter Gutschrift und vollständiger Dokumentation des Stornierungsvorgangs.

8.4 Belegmanagement

8.4.1 Beleg drucken/per E-Mail versenden

Was: Der Benutzer gibt einen beliebigen Beleg (Angebot, Auftrag, Lieferschein, Rechnung) als Ausdruck oder E-Mail aus, basierend auf konfigurierten Druckvorlagen.

Warum: Die flexible Belegausgabe bedient unterschiedliche Kundenpräferenzen und gesetzliche Anforderungen an die Belegzustellung.

Ergebnis: Ein gedruckter oder per E-Mail versendeter Beleg im definierten Layout mit Versanddokumentation.

8.4.2 Beleg-Notizen und interne Kommentare

Was: Der Benutzer fügt einem Beleg interne Vermerke hinzu, die nicht auf dem Ausdruck erscheinen.

Warum: Interne Notizen ermöglichen Team-Kommunikation zum Beleg, ohne dass der Kunde diese Informationen sieht.

Ergebnis: Gespeicherte interne Notizen am Beleg, sichtbar nur für Mitarbeiter und nicht auf dem gedruckten Dokument.

8.4.3 Belegkette anzeigen (Angebot zu Auftrag zu Lieferschein zu Rechnung)

Was: Der Benutzer sieht die vollständige Belegkette eines Geschäftsvorgangs als navigierbare Darstellung: vom Angebot über den Auftrag bis zum Lieferschein und zur Rechnung.

Warum: Die durchgängige Belegkette ermöglicht lückenlose Nachverfolgung des gesamten Geschäftsvorgangs und unterstützt Audit-Anforderungen.

Ergebnis: Eine navigierbare Belegketten-Ansicht mit bidirektionalen Links zwischen allen verknüpften Belegen.

8.4.4 Dokument zu Entität verknüpfen

Was: Der Benutzer hängt ein Dokument (PDF, Bild etc.) an ein Ticket, einen Vertrag, einen Kunden oder einen Artikel an.

Warum: Die Dokumentenverknüpfung zentralisiert alle relevanten Unterlagen an der zugehörigen Entität und erleichtert das Auffinden von Informationen.

Ergebnis: Ein verknüpftes Dokument, abrufbar über die Entitätsansicht.

8.4.5 Dokument-Verknüpfung lösen

Was: Der Benutzer entfernt die Zuordnung eines Dokuments von einer Entität.

Warum: Falsch zugeordnete oder veraltete Dokumente können bereinigt werden, ohne das Dokument selbst zu löschen.

Ergebnis: Die Zuordnung ist gelöst; das Dokument existiert weiterhin, ist aber nicht mehr mit der Entität verknüpft.

9. Helpdesk

9.1 Checklisten

9.1.1 Checklisten-Template erstellen

Was: Der Teamleiter erstellt eine standardisierte Checklisten-Vorlage mit Name, Kategorie (z.B. "Hardware-Setup", "Kundenfreigabe"), Checklistenpunkten inklusive Beschreibung, Priorität (Kritisch/Normal/Optional), verantwortlicher Rolle und geschätztem Aufwand.

Warum: Standardisierte Vorlagen sichern gleichbleibende Prozessqualität, erleichtern die Einarbeitung neuer Mitarbeiter und erfüllen Audit-Compliance-Anforderungen.

Ergebnis: Ein gespeichertes Checklisten-Template mit Sub-Items, Abhängigkeiten und Gültigkeitsdauer, verfügbar zur Wiederverwendung.

9.1.2 Checkliste aus Template erstellen und durcharbeiten

Was: Der Support-Techniker erstellt eine konkrete Checkliste aus einem Template, verknüpft sie mit einem Ticket oder Projekt und arbeitet die Items in einer Master-Detail-Ansicht ab: Beschreibung lesen, Aktion durchführen, Checkbox setzen, Notizen hinzufügen.

Warum: Die schrittweise Abarbeitung stellt sicher, dass nichts vergessen wird (Qualitätssicherung), Prozesse werden automatisch dokumentiert und ein Audit-Trail mit Zeitstempel und Benutzer entsteht.

Ergebnis: Eine abgeschlossene Checkliste mit Fortschrittsanzeige (X von Y Items), Bestätigung mit Zeitstempel und vollständiger Prozessdokumentation.

9.1.3 Checklisten-Vorlagen verwalten und aktualisieren

Was: Der Administrator verwaltet alle Checklisten-Templates: Bearbeiten, Duplizieren, Löschen (mit Warnung bei aktiver Verwendung), Versionierung und Aktivierung/Deaktivierung.

Warum: Die kontinuierliche Pflege der Templates stellt sicher, dass Prozesse aktuell bleiben, Best Practices dokumentiert werden und Compliance-Anforderungen angepasst werden können.

Ergebnis: Aktualisierte Templates mit Versionsverlauf, Verwendungsstatistik und Änderungsdokumentation.

9.1.4 Checklisten-Analysen und Compliance-Reporting

Was: Der Manager öffnet die Reporting-Ansicht und sieht Checklisten-Statistiken: Abschlussquote pro Template, Durchschnittszeit zum Abschließen, Warnungen bei nicht abgeschlossenen Checklisten (älter als X Tage) und häufige Fehlerquellen.

Warum: Die Analyse zeigt, wie gut Checklisten durchgeführt werden, erkennt Schulungsbedarf und liefert Compliance-Dokumentation für Management und externe Prüfer.

Ergebnis: Ein exportierbarer Report mit Filter nach Template, Benutzer und Zeitraum für Compliance-Dokumentation und Prozessoptimierung.

9.1.5 Mobile Checklisten-Erfassung

Was: Der Techniker führt auf der Kundenbaustelle Checklisten über die Mobile App durch, inklusive Offline-Modus, Foto-Aufnahme und Sprachmemos. Nach Rückkehr werden die Daten automatisch synchronisiert.

Warum: Die mobile Erfassung eliminiert Papier-Checklisten, ermöglicht fehlerlose Datenerfassung direkt vor Ort und macht die Ergebnisse sofort im Büro verfügbar.

Ergebnis: Synchronisierte Checklisten-Daten mit Fotos, Notizen und Status-Icons (grün: synchronisiert, gelb: ausstehend).

9.1.6 Verknüpfung mit Tickets und Kundenaufträgen

Was: Beim Erstellen eines Tickets wird automatisch basierend auf der Ticket-Kategorie ein passendes Checklisten-Template zugeordnet (z.B. Ticket-Typ "Neuer Kunde" ergibt "Kundenfreigabe-Checkliste"). Optional blockiert eine unvollständige Checkliste die Ticket-Schließung.

Warum: Die automatische Checklisten-Zuordnung garantiert, dass bei keinem Ticket der zugehörige Prozess vergessen wird, und stellt Qualitätssicherung beim Ticket-Abschluss sicher.

Ergebnis: Ein Ticket mit zugeordneter Checkliste, Fortschrittsanzeige und optionaler Schließungsblockierung bei unvollständiger Checkliste.

9.1.7 Checklisten-Konvertierung (Legacy zu Neu)

Was: Der Administrator migriert alte Papier-Checklisten über einen Import-Wizard per OCR-Scan oder CSV-Import ins digitale System mit Mapping alter Item-Namen auf neue Strukturen.

Warum: Die Migration stellt sicher, dass historische Daten nicht verloren gehen, digital durchsuchbar werden und die Compliance-Dokumentation vollständig bleibt.

Ergebnis: Digital verfügbare Checklisten aus Altbeständen mit Migrationsstatistik (Erfolgreich/Fehler) und archivierten Original-Scans.

9.2 Projektverwaltung

9.2.1 Entwicklungsprojekte anzeigen und filtern

Was: Der Benutzer öffnet die Projektverwaltung und sieht eine Tabelle aller Projekte mit Name, Typ, Status, Startdatum, geplantem Enddatum, Projektleiter, Team-Größe, Budget, aktuelle Kosten und Abweichung vom Plan. Filter nach Typ, Status und Projektleiter stehen zur Verfügung.

Warum: Die Projektübersicht macht das gesamte Projektportfolio transparent, ermöglicht die Konzentration von Ressourcen auf kritische Projekte und die frühzeitige Erkennung von Chancen und Risiken.

Ergebnis: Eine farbcodierte Projekttabelle (Rot: überfällig, Gelb: kritisch, Grün: im Plan) mit Klick-Drill-Down zu Projektdetails.

9.2.2 Tickets pro Projekt anzeigen und verwalten

Was: Der Benutzer wählt ein Projekt und sieht alle verknüpften Tickets mit Nummer, Typ (Feature/Bug/Task), Status, Priorität, zugewiesenem Entwickler, geschätztem und tatsächlichem Aufwand. Batch-Operationen und Gantt-Charts sind verfügbar.

Warum: Die Ticket-Übersicht pro Projekt trackt den Projektfortschritt (Tickets abarbeiten bedeutet Projekt voranschreiten), erkennt Bottlenecks und ermöglicht Prognosen zur Deadline.

Ergebnis: Eine Ticket-Liste mit Drill-Down, Test-Status pro Ticket und Gantt-Chart-Visualisierung der Timeline.

9.2.3 Team-Auslastung und Ressourcenplanung pro Projekt

Was: Der Projektleiter sieht pro Teammitglied: Name, Rolle, geplante Gesamtstunden, gebuchte Stunden, verfügbare Reststunden und Auslastung in Prozent. Das System warnt bei Über- und Unterauslastung und schlägt Ressourcen-Umverteilungen vor.

Warum: Die projektbezogene Ressourcenplanung stellt realistische Planung sicher, ermöglicht Personalentscheidungen und verhindert Burnout bei Teammitgliedern.

Ergebnis: Eine Auslastungsübersicht mit Trend, Warnungen und Szenario-Planung ("Was wenn wir 1 Person hinzufügen?").

9.2.4 Projektfortschritt und Earned Value Analyse

Was: Der Projektleiter sieht Earned Value Metriken: geplanter Wert (PV), tatsächlicher Wert (EV), tatsächliche Kosten (AC) sowie daraus berechnete Zeitabweichung (Schedule Variance) und Kostenabweichung (Cost Variance).

Warum: Die Earned Value Analyse erkennt frühzeitig, ob ein Projekt aus dem Ruder läuft, und ermöglicht Gegenmassnahmen (Ressourcen erhöhen, Scope reduzieren) sowie datengestützte Stakeholder-Information.

Ergebnis: Charts mit geplantem vs. tatsächlichem Fortschritt, Prognose zur Fertigstellung und Kosten sowie eine Risikoliste.

9.2.5 Terminplanung und Abwesenheitsberücksichtigung

Was: Der Projektleiter sieht eine Kalenderansicht mit farblicher Markierung von Urlaub, Krankheit und Training pro Teammitglied. Automatische Warnungen zeigen drohende Abwesenheiten in kritischen Projektphasen.

Warum: Die Berücksichtigung von Abwesenheiten bei der Projektplanung verhindert unrealistische Terminpläne und stellt sicher, dass Milestones nicht in Abwesenheitszeiten fallen.

Ergebnis: Eine Kalenderansicht mit Skill-Abbildung (wer kann kompensieren), Was-wenn-Szenarien und Abwesenheitsrate-Report pro Team.

9.2.6 Vertragliche Liefertermine und Verträge

Was: Die Projektverwaltung zeigt verknüpfte Verträge mit Lieferdatum, Penalty-Regelung bei Verzug und Bonus bei frühzeitiger Lieferung. Warnungen erscheinen automatisch 2 Wochen vor dem Lieferdatum und bei drohendem Verzug.

Warum: Das Tracking vertraglicher Termine sichert die Einhaltung von Kundenzusagen, vermeidet finanzielle Penalties und ermöglicht die Realisierung von Bonus-Zahlungen bei frühzeitiger Lieferung.

Ergebnis: Automatische Erinnerungen, Prognose zum Liefertermin basierend auf aktuellem Trend und Eskalation an die Geschäftsführung bei drohendem Verzug.

9.2.7 Technischer Schulden und Refactoring-Tracker

Was: Im Projekt können Tickets als "Technical Debt" markiert werden. Das System sammelt diese und zeigt einen Schulden-Report: Gesamtschulden in geschätzten Stunden, Verteilung pro Code-Bereich und Trend (wird Schuld schneller erzeugt oder abgebaut?).

Warum: Die systematische Erfassung technischer Schulden ermöglicht gezielte Refactoring-Planung, priorisiert den Abbau nach Nutzen und verbessert langfristig die Code-Qualität.

Ergebnis: Ein Schulden-Report mit Priorisierung, Refactoring-Plan und QA-Metriken (Code Coverage, Bugs, Performance).

9.2.8 Retrospektiven und Lessons Learned

Was: Nach Projektabschluss füllt der Projektleiter ein Retrospektive-Template aus: Was hat gut funktioniert, was hätte besser gehen können, geplante vs. tatsächliche Aufwände und Team-Rückmeldung.

Warum: Systematisch dokumentierte Lessons Learned verbessern zukünftige Schätzungen, vermeiden wiederholte Fehler und teilen Best Practices mit anderen Teams.

Ergebnis: Ein gespeichertes Lessons-Learned-Dokument, durchsuchbar für zukünftige Projekte, mit gesammelten Aufwandsmetriken pro Feature-Typ.

9.3 RMA/Werkstatt

9.3.1 RMA erstellen und registrieren

Was: Der Support-Techniker erstellt über einen Wizard einen Reparaturfall (RMA) mit Kundenauswahl, Artikel/Seriennummern, Fehlerbeschreibung und Versandart. Das System generiert automatisch eine RMA-Nummer (z.B. RMA-2025-001234) und einen QR-Code für das Versandlabel.

Warum: Die strukturierte RMA-Erfassung dokumentiert den Reparaturfall von Anfang an, gibt dem Kunden eine Tracking-Nummer und informiert die Werkstatt, was zu reparieren ist.

Ergebnis: Ein registrierter RMA-Fall im Status "Eingegangen" mit automatisch verknüpftem Support-Ticket und druckbarem QR-Code/Barcode.

9.3.2 RMA-Bearbeitung in der Werkstatt

Was: Der Werkstatt-Techniker scannt die RMA-Nummer, sieht die Details und dokumentiert die Reparatur: Diagnose, durchgeführte Reparaturschritte, verbrauchte Ersatzteile (aus Werkstattlager) und Arbeitszeit. Ein Quality-Check bestätigt die erfolgreiche Reparatur.

Warum: Die vollständige Dokumentation des Reparaturverlaufs ermöglicht Kostenverfolgung, Garantie-Erfüllung und ist Grundlage für die spätere Rechnungsstellung an den Kunden.

Ergebnis: Ein aktualisierter RMA-Status ("In Reparatur" zu "Repariert" oder "Nicht reparierbar") mit Diagnose, Reparaturbeschreibung und Kostenaufstellung.

9.3.3 RMA zurück an Kunde versenden

Was: Nach erfolgreicher Reparatur wählt der Benutzer Versandoptionen (Paket, Express, Standard), generiert einen Packzettel und ein Versandlabel. Das System erzeugt eine Tracking-Nummer und sendet dem Kunden eine E-Mail mit Tracking-Link.

Warum: Die integrierte Versandabwicklung beschleunigt die Rücksendung, informiert den Kunden transparent und dokumentiert Versandkosten.

Ergebnis: Ein versandter RMA im Status "Versendet" mit Tracking-Nummer und automatischer Kundenbenachrichtigung.

9.3.4 RMA-Lagerverwaltung (Eigenbestand vs. Kundeneigentum)

Was: Das System verwaltet zwei Bestandstypen: Leihgeräte des Unternehmens (zum Ersatz während der Reparatur) und Kundengeräte in Reparatur. Leihgeräte werden getrackt mit Warnung nach über 30 Tagen beim Kunden.

Warum: Die getrennte Lagerverwaltung verhindert den Verlust teurer Leihgeräte, verbessert die Kundenbeziehung durch schnellen Ersatz und ermöglicht Bestandsplanung (wie viele Leihgeräte werden benötigt).

Ergebnis: Eine Übersicht über Leihgeräte (wer hat welches, wie lange) und Kundengeräte mit Rückruf-Warnungen und Retourenmanagement.

9.3.5 RMA-Kostenberechnung und Rechnungstellung

Was: Nach Reparaturabschluss generiert das System automatisch einen Rechnungsentwurf mit Materialkosten (Ersatzteile), Arbeitskosten (Stunden mal Stundensatz), Versandkosten und automatisch angewandten Rabatten (Garantie, Vertrag).

Warum: Die automatische Kostenberechnung ermöglicht das Tracking von Reparatureinnahmen, Gewinnmargenanalyse pro RMA-Typ und faire Preisstellung für den Kunden.

Ergebnis: Ein geprüfter und versandter Rechnungsentwurf mit Zahlungs-Tracking und Statusaktualisierung auf "Abgeschlossen".

9.3.6 RMA-Statistiken und Qualitätsmetriken

Was: Der Manager öffnet die RMA-Analytics und sieht Reparaturquote (erfolgreich vs. nicht reparierbar), Durchschnittszeit, Kosten pro RMA, Reklamationsquote (RMA die nochmal zurückkommen) und eine Analyse problematischer Artikel.

Warum: Die Metriken machen die Reparaturservice-Qualität transparent, identifizieren häufig defekte Artikel und helfen bei der Kapazitätsplanung der Werkstatt.

Ergebnis: Ein Analytics-Dashboard mit Prognose zur Werkstattkapazität und Identifikation von Problemartikel und -lieferanten.

9.3.7 RMA-Archivierung und Compliance

Was: Abgeschlossene RMA-Fälle werden digital archiviert: Dokumentation, Fotos, Ersatzteile-Rechnungen und Kundenrechnungen mit konfigurierbarer Aufbewahrungsfrist (2-5 Jahre je nach Garantie/Gewährleistung). DSGVO-konforme Löschung nach Ablauf.

Warum: Die revisionssichere Archivierung erfüllt Garantieansprüche, vereinfacht externe Audits und stellt Datenschutz-Compliance sicher.

Ergebnis: Archivierte RMA-Daten mit Suchfunktion für Musteranalysen, Export für externe Audits und automatischer Löschung nach Aufbewahrungsfrist.

9.3.8 RMA: In Reparatur zu Nicht reparierbar

Was: Der Werkstatt-Techniker stellt fest, dass eine Reparatur wirtschaftlich nicht sinnvoll ist und dokumentiert den Befund. Optionen werden angeboten: Verschrottung des Geräts oder Austausch durch ein Ersatzgerät.

Warum: Die formale Feststellung der Nicht-Reparierbarkeit dokumentiert den Sachverhalt für den Kunden, klärt die nächsten Schritte und ermöglicht die Kostenberechnung für den Austausch.

Ergebnis: Ein aktualisierter RMA-Status "Nicht reparierbar" mit Dokumentation des Befunds und Optionen für Verschrottung oder Austausch.

9.4 Taskmanagement

9.4.1 Task erstellen und zuweisen

Was: Der Benutzer erstellt einen Task mit Titel, Beschreibung, Priorität (Hoch/Normal/Niedrig), zugewiesenem Mitarbeiter, Deadline, Kategorie, optionalem Parent-Task, Abhängigkeiten und geschätztem Aufwand.

Warum: Die zentrale Task-Verwaltung macht alle Arbeitspakete im System transparent, verhindert das Vergessen von Aufgaben und stellt durch klare Priorisierung sicher, dass Wichtiges zuerst bearbeitet wird.

Ergebnis: Ein erstellter und zugewiesener Task mit automatischer Benachrichtigung des zugewiesenen Mitarbeiters.

9.4.2 Task-Board und Kanban-Ansicht

Was: Die Kanban-Ansicht zeigt Tasks als Karten in Spalten nach Status: "Neu", "In Arbeit", "Review" und "Abgeschlossen". Per Drag-und-Drop werden Tasks zwischen Status verschoben. Farben zeigen Fälligkeitsstatus (Rot: überfällig, Gelb: bald fällig, Grün: OK).

Warum: Die visuelle Kanban-Darstellung gibt einen sofortigen Überblick über den Workflow, identifiziert Blocker schnell und motiviert durch sichtbaren Fortschritt.

Ergebnis: Ein interaktives Board mit Status-Änderung per Drag-und-Drop, Filtermöglichkeiten und Klick auf Tasks für Details.

9.4.3 Task-Abhängigkeiten und Reihenfolge

Was: Bei der Task-Erstellung können Abhängigkeiten definiert werden ("Task B erst nach Task A"). Das System zeigt einen Abhängigkeits-Graph, blockiert automatisch abhängige Tasks und stellt die Sequenzen in einem Gantt-Chart dar.

Warum: Abhängigkeits-Management stellt die richtige Reihenfolge sicher, verhindert fehlerhafte Bearbeitung und ermöglicht genauere Prognosen, wann alle Tasks fertig sind.

Ergebnis: Ein visualisierter Abhängigkeits-Graph mit automatischer Blockierung, Warnungen bei überfälligen Vorgängern und Gantt-Chart.

9.4.4 Task-Kommentare und Zusammenarbeit

Was: Team-Mitglieder fügen Kommentare zu Tasks hinzu, nutzen @-Mentions für Benachrichtigungen, hängen Dateien an und sehen die vollständige Task-History (wer hat was wann geändert).

Warum: Die integrierte Team-Kommunikation verhindert "Lost-in-Email"-Situationen, schafft einen Audit-Trail von Entscheidungen und ermöglicht asynchrone Zusammenarbeit.

Ergebnis: Eine vollständige Kommentar-Historie mit Attachments, Mentions-Benachrichtigungen und unveränderlichem Änderungsverlauf.

9.4.5 Task-Zeittracking und Effort-Vergleich

Was: Bei Task-Abschluss werden die tatsächlich verbrauchten Stunden erfasst und mit der ursprünglichen Schätzung verglichen. Das System berechnet die Schätzgenauigkeit und erstellt Durchschnittszeiten pro Task-Typ.

Warum: Der systematische Vergleich verbessert zukünftige Schätzungen, ermöglicht Kunden-Abrechnung auf Basis realer Zeiten und misst Prozessverbesserungen über die Zeit.

Ergebnis: Eine Accuracy-Analyse (z.B. "Schätzungen meist 20% zu hoch") mit Durchschnittswerten pro Task-Typ und Trend.

9.4.6 Task-Templates und Wiederkehrende Tasks

Was: Der Administrator erstellt Task-Templates (z.B. "Monatsabschluss") mit vordefinierten Sub-Tasks, Abhängigkeiten und Prioritäten. Templates können periodisch automatisch als Batch erstellt werden.

Warum: Die Standardisierung wiederkehrender Aufgaben stellt konsistente Prozesse sicher, verhindert das Vergessen von Routineaufgaben und erleichtert die Einarbeitung neuer Mitarbeiter.

Ergebnis: Automatisch erstellte Task-Sets basierend auf Templates mit Wiederholungsregel (monatlich, wöchentlich) und Rollenzuweisung.

9.4.7 Task-Eskalation und Alerts

Was: Das System überwacht Task-Status kontinuierlich und eskaliert mehrstufig: E-Mail nach 1 Stunde Überfälligkeit, SMS/Popup nach 1 Tag, Manager-Benachrichtigung nach 2 Tagen. Bei blockierten Tasks wird erkannt, dass der Zugewiesene nicht verantwortlich ist.

Warum: Die automatische Eskalation macht überfällige Tasks schnell sichtbar, entlastet Manager von manueller Überwachung und ermöglicht proaktives statt reaktives Management.

Ergebnis: Automatische Benachrichtigungen, Status-Bericht aller überfälligen Tasks für Manager und Differenzierung zwischen eigenverschuldeter Überfälligkeit und Blockierung.

9.4.8 Task-Performance-Analysen

Was: Der Manager sieht Task-Analytics: Abschlussquote (pünktlich fertig), Durchschnittliche Durchlaufzeit, Priorisierungs-Effektivität (werden Hochprio-Tasks zuerst bearbeitet) und Pro-Mitarbeiter-Effizienz.

Warum: Die Performance-Analysen identifizieren Bottlenecks, erkennen Schulungsbedarf und ermöglichen bessere Kapazitätsplanung basierend auf realen Durchsatzzahlen.

Ergebnis: Ein Analytics-Dashboard mit Metriken pro Mitarbeiter und Kategorie, Bottleneck-Analyse und Prognose für die nächste Woche.

9.5 Ticket-Liste

9.5.1 Alle offenen Tickets filtern und anzeigen

Was: Der Team-Lead öffnet die Ticket-Liste und sieht alle Tickets mit Status "Neu", "In Bearbeitung" und "Warte auf Kunde", sortiert nach Priorität mit Spalten wie Ticketnummer, Kunde, Titel, Status, Priorität, Zuweiser und Alter in Tagen.

Warum: Die zentrale Ticket-Übersicht ermöglicht dem Support-Team den täglichen Überblick über alle aktiven Vorgänge und die schnelle Identifikation kritischer Tickets.

Ergebnis: Eine gefilterte Ticket-Liste mit Standard-Filtern (offene Tickets der letzten 30 Tage) und Prioritätssortierung.

9.5.2 Nach Kunde, Typ oder Priorität filtern

Was: Der Benutzer grenzt Tickets über Multi-Select-Filter ein: nach Kunde, Tickettyp (Incident, Service Request, Change Request), Priorität, Status, Zuweiser, Kategorie, SLA-Status und Erstellungsdatum.

Warum: Gezielte Filterung ermöglicht den Fokus auf spezifische Tickets und reduziert die Informationsflut für effizientere Bearbeitung.

Ergebnis: Eine eingegrenzte Ticket-Ansicht mit kombinierbaren Filtern und verschiebbarem Filter-Panel.

9.5.3 Nach Tickettext suchen (Volltextsuche)

Was: Der Benutzer sucht in Beschreibung, Titel, Kommentaren, Notizen und Dateianhang-OCR mit erweiterten Operatoren (Phrasen, Ausschluss, Wildcard). Die Live-Suche liefert Ergebnisse während der Eingabe mit Debounce von 0,5 Sekunden.

Warum: Die Volltextsuche ermöglicht schnelles Auffinden früherer Tickets zu ähnlichen Problemen, was die Lösungszeit verkürzt und Doppelarbeit vermeidet.

Ergebnis: Suchergebnisse in Echtzeit mit maximal 1000 Treffern und Unterstützung für Phrasen-, Ausschluss- und Wildcard-Suche.

9.5.4 SLA-Status prüfen und Eskalationen sehen

Was: Pro Ticket werden die Zielzeit für Response und Lösung angezeigt mit Statusindikator: Grün (über 50% Zeit verbleibend), Gelb (unter 25% verbleibend), Rot (überschritten oder unter 5%). SLA-Regeln basieren auf Prioritätsstufen.

Warum: Die SLA-Überwachung stellt die Einhaltung von Service-Level-Vereinbarungen sicher, warnt rechtzeitig vor drohenden Überschreitungen und ermöglicht SLA-Pausierung bei "Warte auf Kunde".

Ergebnis: Farbcodierte SLA-Status pro Ticket mit Zielzeiten (z.B. Kritisch: 4h Response, 8h Lösung) und Pausierungsoption.

9.5.5 Mehrere Tickets gleichzeitig bearbeiten (Bulk)

Was: Der Benutzer selektiert mehrere Tickets per Checkbox und führt Bulk-Aktionen aus: Priorität oder Status ändern, Zuweiser wechseln, Notiz anhängen, Tickets schließen/stornieren oder Massen-Export als CSV.

Warum: Bulk-Operationen sparen erheblich Zeit bei der Verwaltung vieler gleichartiger Tickets, z.B. wenn ein Team-Lead morgens neue Tickets verteilt.

Ergebnis: Durchgeführte Massenänderung an den selektierten Tickets mit Bestätigungsdialog ("Diese Aktion betrifft X Tickets").

9.5.6 Ticket-Details im Panel oder Pop-up anzeigen

Was: Per Klick auf ein Ticket erscheint eine Schnellvorschau mit Ticketnummer, Kundendaten, Beschreibung, vollständiger Historie, Anhängen, SLA-Status und verknüpften Tickets sowie Aktions-Buttons (Edit, Close, Assign to me).

Warum: Die Schnellvorschau ermöglicht die Bewertung von Tickets ohne Kontextwechsel in einen separaten Tab und beschleunigt die tägliche Arbeit.

Ergebnis: Ein Detail-Panel mit allen relevanten Informationen und Direktaktions-Buttons.

9.5.7 Ticket kommentieren und Status aktualisieren

Was: Der Benutzer gibt eine interne Notiz oder eine Kundenantwort ein, wählt optional einen neuen Status (z.B. "Warte auf Kunde") und klickt "Send und Update". Bei Kundenantwort wird automatisch eine E-Mail versendet.

Warum: Die häufigste Ticket-Operation (Kommunikation mit dem Kunden) wird in einem einzigen Schritt abgewickelt: Kommentar speichern, Status ändern und E-Mail versenden.

Ergebnis: Gespeicherter Kommentar, aktualisierter Status und (bei Kundenantwort) versendete E-Mail mit automatischem Template.

9.5.8 Ticket schließen mit Lösungs-Dokumentation

Was: Der Benutzer schließt ein Ticket, wählt einen Schließungsgrund (Gelöst, Duplikat, Nicht reproduzierbar, Keine Antwort), dokumentiert optional die Lösung für die Wissensdatenbank und gibt den Zeitaufwand an.

Warum: Die strukturierte Schließung mit Dokumentation ermöglicht Auswertung der Lösungsquoten, baut eine Wissensdatenbank auf und sendet dem Kunden eine Bestätigungsmail.

Ergebnis: Ein geschlossenes Ticket mit Schließungsgrund, optional in der Wissensdatenbank hinterlegter Lösung und versendeter Abschluss-E-Mail.

9.5.9 Favoriten speichern (gespeicherte Suchanfragen)

Was: Der Benutzer speichert die aktuelle Filter-Kombination als Favorit (z.B. "Meine offenen Tickets", "Kritische EDI Tickets") und ruft sie über die Sidebar schnell ab. Favoriten können auch als Team-Favoriten geteilt werden.

Warum: Gespeicherte Suchanfragen beschleunigen die tägliche Arbeit und stellen sicher, dass häufig benötigte Ticket-Ansichten mit einem Klick verfügbar sind.

Ergebnis: In der Sidebar verfügbare Favoriten mit gespeicherten Filtern, aufrufbar per Klick und optional für das Team freigegeben.

9.5.10 Ticket-Historie und Änderungsverlauf anzeigen

Was: Ein chronologischer Zeitstrahl zeigt alle Events eines Tickets: Erstellung, Statusänderungen, Zuweiser-Wechsel, Kommentare, Datei-Uploads und SLA-Events. Filter nach internen Notizen oder Kundenkommunikation sind verfügbar.

Warum: Die vollständige, unveränderliche Änderungshistorie dokumentiert den gesamten Ticketverlauf lückenlos und erfüllt Audit-Anforderungen.

Ergebnis: Ein Zeitstrahl-View mit allen Events, Export als PDF ("Ticket-Geschichte") und unveränderlicher Audit-Trail.

9.6 Ticket-Verwaltung (CRUD und Zuweisungen)

9.6.1 Neues Ticket erstellen (Desktop)

Was: Der Mitarbeiter erstellt ein Support-Ticket im Desktop-Client mit Kunde, Titel, Beschreibung, Klassifizierung und optional verknüpftem Vertrag oder Gerät.

Warum: Die strukturierte Ticket-Erfassung ist der Einstiegspunkt für jeden Support-Vorgang und stellt sicher, dass alle relevanten Informationen von Anfang an dokumentiert sind.

Ergebnis: Ein neues Ticket im Status "Neu" mit allen erfassten Stammdaten.

9.6.2 Ticket einem Mitarbeiter zuweisen

Was: Der Dispatcher oder Team-Lead weist ein Ticket einem bestimmten Bearbeiter zu. Der zugewiesene Mitarbeiter erhält eine Benachrichtigung.

Warum: Die klare Zuweisung stellt Verantwortlichkeit sicher und verhindert, dass Tickets unbearbeitet liegen bleiben.

Ergebnis: Ein zugewiesenes Ticket mit Benachrichtigung an den Bearbeiter und aktualisiertem Zuweisungsstatus.

9.6.3 Ticket eine Priorität zuweisen

Was: Der Benutzer legt die Prioritätsstufe fest: Kritisch, Hoch, Mittel oder Niedrig. Die Priorität beeinflusst die SLA-Zielzeiten.

Warum: Die Priorisierung steuert die Bearbeitungsreihenfolge und die SLA-Berechnung und stellt sicher, dass kritische Probleme zuerst bearbeitet werden.

Ergebnis: Ein priorisiertes Ticket mit entsprechend berechneten SLA-Zielzeiten.

9.6.4 Ticket einen Typ zuweisen

Was: Das Ticket wird als Incident, Service Request, Change Request oder Problem klassifiziert.

Warum: Die Typklassifizierung steuert den Bearbeitungs-Workflow, ermöglicht typspezifische Auswertungen und hilft bei der Kapazitätsplanung.

Ergebnis: Ein typklassifiziertes Ticket mit entsprechendem Workflow.

9.6.5 Ticket eine Kategorie zuweisen

Was: Das Ticket wird organisatorisch kategorisiert (z.B. Netzwerk, Hardware, Software) für Routing und Auswertung.

Warum: Die Kategorisierung ermöglicht automatisches Routing an die richtige Abteilung und liefert Daten für Auswertungen nach Problembereich.

Ergebnis: Ein kategorisiertes Ticket, routbar an die zuständige Fachabteilung.

9.6.6 Ticket einem Kunden zuordnen

Was: Das Ticket wird mit einem Kundenstamm-Eintrag verknüpft.

Warum: Die Kundenzuordnung ermöglicht die Ticket-Abrechnung, SLA-Berechnung basierend auf Kundenvertrag und vollständige Kundenkommunikationshistorie.

Ergebnis: Ein kundenverknüpftes Ticket mit Zugriff auf Kundenstammdaten und Vertragskonditionen.

9.6.7 Ticket einem Vertrag/Service zuordnen

Was: Das Ticket wird mit einem bestehenden Service-Vertrag verknüpft.

Warum: Die Vertragszuordnung aktiviert die vertragsspezifische SLA-Berechnung und stellt sicher, dass der Kunde die vereinbarte Service-Qualität erhält.

Ergebnis: Ein vertragsverknüpftes Ticket mit automatisch berechneten SLA-Zeiten basierend auf den Vertragskonditionen.

9.6.8 Ticket wiedereröffnen

Was: Ein geschlossenes Ticket wird in den Status "In Bearbeitung" zurückgeführt, wenn das Problem erneut auftritt.

Warum: Die Wiedereröffnung statt Neuanlage bewahrt die vollständige Problemhistorie und vermeidet Datenverlust.

Ergebnis: Ein wiedereröffnetes Ticket mit vollständiger bisheriger Historie und neuem Bearbeitungszyklus.

9.6.9 Ticket eskalieren

Was: Die Priorität wird erhöht und das Ticket wird an einen übergeordneten Bearbeiter neu zugewiesen, typischerweise bei SLA-Verletzung.

Warum: Die Eskalation stellt sicher, dass kritische Probleme schnellstmöglich von erfahreneren Mitarbeitern bearbeitet werden.

Ergebnis: Ein eskaliertes Ticket mit erhöhter Priorität und neuem Bearbeiter.

9.6.10 Tickets zusammenführen (Merge)

Was: Zwei Duplikat-Tickets werden zu einem einzigen zusammengelegt mit konsolidierter Historie beider Tickets.

Warum: Die Zusammenführung verhindert Doppelarbeit und konsolidiert alle Informationen zu einem Problem an einer Stelle.

Ergebnis: Ein zusammengeführtes Ticket mit vollständiger konsolidierter Historie. Das Duplikat-Ticket wird als zusammengeführt markiert.

9.6.11 Ticket splitten

Was: Ein Ticket wird in mehrere Einzeltickets aufgeteilt, wenn es unabhängige Teilprobleme enthält.

Warum: Die Aufteilung ermöglicht separate Bearbeitung und Zuweisung unabhängiger Teilprobleme an verschiedene Bearbeiter.

Ergebnis: Mehrere neue Tickets mit Referenz zum Originalticket und jeweils eigenem Bearbeitungsstatus.

9.6.12 Ticket an externen Dienstleister weiterleiten

Was: Ein Ticket wird an einen Service-Partner weitergeleitet, der die Bearbeitung übernimmt. Status und Rückmeldung werden verfolgt.

Warum: Die externe Weiterleitung ermöglicht die Einbindung spezialisierter Partner, ohne dass das Tracking im eigenen System verloren geht.

Ergebnis: Ein weitergeleitetes Ticket mit Statusverfolgung und dokumentierter Rückmeldung des externen Dienstleisters.

9.7 Ticket-Stammdaten

9.7.1 Ticket-Prioritäten verwalten

Was: Der Administrator erstellt und pflegt Prioritätsstufen mit Name, Farbe und zugeordneten SLA-Zeiten (Response- und Lösungszeit).

Warum: Konfigurierbare Prioritäten ermöglichen die Anpassung an unternehmensspezifische SLA-Strukturen und steuern die Ticket-Bearbeitung.

Ergebnis: Konfigurierte Prioritätsstufen, referenziert in Ticket-Filtern und bei der Ticket-Erstellung.

9.7.2 Ticket-Kategorien verwalten

Was: Der Administrator erstellt und pflegt Ticket-Kategorien mit Name, Beschreibung und optionalem Standard-Zuweiser.

Warum: Kategorien ermöglichen automatisches Routing und liefern die Basis für Auswertungen nach Problembereich.

Ergebnis: Konfigurierte Kategorien, referenziert in Ticket-Filtern und bei der Ticket-Erstellung.

9.7.3 Ticket-Typen verwalten

Was: Der Administrator pflegt Ticket-Typen (Incident, Service Request, Change Request, Problem).

Warum: Typendefinitionen steuern den jeweiligen Bearbeitungs-Workflow und ermöglichen typspezifische Auswertungen.

Ergebnis: Konfigurierte Ticket-Typen für die Klassifizierung.

9.7.4 Ticket-Status-Definitionen verwalten

Was: Der Administrator konfiguriert verfügbare Ticket-Status und die erlaubten Übergänge zwischen den Status.

Warum: Die Workflow-Definition stellt sicher, dass Tickets nur gültige Statusübergänge durchlaufen und der Bearbeitungsprozess konsistent bleibt.

Ergebnis: Konfigurierte Status-Definitionen mit erlaubten Übergängen.

9.8 Ticket-Verknüpfungen

9.8.1 Ticket mit anderem Ticket verknüpfen

Was: Der Benutzer erstellt eine Beziehung zwischen zwei Tickets: Duplikat, Blocker, Bezug oder Eltern-Kind.

Warum: Die Verknüpfung ermöglicht kontextbezogene Navigation zwischen zusammenhängenden Tickets und macht Abhängigkeiten sichtbar.

Ergebnis: Eine bidirektionale Verknüpfung mit Beziehungstyp, sichtbar in beiden Tickets.

9.8.2 Ticket-Verknüpfung entfernen

Was: Der Benutzer löst eine bestehende Beziehung zwischen zwei Tickets.

Warum: Falsch erstellte oder nicht mehr relevante Verknüpfungen können bereinigt werden.

Ergebnis: Die Verknüpfung ist in beiden Tickets entfernt.

10. MyCentron / Hilfe

10.1 Dashboard

10.1.1 Dashboard-Kacheln konfigurieren

Was: Der Benutzer fügt per Drag-und-Drop Widgets (Meine Tickets, Offene Aufgaben, OPOS, Umsatz-KPIs) zum persönlichen Dashboard hinzu, passt Größe und Position an und konfiguriert das Aktualisierungsintervall (Echtzeit, 5 Min, 15 Min).

Warum: Das personalisierte Dashboard stellt sicher, dass jeder Mitarbeiter beim Login sofort die für ihn relevanten Informationen sieht und effizient mit der Arbeit beginnen kann.

Ergebnis: Ein persönliches Dashboard-Layout, das beim nächsten Login wiederhergestellt wird.

10.1.2 Echtzeit-Benachrichtigungen empfangen

Was: Das System überwacht konfigurierte Trigger (neues Ticket zugewiesen, OPOS-Erinnerung, Genehmigung erforderlich) und zeigt Push-Benachrichtigungen als Kachel im Dashboard mit Direktaktion-Möglichkeit.

Warum: Echtzeit-Benachrichtigungen verhindern, dass wichtige Ereignisse verpasst werden, und ermöglichen schnelle Reaktionszeiten.

Ergebnis: Benachrichtigungs-Kacheln mit Anzahl, Detailansicht und Direktaktionen (Ticket öffnen, Genehmigung erteilen).

10.1.3 KPI-Kacheln auswerten

Was: Der Benutzer fügt KPI-Kacheln hinzu (Umsatz, Marge, Ticket-Volumen, OPOS), wählt Zeitraum und Vergleichswert (Vorjahr, Zielwert) und erhält eine Visualisierung mit Sparkline-Trend und farbcodierter Abweichung.

Warum: Die KPI-Visualisierung macht die Geschäftsentwicklung transparent, erkennt Abweichungen schnell und ermöglicht datenbasierte Entscheidungen.

Ergebnis: KPI-Kacheln mit Trend, Vergleich und Drill-Down-Möglichkeit in Detailreports.

10.1.4 Schnellzugriffe verwenden

Was: Der Benutzer konfiguriert Quick-Action-Kacheln für häufig genutzte Funktionen (Neues Ticket, Rechnung erfassen, Kunde anlegen). Ein Klick öffnet direkt das Zielmodul.

Warum: Schnellzugriffe beschleunigen Workflows, vermeiden Mehrfachklicks in der Navigation und zeigen automatisch die meistgenutzten Aktionen hervorgehoben an.

Ergebnis: Quick-Action-Kacheln mit Icons und Ein-Klick-Zugang zum Zielmodul.

10.2 Kalender

10.2.1 Termin anlegen

Was: Der Benutzer erfasst einen Termin mit Titel, Start-/Endzeit, Ort, Teilnehmern (intern und extern), Raum-/Ressourcen-Buchung und Terminart (Meeting, Kundenbesuch, Schulung). Optional werden Erinnerung und Verknüpfung zu Ticket/Projekt hinterlegt.

Warum: Die zentrale Terminverwaltung koordiniert Meetings, verhindert Doppelbuchungen von Räumen und Ressourcen und informiert Teilnehmer automatisch per E-Mail.

Ergebnis: Ein gespeicherter Termin mit versendeten Einladungen und gebuchten Ressourcen.

10.2.2 Team-Kalender einsehen

Was: Der Benutzer wechselt in die Team-Ansicht, wählt Mitarbeiter oder eine Abteilung und sieht alle Kalender nebeneinander mit grün hervorgehobenen freien Zeitslots.

Warum: Die Team-Kalender-Ansicht vereinfacht die Terminabstimmung, macht Verfügbarkeiten transparent und ermöglicht das Erstellen von Terminen direkt aus der Übersicht.

Ergebnis: Eine nebeneinander dargestellte Kalenderansicht mit markierten freien Slots und Direkterstellungs-Möglichkeit.

10.2.3 Wiederkehrende Termine verwalten

Was: Der Benutzer erstellt einen wiederkehrenden Termin mit Wiederholungsregel (täglich, wöchentlich, monatlich), Enddatum oder Anzahl und Ausnahmen (z.B. Feiertage). Änderungen können auf einzelne Termine oder die gesamte Serie angewendet werden.

Warum: Die Serien-Verwaltung erleichtert die Planung regelmäßiger Meetings und stellt sicher, dass Wartungsintervalle oder Stand-ups nicht vergessen werden.

Ergebnis: Eine automatisch generierte Terminserie mit Einzeltermin- oder Serien-Bearbeitungsmöglichkeit.

10.3 c-entron Inspektor

10.3.1 Datenintegrität prüfen

Was: Der Administrator startet eine Prüfung auf Orphan-Records, Duplikate und fehlerhafte Foreign Keys. Ergebnisse werden tabellarisch mit Schweregrad (Warnung/Fehler) angezeigt und können direkt korrigiert werden (Löschen, Zusammenführen, Referenz korrigieren).

Warum: Die regelmäßige Datenintegritätsprüfung erkennt Anomalien frühzeitig, verbessert die Datenqualität und erhöht die Systemstabilität.

Ergebnis: Ein Prüfbericht mit gefundenen Problemen, Schweregrad, Korrekturmöglichkeiten und archiviertem Report.

10.3.2 Performance-Checks durchführen

Was: Der Administrator analysiert langsame SQL-Queries, Speicherbelegung und API-Response-Zeiten. Das System zeigt problematische Queries mit Laufzeit und Ausführungshäufigkeit und schlägt Indizes vor.

Warum: Die Performance-Analyse optimiert die Systemgeschwindigkeit, verbessert die Benutzererfahrung und nutzt Ressourcen effizienter.

Ergebnis: Ein Performance-Report mit Index-Empfehlungen, Trend-Analyse und Möglichkeit zur direkten Index-Erstellung.

10.3.3 Konfigurationsprobleme erkennen

Was: Das System prüft E-Mail-Einstellungen, API-Verbindungen, Lizenzstatus und Buchhaltungsexporte mit Status-Anzeige (OK, Warnung, Fehler) und Test-Funktion (Test-E-Mail, API-Ping).

Warum: Die Konfigurationsvalidierung erkennt Fehlkonfigurationen schnell, minimiert Ausfallzeiten und reduziert den Support-Aufwand.

Ergebnis: Ein Konfigurations-Status-Report mit konkreten Hinweisen bei Fehlern und Direktkorrektur-Möglichkeit.

10.4 Zeiterfassung (MyDay Editor)

10.4.1 Arbeitszeiten erfassen

Was: Der Mitarbeiter erfasst Zeiteinträge mit Ticket-Nummer, Tätigkeit, Start-/Endzeit oder Dauer und Projektzuordnung. Das System prüft auf Überschneidungen und warnt bei über 10 Stunden pro Tag.

Warum: Die tägliche Zeiterfassung ist Grundlage für transparente Projektkostenrechnung, korrekte Kundenabrechnung und Einhaltung arbeitszeitrechtlicher Vorgaben.

Ergebnis: Gespeicherte Zeiteinträge mit automatischer Projektzuordnung durch Ticket-Verknüpfung und Freigabe an den Vorgesetzten.

10.4.2 Pauschale Tätigkeiten buchen

Was: Der Mitarbeiter erfasst nicht-projektbezogene Tätigkeiten wie Urlaub, Krankheit, Fortbildung oder interne Aufgaben als Ganztags- oder Stundeneintrag.

Warum: Die vollständige Zeiterfassung inklusive nicht-projektbezogener Zeiten ermöglicht korrekte Personalkosten-Verteilung und integrierte Urlaubsverwaltung.

Ergebnis: Gespeicherte pauschale Zeiteinträge mit Verknüpfung zu Antrag-Referenzen oder Schulungs-IDs.

10.4.3 Zeiteinträge genehmigen

Was: Der Vorgesetzte sieht offene Zeiteinträge seiner Mitarbeiter, prüft auf Plausibilität und Projektzuordnung und genehmigt diese einzeln oder per Bulk-Genehmigung. Bei Unstimmigkeiten wird eine Rückfrage mit Kommentar an den Mitarbeiter gesendet.

Warum: Das Vier-Augen-Prinzip bei der Zeiterfassung stellt korrekte Buchungen sicher und gibt genehmigte Stunden für Abrechnung und Controlling frei.

Ergebnis: Genehmigte Zeiteinträge, freigegeben für Kundenabrechnung und Controlling.

10.5 Mitarbeiter-Übersicht

10.5.1 Teamauslastung monitoren

Was: Der Teamleiter sieht die Auslastung aller Mitarbeiter in Prozent (diese Woche) mit Farbcodierung: Grün unter 80%, Gelb 80-100%, Rot über 100%. Drill-Down zeigt konkrete Tickets und Projekte.

Warum: Die Teamauslastungsübersicht erkennt Überlastung, ermöglicht Ressourcenumverteilung und dient der Burnout-Prävention.

Ergebnis: Eine Auslastungsübersicht mit Filter nach Abteilung, Standort oder Skill und Drill-Down zu Details.

10.5.2 Verfügbarkeiten prüfen

Was: Der Projektleiter wählt einen Zeitraum und sieht Mitarbeiter mit freien Kapazitäten, berücksichtigt Skills und geplanten Urlaub. Direkte Ticketzuweisung aus der Übersicht ist möglich.

Warum: Die Verfügbarkeitsprüfung ermöglicht realistische Planung neuer Projekte, optimale Ressourcennutzung und verlässliche Liefertermine.

Ergebnis: Eine Verfügbarkeitsansicht mit Skill-Filter und direkter Zuweisungsmöglichkeit.

10.5.3 Überstunden tracken

Was: Die Personalabteilung sieht den monatlichen Überstunden-Saldo pro Mitarbeiter mit Trend (steigend, konstant, abnehmend) und Ausgleichsoptionen (Freizeitausgleich oder Auszahlung).

Warum: Das Überstunden-Tracking stellt die Einhaltung gesetzlicher Anforderungen sicher, verhindert das Vergessen von Überstunden und erhöht die Mitarbeiterzufriedenheit.

Ergebnis: Ein Überstunden-Report mit Saldo, Trend und Ausgleichsmöglichkeiten inklusive direkter Antragstellung.

10.6 Monatsabschluss

10.6.1 Monatsbericht generieren

Was: Der Mitarbeiter wählt einen Monat und erhält eine Zusammenfassung: Gesamt-Stunden, Projekte, Tätigkeitsverteilung und Soll-Vergleich. Export als PDF für die Personalakte ist möglich.

Warum: Der Monatsbericht bietet Transparenz über die geleistete Arbeit, dient als Basis für die Gehaltsabrechnung und als Nachweis für Auditoren.

Ergebnis: Eine Monatszusammenfassung mit Aufschlüsselung nach Projekten und nicht-projektbezogenen Zeiten.

10.6.2 Fehlende Zeiteinträge identifizieren

Was: Das System markiert Arbeitstage ohne Zeiteinträge (außer Wochenende und Urlaub) und zeigt eine Warnung. Der Benutzer kann fehlende Tage direkt nacherfassen. Der Monat kann erst nach Vollständigkeit abgeschlossen werden.

Warum: Die Vollständigkeitsprüfung stellt lückenlose Zeiterfassung sicher, gewährleistet vollständige Projektkosten und erfüllt Compliance-Anforderungen.

Ergebnis: Identifizierte Lücken mit Nacherfassungsmöglichkeit und Sperre des Monatsabschlusses bis zur Vollständigkeit.

10.6.3 Monat abschließen

Was: Der Mitarbeiter schließt den Monat ab, woraufhin alle Einträge gegen Änderungen gesperrt werden. Der Vorgesetzte erhält eine Benachrichtigung zur finalen Freigabe, danach werden die Daten an die Lohnbuchhaltung übermittelt.

Warum: Der formale Monatsabschluss macht die Daten verbindlich, verhindert nachträgliche Manipulationen und schafft einen klaren Übergabepunkt zur Lohnbuchhaltung.

Ergebnis: Ein gesperrter Monat mit Vorgesetzten-Freigabe und Übermittlung an die Lohnbuchhaltung. Änderungen nur noch mit Admin-Rechten möglich.

10.7 Telefonate

10.7.1 Anrufe automatisch erfassen

Was: Die angebundene Telefonanlage (Starface, 3CX) übermittelt automatisch Rufnummer, Zeitpunkt und Dauer jedes Anrufs. Das System gleicht die Nummer mit dem Kundenstamm ab und zeigt den Kundennamen an.

Warum: Das automatische Logging eliminiert manuelle Anrufdokumentation und stellt sicher, dass alle Anrufe lückenlos erfasst sind.

Ergebnis: Ein Anrufprotokoll in Echtzeit mit automatischer Kundenzuordnung und Option zur manuellen Zuordnung bei unbekannten Nummern.

10.7.2 Anrufe zu Tickets verknüpfen

Was: Der Mitarbeiter wählt einen Anruf aus dem Call Log und verknüpft ihn mit einem bestehenden Ticket oder erstellt ein neues. Ein optionaler Kommentar dokumentiert den Gesprächsinhalt.

Warum: Die Verknüpfung stellt eine vollständige Kommunikationshistorie pro Ticket sicher und verhindert Informationsverluste.

Ergebnis: Ein mit dem Ticket verknüpfter Anruf-Eintrag mit Kommentar und Link zum Call-Log.

10.7.3 Anrufstatistiken auswerten

Was: Der Manager sieht KPIs: Gesamtanrufe, angenommene, verpasste, Durchschnittsdauer, Verteilung nach Mitarbeitern und Peak-Zeiten.

Warum: Die Anrufstatistiken optimieren die Personalplanung im Telefonsupport, reduzieren verpasste Anrufe und verbessern den Service-Level.

Ergebnis: Ein Statistik-Dashboard mit KPIs, Peak-Zeiten-Visualisierung und hervorgehobenen verpassten Anrufen zur Nachverfolgung.

10.8 Todo-Liste

10.8.1 Aufgaben erstellen und priorisieren

Was: Der Benutzer erstellt persönliche Todos mit Titel, Beschreibung, Fälligkeitsdatum, Priorität (Niedrig, Normal, Hoch, Kritisch) und optionaler Verknüpfung zu Kunde, Ticket oder Projekt.

Warum: Die persönliche Aufgabenverwaltung stellt sicher, dass nichts vergessen wird und die klare Priorisierung den Fokus auf Wesentliches lenkt.

Ergebnis: Eine sortierte Todo-Liste mit priorisierten Aufgaben und optionalen Entitätsverknüpfungen.

10.8.2 Fällige Aufgaben anzeigen

Was: Die Todo-Liste öffnet automatisch mit dem Filter "Fällig heute". Überfällige Aufgaben werden rot markiert, erledigte Aufgaben verschwinden aus der Hauptansicht. Eine Dashboard-Kachel zeigt die Anzahl fälliger Aufgaben.

Warum: Der automatische Fokus auf fällige Aufgaben stellt sicher, dass Deadlines eingehalten werden und der Tagesstart effizient gestaltet wird.

Ergebnis: Eine fokussierte Ansicht fälliger Aufgaben mit visueller Hervorhebung überfälliger Einträge.

10.8.3 Wiederkehrende Aufgaben einrichten

Was: Der Benutzer aktiviert bei einer Aufgabe "Wiederkehrend" mit konfigurierbarem Intervall (täglich, wöchentlich, monatlich). Nach Erledigung erstellt das System automatisch die nächste Instanz.

Warum: Wiederkehrende Todos automatisieren Routineaufgaben und stellen sicher, dass regelmäßige Prüfungen (z.B. Backup prüfen, Monatsabschluss) zuverlässig durchgeführt werden.

Ergebnis: Automatisch erstellte neue Todo-Instanzen nach Erledigung mit konfigurierbarer Vorlaufzeit.

11. Logistik

11.1 Artikelimport

11.1.1 Neue Artikel-Import-Konfiguration erstellen

Was: Der Benutzer richtet eine neue Importquelle ein: Importtyp (Single File, TechData, Wortmann etc.), Quelle (FTP, HTTP, lokale Datei), Authentifizierung, Trennzeichen, Dezimalzeichen und Kodierung.

Warum: Konfigurierte Importquellen ermöglichen regelmäßige automatisierte Artikeldaten-Aktualisierungen aus verschiedenen Distributoren und Lieferanten.

Ergebnis: Eine gespeicherte Import-Konfiguration mit allen Parametern, bereit für zeitgesteuerte oder manuelle Importe.

11.1.2 Feldmapping und Datenformate konfigurieren

Was: Der Benutzer ordnet externe Felder (z.B. "Product Code", "Description", "Price") den internen c-entron-Feldern zu, konfiguriert Validierungsregeln und sieht eine Vorschau der Zuordnung.

Warum: Flexible Feld-Mappings ermöglichen die Verarbeitung unterschiedlicher Lieferantenformate und stellen durch Validierungsregeln die Datenqualität sicher.

Ergebnis: Ein gespeichertes Feldmapping mit Validierungsregeln und Vorschau der Zuordnung.

11.1.3 Import-Dateien verarbeiten und Vorschau anzeigen

Was: Der Benutzer lädt eine Import-Datei hoch. Das System erkennt das Format automatisch, zeigt eine Vorschau der ersten 10-20 Zeilen, führt einen Duplikat-Check durch und zeigt Import-Statistiken (X neue, Y Updates, Z Fehler) vor der Bestätigung.

Warum: Die Vorschau mit Duplikat-Check ermöglicht Qualitätskontrolle vor dem eigentlichen Import und verhindert fehlerhafte Datenübernahmen.

Ergebnis: Transparente Import-Statistik mit Vorschau und Duplikat-Erkennung vor finaler Bestätigung.

11.1.4 Artikelmasterdaten aus Distributoren-Katalogen importieren

Was: Das System importiert automatisiert Produktspezifikationen, Herkunftsinformationen und Varianten aus externen Distributoren-Katalogen (z.B. TechData) und reichert lokale Artikeldaten mit zusätzlichen Attributen und Kompatibilitätsinformationen an.

Warum: Die automatische Datenanreicherung liefert vollständige Produktkataloge und verbessert die Verkaufsunterstützung durch zusätzliche Informationen.

Ergebnis: Angereicherte Artikeldaten mit Distributor-Verknüpfung, sofort verfügbar in Vertriebssystemen.

11.1.5 Import-Fehlerbehandlung und Fehler-Reports

Was: Bei Import-Fehlern dokumentiert das System den Fehlertyp, klassifiziert nach Schwere (Kritisch, Major, Minor) und erzeugt einen Fehler-Report. Der Benutzer kann fehlerhafte Zeilen ignorieren und mit dem Rest fortfahren.

Warum: Die systematische Fehlerbehandlung stellt sicher, dass Probleme schnell identifiziert und behoben werden, und verbessert die Import-Ausfallrate über die Zeit.

Ergebnis: Ein Fehler-Report mit Details pro Zeile, Klassifizierung und Option zum selektiven Import.

11.1.6 Import-Automatisierung und Zeitplanung

Was: Der Benutzer konfiguriert automatische Importe mit Zeitplan (z.B. täglich um 2:00 Uhr nachts), Benachrichtigungen bei Erfolg/Fehler und automatischer Fehlerbehebung (Retry bei Timeout).

Warum: Die vollständige Automatisierung stellt permanent aktuelle Artikeldaten sicher und eliminiert manuellen Import-Aufwand.

Ergebnis: Automatisch ausgeführte Importe im Hintergrund mit Import-Historie, E-Mail-Benachrichtigungen und Fehler-Alarmen.

11.2 Artikelverwaltung

11.2.1 Neuen Artikel erstellen

Was: Der Benutzer erfasst einen neuen Artikel mit Artikelnummer, Name, Beschreibung, Klassifikation (Materialgruppe, Kategorie), Einheit, Einkaufspreis und Barcode. Der Artikel wird im Status "Entwurf" erstellt.

Warum: Die Artikelerfassung ist die Grundlage für Einkauf, Verkauf und Lagerverwaltung. Nach Genehmigung ist der Artikel in allen Systemen verfügbar.

Ergebnis: Ein neuer Artikel im Status "Entwurf", bereit zur Freigabe und Verwendung in Bestellungen und Angeboten.

11.2.2 Artikel-Spezifikationen und technische Details hinzufügen

Was: Der Benutzer ergänzt vordefinierte und benutzerdefinierte Eigenschaften (Größe, Farbe, Gewicht, Material), lädt technische Datenblätter hoch und fügt Video-Links hinzu.

Warum: Vollständige Produktdokumentation hilft Kunden beim Artikelfinden, unterstützt das Support-Team und verbessert die Suchergebnisse.

Ergebnis: Ein umfassend dokumentierter Artikel mit durchsuchbaren Spezifikationen und angehängten Datenblättern.

11.2.3 Barcode-Verwaltung und Generierung

Was: Der Benutzer verwaltet Barcodes für Artikel in verschiedenen Formaten (EAN-13, EAN-8, CODE-128, QR-Code). Barcodes können automatisch generiert oder manuell eingegeben werden, mit Prüfsummen-Validierung.

Warum: Barcodes beschleunigen die Lagerverwaltung, automatisieren die Bestandsverfolgung und verbessern die Bestellgenauigkeit.

Ergebnis: Validierte Barcodes mit Variantenunterstützung und Export im Label-Format für den Druck.

11.2.4 Preise und Einkaufskonditionen verwalten

Was: Der Benutzer pflegt pro Lieferant den Einkaufspreis, Mengenrabatte, Lieferzeit, Mindestbestellmenge und Währung. Die Preishistorie wird archiviert.

Warum: Aktuelle Einkaufskonditionen pro Lieferant ermöglichen wettbewerbsfähige Einkaufspreise, automatische Kalkulation und kontrollierte Gewinnmargen.

Ergebnis: Eine gepflegte Preismatrix pro Artikel-Lieferant mit historischen Preisen und automatischer Übernahme aus EDI-Importen.

11.2.5 Einheits-Umrechnung und Varianten

Was: Der Benutzer definiert eine Basiseinheit mit alternativen Einheiten und Umrechnungsfaktoren (z.B. 1 Palette = 80 Kartons) sowie Artikelvarianten (Größe, Farbe, Konfiguration) mit jeweils eigener Artikelnummer.

Warum: Einheiten-Umrechnung und Varianten ermöglichen flexible Bestellungen (Einkauf in Paletten, Verkauf in Stück) und präzise Lagerverwaltung pro Variante.

Ergebnis: Konfigurierte Einheitsumrechnungen und Varianten mit eigenständiger Lagerverwaltung und Preispflege.

11.2.6 Lagerbestand-Management und Schwellenwerte

Was: Der Benutzer definiert Mindestbestand, Maximalbestand und Reorder-Point pro Artikel. Bei Unterschreitung des Mindestbestands wird automatisch eine Nachbestellung ausgelöst.

Warum: Schwellenwerte-basiertes Bestandsmanagement minimiert Überbestände, verhindert Lieferverzögerungen und optimiert die Kapitalbindung.

Ergebnis: Konfigurierte Schwellenwerte mit automatischer Bestellauslösung und Überalterungs-Warnung für verderbliche Waren.

11.2.7 Artikel einer Warengruppe zuweisen

Was: Der Benutzer ordnet einen Artikel einer Warengruppe zu, die Voraussetzung für Warengruppen-Analysen und Provisionsberechnung ist.

Warum: Die Warengruppenstruktur ermöglicht Umsatzanalysen, Provisionsberechnung und Sortimentsmanagement auf Gruppenebene.

Ergebnis: Ein warengruppenverknüpfter Artikel mit geerbten Eigenschaften und Auswertungsmöglichkeiten.

11.2.8 Artikel einem Lieferanten zuordnen

Was: Der Benutzer verknüpft einen Artikel mit einem Lieferanten inklusive Einkaufskonditionen.

Warum: Die Lieferantenzuordnung ist Voraussetzung für automatische Bestellvorschläge und ermöglicht lieferantenspezifische Preisvergleiche.

Ergebnis: Eine Artikel-Lieferant-Verknüpfung mit Einkaufskonditionen.

11.2.9 Artikel einer Steuerkategorie zuordnen

Was: Der Benutzer weist dem Artikel den korrekten MwSt-Satz zu (z.B. 19% Standard, 7% ermäßigt).

Warum: Die korrekte Steuerkategorie ist Voraussetzung für die fehlerfreie Rechnungsstellung und Steuerberechnung.

Ergebnis: Ein steuerlich korrekt konfigurierter Artikel.

11.2.10 Artikel einem Lagerort zuweisen

Was: Der Benutzer legt den Standard-Lagerort und Lagerplatz für einen Artikel fest.

Warum: Die Lagerortzuweisung optimiert Kommissionierungswege und ermöglicht lagerortspezifische Bestandsabfragen.

Ergebnis: Ein Artikel mit zugewiesenem Standard-Lagerort.

11.2.11 Artikel deaktivieren/archivieren

Was: Der Benutzer deaktiviert einen Artikel ohne Löschung, nachdem das System auf offene Bestellungen und Verträge geprüft hat.

Warum: Die Deaktivierung statt Löschung bewahrt historische Daten (Rechnungen, Bestellungen) und verhindert die weitere Verwendung in neuen Vorgängen.

Ergebnis: Ein deaktivierter Artikel, nicht mehr für neue Vorgänge verfügbar, historische Daten bleiben erhalten.

11.3 Inventur

11.3.1 Inventur planen und initialisieren

Was: Der Benutzer wählt Inventurtyp (vollständig oder teilweise), Lagerorte, Datum und Gruppen. Das System erzeugt automatisch Inventurlisten mit QR-Code-/Barcode-Labels und benachrichtigt das Lagerpersonal.

Warum: Die strukturierte Inventurplanung stellt sicher, dass Lagerbestände zu einem einheitlichen Zeitpunkt aufgenommen und die Ergebnisse vergleichbar sind.

Ergebnis: Eine initialisierte Inventur im Status "Offen" mit gedruckten Listen und benachrichtigtem Personal.

11.3.2 Artikel erfassen während Bestandsaufnahme

Was: Der Lagermitarbeiter scannt Artikel-Barcodes oder gibt Artikelnummern manuell ein und erfasst die gezählte Menge mit optionalen Bemerkungen. Im Offline-Modus werden Daten lokal gespeichert und später synchronisiert.

Warum: Die Barcode-gestützte Erfassung beschleunigt den Inventurprozess, reduziert Zählfehler und ermöglicht auch ohne Netzwerkverbindung die Erfassung.

Ergebnis: Erfasste Istbestände pro Artikel mit Zeitstempel, Benutzer und Synchronisationsstatus.

11.3.3 Abweichungen analysieren und korrigieren

Was: Nach der Inventur zeigt das System Sollbestand vs. Istbestand pro Artikel, klassifiziert Abweichungen nach Größe und ermöglicht die Erfassung von Ursachen (Lagerfehler, Systemfehler, Schwund, falscher Lagerort).

Warum: Die Abweichungsanalyse identifiziert Ursachen von Bestandsfehlern und minimiert durch gezielte Maßnahmen die Schwundrate.

Ergebnis: Ein dokumentierter Abweichungs-Report mit Ursachen, genehmigter Bestandskorrektur und Audit-Protokoll.

11.3.4 Inventur abschließen und Bestandskorrektur

Was: Nach Vollständigkeitsprüfung und Klärung aller Abweichungen schließt der Benutzer die Inventur ab. Das System generiert Bestandskorrektur-Buchungen, erstellt Finanzbuchungen bei Abweichungen über der Toleranz und versendet den Inventur-Report.

Warum: Der formale Abschluss aktualisiert die Lagerverwaltung und Finanzbuchhaltung auf Basis der tatsächlichen Zählung.

Ergebnis: Aktualisierte Lagerbestände, Korrektur-Buchungen, Finanzbuchungen und archivierter Inventur-Report.

11.3.5 Inventur-Ergebnisse und Kennzahlen

Was: Reports zeigen Gesamt-Abweichungsquote, Abweichungen nach Artikelgruppe und Lagerort, Schwund-Analyse und Trends über mehrere Inventuren.

Warum: Die Kennzahlen machen die Bestandsverwaltungsqualität transparent und identifizieren systematische Verbesserungspotenziale.

Ergebnis: Exportierbare Reports (Excel, PDF) mit Trend-Analyse und Management-Kennzahlen.

11.3.6 Seriennummern und Chargenverfolgung in Inventur

Was: Bei verfolgungspflichtigen Artikeln werden Seriennummern erfasst und gegen die Lagerverwaltung validiert. Chargennummern und Verfallsdaten werden geprüft, abgelaufene Chargen werden markiert.

Warum: Die Seriennummernverfolgung erfüllt Compliance-Anforderungen, automatisiert das Verfallsdatum-Management und identifiziert zu vernichtende Bestände.

Ergebnis: Validierte Seriennummern und Chargen mit Verfallsdatum-Prüfung und Markierung abgelaufener Waren.

11.3b Warenausgang

11.3b.1 Warenausgang aus Lieferschein buchen

Was: Bei Erstellung eines Lieferscheins wird automatisch die Lagerausbuchung durchgeführt: Mengenreduzierung im Lager mit vollständiger Protokollierung.

Warum: Die automatische Lagerausbuchung stellt sicher, dass Bestände sofort korrekt sind und keine manuellen Buchungen vergessen werden.

Ergebnis: Reduzierter Lagerbestand mit protokollierter Bestandsbewegung.

11.3b.2 FIFO-/Seriennummern-Auswahl beim Ausbuchen

Was: Bei der Ausbuchung wählt der Benutzer die auszubuchenden Chargen oder Seriennummern nach FIFO-Prinzip (älteste zuerst) oder per manueller Selektion.

Warum: Die FIFO-Logik minimiert Überalterung und stellt bei verfolgungspflichtigen Artikeln die korrekte Chargenidentifikation sicher.

Ergebnis: Korrekt ausgebuchte Chargen/Seriennummern nach FIFO oder manueller Auswahl.

11.3b.3 Bestandsaktualisierung nach Warenausgang

Was: Nach der Warenausgangsbuchung werden alle verknüpften Bestandsansichten sofort aktualisiert.

Warum: Die Echtzeit-Aktualisierung verhindert Überverkäufe und stellt sicher, dass alle Systemteile den aktuellen Bestand sehen.

Ergebnis: Sofort aktualisierte Bestände in allen Ansichten und Auswertungen.

11.3b.4 Warenausgangs-Protokoll

Was: Das System erstellt einen lückenlosen Nachweis aller Warenausgänge mit Datum, Artikel, Menge, Seriennummer, Empfänger und Belegreferenz.

Warum: Das Protokoll erfüllt Nachweispflichten, ermöglicht Rückverfolgung und unterstützt Audit-Anforderungen.

Ergebnis: Ein vollständiges Warenausgangs-Protokoll mit allen relevanten Informationen.

11.3c Bestandsführung

11.3c.1 Lagerbestandsabfrage

Was: Der Benutzer fragt den aktuellen Bestand ab: Menge gesamt, reserviert und verfügbar, filterbar nach Artikel, Lagerort und Warengruppe.

Warum: Die Echtzeit-Bestandsabfrage ist Grundlage für Verkaufsentscheidungen, Bestellvorschläge und Kundenauskunft.

Ergebnis: Eine aktuelle Bestandsübersicht mit Filter- und Drill-Down-Möglichkeiten.

11.3c.2 Lagerumbuchung zwischen Lagerorten

Was: Der Benutzer verschiebt Bestände zwischen Lagerorten (z.B. Hauptlager zu Außenlager) mit Buchungsbeleg und Mengenvalidierung.

Warum: Lagerumbuchungen optimieren die Bestandsverteilung und stellen sicher, dass Bestände dort verfügbar sind, wo sie gebraucht werden.

Ergebnis: Durchgeführte Umbuchung mit Buchungsbeleg und aktualisierten Beständen an beiden Lagerorten.

11.3c.3 Manuelle Bestandskorrektur

Was: Der Benutzer korrigiert Lagerbestände mit Pflicht-Begründung (Schwund, Bruch, Fehlbuchung). Ein Korrekturbeleg wird automatisch erzeugt.

Warum: Manuelle Korrekturen gleichen Differenzen zwischen System- und Realbestand aus und dokumentieren den Grund lückenlos.

Ergebnis: Korrigierter Bestand mit Korrekturbeleg und Begründung im Audit-Trail.

11.3c.4 Mindestbestandswarnungen

Was: Das System benachrichtigt automatisch, wenn der Bestand eines Artikels unter den konfigurierten Mindestbestand fällt, und verknüpft die Warnung mit der Bestellvorschlagsliste.

Warum: Automatische Warnungen verhindern Lieferengpässe und lösen rechtzeitig Nachbestellprozesse aus.

Ergebnis: Automatische Benachrichtigung mit Verknüpfung zur Bestellvorschlagsliste.

11.3c.5 Bestandsabstimmung (Soll/Ist-Vergleich)

Was: Das System vergleicht Buchbestände (System) mit physischen Beständen und erstellt eine Abweichungsliste mit Korrekturvorschlägen.

Warum: Die regelmäßige Abstimmung stellt Bestandsgenauigkeit sicher und identifiziert systematische Fehlerquellen.

Ergebnis: Eine Abweichungsliste mit Korrekturvorschlägen und Analysemöglichkeit.

11.4 Kommissionierung

11.4.1 Bestellungen für Kommissionierung auswählen

Was: Der Benutzer sieht eine priorisierte Liste von Bestellungen mit Auftragstyp, Status und Priorität, filtert nach Liefertyp und wählt Bestellungen zur Generierung von Kommissionieraufträgen aus.

Warum: Die strukturierte Auswahl und Priorisierung stellt sicher, dass VIP-Aufträge bevorzugt und Eillieferungen rechtzeitig bearbeitet werden.

Ergebnis: Generierte Kommissionieraufträge in festgelegter Bearbeitungsreihenfolge.

11.4.2 Artikel kommissionieren und scannen

Was: Der Lagermitarbeiter navigiert zum Lagerlocation, scannt den Location-Barcode, dann den Artikel-Barcode, und das System validiert: Richtiger Artikel? Richtige Menge? Nach Abschluss aller Picks wird der Bestand aktualisiert.

Warum: Die Barcode-Validierung senkt die Fehlerquote bei der Kommissionierung, beschleunigt den Prozess und garantiert Bestandsgenauigkeit.

Ergebnis: Erfolgreich kommissionierte Artikel mit automatischer Bestandsbuchung und dokumentiertem Pick-Verlauf.

11.4.3 Seriennummern und Verfallsdatum tracken

Was: Bei Artikeln mit Seriennummern werden diese beim Pick erfasst und validiert. FIFO-Logik wird angewendet (älteste Chargen zuerst), Verfallsdatum-Warnungen werden angezeigt.

Warum: Das FIFO-Tracking verhindert den Versand abgelaufener Waren, erfüllt Compliance-Anforderungen und dokumentiert Seriennummern in Versandetiketten.

Ergebnis: Validierte Seriennummern mit FIFO-Einhaltung und Verfallsdatum-Dokumentation.

11.4.4 Lagerbestände aktualisieren bei Kommissionierung

Was: Nach erfolgreicher Kommissionierung werden Bestandsbewegungen generiert (von Lagerlocation zu Versand-Staging) und die Echtzeit-Bestandssicht aktualisiert.

Warum: Die sofortige Bestandsaktualisierung verhindert Überbuchungen und stellt sicher, dass alle Systeme den aktuellen Bestand sehen.

Ergebnis: Aktualisierte Lagerbestände mit dokumentierter Bestandsbewegung und Audit-Trail.

11.4.5 Unfähige-Picks und Abweichungen behandeln

Was: Wenn ein Artikel nicht am erwarteten Lagerort gefunden wird, zeigt das System Alternativen (anderer Lagerort) an. Bei Nicht-Verfügbarkeit wird die Bestellung als "Teilweise gepickt" markiert und ein Backorder automatisch erstellt.

Warum: Die strukturierte Behandlung unerwarteter Abweichungen informiert den Kunden transparent über Verfügbarkeit und automatisiert den Backorder-Prozess.

Ergebnis: Dokumentierte Abweichung mit Alternativangebot oder Backorder und Kundeninformation.

11.4.6 Versand vorbereiten und abschließen

Was: Nach der Kommissionierung verpackt das Versandteam die Artikel, scannt den Paketbarcode und generiert Versandetiketten mit Tracking-Nummer über Integration mit Versanddienstleistern (GLS, DHL etc.). Der Kunde wird automatisch benachrichtigt.

Warum: Die integrierte Versandabwicklung beschleunigt den Versand, minimiert Fehler und bietet dem Kunden transparentes Tracking.

Ergebnis: Versandfertiges Paket mit Tracking-Nummer, Kundenbenachrichtigung und verknüpfter Sendungsverfolgung.

11.5 Lagerorte

11.5.1 Lagerorte/Lagerbereiche verwalten

Was: Der Administrator erstellt und pflegt Lagerorte und -bereiche (Halle, Regal, Fach) als hierarchische Struktur.

Warum: Definierte Lagerorte sind Voraussetzung für Inventur, Kommissionierung und Bestandsführung und ermöglichen standortspezifische Auswertungen.

Ergebnis: Konfigurierte Lagerorte, referenziert in allen lagerbezogenen Prozessen.

11.6 Versanddienstleister

11.6.1 Versanddienstleister verwalten

Was: Der Administrator erstellt und pflegt Versanddienstleister (GLS, DHL, UPS) mit API-Konfiguration für Label-Generierung und Tracking.

Warum: Konfigurierte Versanddienstleister ermöglichen automatische Versandetiketten und Sendungsverfolgung direkt aus dem System.

Ergebnis: Konfigurierte Versand-Provider, referenziert in Kommissionierung und Versand.

12. Stammdaten

12.1 Belegkonditionen

12.1.1 Zahlungsbedingungen definieren

Was: Der Administrator erstellt Zahlungsbedingungen mit Skonto-Prozentsatz, Skonto-Tagen und Zahlungsfrist (z.B. "Netto 30 Tage", "2/10 Netto 30"). Die Konditionstabelle unterstützt zweistufige Skontoregeln und verschiedene Fälligkeitsberechnungsarten.

Warum: Standardisierte Zahlungsbedingungen automatisieren Skonto-Berechnungen, steuern Mahnprozesse und stellen konsistente Konditionen über alle Geschäftspartner sicher.

Ergebnis: Konfigurierte Zahlungsbedingungen, die in Bestellungen und Rechnungen automatisch angewendet werden.

12.1.2 Lieferbedingungen konfigurieren

Was: Der Administrator erstellt Lieferbedingungen mit Incoterms (EXW, FOB, CIF, DDP), Versandart, Lieferzeiten und Versicherungsoptionen.

Warum: Standardisierte Lieferbedingungen klären die Kosten-Verantwortung zwischen Lieferant und Empfänger und machen die Gesamtkosten (TCO) berechenbar.

Ergebnis: Konfigurierte Lieferbedingungen, auswählbar in Bestellungen und Aufträgen.

12.1.3 Rabatte und Skonti verwalten

Was: Der Administrator erstellt Rabattstaffeln (Mengenrabatte), zeitlich begrenzte Aktionsrabatte und kundenspezifische Rabatte, die in Bestellungen automatisch angewendet werden.

Warum: Flexible Rabattstrukturen ermöglichen Volumen-Anreize, zeitlich begrenzte Promotionen und kundenindividuelle Konditionen.

Ergebnis: Konfigurierte Rabattstaffeln mit automatischer Anwendung in Belegen und Rabatt-Reporting.

12.1.4 Standardbedingungen zuweisen

Was: Der Administrator weist Kunden und Lieferanten Standard-Zahlungs- und Lieferbedingungen zu, die automatisch in neuen Bestellungen vorgefüllt werden.

Warum: Standardbedingungen beschleunigen die Bestellungserstellung, stellen konsistente Partnerbehandlung sicher und minimieren Eingabefehler.

Ergebnis: Zugewiesene Standardbedingungen, automatisch in neue Belege übernommen mit Möglichkeit zur einzelnen Anpassung.

12.1.5 Bedingungen-Reports und Audit

Was: Der Administrator erstellt Reports über Bedingungen-Verwendung, identifiziert Abweichungen (z.B. "Kunde XYZ erhält 50% statt Standard 5%") und prüft den Änderungs-Audit-Trail.

Warum: Transparente Reporting und Audit-Trail stellen Compliance sicher, unterstützen datengetriebene Verhandlungen und dokumentieren Änderungen lückenlos.

Ergebnis: Reports über Verwendungshäufigkeit und Abweichungen mit vollständigem Audit-Trail.

12.2 Data Updater

12.2.1 Artikel-Preise stapelweise aktualisieren

Was: Der Administrator wählt einen Artikelfilter, definiert eine Änderungsregel (z.B. "+10% auf alle Preise") und sieht eine Vorschau der betroffenen Artikel und neuen Preise vor der Durchführung.

Warum: Massenpreisanpassungen sparen erheblich Zeit gegenüber Einzelerfassung und gewährleisten konsistente Preisänderungen über alle betroffenen Artikel.

Ergebnis: Aktualisierte Preise mit dokumentiertem Update-Report und Rollback-Möglichkeit.

12.2.2 Artikel-Attribute in Batch ändern

Was: Der Administrator ändert Kategorie, Materialgruppe oder Lieferant für viele Artikel gleichzeitig per Template-Anwendung (z.B. "Alle 250 Artikel der Kategorie 'Veraltet' verschieben nach 'Sonderangebote'").

Warum: Katalogneuorganisationen und Massenänderungen werden schnell und fehlerfrei durchgeführt statt mühsam einzeln.

Ergebnis: Aktualisierte Artikel-Attribute mit Audit-Log der Massenoperation.

12.2.3 Bestellungen-Massendaten-Korrektur

Was: Der Administrator identifiziert fehlerhafte Bestellungsdaten, setzt einen Filter auf die betroffenen Datensätze und führt eine Batch-Korrektur durch.

Warum: Flächendeckende Korrekturen (z.B. falsche Lagerort-Zuordnung an einem bestimmten Tag) werden in einem Schritt statt einzeln durchgeführt.

Ergebnis: Korrigierte Bestellungsdaten mit Korrektur-Report und konsistenten Daten für Reporting und Finanzbuchhaltung.

12.2.4 Validierung und Plausibilitätsprüfung

Was: Vor jeder Massenänderung führt das System automatisch Validierungen durch (Datentypen, Constraints, Konflikte) und zeigt einen Validierungs-Report.

Warum: Die automatische Validierung garantiert Datenqualität und Datenbankintegrität, sodass Rollbacks nicht nötig werden.

Ergebnis: Ein Validierungs-Report mit fehlerfreier Durchführung oder Protokollierung fehlerhafter Datensätze.

12.2.5 Update-Historie und Rollback

Was: Der Administrator kann die Update-Historie einsehen ("Wer hat wann was geändert?") und bei Bedarf einen Rollback durchführen, um vorherige Datenstände wiederherzustellen.

Warum: Die Rollback-Möglichkeit schafft Sicherheit bei Massenänderungen und stellt bei Fehlern den Ausgangszustand wieder her.

Ergebnis: Vollständige Update-Historie mit dokumentiertem Rollback und Benachrichtigung.

12.3 Kostenträger/Kostenstellen

12.3.1 Kostenstelle erstellen und strukturieren

Was: Der Controller erstellt hierarchische Kostenstellen (z.B. Sales, Administration, Produktion) mit Verantwortlichem und Budget. Die Kostenstellen sind in Belegen selektierbar.

Warum: Kostenstellen ermöglichen verursachergerechte Kostenverteilung, klare Kostenverantwortung und gesteuerte Budgets.

Ergebnis: Konfigurierte Kostenstellen-Hierarchie, referenziert in Rechnungen, Bestellungen und Buchungen.

12.3.2 Kostenträger und Projekt-Kostenrechnung

Was: Der Projektmanager erstellt Kostenträger für Projekte, ordnet alle anfallenden Kosten zu (externe Kosten, Personalkosten, Materialkosten) und erhält einen Rentabilitäts-Report.

Warum: Kostenträger ermöglichen die genaue Berechnung der Projektrentabilität und die Einhaltung von Projektbudgets.

Ergebnis: Ein Kostenträger mit zugeordneten Kosten, Rentabilitäts-Report und Budget-Abweichungswarnung.

12.3.3 Budgetierung und Forecast

Was: Der Controller definiert Jahresbudgets pro Kostenstelle, erstellt monatliche Forecasts basierend auf bisherigen Ausgaben und erhält automatische Warnungen bei Überschreitungen (80%, 95%, 100%).

Warum: Proaktive Budgetkontrolle vermeidet Überraschungen, sichert die Finanzierung und integriert Prognosen in die Finanzberichte.

Ergebnis: Budgets mit Forecast, automatischen Warnungen und Integration in Finanzberichte.

12.3.4 Kosten-Umlagen und Verteilungen

Was: Der CFO definiert Verteilschlüssel (z.B. "Miete anteilig nach Fläche: Produktion 60%, Admin 30%, Sales 10%"). Das System berechnet automatisch die Anteile und verbucht die verteilten Kosten.

Warum: Kosten-Umlagen ordnen Gemeinkosten verursachergerecht zu und ermöglichen die genaue Berechnung der Rentabilität pro Kostenstelle.

Ergebnis: Automatisch berechnete und verbuchte Kostenumlagen mit transparenter Dokumentation des Verteilschlüssels.

12.3.5 Kostenstellen-Reporting und Analyse

Was: Der Manager fordert Reports an, z.B. "Kostenentwicklung Sales 2024 vs. 2025", mit Budget, Forecast, Actual und Abweichung. Vergleiche zwischen Kostenstellen und Trend-Identifikation sind möglich.

Warum: Datengetriebenes Kostenmanagement identifiziert Effizienzpotenziale und ermöglicht gezielte Optimierungen.

Ergebnis: Exportierbare Reports mit Plan-Ist-Vergleich, Trend und Kostenstellen-Vergleich.

12.3.6 Kostenstelle einem Beleg zuweisen

Was: Der Benutzer ordnet einer Rechnung, Bestellung oder Buchung eine Kostenstelle zu.

Warum: Die Belegzuordnung ermöglicht die korrekte Zurechnung der Kosten in der internen Leistungsverrechnung.

Ergebnis: Ein belegverknüpfter Kostenstelleneintrag für die Kostenrechnung.

12.4 Länderverwaltung

12.4.1 Länder und Regionen konfigurieren

Was: Der Administrator erstellt Länder mit Regionen (Bundesländer), Lieferzonen, Standardwährung, Sprache und ISO-Codes. Die Ländertabelle enthält gleichzeitig die Währungsinformation (Name, ISO, Wechselkurs).

Warum: Korrekt konfigurierte Länder und Regionen sind Grundlage für Versandorganisation, automatische Währungskonvertierung und landesspezifische Belegsprache.

Ergebnis: Konfigurierte Länderdaten, referenziert in Adressverwaltung, Belegwesen und Versand.

12.4.2 Steuersätze pro Land verwalten

Was: Der Administrator konfiguriert MwSt-Sätze pro Land (z.B. Deutschland: 19% Standard, 7% ermäßigt, 0% Export; Schweiz: 7,7% Standard) mit Gültigkeitsdatum und automatischer Anwendung.

Warum: Korrekte länderspezifische Steuersätze stellen die steuerliche Compliance bei internationalen Geschäften sicher und werden automatisch in Rechnungen angewendet.

Ergebnis: Länderspezifische Steuersätze mit Gültigkeitsdaten und automatischer Anwendung in Belegen.

12.4.3 Versand- und Lieferbestimmungen pro Land

Was: Der Administrator definiert länderspezifische Versandzeiten und Porto (z.B. Deutschland: 2-3 Tage, 4,99 Euro; Schweiz: nur Kurier, 15,99 Euro) mit Warnung bei nicht lieferbaren Ländern.

Warum: Transparente Versandkosten und Lieferzeiten ermöglichen korrekte Bestellbestätigungen und klare Kundenerwartungen.

Ergebnis: Konfigurierte Versandbestimmungen pro Land, angezeigt in Bestellbestätigungen.

12.4.4 Compliance und Regulations-Anforderungen

Was: Der Administrator dokumentiert länderspezifische regulatorische Anforderungen (z.B. DSGVO für Deutschland, DataProtectionAct für die Schweiz) und integriert Compliance-Checks in die Geschäftsprozesse.

Warum: Dokumentierte Regulations-Anforderungen stellen Compliance sicher und minimieren rechtliche Risiken bei internationaler Geschäftstätigkeit.

Ergebnis: Dokumentierte Compliance-Anforderungen mit Status-Reports und Audit-Trail.

12.4.5 Länderpräferenzen und Konfiguration

Was: Der Administrator aktiviert/deaktiviert Länder, konfiguriert Währungs-Konvertierungskurse, Telefon-Formate und Adressformate pro Land.

Warum: Die Länderkonfiguration unterstützt internationale Geschäftstätigkeit, automatisiert Dateneingabe und minimiert Formatfehler.

Ergebnis: Konfigurierte und sofort wirksame Länderpräferenzen.

12.5 Mehrwertsteuer

12.5.1 Steuerkategorien und Sätze definieren

Was: Der Administrator erstellt Steuerkategorien (z.B. "Standardartikel" 19%, "Lebensmittel" 7%, "Medikamente" 0%) und ordnet Artikel diesen Kategorien zu. Die MwSt-Tabelle enthält auch Erlöskonten und BuHa-Steuerschlüssel.

Warum: Korrekte Steuerkategorien sind Voraussetzung für fehlerfreie Rechnungsstellung, automatische Steuerberechnung und Compliance.

Ergebnis: Konfigurierte Steuerkategorien mit automatischer Anwendung in Rechnungen.

12.5.2 Steuerbefreiungen und Ausnahmen

Was: Der Administrator erstellt Ausnahmeregelungen (z.B. "Export außerhalb EU = 0% MwSt") mit automatischer Anwendung basierend auf Lieferadresse und EU-MwSt-Nummern-Validierung.

Warum: Korrekte Steuerbefreiungen bei Exporten sparen Kosten und stellen Compliance mit der Umsatzsteuer-Richtlinie sicher.

Ergebnis: Automatisch angewendete Steuerbefreiungen mit EU-MwSt-Nummern-Validierung.

12.5.3 Steuersätze nach Lieferland

Was: Das System bestimmt automatisch den MwSt-Satz basierend auf der Lieferadresse (z.B. Österreich 20%, Schweiz 7,7%, Luxemburg 17%).

Warum: Die automatische Satzbestimmung stellt korrekten Mehrländer-Verkauf sicher, erleichtert die Steuererklärung und verhindert manuelle Fehler.

Ergebnis: Automatisch berechnete länderspezifische Steuersätze in Rechnungen.

12.5.4 Steuersatz-Änderungen verwalten

Was: Der Administrator erfasst Satzänderungen mit Gültigkeitsdatum (z.B. "Ab 01.01.2024: 19% wird 20%"). Das System erkennt automatisch, ob eine Rechnung mit dem alten oder neuen Satz zu berechnen ist, und unterstützt einen konfigurierbaren Übergangszeitraum.

Warum: Gesetzliche Steuersatzänderungen müssen korrekt abgebildet werden, um fehlerhafte Rechnungen und Audit-Probleme zu vermeiden.

Ergebnis: Konfigurierte Satzänderungen mit automatischer Erkennung und Reports über Auswirkungen.

12.5.5 Steuerzahlungen und Abrechnung

Was: Der Controller fordert einen MwSt-Schuld-Report an (Eingangssteuern minus Ausgangssteuern = Zahllast), detailliert nach Steuerkategorie, mit Möglichkeit zum Export im ELSTER-Format.

Warum: Die automatische Berechnung der Steuerzahllast stellt fristgerechte Zahlungen sicher und vereinfacht die Steuererklärung.

Ergebnis: Ein MwSt-Report mit Zahllast-Berechnung und ELSTER-Export.

12.6 Projektpreis Import

12.6.1 Projekt-Preis-Tabelle importieren

Was: Der Administrator lädt eine Excel-Datei mit Artikelnummer, Kundennummer, Projekt und Spezialpreis hoch. Das System validiert die Datei (alle Artikel und Kunden existieren?) und zeigt eine Vorschau vor dem Import.

Warum: Projekt- und kundenspezifische Preise ermöglichen individuelle Vereinbarungen und werden automatisch in Bestellungen angewendet.

Ergebnis: Importierte Projektpreise mit Validierung und Vorschau.

12.6.2 Projekt-Preise in Bestellungen anwenden

Was: Bei Bestellungen für ein bestimmtes Projekt erkennt das System automatisch spezielle Kunde-Projekt-Preise und rechnet mit dem Projektpreis statt dem Standardpreis.

Warum: Die automatische Preiserkennung stellt sicher, dass Kundenvereinbarungen zuverlässig eingehalten werden und keine manuellen Preisanpassungen nötig sind.

Ergebnis: Bestellpositionen mit automatisch angewendetem Projektpreis und Dokumentation der Preisquelle.

12.6.3 Preis-Effektivität und Rabatt-Tracking

Was: Reports zeigen angewendete Projektpreise mit durchschnittlichem Rabatt, Trend und Gesamtvolumen pro Projekt.

Warum: Die Analyse der Rabatt-Effektivität ermöglicht datengetriebene Anpassung von Rabattstrategien und kontrollierte Profitabilität.

Ergebnis: Ein Rabatt-Tracking-Report mit Trend und Durchschnittswerten pro Projekt.

12.6.4 Gültigkeitsdauern und Ablauf

Was: Projektpreise werden mit Gültigkeitszeitraum versehen. Nach Ablauf kehrt das System automatisch zu Standardpreisen zurück und sendet eine Benachrichtigung zur Neuverhandlung.

Warum: Automatischer Ablauf verhindert die unbegrenzte Fortführung temporärer Sonderkonditionen und stellt rechtzeitige Neuverhandlungen sicher.

Ergebnis: Automatischer Rückfall auf Standardpreise nach Ablauf mit Benachrichtigung und Möglichkeit zur Verlängerung.

12.6.5 Sonder-Vereinbarungen verwalten

Was: Der Administrator erstellt zeitlich begrenzte Sonderkonditionen (z.B. "Kunde ABC erhält 25% Rabatt auf alle IT-Artikel für Projekt Netzwerk-Upgrade bis 31.12.2025"). Das System wendet den Rabatt automatisch an.

Warum: Die automatische Einhaltung von Sondervereinbarungen stärkt das Kundenvertrauen und verhindert Streitfälle.

Ergebnis: Konfigurierte Sondervereinbarung mit automatischer Anwendung, Gültigkeitsbegrenzung und Compliance-Reports.

12.7 Reportverwaltung

12.7.1 Report-Templates erstellen

Was: Der Report-Designer erstellt Vorlagen mit Daten-Query, Layout (Header, Tabellen, Diagramme) und Formatierung. Das Template ist sofort für alle Benutzer nutzbar.

Warum: Standardisierte Report-Vorlagen beschleunigen die Berichtserstellung, gewährleisten Konsistenz und machen Berichte wiederverwendbar.

Ergebnis: Ein gespeichertes Report-Template, sofort einsetzbar.

12.7.2 Reports zeitlich planen

Was: Der Manager plant Reports zeitgesteuert (z.B. "Verkaufs-Report täglich um 6:00 Uhr") mit automatischem E-Mail-Versand an definierte Empfänger. Reports werden automatisch archiviert.

Warum: Automatische Report-Erstellung stellt sicher, dass Entscheider ohne manuellen Aufwand regelmäßig aktuelle Daten erhalten.

Ergebnis: Automatisch erstellte und versendete Reports zum geplanten Zeitpunkt.

12.7.3 Report-Filter und Dimensionen

Was: Der Benutzer wendet flexible Filter auf Reports an (Region, Kunden, Zeitraum), nutzt Drilldown-Funktionen und erhält den Report nach Filterung neu berechnet.

Warum: Flexible Filterung ermöglicht unterschiedliche Perspektiven auf dieselben Daten und beantwortet spezifische Geschäftsfragen schneller.

Ergebnis: Ein gefilterter Report mit Drilldown-Möglichkeiten und Neuberechnung.

12.7.4 Report-Verteilung und Genehmigung

Was: Für sensitive Reports können Genehmigungsregeln definiert werden (z.B. "Muss von CFO genehmigt werden"). Erst nach Genehmigung wird der Report an das Management-Team verteilt.

Warum: Genehmigungslogik schützt sensible Informationen und stellt kontrollierte Governance bei der Report-Verteilung sicher.

Ergebnis: Ein genehmigter und kontrolliert verteilter Report mit Genehmigungsprotokoll.

12.7.5 Report-Archivierung und Compliance

Was: Das System archiviert Reports täglich mit konfigurierbarer Aufbewahrungsfrist (z.B. "5 Jahre für Finanz-Reports") und Audit-Trail über Zugriffe.

Warum: Die Langzeitarchivierung erfüllt Compliance-Anforderungen, macht historische Daten verfügbar und dokumentiert alle Zugriffe.

Ergebnis: Archivierte Reports mit Aufbewahrungsstatus, Zugriffs-Audit-Trail und Compliance-Report.

12.8 Warengruppenverwaltung

12.8.1 Warengruppen-Hierarchie aufbauen

Was: Der Administrator erstellt Hauptgruppen (z.B. "IT Hardware") mit Untergruppen ("Computer" zu "Laptops", "Desktops", "Server"). Jeder Artikel wird einer Blatt-Kategorie zugeordnet. Die Warengruppe enthält auch Erlöskonten für Inland, EU und Übersee.

Warum: Die hierarchische Warengruppenstruktur organisiert den Produktkatalog, ermöglicht intuitive Navigation und ist Grundlage für Umsatzanalysen und Erlöskontenzuordnung.

Ergebnis: Eine konfigurierte Warengruppen-Hierarchie, nutzbar für Navigation, Reporting und Provisionsberechnung.

12.8.2 Warengruppen-Eigenschaften und Standards

Was: Der Administrator definiert pro Warengruppe Standard-Lagerdauer, Margenerwartung und bevorzugten Lieferanten. Neue Artikel dieser Gruppe erben diese Standards automatisch.

Warum: Gruppenstandards beschleunigen die Artikelanlage, stellen konsistente Kalkulation sicher und ermöglichen gruppenbasierte Abweichungsanalysen.

Ergebnis: Konfigurierte Gruppenstandards mit automatischer Vererbung an neue Artikel.

12.8.3 Steuern und Konditionen pro Warengruppe

Was: Der Administrator weist MwSt-Sätze auf Warengruppenebene zu (z.B. "Lebensmittel" 7%, "Technische Geräte" 19%). Neue Artikel erben den Steuersatz der Gruppe automatisch.

Warum: Die Steuerzuweisung auf Gruppenebene stellt korrekte Besteuerung sicher und reduziert den Konfigurationsaufwand bei der Artikelanlage.

Ergebnis: Warengruppenbasierte Steuerzuweisung mit automatischer Vererbung.

12.8.4 Warengruppen-Leistung und Analytics

Was: Reports zeigen Umsatz, Marge und Wachstumstrends pro Warengruppe (z.B. "IT Hardware: 500.000 Euro, 22% Marge, +15% YoY") mit Identifikation von Unterperformance.

Warum: Die gruppenbasierte Leistungsanalyse optimiert das Portfolio datengetrieben und setzt Ressourcen gezielt in den profitabelsten Bereichen ein.

Ergebnis: Ein Warengruppen-Performance-Report mit Umsatz, Marge, Wachstum und Vergleich.

12.8.5 Warengruppen-Umstrukturierung und Umbau

Was: Der Administrator plant Umstrukturierungen (z.B. Zusammenführung von "Old Models" und "Refurbished"), ordnet Artikel neu zu und das System validiert, dass keine Artikel verloren gehen. Alte Gruppen werden archiviert.

Warum: Die kontrollierte Umstrukturierung hält den Katalog aktuell, bildet Organisationsänderungen ab und gewährleistet Kontinuität.

Ergebnis: Aktualisierte Gruppenstruktur mit neu zugeordneten Artikeln und archivierten Altgruppen.

12.9 Währungen

12.9.1 Währungen verwalten

Was: Der Administrator erstellt und pflegt Währungen mit aktuellen Wechselkursen.

Warum: Korrekte Währungsdaten sind Voraussetzung für Multi-Währungs-Einkauf und internationale Abrechnung.

Ergebnis: Konfigurierte Währungen, referenziert in Einkauf und Belegwesen.

12.10 Einheiten

12.10.1 Einheiten verwalten

Was: Der Administrator erstellt und pflegt Mengeneinheiten (Stück, Stunde, Kilogramm etc.).

Warum: Definierte Mengeneinheiten sind Voraussetzung für korrekte Artikelverwaltung und Bestellmengenberechnung.

Ergebnis: Konfigurierte Einheiten, referenziert in der Artikelverwaltung.

13. Verträge

13.1 Dynamischer Datenimport

13.1.1 Externe Datenquellen verbinden und konfigurieren

Was: Der Benutzer öffnet das Modul für dynamischen Datenimport, wählt eine externe Datenquelle (z.B. Lieferanten-Gateway, Custom API), konfiguriert Credentials und Verbindungsparameter, testet die Verbindung und speichert die Konfiguration.

Warum: Konfigurierte Datenquellen ermöglichen vollautomatisierte Datenabfragen ohne manuelle Eingriffe, reduzieren Fehler bei der Dateneingabe und erhöhen die Verarbeitungsgeschwindigkeit von Vertragsabrechnungen.

Ergebnis: Eine gespeicherte und getestete Datenquellen-Konfiguration für wiederholte Nutzung.

13.1.2 Vertragspositionsdaten automatisch abrufen und importieren

Was: Der Benutzer definiert Abfrage-Filter (Kunde, Vertragstyp, Zeitraum), das System stellt eine Anfrage an die konfigurierte Datenquelle, formatiert und validiert die Daten, verknüpft sie mit bestehenden Verträgen und zeigt eine Vorschau vor der Bestätigung.

Warum: Der automatisierte Abruf ersetzt manuelle Copy-Paste-Operationen, erhöht die Datenqualität und spart erheblich Zeit bei regelmäßigen Abrechnungsläufen.

Ergebnis: Importierte und mit Verträgen verknüpfte Positionsdaten mit Vorschau und Bestätigungsmöglichkeit.

13.1.3 Automatische Preisberechnung aus mehreren Quellen

Was: Das System lädt Artikelstammdaten und Kundenpreise, ruft externe Preisquellen ab, wendet Rabatt- und Bonusregeln an und berücksichtigt Währungsumrechnung und Steuern. Die Preisquelle wird für den Audit-Trail dokumentiert.

Warum: Die mehrstufige Preisberechnung sichert Preisgenauigkeit, wendet automatisch Kundenvergünstigungen an und verhindert Abweichungen zwischen Quelle und Abrechnung.

Ergebnis: Korrekt berechnete und dokumentierte Preise in Vertragspositionen mit Quellennachweis.

13.1.4 Fehlerbehandlung und Validierung bei Datenabweichungen

Was: Das System führt Validierungsprüfungen durch (Formatprüfung, Wertebereich, Referenzintegrität), identifiziert fehlende oder ungültige Daten und bietet Optionen: Datensatz überspringen, Korrektur vorschlagen oder manuell bearbeiten.

Warum: Die systematische Fehlerbehandlung verhindert fehlerhafte Vertragsabrechnungen und dokumentiert alle Import-Fehler für Compliance.

Ergebnis: Ein Fehler-Report mit Zusammenfassung importierter vs. fehlgeschlagener Datensätze und Korrekturoptionen.

13.1.5 Massen-Import und Planungsintervalle

Was: Der Benutzer erstellt Import-Profile mit Zeitplan (täglich, wöchentlich, monatlich) und das System führt Importe automatisch zum geplanten Zeitpunkt aus, sendet Benachrichtigungen über Erfolg/Fehler und erstellt Audit-Reports.

Warum: Die vollständige Automatisierung regelmäßiger Importe eliminiert manuelle Eingriffe und gewährleistet konsistente Datenqualität.

Ergebnis: Automatisch ausgeführte Importe mit Audit-Report und Benachrichtigung.

13.1.6 Import-Ergebnisse analysieren und nachbearbeiten

Was: Der Benutzer öffnet den Import-Verlauf, sieht Import-Statistiken (Anzahl importiert, aktualisiert, fehlerhaft), kann einzelne Datensätze durchsehen, fehlgeschlagene erneut verarbeiten und Daten vor der Abrechnung noch korrigieren.

Warum: Die detaillierte Nachbearbeitung ermöglicht Qualitätskontrolle vor der Abrechnung und volle Transparenz über durchgeführte Datenoperationen.

Ergebnis: Analysierter Import mit Korrekturmöglichkeiten, Export des Import-Reports und archiviertem Protokoll.

13.2 Klick-Zählerverwaltung

13.2.1 Click-Counter-Lesevorgänge manuell erfassen

Was: Der Servicetechniker erfasst einen Zähler-Lesevorgang mit Geräte-Seriennummer, Lesedatum und aktuellem Zählerwert (z.B. "156.234 Kopien"). Das System validiert die Plausibilität (Zähler darf nur steigen) und berechnet den Verbrauch seit dem letzten Lesedatum.

Warum: Die dokumentierte Zählererfassung ist Grundlage für die verbrauchsabhängige Kundenabrechnung und stellt durch Plausibilitätsprüfung korrekte Zählerstände sicher.

Ergebnis: Ein gespeicherter Leseeintrag mit berechneter Verbrauchsdifferenz und Audit-Trail.

13.2.2 Zählerstände aus Excel/CSV importieren

Was: Der Benutzer importiert eine Excel- oder CSV-Datei mit Zählerständen (Geräte-ID, Zähler, Datum). Das System parst die Datei, validiert das Spaltenformat, zeigt eine Vorschau und verknüpft die Zähler mit Verträgen.

Warum: Der Massenimport ermöglicht die schnelle Verarbeitung großer Zählerdatenmengen und eliminiert manuelle Einzelerfassung.

Ergebnis: Importierte und vertragsverknüpfte Zählerstände mit Import-Report (Erfolgs-/Fehlerquote).

13.2.3 Zähler mit Verträgen verknüpfen und verwalten

Was: Der Benutzer ordnet Zählergeräte Service-Verträgen zu mit Zählerverhältnis, Abrechnungsfrequenz und Start-/Enddatum. Mehrere Zähler pro Gerät (z.B. Farb- und Schwarzweiß-Seiten) werden unterstützt.

Warum: Die klare Zuordnung zwischen Geräten und Verträgen ist Voraussetzung für flexible, gerätebezogene Abrechnung und verhindert Doppel- oder Fehlbuchungen.

Ergebnis: Konfigurierte Zähler-Vertragszuordnung mit Abrechnungssimulation basierend auf aktuellen Ständen.

13.2.4 Counter-Leseverlauf und Trend-Analyse

Was: Der Benutzer wählt ein Gerät und einen Zeitraum und sieht alle Lesevorgänge chronologisch, die durchschnittliche Nutzung pro Monat/Woche, eine Trendgrafik und eine Anomalien-Erkennung (Spitzen oder Ausfälle).

Warum: Die Trendanalyse ermöglicht Früherkennung von Gerätedefekten, Optimierung der Vertragsplanung und bessere Vorhersage zukünftiger Abrechnungsbeträge.

Ergebnis: Eine chronologische Leseverlaufsdarstellung mit Trend, Anomalieerkennung und prognostizierter nächster Abrechnung.

13.2.5 Verschiedene Counter-Formate verarbeiten (Riverbird, docuForm)

Was: Der Benutzer wählt ein Counter-Format (z.B. Riverbird, docuForm, Standard), das System lädt das entsprechende Import-Profil, konvertiert die Daten und validiert nach formatspezifischen Regeln.

Warum: Die Unterstützung verschiedener Lieferantenformate ermöglicht eine zentralisierte Zählerverwaltung trotz unterschiedlicher Datenquellen.

Ergebnis: Konvertierte und validierte Zählerdaten im Standardformat mit dokumentiertem Originalformat.

13.2.6 Abrechnungsvorschläge generieren und freigeben

Was: Das System ruft die letzten bestätigten Zählerstände ab, berechnet die Differenzen, wendet Preistabellen und Rabatte an und erstellt einen Abrechnungsvorschlag. Der Benutzer prüft, genehmigt und das System erstellt automatisch Rechnungspositionen.

Warum: Die automatische Abrechnungsvorschlagserstellung aus Zählerdaten beschleunigt die Rechnungsstellung, stellt Transparenz über die Abrechnungsgrundlagen sicher und ermöglicht Qualitätskontrolle vor der Fakturierung.

Ergebnis: Genehmigte Abrechnungsvorschläge mit automatisch erstellten Rechnungspositionen und Nachverfolgbarkeit.

13.3 Statischer Datenimport

13.3.1 Vertragspositionsdaten manuell erfassen

Was: Der Benutzer gibt manuell Vertragspositionen ein: Artikel/Leistung, Positionsnummer, Beschreibung, Menge, Preis mit Validierung (nicht-negative Mengen, gültige Preise). Ad-Hoc-Positionen ohne Artikelstamm werden unterstützt.

Warum: Die manuelle Erfassung deckt Fälle ab, in denen kein automatisierter Import möglich ist, und ermöglicht flexible Eingabe für Spezial- und Einmalpositionen.

Ergebnis: Gespeicherte Vertragspositionen, sofort für die Abrechnung verfügbar.

13.3.2 Vertragspositionsdaten aus statischen Dateien importieren

Was: Der Benutzer wählt eine Datei (Excel, CSV, Text), das System erkennt Format und Spaltenstruktur, zeigt einen Spalten-Mapping-Dialog und führt nach Bestätigung den Import durch.

Warum: Der dateibasierte Massenimport reduziert die manuelle Dateneingabe erheblich und ermöglicht wiederholbare Import-Prozesse.

Ergebnis: Importierte Vertragspositionen mit dokumentierter Datenquelle.

13.3.3 Artikel-Zuordnung und Enrichment bei Import

Was: Das System versucht per Fuzzy-Matching automatisch, importierte Positionsbeschreibungen bestehenden Artikeln zuzuordnen. Bei unsicheren Matches werden Vorschläge zur manuellen Auswahl angeboten. Bei Zuordnung werden Artikeleigenschaften (Standardpreis, Steuern) automatisch geladen.

Warum: Die automatische Artikelzuordnung stellt konsistente Verwendung von Standardpreisen und Steuern sicher und reduziert Fehler durch Validierung gegen den Artikelstamm.

Ergebnis: Zugeordnete und angereicherte Positionen mit Artikelverknüpfung und geladenen Standardwerten.

13.3.4 Validierung und Qualitätskontrolle vor Übernahme

Was: Das System führt umfassende Validierungsprüfungen durch: Formatprüfung, Referenzintegrität, Geschäftsregeln und Duplikaterkennung. Fehler werden als "Kritisch" (Import abbrechen) oder "Warnung" (mit Hinweis fortfahren) kategorisiert.

Warum: Die mehrstufige Validierung verhindert fehlerhafte Vertragspositionsdaten und ermöglicht Früherkennung von Datenqualitätsproblemen.

Ergebnis: Ein Validierungsreport mit Korrekturoptionen und Genehmigung nach erfolgreicher Validierung.

13.3.5 Import-Vorschau und Änderungs-Tracking

Was: Der Benutzer sieht eine tabellarische Preview mit Inline-Editing-Möglichkeit, Vergleich Original vs. editierte Werte, Highlights bei Unterschieden zu bestehenden Positionen und Möglichkeit zum Ausschluss einzelner Zeilen.

Warum: Die transparente Vorschau ermöglicht Feinabstimmung vor der Übernahme und stellt durch Änderungsnachverfolgung Compliance sicher.

Ergebnis: Geprüfte und ggf. angepasste Import-Daten mit Audit-Timestamp und Änderungs-Tracking.

13.3.6 Import-Verlauf und Rollback-Funktionalität

Was: Das System dokumentiert alle durchgeführten Importe mit Datum, Benutzer und Details. Der Benutzer kann einen Rollback durchführen (Import rückgängig machen), sofern noch keine Rechnungen erstellt wurden.

Warum: Die vollständige Import-Historie mit Rollback-Möglichkeit schafft Vertrauen in den Import-Prozess und ermöglicht Fehlerkorrektur ohne Datenverlust.

Ergebnis: Dokumentierte Import-Historie mit Rollback-Möglichkeit, Prüfung auf Rückgängig-Machbarkeit und Audit-Trail.

13.4 Vertragsverwaltung (CRUD und Zuweisungen)

13.4.1 Neuen Vertrag erstellen

Was: Der Benutzer legt einen neuen Vertrag an über Wizard oder Direkteingabe mit Kunde, Vertragsart, Laufzeit und Konditionen.

Warum: Die Vertragsanlage ist der Ausgangspunkt für wiederkehrende Abrechnungen und Service-Verwaltung.

Ergebnis: Ein neuer Vertrag im Status Entwurf, bereit für Konfiguration und Aktivierung.

13.4.2 Vertrag bearbeiten

Was: Der Benutzer ändert bestehende Vertragsdaten (Konditionen, Positionen, Laufzeit) mit automatischer Versionierung und Audit-Trail.

Warum: Die Versionierung dokumentiert alle Vertragsänderungen lückenlos und macht den Vertragsverlauf jederzeit nachvollziehbar.

Ergebnis: Ein aktualisierter Vertrag mit neuer Version und vollständigem Änderungsprotokoll.

13.4.3 Vertrag einem Kunden zuordnen

Was: Der Benutzer verknüpft den Vertrag mit einem bestehenden Kundenstamm-Eintrag.

Warum: Die Kundenzuordnung ist Voraussetzung für die korrekte Abrechnung und Kundenkommunikation.

Ergebnis: Ein kundenverknüpfter Vertrag.

13.4.4 Vertrag eine Vertragsart zuweisen

Was: Der Benutzer weist dem Vertrag eine Vertragsart zu.

Warum: Die Vertragsart steuert Filter- und Auswertungsmöglichkeiten in der Vertragsabrechnung.

Ergebnis: Ein typklassifizierter Vertrag, filterbar in der Abrechnungsauswahl.

13.4.5 Vertrag einer Filiale zuweisen

Was: Der Benutzer ordnet den Vertrag einer Filiale zu.

Warum: Die Filialzuordnung ermöglicht filialspezifische Abrechnungsläufe und Auswertungen.

Ergebnis: Ein filialzugeordneter Vertrag.

13.4.6 Kalkulationsart für Vertrag festlegen

Was: Der Benutzer legt fest, ob der Vertrag automatisch, manuell oder bedarfsgesteuert abgerechnet wird.

Warum: Die Kalkulationsart steuert den Abrechnungsprozess und ist Voraussetzung für die Filterung in der automatischen Abrechnung.

Ergebnis: Ein Vertrag mit definierter Kalkulationsart.

13.4.7 Abrechnungsintervall für Vertrag festlegen

Was: Der Benutzer definiert die Abrechnungsfrequenz: monatlich, quartalsweise oder jährlich.

Warum: Das Abrechnungsintervall steuert, wann der nächste Abrechnungslauf für diesen Vertrag fällig ist.

Ergebnis: Ein Vertrag mit definiertem Abrechnungsintervall.

13.4.8 Abrechnungsmodus festlegen (Vorauszahlung/Nachberechnung)

Was: Der Benutzer konfiguriert, ob der Vertrag im Voraus (Vorauskasse) oder nachträglich (Nachkasse) abgerechnet wird.

Warum: Der Abrechnungsmodus beeinflusst den Zeitpunkt der Rechnungsstellung und die Cash-Flow-Planung.

Ergebnis: Ein Vertrag mit definiertem Abrechnungsmodus.

13.4.9 Vertrag als Sammelrechnung markieren

Was: Der Benutzer legt fest, ob der Vertrag in Sammelrechnungen mit anderen Verträgen des gleichen Kunden gruppiert wird.

Warum: Sammelrechnungen reduzieren die Anzahl der Rechnungen an einen Kunden und vereinfachen dessen Buchhaltung.

Ergebnis: Ein Vertrag mit Sammelrechnungs-Kennzeichnung.

13.4.10 Vertragspositionen hinzufügen

Was: Der Benutzer legt neue Einzelpositionen (Artikel, Menge, Preis) zu einem bestehenden Vertrag an.

Warum: Vertragspositionen definieren den Leistungsumfang und die Abrechnungsgrundlage des Vertrags.

Ergebnis: Neue Vertragspositionen, bereit für die Abrechnung.

13.4.11 Vertragspositionen bearbeiten

Was: Der Benutzer ändert Menge, Preis oder Beschreibung bestehender Vertragspositionen.

Warum: Anpassungen an Positionen ermöglichen die Reaktion auf geänderte Kundenanforderungen oder Preisentwicklungen.

Ergebnis: Aktualisierte Vertragspositionen.

13.4.12 Vertragspositionen löschen

Was: Der Benutzer entfernt Positionen aus dem Vertrag mit Dokumentation des Grundes.

Warum: Die Löschung mit Begründung stellt sicher, dass die Vertragsänderung nachvollziehbar dokumentiert ist.

Ergebnis: Entfernte Position mit dokumentiertem Löschungsgrund.

13.4.13 SLA einem Vertrag zuweisen

Was: Der Benutzer verknüpft ein Service-Level-Agreement (Gold/Silber/Bronze) mit dem Vertrag.

Warum: Die SLA-Zuordnung steuert die Ticket-Bearbeitungszeiten und Service-Qualität für diesen Kunden.

Ergebnis: Ein Vertrag mit zugeordnetem SLA.

13.4.14 Kostenstelle/Kostenträger einem Vertrag zuweisen

Was: Der Benutzer ordnet dem Vertrag eine Kostenstelle für die interne Leistungsverrechnung zu.

Warum: Die Kostenstellenzuordnung ermöglicht die verursachergerechte Zurechnung der Vertragskosten.

Ergebnis: Ein Vertrag mit zugeordneter Kostenstelle/Kostenträger.

13.5 Vertrags-Lifecycle

13.5.1 Vertrag: Entwurf zu Aktiv

Was: Ein Vertragsentwurf wird nach Genehmigung aktiviert. Das System prüft das Startdatum und gibt den Vertrag für die Abrechnung frei.

Warum: Die formale Aktivierung markiert den Übergang vom Planungsstatus zum produktiven Vertrag und startet den Abrechnungszyklus.

Ergebnis: Ein aktiver Vertrag, bereit für die automatische Abrechnung.

13.5.2 Vertrag: Aktiv zu Pausiert

Was: Ein laufender Vertrag wird temporär ausgesetzt (z.B. bei Zahlungsausfall des Kunden). Die Abrechnung wird für die Pausierungsdauer unterbrochen.

Warum: Die Pausierung ermöglicht eine kontrollierte Unterbrechung ohne den Vertrag zu kündigen, z.B. bis Zahlungsprobleme geklärt sind.

Ergebnis: Ein pausierter Vertrag mit unterbrochener Abrechnung.

13.5.3 Vertrag: Pausiert zu Aktiv

Was: Ein pausierter Vertrag wird nach Klärung der Ursache wieder aktiviert und die Abrechnung wird fortgesetzt.

Warum: Die Wiederaufnahme stellt die Vertragsbeziehung wieder her, ohne einen neuen Vertrag anlegen zu müssen.

Ergebnis: Ein reaktivierter Vertrag mit fortgesetzter Abrechnung.

13.5.4 Vertrag kündigen

Was: Der Benutzer leitet die Kündigung ein mit Kündigungsgrund, Kündigungsfrist und Wirksamkeitsdatum.

Warum: Die formale Kündigung dokumentiert den Vorgang, berechnet die Kündigungsfrist und stellt sicher, dass offene Abrechnungen noch durchgeführt werden.

Ergebnis: Ein gekündigter Vertrag mit dokumentiertem Grund, berechneter Frist und Wirksamkeitsdatum.

13.5.5 Vertrag verlängern

Was: Der Benutzer verlängert einen auslaufenden Vertrag manuell oder das System führt die automatische Verlängerung durch, ggf. mit neuen Konditionen.

Warum: Die rechtzeitige Vertragsverlängerung sichert Umsätze, stellt Servicekontinuität sicher und ermöglicht die Anpassung an aktuelle Konditionen.

Ergebnis: Ein verlängerter Vertrag mit neuem Enddatum und ggf. aktualisierten Konditionen.

13.5.6 Vertrag: Gekündigt zu Archiviert

Was: Nach Ablauf der Kündigungsfrist und Durchführung der finalen Abrechnung wird der Vertrag endgültig archiviert.

Warum: Die Archivierung schließt den Vertrags-Lifecycle formal ab, bewahrt alle Daten für Audits und entfernt den Vertrag aus der aktiven Verwaltung.

Ergebnis: Ein archivierter Vertrag, nicht mehr abrechnungsrelevant, aber für Auswertungen und Audits weiterhin verfügbar.

14. CentronNexus Web-Portal

14.1 Dashboard

14.1.1 Personalisierte Willkommensnachricht

Was: Beim Anmelden am Web-Portal wird der Mitarbeiter mit seinem Namen begrüßt und sieht rollenspezifische Inhalte auf dem Dashboard.

Warum: Die persönliche Begrüßung schafft einen strukturierten Einstieg in den Arbeitstag und lenkt die Aufmerksamkeit sofort auf die wichtigsten Aufgaben der jeweiligen Rolle.

Ergebnis: Ein personalisiertes Dashboard mit Begrüßung, rollenabhängigen Kennzahlen und den wichtigsten offenen Aufgaben des Tages.

14.1.2 Schnelle Statistiken & Metriken

Was: Auf dem Dashboard werden Echtzeit-Kennzahlen (KPIs) als farbcodierte Karten angezeigt, die sich automatisch aktualisieren.

Warum: Führungskräfte und Mitarbeiter benötigen jederzeit einen schnellen Überblick über den aktuellen Betriebszustand, um rechtzeitig auf kritische Situationen reagieren zu können.

Ergebnis: Übersichtliche Metrik-Karten mit Ampelfarben (grün/gelb/rot), die den aktuellen Status von Tickets, Auslastung und weiteren Leistungskennzahlen auf einen Blick zeigen.

14.1.3 Favoriten-Tickets Schnellzugriff

Was: Vom Dashboard aus greift der Mitarbeiter mit einem Klick auf seine als Favorit markierten Tickets zu und navigiert direkt zur Detailansicht.

Warum: Häufig bearbeitete oder besonders wichtige Tickets sollen ohne Umwege erreichbar sein, um Suchzeiten zu vermeiden und die Produktivität zu steigern.

Ergebnis: Eine Favoritenliste auf dem Dashboard mit Ticket-Kurzinformationen und einem Zähler, die über alle Sitzungen hinweg gespeichert bleibt.

14.1.4 Aktivitäts-Feed anzeigen

Was: Der Mitarbeiter sieht auf dem Dashboard einen chronologischen Feed seiner letzten Zeiteinträge, bearbeiteten Tickets und sonstigen Aktivitäten mit Zeitstempel und Aktivitätstyp.

Warum: Die Transparenz über kürzliche Tätigkeiten erleichtert den Wiedereinstieg nach Pausen und die Nachverfolgung des eigenen Arbeitsfortschritts.

Ergebnis: Ein Aktivitäts-Feed mit konfigurierbarem Zeitraum (Standard: heute und letzte 7 Tage), der Zeiteinträge, Ticket-Bearbeitungen und Kommentare chronologisch auflistet.

14.1.5 Tagesplan-Integration

Was: Direkt auf dem Dashboard ist die "Mein Tag"-Komponente eingebettet, die eine kompakte Übersicht der heutigen Aufgaben, Zeitblöcke und Termine zeigt.

Warum: Der Mitarbeiter soll beim ersten Blick auf das Dashboard sofort erkennen, was heute ansteht, ohne in ein separates Modul wechseln zu müssen.

Ergebnis: Eine eingebettete Tagesansicht mit Aufgabenliste, Zeitblock-Visualisierung und einem Link zur vollständigen Tagesplanung.

14.1.6 Arbeits-Status-Warnungen

Was: Das Dashboard zeigt Warnmeldungen an, wenn für bestimmte Zeiträume keine Arbeitszeiten erfasst wurden oder Zeiteinträge unvollständig sind.

Warum: Lücken in der Zeiterfassung führen zu fehlerhaften Abrechnungen und Projektauswertungen. Frühzeitige Warnungen verhindern nachträglichen Korrekturbedarf.

Ergebnis: Farblich hervorgehobene Warnhinweise mit Angabe des betroffenen Zeitraums und einem direkten Link zur Zeiterfassung, die bestätigt oder bearbeitet werden können.

14.1.7 Card-basiertes Layout-System

Was: Das Dashboard besteht aus flexiblen Karten, die der Benutzer nach seinen Bedürfnissen anordnen, ein-/ausklappen und anpassen kann.

Warum: Unterschiedliche Rollen und Arbeitsweisen erfordern ein individualisierbares Dashboard, das nur die jeweils relevanten Informationen prominent anzeigt.

Ergebnis: Ein responsives Karten-Layout mit anpassbarer Anordnung und Sichtbarkeit, das die Konfiguration sitzungsübergreifend speichert.

14.2 Mein Tag

14.2.1 Tägliche Aufgabenliste anzeigen

Was: Der Mitarbeiter öffnet die "Mein Tag"-Ansicht und sieht alle heute fälligen Aufgaben mit Titel, Beschreibung, Status und Typ-Indikatoren.

Warum: Eine fokussierte Tagesansicht verhindert Überforderung durch die Gesamtticket-Liste und lenkt die Konzentration auf die tatsächlich heute anstehenden Arbeiten.

Ergebnis: Eine übersichtliche Aufgabenliste mit Zähleranzeige, gefiltert ausschließlich auf den heutigen Tag, mit Status-Indikatoren (offen, in Arbeit, erledigt).

14.2.2 Task-Abschluss-Tracking

Was: Der Mitarbeiter markiert einzelne Aufgaben per Klick als erledigt oder setzt sie auf offen zurück. Der Fortschritt wird prozentual angezeigt.

Warum: Die visuelle Fortschrittsanzeige motiviert zur Aufgabenerledigung und gibt dem Mitarbeiter und dem Team jederzeit einen transparenten Überblick über den Tagesfortschritt.

Ergebnis: Eine Fortschrittsanzeige (z.B. "7 von 12 erledigt") mit visueller Durchstreichung erledigter Aufgaben, die sofort in der Datenbank gespeichert wird.

14.2.3 Tages-Fokus-Ansicht

Was: Die "Mein Tag"-Ansicht filtert automatisch auf den heutigen Tag und zeigt ausschließlich die heute relevanten Aufgaben, getrennt von der allgemeinen Ticket-Liste.

Warum: Die klare Trennung zwischen Tagesansicht und Gesamtansicht verhindert Ablenkung und unterstützt fokussiertes Arbeiten.

Ergebnis: Eine zeitbasiert sortierte Tagesansicht mit deutlicher Datumsanzeige, die sich täglich automatisch zurücksetzt und gestrige Einträge entfernt.

14.2.4 Zeitallokations-Visualisierung

Was: Der Mitarbeiter sieht seine geplanten Tagesaufgaben als Zeitblöcke in einer Gantt-artigen Darstellung, inklusive freier Zeitfenster und eventueller Überlappungen.

Warum: Die visuelle Darstellung der Zeitverteilung hilft, den Tag realistisch zu planen, Überbuchungen zu erkennen und Pufferzeiten einzuplanen.

Ergebnis: Eine Zeitblock-Darstellung im HH:MM-Format mit Dauer pro Aufgabe, Kennzeichnung freier Zeitfenster und Warnung bei überlappenden Blöcken.

14.2.5 Arbeits-Prioritäten-Management

Was: Der Mitarbeiter sortiert seine Tagesaufgaben per Drag & Drop nach Priorität und sieht die Einstufung farblich gekennzeichnet (hoch/mittel/niedrig).

Warum: Durch die bewusste Priorisierung wird sichergestellt, dass die wichtigsten und dringendsten Aufgaben zuerst bearbeitet werden.

Ergebnis: Eine nach Priorität sortierbare Aufgabenliste mit Farbcodierung (rot/gelb/grün), die die gewählte Reihenfolge sitzungsübergreifend beibehält.

14.2.6 Zeit-Tracking-Integration

Was: Direkt aus der Tagesansicht heraus kann der Mitarbeiter einen Timer für eine Aufgabe starten, der mit dem globalen Stoppuhr-System verknüpft ist.

Warum: Die nahtlose Verknüpfung zwischen Aufgabenplanung und Zeiterfassung vermeidet Medienbrüche und sorgt für präzise Erfassung der tatsächlich aufgewendeten Zeit.

Ergebnis: Eine bidirektionale Verbindung zwischen Aufgabe und Timer, mit Anzeige der geschätzten versus tatsächlichen Zeit und automatischer Protokollierung bei Aufgabenabschluss.

14.2.7 Zeitplan-Zusammenfassung

Was: Die "Mein Tag"-Ansicht zeigt ergänzend zu den Aufgaben auch die Termine und Besprechungen des Tages mit Uhrzeit, Dauer und Ort an.

Warum: Damit der Mitarbeiter alle zeitlichen Verpflichtungen des Tages an einer Stelle sieht und seinen Arbeitstag ohne Terminüberschneidungen organisieren kann.

Ergebnis: Eine integrierte Terminübersicht mit Besprechungsdetails (Zeitpunkt, Dauer, Ort), die gegebenenfalls mit dem externen Kalender synchronisiert ist.

14.3 Stoppuhren

14.3.1 Mehrere aktive Timer anzeigen

Was: Im seitlichen Panel werden alle aktuell laufenden Timer gleichzeitig angezeigt, jeweils mit laufender Zeitanzeige und Status-Indikator.

Warum: Mitarbeiter arbeiten häufig parallel an mehreren Vorgängen und benötigen eine permanente Übersicht über alle laufenden Zeiterfassungen.

Ergebnis: Ein immer sichtbares Sidebar-Panel mit einer Liste aller aktiven Timer im HHH:MM:SS-Format, inklusive Echtzeit-Updates und Gesamtzeitsumme.

14.3.2 Play/Pause Timer-Steuerung

Was: Der Mitarbeiter startet, pausiert oder setzt einen einzelnen Timer mit einem Klick auf die Play/Pause-Schaltfläche fort.

Warum: Unterbrechungen, Meetings oder Aufgabenwechsel erfordern das schnelle Anhalten und Fortsetzen der Zeiterfassung, ohne den Timer zu verlieren.

Ergebnis: Ein Timer, der seinen Zustand (laufend/pausiert) sofort aktualisiert und den Pause-Zeitraum nicht in die erfasste Zeit einrechnet.

14.3.3 Timer löschen

Was: Der Mitarbeiter entfernt einen Timer aus der aktiven Liste, wobei die bereits erfasste Zeit optional vor dem Löschen gespeichert werden kann.

Warum: Nicht mehr benötigte oder irrtümlich gestartete Timer sollen schnell aufgeräumt werden können, ohne dass die Übersichtlichkeit leidet.

Ergebnis: Der Timer wird aus der Sidebar entfernt. Die bisher erfasste Zeit bleibt in der Historie erhalten und steht für spätere Auswertungen zur Verfügung.

14.3.4 Timer markieren/Flaggen

Was: Der Mitarbeiter kennzeichnet wichtige Timer mit einer Flagge, um sie visuell hervorzuheben und später filtern zu können.

Warum: In einer Liste paralleler Timer sollen abrechenbare Zeiten, Überstunden oder Prioritätsprojekte sofort erkennbar sein.

Ergebnis: Ein visueller Flag-Indikator am Timer mit der Möglichkeit, nach gekennzeichneten Timern zu filtern und Notizen zur Kennzeichnung hinzuzufügen.

14.3.5 Timer-Details bearbeiten

Was: Der Mitarbeiter ändert den Namen, die Kategorie oder die zugeordnete Tätigkeit eines laufenden Timers, ohne ihn stoppen zu müssen.

Warum: Häufig wird erst nach dem Start klar, zu welchem Vorgang die Tätigkeit genau gehört, oder die Zuordnung ändert sich im Laufe der Arbeit.

Ergebnis: Aktualisierte Timer-Informationen (Name, Kategorie, zugehöriges Ticket, Notizen) bei weiterhin laufender Zeitmessung.

14.3.6 Ticket-Zuordnung erstellen

Was: Der Mitarbeiter verknüpft einen laufenden Timer mit einem bestimmten Ticket, indem er über einen Auswahldialog nach Ticketnummer oder -titel sucht.

Warum: Damit die erfasste Zeit automatisch dem richtigen Ticket und damit dem richtigen Kunden und Vertrag zugeordnet wird -- als Grundlage für korrekte Abrechnung.

Ergebnis: Eine Verknüpfung zwischen Timer und Ticket, die beim Stoppen des Timers automatisch einen Zeiteintrag im Ticket erzeugt.

14.3.7 Ticket-Zuordnung aktualisieren

Was: Der Mitarbeiter ändert die bestehende Ticket-Zuordnung eines Timers, indem er ein anderes Ticket auswählt oder die Verknüpfung entfernt.

Warum: Bei Aufgabenwechseln oder fehlerhaften Zuordnungen muss die Ticket-Verknüpfung nachträglich korrigiert werden können, um Abrechnungsfehler zu vermeiden.

Ergebnis: Die aktualisierte Zuordnung überschreibt die vorherige Verknüpfung. Der Zuordnungsverlauf wird für die Nachvollziehbarkeit protokolliert.

14.3.8 Neuen Timer erstellen

Was: Der Mitarbeiter startet über eine Schaltfläche einen neuen Timer, gibt optional einen Namen ein und ordnet ihn direkt einem Ticket zu.

Warum: Für jede neue Tätigkeit soll möglichst schnell und unkompliziert eine Zeiterfassung begonnen werden können.

Ergebnis: Ein neuer Timer, der sofort startet und in der Sidebar-Liste erscheint, optional bereits mit Ticket-Zuordnung und Beschreibung.

14.3.9 Timer-Sitzungs-Persistierung

Was: Laufende Timer bleiben beim Navigieren zwischen verschiedenen Modulen und Seiten innerhalb des Portals bestehen und laufen ununterbrochen weiter.

Warum: Ein Seitenwechsel darf nicht dazu führen, dass laufende Zeiterfassungen verloren gehen oder unterbrochen werden.

Ergebnis: Timer, die über die gesamte Arbeitssitzung hinweg aktiv bleiben, wobei die historischen Timer-Daten automatisch archiviert werden.

14.3.10 Sidebar-Panel-Integration

Was: Das Stoppuhr-Panel ist dauerhaft als Seitenleiste neben dem Hauptinhalt sichtbar und blockiert keine anderen Inhalte.

Warum: Die permanente Sichtbarkeit der laufenden Timer ermöglicht es dem Mitarbeiter, jederzeit den Erfassungsstatus zu überblicken, ohne den Arbeitskontext zu verlassen.

Ergebnis: Ein fixiertes, ein-/ausklappbares Seitenpanel, das bei vielen Timern scrollbar ist und sich an mobile Bildschirme anpasst.

14.3.11 Echtzeit-Zeit-Anzeige

Was: Jeder aktive Timer zeigt sekundengenau die laufende Zeit an, die sich in Echtzeit ohne merkbare Verzögerung aktualisiert.

Warum: Eine exakte, verzögerungsfreie Zeitanzeige ist die Grundlage für zuverlässige Zeiterfassung und vermittelt dem Mitarbeiter Vertrauen in das System.

Ergebnis: Flüssig laufende Zähler im HHH:MM:SS-Format, die auch bei Sitzungen über 24 Stunden korrekt zählen.

14.3.12 Multi-Task Parallel-Tracking

Was: Der Mitarbeiter betreibt fünf oder mehr Timer gleichzeitig, um parallele Tätigkeiten für verschiedene Kunden oder Projekte zu erfassen.

Warum: Im IT-Dienstleistungsalltag werden häufig mehrere Vorgänge gleichzeitig bearbeitet (z.B. Fernwartung für Kunde A während Dokumentation für Kunde B). Jeder Vorgang muss separat erfasst werden.

Ergebnis: Eine klar unterscheidbare Timer-Liste mit visueller Differenzierung pro Timer, die Kontextwechsel zwischen Aufgaben unterstützt.

14.4 Ticket-Liste (Web)

14.4.1 Erweiterte Suche (Live-Suche)

Was: Der Mitarbeiter tippt in das Suchfeld und erhält in Echtzeit -- noch während der Eingabe -- gefilterte Ergebnisse über alle sichtbaren Spalten der Ticket-Liste.

Warum: In großen Ticket-Beständen muss ein bestimmtes Ticket schnell gefunden werden, ohne die genaue Nummer auswendig zu wissen.

Ergebnis: Sofortige Filterung der Ticket-Liste mit Hervorhebung der Suchbegriffe, unabhängig von Groß-/Kleinschreibung und mit Teilwort-Erkennung.

14.4.2 Dual-Tier Filtersystem

Was: Der Mitarbeiter kombiniert zwei Filterebenen -- "Nur" (exklusiv) und "Auch" (inklusiv) -- um komplexe Filterlogiken mit UND/ODER-Verknüpfung aufzubauen.

Warum: Einfache Filter reichen in der Praxis oft nicht aus. Die Kombination von exklusiven und inklusiven Filtern ermöglicht präzise Eingrenzung auch bei komplexen Suchszenarien.

Ergebnis: Eine Ticket-Liste, die nach der konfigurierten Filterlogik gefiltert ist, mit visueller Anzeige des aktiven Filtermodus und der Anzahl aktiver Filter.

14.4.3 Sidebar Schnellfilter

Was: Der Mitarbeiter wählt in der Seitenleiste vordefinierte Filterkategorien (z.B. "offen", "hohe Priorität", "fällig", "Admin") per Klick aus und sieht die Trefferzahl pro Kategorie.

Warum: Wiederkehrende Filterkombinationen sollen mit einem einzigen Klick angewendet werden können, ohne jedes Mal die Filterlogik manuell zusammenzustellen.

Ergebnis: Sofort angewendete Filter mit Anzeige der Ticket-Anzahl pro Kategorie, Multi-Select-Möglichkeit und ein-/ausklappbaren Kategoriegruppen.

14.4.4 Multi-Column Tabellenanzeige

Was: Die Ticket-Liste wird als sortierbare, mehrspaltige Tabelle dargestellt, deren Spaltenreihenfolge, -breite und -sichtbarkeit der Benutzer per Drag & Drop anpassen kann.

Warum: Verschiedene Rollen benötigen unterschiedliche Spalten (z.B. Kundennummer für Support, Fälligkeitsdatum für Teamleiter). Die Anpassbarkeit steigert die Effizienz.

Ergebnis: Eine konfigurierbare Tabellenansicht mit Spalten für Ticketnummer, Kunde, Betreff, Erstellungs- und Fälligkeitsdatum, die auf- und absteigend sortiert werden kann.

14.4.5 Favoriten/Stern-System

Was: Der Mitarbeiter markiert wichtige Tickets mit einem Stern und filtert die Liste anschließend auf seine Favoriten.

Warum: Regelmäßig bearbeitete oder priorisierte Tickets sollen jederzeit schnell auffindbar sein, ohne sie erneut suchen zu müssen.

Ergebnis: Stern-Markierungen, die über Sitzungen hinweg gespeichert bleiben und sowohl in der Ticket-Liste als auch auf dem Dashboard als Schnellzugriff verfügbar sind.

14.4.6 Layout-Persistierung

Was: Der Mitarbeiter speichert sein benutzerdefiniertes Spalten-Layout (Reihenfolge, Breite, Sichtbarkeit) und findet es bei der nächsten Anmeldung unverändert vor.

Warum: Das tägliche Neukonfigurieren der Tabelle kostet Zeit. Einmal eingerichtete Layouts sollen dauerhaft erhalten bleiben.

Ergebnis: Ein pro Benutzer gespeichertes Layout, das sitzungsübergreifend persistiert wird, mit Option zur Wiederherstellung des Standard-Layouts.

14.5 Ticket-Details (Web)

14.5.1 Vollständige Ticket-Informations-Anzeige

Was: Der Mitarbeiter öffnet ein Ticket und sieht alle relevanten Informationen -- Betreff, Beschreibung, Kunde, Priorität, Status, Kategorie, Metadaten -- in logischen Reitern organisiert.

Warum: Für eine fundierte Bearbeitung muss der Mitarbeiter alle Ticket-Informationen auf einen Blick erfassen können, ohne zwischen verschiedenen Ansichten wechseln zu müssen.

Ergebnis: Eine strukturierte Detailansicht mit Reitern für Übersicht, Dokumente, E-Mail-Kommunikation und Historie, die alle Ticket-Daten vollständig darstellt.

14.5.2 Ticket-Status-Management

Was: Der Mitarbeiter ändert den Status eines Tickets (z.B. Neu, Offen, In Arbeit, Warten, Gelöst, Geschlossen) über ein Auswahlfeld, wobei das System die erlaubten Übergänge validiert.

Warum: Die Einhaltung des Workflow-Prozesses stellt sicher, dass Tickets ordnungsgemäß bearbeitet werden und für SLA-Auswertungen korrekte Statuswechsel-Zeitpunkte vorliegen.

Ergebnis: Ein aktualisierter Ticket-Status mit farblicher Kennzeichnung, Zeitstempel des Wechsels und automatischer Benachrichtigung betroffener Mitarbeiter.

14.5.3 Bearbeitbare Ticket-Felder

Was: Der Mitarbeiter bearbeitet Ticket-Felder wie Titel, Beschreibung, Priorität, Typ, Kategorie oder zugeordneten Mitarbeiter direkt in der Detailansicht.

Warum: Ticket-Informationen ändern sich im Laufe der Bearbeitung. Inline-Bearbeitung ohne Umweg über separate Formulare beschleunigt den Arbeitsfluss.

Ergebnis: Geänderte Ticket-Felder mit Validierung, Anzeige ungespeicherter Änderungen und vollständiger Änderungsverfolgung (altes/neues Feld).

14.5.4 E-Mail-Konversations-Thread

Was: Der Mitarbeiter sieht die gesamte E-Mail-Kommunikation zum Ticket als chronologischen Thread mit Absender, Zeitstempel und Inhalt und kann direkt antworten oder weiterleiten.

Warum: Die E-Mail-Kommunikation ist oft der Hauptkommunikationskanal mit dem Kunden. Alle relevanten Nachrichten am Ticket zu bündeln vermeidet Informationsverlust.

Ergebnis: Ein vollständiger E-Mail-Verlauf mit Antwort- und Weiterleitungsfunktion, inklusive aller Anhänge der einzelnen Nachrichten.

14.5.5 Ticket-Verlauf & Zeitleiste

Was: Der Mitarbeiter sieht eine chronologische Zeitleiste aller Änderungen am Ticket: Statuswechsel, Feldänderungen, Kommentare und Zuweisungen mit Zeitstempel und ausführendem Benutzer.

Warum: Die lückenlose Dokumentation aller Änderungen ist für die Nachvollziehbarkeit, Qualitätssicherung und bei Kundendisputen unverzichtbar.

Ergebnis: Eine rückwärts-chronologische Zeitleiste mit Änderungstyp, altem und neuem Wert, Benutzername und Zeitstempel.

14.5.6 Zugehörige Ticket-Links

Was: Der Mitarbeiter sieht alle mit dem aktuellen Ticket verknüpften Tickets (Duplikate, Blocker, übergeordnete/untergeordnete Tickets) und kann neue Verknüpfungen erstellen oder entfernen.

Warum: Zusammenhängende Vorgänge sollen erkennbar sein, damit z.B. Duplikate nicht doppelt bearbeitet oder Blocker-Abhängigkeiten übersehen werden.

Ergebnis: Eine Liste verknüpfter Tickets mit Beziehungstyp und Kurzinformation, die per Klick zur Detailansicht des verknüpften Tickets navigiert.

14.5.7 Service/Vertrags-Informationen

Was: Im Ticket werden die verknüpften Services, Verträge und das zugehörige Service Level Agreement mit Gültigkeitsdaten und Status angezeigt.

Warum: Der Support-Mitarbeiter muss wissen, ob ein Vertrag aktiv ist und welche SLA-Bedingungen gelten, um die Bearbeitungspriorität korrekt einzuschätzen.

Ergebnis: Eine Informationsanzeige mit Vertragsname, -nummer, SLA-Stufe, Gültigkeitszeitraum und einem Link zu den vollständigen Vertragsdetails.

14.6 Ticket-Erstellung (Web)

14.6.1 Quick Ticket-Erstellungs-Dialog

Was: Der Mitarbeiter öffnet einen kompakten Dialog und erstellt mit wenigen Pflichtfeldern (Kunde, Betreff, Priorität) schnell ein neues Ticket.

Warum: In hektischen Support-Situationen (z.B. Telefonat mit Kunde) muss ein Ticket in Sekunden angelegt werden können, ohne ein umfangreiches Formular ausfüllen zu müssen.

Ergebnis: Ein neues Ticket mit den Basisdaten, das sofort in der Ticket-Liste erscheint und anschließend bei Bedarf um Details ergänzt werden kann.

14.6.2 Kundensuche und -auswahl

Was: Bei der Ticket-Erstellung sucht der Mitarbeiter den Kunden über ein Autocomplete-Suchfeld und wählt ihn aus der Vorschlagsliste aus.

Warum: Die schnelle und fehlerfreie Zuordnung zum richtigen Kunden ist Voraussetzung für korrekte Abrechnung und Vertragsreferenz.

Ergebnis: Ein ausgewählter Kunde mit automatisch übernommenen Stammdaten, der dem neuen Ticket zugeordnet wird.

14.6.3 Service/Leistungs-Auswahl

Was: Der Mitarbeiter wählt bei der Ticket-Erstellung den Service-Typ aus, dem das Ticket zugeordnet werden soll.

Warum: Die Kategorisierung nach Service-Typ steuert die SLA-Zuordnung, die Auswertung und die Kostenverrechnung.

Ergebnis: Ein Ticket mit zugeordnetem Service-Typ, der die weitere Bearbeitungs- und Abrechnungslogik bestimmt.

14.6.4 Vertrag/Contract-Auswahl

Was: Der Mitarbeiter verknüpft das neue Ticket mit einem bestehenden Service- oder Wartungsvertrag des Kunden.

Warum: Die Vertragsverknüpfung stellt sicher, dass die erbrachte Leistung korrekt gegen das vereinbarte Kontingent oder den vereinbarten Festpreis verrechnet wird.

Ergebnis: Ein Ticket mit Vertragsbezug, das die geltenden SLA-Bedingungen und Abrechnungsregeln des Vertrags übernimmt.

14.6.5 Prioritäts- und Typ-Klassifizierung

Was: Der Mitarbeiter legt bei der Ticket-Erstellung die Prioritätsstufe (z.B. kritisch, hoch, mittel, niedrig) und den Ticket-Typ fest.

Warum: Priorität und Typ bestimmen die Bearbeitungsreihenfolge, die SLA-Fristen und die Routing-Regeln für die Zuweisung an das richtige Team.

Ergebnis: Ein Ticket mit festgelegter Priorität und Typ, das im Ticket-System entsprechend eingeordnet und priorisiert wird.

14.6.6 Ticket-Template-Auswahl

Was: Der Mitarbeiter wählt eine vordefinierte Vorlage aus einer Template-Bibliothek, die Felder wie Betreff, Beschreibung, Priorität und Kategorie automatisch vorbefüllt.

Warum: Für wiederkehrende Ticket-Typen (z.B. "Neuer Mitarbeiter einrichten", "Drucker defekt") beschleunigen Templates die Erstellung und stellen eine einheitliche Dokumentation sicher.

Ergebnis: Ein vorbefülltes Ticket-Formular auf Basis der gewählten Vorlage, das der Mitarbeiter bei Bedarf anpassen kann.

14.6.7 Standard-/Internes/Smartflow-Ticket

Was: Der Mitarbeiter wählt aus drei Erstellungspfaden: ein externes Kunden-Ticket, ein internes Team-Ticket (nicht kundensichtbar) oder ein Smartflow-Workflow-Ticket mit automatisierten Folgeschritten.

Warum: Unterschiedliche Vorgänge erfordern unterschiedliche Sichtbarkeiten und Bearbeitungswege -- von einfachen Support-Fällen bis zu komplexen, automatisierten Workflows.

Ergebnis: Ein Ticket des gewählten Typs, das je nach Pfad unterschiedliche Sichtbarkeit, Benachrichtigungen und Automatisierungsregeln besitzt.

14.7 Kunden (Web)

14.7.1 Kundensuche

Was: Der Mitarbeiter sucht über ein Suchfeld nach Kunden und erhält in Echtzeit Ergebnisse aus dem Kundenstamm.

Warum: In einem großen Kundenstamm muss der gewünschte Kunde schnell gefunden werden -- sei es für eine Ticket-Erstellung, eine Vertragsauskunft oder eine Terminplanung.

Ergebnis: Echtzeit-Suchergebnisse, die bei Eingabe von Name, Nummer oder Adressbestandteilen sofort die passenden Kunden anzeigen.

14.7.2 Aktiv/Inaktiv-Filter

Was: Der Mitarbeiter schaltet per Umschalter zwischen der Anzeige aktiver, inaktiver oder aller Kunden um.

Warum: Inaktive Kunden sollen standardmäßig ausgeblendet sein, um die Übersichtlichkeit zu wahren, bei Bedarf aber gezielt auffindbar bleiben.

Ergebnis: Eine gefilterte Kundenliste, die je nach Einstellung nur aktive, nur inaktive oder alle Kunden zeigt.

14.7.3 Vollständige Kundeninfo-Anzeige

Was: Der Mitarbeiter sieht alle Kundenstammdaten (Name, Nummer, Adresse, Kontakt, Vertragsinformationen) in einer tabellarischen Übersicht.

Warum: Für schnelle Auskünfte am Telefon oder zur Vorbereitung auf Kundengespräche werden alle relevanten Informationen an einem Ort benötigt.

Ergebnis: Eine vollständige Kundendaten-Anzeige im Grid mit allen Stammdatenfeldern und der Möglichkeit, zur Detailansicht zu navigieren.

14.7.4 Ansprechpartner-Tracking

Was: Zu jedem Kunden wird der primäre Ansprechpartner mit Telefonnummer, E-Mail-Adresse und Rolle angezeigt.

Warum: Bei Rückfragen oder Terminvereinbarungen muss sofort klar sein, wer der richtige Kontakt beim Kunden ist.

Ergebnis: Anzeige des Primärkontakts mit allen Kommunikationsdaten direkt in der Kundenübersicht, mit Möglichkeit zur direkten Kontaktaufnahme.

14.8 Zeitplanung (Web)

14.8.1 Kalender-Schnittstelle

Was: Der Mitarbeiter navigiert durch einen Kalender mit Tages-, Wochen- und Monatsansicht, um Termine und geplante Aktivitäten zu überblicken.

Warum: Die visuelle Kalenderdarstellung gibt einen sofortigen Überblick über die zeitliche Verteilung von Terminen und freien Kapazitäten.

Ergebnis: Ein navigierbarer Kalender, der zwischen verschiedenen Ansichtsmodi umschaltbar ist und geplante Aktivitäten als Einträge anzeigt.

14.8.2 Zeitblock-Visualisierung

Was: Geplante Aktivitäten werden als farbige Zeitblöcke im Kalender dargestellt, die Dauer, Typ und Status visuell vermitteln.

Warum: Die grafische Darstellung macht die Auslastung und zeitliche Verteilung auf einen Blick erkennbar und erleichtert die Erkennung von Überlappungen oder Lücken.

Ergebnis: Farblich codierte Zeitblöcke im Kalender, die bei Berührung oder Klick Detailinformationen anzeigen.

14.8.3 Zeitplan-Verwaltung

Was: Der Mitarbeiter erstellt, bearbeitet und löscht Zeitblöcke direkt im Kalender durch Klicken, Ziehen und Eingabe von Details.

Warum: Die Terminplanung muss direkt in der Kalenderansicht möglich sein, um schnell auf Änderungen reagieren zu können.

Ergebnis: Erstellte, geänderte oder gelöschte Zeitblöcke, die sofort im Kalender und in verknüpften Systemen aktualisiert werden.

14.8.4 Ressourcen-Allokation

Was: Der Mitarbeiter weist Zeitblöcken Ressourcen (Mitarbeiter, Räume, Fahrzeuge) zu, um die Verfügbarkeit sicherzustellen.

Warum: Termine und Einsätze erfordern bestimmte Ressourcen. Die explizite Zuweisung verhindert Doppelbuchungen und stellt die Einsatzbereitschaft sicher.

Ergebnis: Zeitblöcke mit zugewiesenen Ressourcen, wobei das System bei Doppelbuchungen warnt und die Ressourcenverfügbarkeit in Echtzeit anzeigt.

15. Asset Management

15.1 Geräte-Inventarverwaltung

15.1.1 Neue IT-Geräte erfassen

Was: Der Techniker registriert ein neues Hardware-Gerät (Desktop, Laptop, Server, Drucker etc.) im System mit Stammdaten wie Gerätetyp, Hersteller, Modellnummer, Seriennummer und Standort.

Warum: Jedes IT-Gerät muss inventarisiert sein, damit Service-Anfragen zugeordnet, Wartungszyklen geplant und Abschreibungen korrekt berechnet werden können.

Ergebnis: Ein neuer Geräteeintrag im Inventarsystem mit Status "Aktiv", zugeordneter Abteilung/Standort und Asset-Tag, der sofort für Ticket-Verknüpfungen und Vertragsreferenzen verfügbar ist.

15.1.2 Geräte-Details anzeigen und bearbeiten

Was: Der Support-Mitarbeiter ruft die vollständigen Informationen eines Geräts auf (Hostname, IP-Adresse, MAC-Adresse, RAM, Festplatte, CPU, Betriebssystem) und aktualisiert sie bei Bedarf.

Warum: Vor einem Remote-Support oder einer Vor-Ort-Reparatur müssen die Gerätespezifikationen bekannt sein, um die richtige Diagnose und Lösung zu wählen.

Ergebnis: Eine vollständige Geräte-Detailansicht mit aktueller Hardware- und Softwarekonfiguration, inklusive der gesamten Service-Historie.

15.1.3 Geräte-Bestände nach Abteilung verwalten

Was: Der IT-Manager filtert die Inventarliste nach Abteilung oder Standort und sieht, welche Geräte in welcher Abteilung vorhanden sind.

Warum: Für Budgetplanung, Umzüge und Audits muss jederzeit klar sein, wie viele und welche Geräte einer bestimmten Organisationseinheit zugeordnet sind.

Ergebnis: Ein nach Abteilung gefilterter Bestandsbericht mit Geräteliste, Anzahl und Statusübersicht.

15.1.4 Geräte-Lebenszyklusmanagement

Was: Der IT-Verantwortliche verfolgt ein Gerät über seinen gesamten Lebenszyklus: Beschaffung, Aktivierung, Nutzung, Wartung, Außerbetriebnahme bis zur Entsorgung, wobei jeder Statuswechsel dokumentiert wird.

Warum: Das Lebenszyklusmanagement ist Voraussetzung für korrekte Abschreibungen, rechtzeitige Ersatzbeschaffungen und die Einhaltung von Compliance-Anforderungen.

Ergebnis: Eine lückenlose Lebenszyklushistorie pro Gerät mit Anschaffungsdatum, Deaktivierungsdatum, aktuellem Status und berechnetem Restwert.

15.1.5 Batch-Import von Geräteinventaren

Was: Der IT-Administrator importiert eine große Anzahl von Geräten (z.B. 500 Computer nach einem Netzwerk-Scan) per CSV-Datei mit Hostnamen, MAC-Adressen, Typen und Abteilungszuordnungen.

Warum: Bei Ersterfassung oder nach umfangreichen Netzwerk-Scans wäre die manuelle Einzelerfassung zu zeitaufwändig. Der Massenimport spart erheblichen Aufwand.

Ergebnis: Alle importierten Geräte sind im Inventarsystem angelegt, Duplikate wurden automatisch erkannt, und ein Importprotokoll zeigt Erfolge und Fehler.

15.1.6 Geräte zu Helpdesk-Tickets verknüpfen

Was: Der Techniker ordnet ein betroffenes Gerät einem Support-Ticket zu, z.B. "Ticket #12345 betrifft den Laptop von Hans Müller".

Warum: Die Verknüpfung zwischen Gerät und Ticket ermöglicht die Analyse wiederkehrender Probleme pro Gerät und die Zuordnung von Reparaturkosten.

Ergebnis: Eine bidirektionale Verknüpfung: Im Ticket wird das betroffene Gerät angezeigt, und in der Geräte-Ansicht erscheint der Ticket-Verweis.

15.1.7 Service-Historie pro Gerät anzeigen

Was: Der Kundenberater ruft die vollständige Wartungs- und Reparaturhistorie eines Geräts auf, inklusive aller zugehörigen Tickets mit Datum, Beschreibung und Lösung.

Warum: Bei wiederkehrenden Problemen muss erkennbar sein, ob ein Gerät bereits mehrfach repariert wurde, um eine fundierte Entscheidung über Austausch oder weitere Reparatur treffen zu können.

Ergebnis: Eine chronologische Liste aller Service-Vorgänge mit Ticketnummer, Datum, Techniker und durchgeführter Maßnahme.

15.1.8 Geräte-Zuordnung zu Benutzern

Was: Die IT-Abteilung dokumentiert, welcher Mitarbeiter welches Gerät nutzt, und pflegt Änderungen bei Gerätewechseln oder Personalveränderungen.

Warum: Für Support-Anfragen, Sicherheits-Audits und Inventur muss nachvollziehbar sein, in wessen Besitz sich ein Gerät befindet.

Ergebnis: Eine aktuelle Benutzer-Geräte-Zuordnung mit Zuweisungsdatum und Änderungshistorie.

15.1.9 Geräte-Abhängigkeiten verwalten

Was: Der IT-Administrator definiert Abhängigkeiten zwischen Geräten (z.B. Server zu Switch, Workstations zu Server), um kritische Infrastrukturketten zu dokumentieren.

Warum: Bei einem Geräteausfall muss sofort erkennbar sein, welche weiteren Geräte und Dienste betroffen sind -- etwa wenn ein Server ausfällt und 15 verbundene Arbeitsplätze nicht mehr funktionieren.

Ergebnis: Ein Abhängigkeitsmodell, das bei Ausfallmeldungen alle betroffenen Geräte identifiziert und die Kritikalität des Ausfalls einschätzt.

15.1.10 Betriebssystem und installierte Software erfassen

Was: Das System erfasst automatisch per Scan oder manuell die installierten Betriebssysteme, Anwendungen und laufenden Dienste auf verwalteten Geräten.

Warum: Veraltete Software oder fehlende Sicherheitsupdates stellen ein Risiko dar. Der IT-Administrator muss wissen, welche Software-Versionen im Einsatz sind.

Ergebnis: Eine pro-Gerät-Softwareliste mit Betriebssystem-Version, Service-Pack-Level und installierten Anwendungen, die bei Abweichungen Warnungen auslöst.

15.1.11 Hardware-Spezifikationen verwalten

Was: Der Techniker dokumentiert und pflegt die Hardware-Details eines Geräts: Prozessor, Arbeitsspeicher (Typ und Größe), Festplatte (HDD/SSD, Kapazität) und Netzwerk-Interfaces.

Warum: Vor Softwareinstallationen, Upgrades oder Ersatzbeschaffungen müssen die exakten Spezifikationen bekannt sein, um die Kompatibilität sicherzustellen.

Ergebnis: Vollständige, aktuelle Hardware-Spezifikationen pro Gerät, die bei Support-Anfragen und Upgrade-Planungen als Referenz dienen.

15.1.12 Geräte-Abhängigkeitsanalyse

Was: Der IT-Leiter analysiert die Abhängigkeitsketten im Netzwerk, um kritische Geräte zu identifizieren, deren Ausfall die größte Auswirkung hätte.

Warum: Für Disaster-Recovery-Planung und Business-Continuity-Management müssen die kritischsten Infrastrukturkomponenten und ihre Abhängigkeiten bekannt sein.

Ergebnis: Eine Kritikalitäts-Matrix, die zeigt, welche Geräte bei Ausfall wie viele andere Geräte oder Dienste beeinträchtigen.

15.1.13 Gerät einem Standort zuweisen

Was: Der IT-Administrator ordnet ein Gerät einem physischen Standort oder Raum zu, um den genauen Aufstellungsort zu dokumentieren.

Warum: Bei Vor-Ort-Service, Inventuren oder Umzügen muss bekannt sein, wo sich ein Gerät physisch befindet.

Ergebnis: Eine aktualisierte Standortzuordnung (Gebäude, Etage, Raum), die bei der Inventur und bei Service-Einsätzen als Referenz dient.

15.1.14 Gerät einer Kostenstelle zuweisen

Was: Der IT-Controller ordnet ein Gerät einer Kostenstelle zu, damit Anschaffungs- und Betriebskosten intern korrekt verrechnet werden.

Warum: Die verursachungsgerechte Kostenzuordnung ist Grundlage für die interne Leistungsverrechnung und die buchhalterische Abschreibung.

Ergebnis: Ein Gerät mit zugeordneter Kostenstelle, das in der Kostenstellenauswertung und im Abschreibungsplan korrekt erfasst ist.

15.1.15 Gerät einem Vertrag zuordnen

Was: Der Vertragsmanager verknüpft ein Gerät mit einem Service- oder Wartungsvertrag, um SLA-Bedingungen und Abrechnungsregeln festzulegen.

Warum: Nur bei korrekter Vertragszuordnung kann das System automatisch prüfen, ob ein Gerät unter Wartungsvertrag steht und welche Reaktionszeiten gelten.

Ergebnis: Eine Verknüpfung zwischen Gerät und Vertrag, die bei Ticket-Erstellung automatisch die geltenden SLA-Bedingungen anzeigt.

15.2 Service-Partner-Management

15.2.1 Service-Partner erstellen

Was: Der IT-Administrator registriert einen externen IT-Dienstleister mit Firmendaten, Kontaktpersonen, Spezialisierungen und SLA-Vereinbarungen im System.

Warum: Externe Partner, die für bestimmte Gerätetypen oder Standorte zuständig sind, müssen im System erfasst sein, um bei Bedarf schnell den richtigen Ansprechpartner zu finden.

Ergebnis: Ein neuer Service-Partner-Eintrag mit allen Kontakt- und Vertragsdaten, der für Standort- und Gerätezuweisungen verfügbar ist.

15.2.2 Service-Partner abrufen (nach ID/Kunde)

Was: Der Support-Mitarbeiter sucht den zuständigen Service-Partner für ein bestimmtes Gerät oder einen bestimmten Kunden, um den Reparaturauftrag weiterzuleiten.

Warum: Bei Hardwaredefekten muss schnell erkennbar sein, welcher externe Partner für die Reparatur zuständig ist -- insbesondere bei Garantie- oder Wartungsverträgen.

Ergebnis: Die Anzeige des zuständigen Partners mit Kontaktdaten und der Information, welche Gerätetypen er betreut.

15.2.3 Service-Partner aktualisieren/löschen

Was: Der IT-Administrator ändert die Daten eines Service-Partners (z.B. neue Telefonnummer, neuer Ansprechpartner) oder entfernt einen nicht mehr kooperierenden Partner aus dem System.

Warum: Veraltete Kontaktdaten führen zu Verzögerungen. Nicht mehr aktive Partner sollen nicht mehr in Suchergebnissen erscheinen.

Ergebnis: Aktualisierte oder als gelöscht markierte Partner-Einträge, wobei historische Verknüpfungen für die Nachvollziehbarkeit erhalten bleiben.

15.2.4 Partner zu Kundenstandort zuordnen

Was: Der IT-Administrator verknüpft einen Service-Partner mit einem bestimmten Kundenstandort und den dort verwalteten Geräten.

Warum: An verschiedenen Standorten können unterschiedliche Service-Partner zuständig sein. Die Zuordnung stellt sicher, dass der geografisch und fachlich richtige Partner beauftragt wird.

Ergebnis: Eine Standort-Partner-Zuordnung, die bei der Ticket-Bearbeitung automatisch den zuständigen Partner vorschlägt.

15.2.5 Partner-Zuweisungen verwalten

Was: Der IT-Administrator zeigt alle bestehenden Standort-Zuweisungen eines Partners an und kann sie aktualisieren oder entfernen.

Warum: Bei Vertragswechseln oder Standortänderungen müssen die Zuweisungen angepasst werden, damit stets der korrekte Partner referenziert wird.

Ergebnis: Eine aktuelle Übersicht aller Partner-Standort-Zuweisungen mit der Möglichkeit zur Bearbeitung und Löschung.

15.2.6 Partner nach Gerätetyp filtern

Was: Der Support-Mitarbeiter sucht gezielt nach Service-Partnern, die einen bestimmten Gerätetyp (z.B. Drucker, Server, Netzwerk-Equipment) betreuen.

Warum: Nicht jeder Partner kann jedes Gerät warten. Die Filterung nach Gerätetyp-Spezialisierung beschleunigt die Beauftragung des richtigen Partners.

Ergebnis: Eine gefilterte Partner-Liste, die nur Partner mit der passenden Gerätetyp-Qualifikation anzeigt.

15.3 RMM-Artikeltyp-Zuordnung

15.3.1 RMM-Artikel-Zuordnungen verwalten (CRUD)

Was: Der Administrator erstellt, bearbeitet oder löscht Zuordnungen zwischen Artikeln und Monitoring-Check-Typen (z.B. welcher Artikel mit welchem Überwachungsprüfpunkt verknüpft ist).

Warum: Die korrekte Zuordnung zwischen Vertragsartikeln und Monitoring-Checks steuert, welche Überwachungsleistungen für einen Kunden erbracht und abgerechnet werden.

Ergebnis: Aktuelle Artikel-zu-Check-Mappings, die bei der Vertragsabrechnung und beim Monitoring-Setup als Konfigurationsgrundlage dienen.

15.3.2 Batch-Update von RMM-Zuordnungen

Was: Der Administrator ändert mehrere Artikel-Check-Zuordnungen gleichzeitig, z.B. bei einer Umstellung des Monitoring-Pakets für einen Kunden.

Warum: Bei Änderungen am Service-Angebot müssen oft viele Zuordnungen gleichzeitig aktualisiert werden. Einzelbearbeitung wäre zu zeitaufwändig.

Ergebnis: Alle betroffenen Zuordnungen werden in einem Vorgang aktualisiert, wobei ein Protokoll die durchgeführten Änderungen dokumentiert.

15.3.3 RMM-Artikeltyp-Enumeration

Was: Das System listet alle verfügbaren Monitoring-Check-Typen auf (z.B. Application, Eventlog, FileSize, HardDrive, Http, Ping und 20+ weitere).

Warum: Bei der Konfiguration neuer Monitoring-Pakete muss der Administrator alle verfügbaren Check-Typen kennen, um das passende Monitoring-Profil zusammenzustellen.

Ergebnis: Eine vollständige Liste aller 28+ Check-Typen mit Beschreibung und aktuellem Verwendungsstatus.

15.3.4 Zuordnung zu Vertrag verknüpfen

Was: Der Vertragsmanager nimmt die konfigurierten Monitoring-Pakete in einen Kundenvertrag auf, damit sie in die regelmäßige Abrechnung einfließen.

Warum: Monitoring-Leistungen müssen vertraglich abgesichert und abrechnungsfähig sein. Die Verknüpfung stellt die korrekte Kostenzuordnung sicher.

Ergebnis: Ein Vertrag mit eingebundenen RMM-Artikeln, die bei der automatisierten Abrechnung berücksichtigt werden.

15.3.5 Zuordnungs-Konfiguration validieren

Was: Das System überprüft die Konsistenz aller Artikel-Check-Zuordnungen und meldet Konfigurationsfehler oder fehlende Verknüpfungen.

Warum: Fehlerhafte Zuordnungen können dazu führen, dass Monitoring-Checks nicht ausgeführt oder falsch abgerechnet werden.

Ergebnis: Ein Validierungsbericht, der inkonsistente oder fehlende Zuordnungen auflistet und Korrekturvorschläge macht.

15.4 Active Directory Benutzerausschluss

15.4.1 Ausgeschlossene AD-Benutzer verwalten (CRUD)

Was: Der Administrator erstellt, bearbeitet oder löscht Einträge in der Ausschlussliste für Active-Directory-Benutzerkonten, die bei Geräte-Scans nicht erfasst werden sollen.

Warum: System- und Service-Konten sollen nicht als reguläre Gerätebenutzer erfasst werden, da sie die Inventarlisten verfälschen und unnötige Einträge erzeugen.

Ergebnis: Eine gepflegte Ausschlussliste, die beim nächsten AD-Import oder Geräte-Scan angewendet wird.

15.4.2 Systemkonten ausschließen

Was: Der Administrator markiert Betriebssystem-Service-Accounts (z.B. SYSTEM, LOCAL SERVICE), damit diese bei Geräte-Scans nicht als Benutzer erscheinen.

Warum: Service-Accounts sind keine echten Benutzer und würden die Benutzer-Geräte-Zuordnung verfälschen.

Ergebnis: Systemkonten sind ausgeschlossen und erscheinen nicht mehr in Geräte-Benutzerlisten.

15.4.3 AD-Benutzer beim Import filtern

Was: Beim Import von Active-Directory-Benutzerdaten wendet das System die Ausschlussliste an und importiert nur relevante Benutzerkonten.

Warum: Ein sauberer Import ohne Service- und Testkonten spart Nacharbeit und hält die Benutzerdatenbank übersichtlich.

Ergebnis: Ein gefilterter AD-Import, der nur echte Benutzerkonten enthält, mit Protokoll über ausgeschlossene Konten.

15.4.4 RMM-Service-Account ausschließen

Was: Der Administrator trägt den RMM-Collector-Service-Account in die Ausschlussliste ein, damit er nicht als Gerätebenutzer angezeigt wird.

Warum: Der Monitoring-Agent läuft unter einem eigenen Service-Account, der nicht einem Mitarbeiter zugeordnet werden soll.

Ergebnis: Der RMM-Service-Account erscheint nicht mehr in der Benutzerliste verwalteter Geräte.

15.4.5 Batch-Ausschluss und Export

Was: Der Administrator registriert mehrere Ausschlüsse gleichzeitig und exportiert die aktuelle Ausschlussliste als Audit-Report.

Warum: Bei der Ersteinrichtung oder bei Audits müssen viele Konten auf einmal ausgeschlossen und die Konfiguration nachweisbar dokumentiert werden.

Ergebnis: Eine aktualisierte Ausschlussliste mit einem exportierbaren Audit-Bericht für Compliance-Nachweise.

15.5 Patch- und Update-Management

15.5.1 Ausstehende Patches ermitteln

Was: Der IT-Manager sieht pro Gerät oder für die gesamte Infrastruktur eine Liste offener Sicherheits- und Bugfix-Patches mit Kritikalitätsstufe.

Warum: Ungepatchte Systeme sind ein Sicherheitsrisiko. Die Übersicht zeigt den Handlungsbedarf und ermöglicht eine risikobasierte Priorisierung.

Ergebnis: Eine filterbare Patch-Liste mit Status (ausstehend, genehmigt, installiert, zurückgerollt) und Einstufung (Sicherheit, kritisch, Standard).

15.5.2 Patch-Bereitstellung planen

Was: Der IT-Administrator plant die Installation eines Patches für ein definiertes Wartungsfenster und hinterlegt einen Rollback-Plan.

Warum: Patches dürfen den Betrieb nicht stören. Die Planung auf außerbetriebliche Zeiten und die Vorbereitung eines Rollback-Plans minimieren das Risiko.

Ergebnis: Ein geplanter Patch-Deployment-Termin mit Wartungsfenster, Backup-Validierung und dokumentiertem Rollback-Plan.

15.5.3 Patch-Deployment-Kampagne

Was: Der IT-Administrator koordiniert das Ausrollen eines Patches auf mehrere Geräte in definierten Phasen (z.B. Phase 1: Server am Samstag, Phase 2: Arbeitsplätze am Sonntag, Phase 3: VPN-Clients am Montag).

Warum: Ein kontrolliertes, phasenweises Rollout begrenzt das Risiko und ermöglicht es, bei Problemen in Phase 1 die nachfolgenden Phasen zu stoppen.

Ergebnis: Eine Kampagne mit Phaseneinteilung, Fortschrittsanzeige und automatischer Benachrichtigung bei Fehlern in einer Phase.

15.5.4 Patch-Kompatibilität überprüfen

Was: Das System prüft vor dem Deployment, ob ein Patch mit der installierten Software und den Treiberversionen auf dem Zielgerät kompatibel ist.

Warum: Inkompatible Patches können Systemabstürze oder Treiberkonflikte verursachen. Eine Vorprüfung verhindert vermeidbare Ausfälle.

Ergebnis: Ein Kompatibilitätsbericht pro Gerät mit Empfehlung (kompatibel, Warnung, nicht kompatibel) und Detailinformationen zu möglichen Konflikten.

15.5.5 Patch-Rollback durchführen

Was: Der IT-Administrator rollt einen fehlgeschlagenen Patch auf den vorherigen Stand zurück, sofern ein Backup vorhanden ist.

Warum: Wenn ein Patch unerwartete Probleme verursacht (z.B. Netzwerktreiber defekt), muss der vorherige Zustand schnell wiederhergestellt werden können.

Ergebnis: Das betroffene System ist auf den Stand vor dem Patch zurückgesetzt, die Rollback-Aktion ist vollständig in der Historie dokumentiert.

15.6 SNMP-Netzwerküberwachung

15.6.1 SNMP-fähige Geräte erfassen

Was: Der Netzwerkadministrator registriert SNMP-fähige Netzwerkgeräte (Switches, Router, Drucker) mit IP-Adresse, Community-String und SNMP-Version für das Monitoring.

Warum: Netzwerkgeräte müssen im Monitoring-System bekannt sein, damit ihre Verfügbarkeit und Leistung überwacht werden können.

Ergebnis: Ein neuer Monitoring-Eintrag für das Netzwerkgerät, das ab sofort in den Überwachungszyklus aufgenommen wird.

15.6.2 SNMP-Monitoring konfigurieren

Was: Der Administrator wählt die zu überwachenden Metriken (CPU-Auslastung, Speichernutzung, Port-Status, Fehlerrate, Uptime) und legt die Abfrageintervalle fest.

Warum: Nicht alle Metriken sind für jedes Gerät relevant. Die individuelle Konfiguration reduziert das Datenvolumen und fokussiert auf aussagekräftige Werte.

Ergebnis: Ein konfiguriertes Monitoring-Profil pro Gerät mit den gewählten Metriken und Polling-Intervallen.

15.6.3 Schwellenwerte definieren

Was: Der Administrator legt Warn- und Kritisch-Schwellenwerte für Metriken fest (z.B. Warnung bei RAM > 80%, kritisch bei > 95%) und definiert die Alarmierungsaktionen (E-Mail, SMS).

Warum: Automatische Schwellenwert-Alarmierung ermöglicht proaktives Handeln, bevor ein Problem den Betrieb beeinträchtigt.

Ergebnis: Definierte Schwellenwerte mit zugeordneten Alarmierungsaktionen, die bei Überschreitung automatisch ausgelöst werden.

15.6.4 Real-Time Netzwerk-Health Dashboard

Was: Der IT-Leiter sieht auf einem Live-Dashboard den aktuellen Status aller überwachten Netzwerkgeräte mit Verfügbarkeit, CPU/RAM-Auslastung und Fehlerrate.

Warum: Ein Echtzeit-Überblick ermöglicht sofortige Reaktion auf Ausfälle oder Überlastungen, bevor Endanwender betroffen sind.

Ergebnis: Ein Dashboard mit Ampelsystem (Online/Warnung/Offline) pro Gerät, das sich alle fünf Minuten automatisch aktualisiert und die wichtigsten Netzwerk-Metriken zeigt.

15.6.5 Netzwerk-Performance-Berichte

Was: Der IT-Leiter generiert historische Berichte über Netzwerk-Metriken für konfigurierbare Zeiträume (täglich, wöchentlich, monatlich) mit Trend-Analyse.

Warum: Langfristtrends wie stetig steigende Auslastung erfordern vorausschauende Planung von Kapazitätserweiterungen.

Ergebnis: Ein Bericht mit Durchschnittsauslastung, Spitzenlastzeiten, Trend-Analyse und Empfehlungen (z.B. "Bandbreite wächst um 20% pro Monat -- Upgrade planen").

15.6.6 Netzwerk-Anomalie-Erkennung

Was: Das System erkennt automatisch ungewöhnliches Netzwerkverhalten (plötzliche CPU-Spitzen, unerwartet aktive Ports, nicht erreichbare Geräte) und alarmiert den Administrator.

Warum: Anomalien können auf Hardwaredefekte, Sicherheitsvorfälle (z.B. Malware) oder Konfigurationsfehler hinweisen und erfordern sofortige Untersuchung.

Ergebnis: Eine automatische Alarmierung bei Anomalien mit Beschreibung der Abweichung, betroffenem Gerät und empfohlener Erstmaßnahme.

15.7 Software-Lizenzverwaltung

15.7.1 Installierte Software-Lizenzen erfassen

Was: Der IT-Administrator katalogisiert alle gekauften Software-Lizenzen mit Produktname, Version, Lizenztyp, Kaufdatum, Ablaufdatum, Lizenzschlüssel und lizenzierter Seat-Anzahl.

Warum: Die vollständige Erfassung aller Lizenzen ist Voraussetzung für die Compliance-Prüfung und verhindert unbeabsichtigte Lizenzvertragsverletzungen.

Ergebnis: Ein Lizenzkatalog mit allen relevanten Daten pro Software-Produkt, der als Grundlage für Compliance-Berichte und Kostenkontrolle dient.

15.7.2 Installationen pro Lizenz verfolgen

Was: Das System vergleicht die Anzahl gekaufter Lizenzen mit der tatsächlichen Anzahl der Installationen und zeigt Über- oder Unterlizenzierungen an.

Warum: Mehr Installationen als Lizenzen stellen einen Compliance-Verstoß dar, während ungenutzte Lizenzen unnötige Kosten verursachen.

Ergebnis: Eine Gegenüberstellung von lizenzierten Seats und tatsächlichen Installationen mit Kennzeichnung von Abweichungen (z.B. "10 Lizenzen, 15 Installationen -- 5 ohne Lizenz").

15.7.3 Lizenz-Compliance-Bericht

Was: Das System generiert einen prüfungsfähigen Bericht über den Lizenzstatus aller Software-Produkte, inklusive abgelaufener, überlizenzierter und nicht registrierter Software.

Warum: Externe Audits (z.B. durch Software-Hersteller oder Wirtschaftsprüfer) erfordern einen nachweisbaren Compliance-Status.

Ergebnis: Ein exportierbarer Bericht (PDF/Excel) mit Compliance-Status pro Produkt, Handlungsbedarf und Empfehlungen.

15.7.4 Lizenz-Ablauf-Warnungen

Was: Das System benachrichtigt den zuständigen Mitarbeiter automatisch in konfigurierbaren Intervallen (90, 60, 30, 7 Tage) vor dem Ablauf einer Software-Lizenz.

Warum: Ablaufende Lizenzen müssen rechtzeitig verlängert werden, um Unterbrechungen des Betriebs und Compliance-Verstöße zu vermeiden.

Ergebnis: Automatische Benachrichtigungen per E-Mail an den Einkauf oder die IT-Leitung mit Produktname, Ablaufdatum und verbleibenden Tagen.

15.7.5 Lizenz-Optimierungsempfehlungen

Was: Das System analysiert die tatsächliche Nutzung installierter Software und empfiehlt Optimierungen wie Deinstallation ungenutzter Software, Downgrade auf günstigere Lizenztypen oder Bündelrabatte.

Warum: Lizenzkosten können durch gezielte Optimierung erheblich gesenkt werden, ohne die Produktivität zu beeinträchtigen.

Ergebnis: Ein Empfehlungsbericht mit konkreten Vorschlägen (z.B. "WinRAR auf 30 Geräten installiert, aber nur 2x täglich genutzt -- Deinstallation empfohlen") und geschätztem Einsparpotenzial.

15.8 Compliance & Abschreibung

15.8.1 Abschreibungsplan erstellen

Was: Der IT-Controller erstellt für IT-Assets einen Abschreibungsplan auf Basis von Anschaffungswert, Nutzungsdauer und Abschreibungsmethode (linear oder degressiv).

Warum: Die buchhalterisch korrekte Abschreibung ist gesetzlich vorgeschrieben und Grundlage für die Bilanzierung und Steuererklärung.

Ergebnis: Ein Abschreibungsplan pro Asset mit monatlichen Abschreibungsbeträgen, Restbuchwerten und voraussichtlichem Zeitpunkt der Vollabschreibung.

15.8.2 Restwert für Entsorgung ermitteln

Was: Der IT-Controller berechnet den aktuellen Restwert eines Geräts bei geplanter Stilllegung oder Veräußerung.

Warum: Bei Entsorgung oder Verkauf muss der buchhalterische Restwert bekannt sein, um den Ertrag oder Verlust korrekt zu buchen.

Ergebnis: Der berechnete Restwert mit Vergleich zum möglichen Verkaufserlös (z.B. Refurbished-Markt) und der buchhalterischen Auswirkung.

15.8.3 Compliance-Audit für IT-Bestände

Was: Der IT-Verantwortliche führt einen Abgleich zwischen dem physischen Inventar und den Datenbankeinträgen durch, um Abweichungen zu identifizieren.

Warum: Diskrepanzen zwischen physischem und buchhalterischem Bestand können auf Verlust, Diebstahl oder fehlerhafte Buchungen hinweisen und müssen aufgeklärt werden.

Ergebnis: Ein Audit-Bericht mit gefundenen Abweichungen (z.B. "3 Laptops in Datenbank, aber nicht physisch auffindbar"), die zur Untersuchung markiert werden.

15.8.4 Asset-Tag und Barcode-Verwaltung

Was: Die IT-Abteilung generiert Asset-Tags und Barcodes/QR-Codes für neue Geräte und verknüpft sie im System mit dem jeweiligen Inventareintrag.

Warum: Physische Kennzeichnung mit scanbaren Tags ermöglicht eine schnelle Identifikation bei Inventuren und Service-Einsätzen.

Ergebnis: Generierte und gedruckte Asset-Tags/Barcodes, die auf den Geräten angebracht und im System eindeutig zugeordnet sind.

15.8.5 Compliance-Report für Sicherheit und Datenschutz

Was: Das System erstellt einen Bericht über den Sicherheits- und Datenschutzstatus aller IT-Assets: Verschlüsselung, Backup-Status, Antivirus, Firewall und Einhaltung von Richtlinien.

Warum: Regulatorische Anforderungen (DSGVO, ISO 27001, SOX) erfordern den dokumentierten Nachweis, dass IT-Systeme angemessen geschützt sind.

Ergebnis: Ein Compliance-Bericht mit dem Status aller Sicherheitsanforderungen pro Gerät, Abweichungen und empfohlenen Maßnahmen.

16. Terminverwaltung & Ressourcenplanung

16.1 Termine und Buchungen

16.1.1 Kunde fordert Termin an

Was: Der Kunde stellt eine Terminanfrage -- telefonisch oder über das Portal -- mit gewünschtem Zeitraum, Art der Leistung (Installation, Wartung, Reparatur), geschätzter Dauer und Einsatzort.

Warum: Die strukturierte Terminanfrage stellt sicher, dass alle für die Planung notwendigen Informationen vorliegen und der Kunde einen verbindlichen Terminvorschlag erhält.

Ergebnis: Eine registrierte Terminanfrage mit allen Rahmendaten, die als Grundlage für die automatische Slot-Suche dient.

16.1.2 System schlägt verfügbare Slots vor

Was: Das System sucht basierend auf der Terminanfrage automatisch verfügbare Zeitfenster, berücksichtigt dabei die Techniker-Qualifikationen, Kalender, Fahrtzeiten und Zonenzuordnungen.

Warum: Die automatische Slot-Suche spart manuelle Planungszeit und berücksichtigt alle Randbedingungen (Qualifikation, Anfahrt, Kapazität), die ein Mensch leicht übersehen könnte.

Ergebnis: Eine Liste von 4-5 konkreten Terminvorschlägen mit Datum, Uhrzeit, zugeordnetem Techniker und geschätzter Fahrtzeit (z.B. "Donnerstag 09:00-10:30, Technikerin Anna, 10 Min Anfahrt").

16.1.3 Kunde wählt Termin-Slot

Was: Der Kunde bestätigt einen der vorgeschlagenen Zeitslots und der Termin wird verbindlich gebucht.

Warum: Die Buchungsbestätigung reserviert den Techniker und den Zeitslot und setzt den Planungsprozess für die Vorbereitung in Gang.

Ergebnis: Ein fest gebuchter Termin, der im Techniker-Kalender eingetragen und als Aufgabe angelegt wird.

16.1.4 Terminbestätigung an Kunde

Was: Das System versendet automatisch eine schriftliche Bestätigung per E-Mail und/oder SMS mit Termin-Datum, Uhrzeit, Techniker-Name, Adresse und Handynummer des Technikers.

Warum: Die schriftliche Bestätigung schafft Verbindlichkeit und gibt dem Kunden alle Informationen, die er für die Vorbereitung benötigt.

Ergebnis: Eine zugestellte Terminbestätigung mit allen Details, optional ergänzt um Vorbereitungshinweise für den Kunden.

16.1.5 Termine verschieben/absagen

Was: Der Kunde oder Techniker verschiebt oder storniert einen bestehenden Termin, wobei das System automatisch alle Beteiligten benachrichtigt und bei Bedarf Ersatztermine vorschlägt.

Warum: Terminänderungen sind im Alltag unvermeidlich (Krankheit, Terminverschiebung des Kunden). Das System muss flexibel darauf reagieren und den Planungsaufwand minimieren.

Ergebnis: Ein verschobener oder stornierter Termin mit aktualisiertem Techniker-Kalender, Benachrichtigung aller Beteiligten und optional einem neuen Terminvorschlag.

16.1.6 Techniker-Arbeitskalender verwalten

Was: Der Personalverantwortliche pflegt die Arbeitszeitmodelle, Urlaubstage, Krankheitstage und sonstigen Abwesenheiten pro Techniker im System.

Warum: Die Terminplanung kann nur dann korrekte Verfügbarkeiten berechnen, wenn die tatsächlichen Arbeitszeiten und Abwesenheiten hinterlegt sind.

Ergebnis: Ein aktueller Verfügbarkeitskalender pro Techniker, der bei der Terminslot-Berechnung automatisch berücksichtigt wird (z.B. "Anna hat Urlaub 15.-21. Juli -- wird nicht vorgeschlagen").

16.1.7 Techniker-Qualifikationen und Spezialisierung

Was: Der Personalverantwortliche hinterlegt die Fähigkeiten und Spezialisierungen jedes Technikers (z.B. Linux, Netzwerk, Datenbank), damit das System nur qualifizierte Techniker für bestimmte Aufgaben vorschlägt.

Warum: Ein Netzwerk-Installationsauftrag erfordert einen Netzwerk-Spezialisten. Fehlzuweisungen verursachen Folgekosten und Kundenzufriedenheitsverluste.

Ergebnis: Ein Skill-Profil pro Techniker, das bei der Terminplanung automatisch mit den Anforderungen der Serviceleistung abgeglichen wird.

16.1.8 Maximale Tagesauslastung begrenzen

Was: Der Planer legt eine maximale Anzahl von Terminen und/oder Arbeitsstunden pro Techniker und Tag fest, die das System bei der Terminvergabe nicht überschreiten darf.

Warum: Überlastung führt zu schlechter Servicequalität, Fehlern und Mitarbeiterausfällen. Kapazitätsgrenzen schützen sowohl den Techniker als auch die Kundenzufriedenheit.

Ergebnis: Eingehaltene Kapazitätsgrenzen, wobei das System bei Erreichen des Limits keine weiteren Termine für diesen Techniker vorschlägt (z.B. "Hans hat schon 4 Termine Montag, nächster Slot erst Dienstag").

16.1.9 Überstunden-Tracking

Was: Das System erfasst und überwacht die tatsächlich geleisteten Stunden im Vergleich zu den geplanten Stunden und weist Überstunden pro Techniker aus.

Warum: Dauerhafte Mehrarbeit muss erkannt werden, um Gegenmaßnahmen zu ergreifen (z.B. Termine umverteilen, zusätzliches Personal einsetzen).

Ergebnis: Ein Überstunden-Report pro Techniker mit Vergleich Plan-/Ist-Stunden und Warnung bei auffälligen Überschreitungen (z.B. "Anna hat seit 3 Wochen Überstunden").

16.1.10 Termin einem Techniker zuweisen

Was: Der Disponent weist einen bestätigten Kundentermin einem konkreten, qualifizierten Techniker zu, der zu diesem Zeitpunkt verfügbar ist.

Warum: Die explizite Zuweisung ist Voraussetzung für die Routenplanung und stellt sicher, dass der Techniker über seinen Einsatz informiert wird.

Ergebnis: Ein zugewiesener Termin im Kalender des Technikers, der als Grundlage für die Tagesroutenplanung dient.

16.2 Techniker-Routenoptimierung

16.2.1 Fahrt-Zonen definieren

Was: Der Disponent definiert geographische Servicezonen (z.B. "München-Mitte", "München-Nord", "Umland") und ordnet ihnen primäre und Backup-Techniker zu.

Warum: Die Zoneneinteilung ermöglicht eine effiziente Einsatzplanung, bei der Techniker bevorzugt in ihrer Stammzone eingesetzt werden und Fahrtzeiten minimiert werden.

Ergebnis: Definierte Zonen mit geographischen Grenzen und zugeordneten Technikern, die bei der Terminplanung automatisch berücksichtigt werden.

16.2.2 Kunde-Standort zu Zone zuordnen

Was: Das System ordnet Kundenstandorte automatisch anhand der Adresse (Postleitzahl/Geocoding) der passenden Servicezone zu.

Warum: Die automatische Zonenzuordnung eliminiert manuelle Eingaben und stellt sicher, dass der geographisch nächste Techniker vorgeschlagen wird.

Ergebnis: Eine automatisch zugewiesene Zone pro Kundenstandort (z.B. "Neuer Kunde in München Schwabing -- automatisch Zone Nord").

16.2.3 Route-Vorschlag pro Techniker/Tag

Was: Das System generiert für jeden Techniker eine optimierte Besuchsreihenfolge, die die Fahrtzeit zwischen allen Terminen eines Tages minimiert.

Warum: Eine optimierte Route spart Fahrtzeit, Kraftstoffkosten und ermöglicht mehr Kundenbesuche pro Tag. Die manuelle Optimierung bei mehreren Terminen ist fehleranfällig und zeitaufwändig.

Ergebnis: Eine optimierte Tagesroute mit Besuchsreihenfolge, geschätzten Fahrtzeiten zwischen den Stationen und Zeitersparnis gegenüber einer nicht optimierten Route.

16.2.4 Fahrtzeit-Berechnung zwischen Punkten

Was: Das System berechnet die realistische Reisezeit zwischen zwei Kundenstandorten unter Berücksichtigung der aktuellen Verkehrslage.

Warum: Realistische Fahrtzeitschätzungen sind Voraussetzung für eine machbare Tagesplanung und verhindern verspätete Termine.

Ergebnis: Die geschätzte Fahrtzeit bei normaler Verkehrslage und bei Stoßzeitverkehr, sowie die Entfernung in Kilometern.

16.2.5 Puffer und Flexibilität einplanen

Was: Der Planer hinterlegt Zeitpuffer pro Termin (z.B. 15 Minuten für Parkplatzsuche und Vorbereitung), Mittagspausen und einen Notfall-Slot für dringende Reparaturen.

Warum: Ein vollständig durchgeplanter Tag ohne Puffer führt bei der kleinsten Verzögerung zu Dominoeffekten bei allen Folgeterminen.

Ergebnis: Eine Tagesplanung mit eingebauten Pufferzeiten, die Überziehungen und unvorhergesehene Aufgaben auffangen kann.

16.2.6 Tages-Tournee zusammenstellen

Was: Der Disponent fasst die Termine eines Technikers zu einer strukturierten Tagestour zusammen, inklusive Start- und Endzeit, Kilometerschätzung und Kundenliste.

Warum: Die Tour als ganzheitliche Planungseinheit ermöglicht eine Gesamtbewertung der Tagesauslastung und die Berechnung der Tourenkosten.

Ergebnis: Eine definierte Tagestour mit allen Stationen, geschätztem Kilometeraufwand und Zeitplan.

16.2.7 Fahrt-Kosten berechnen

Was: Das System berechnet die Reisekosten einer Tour auf Basis der Kilometer und eines konfigurierbaren Kilometersatzes (z.B. 0,50 EUR/km).

Warum: Die Fahrtkosten sind Bestandteil der Projektkalkulation und ggf. dem Kunden in Rechnung zu stellen.

Ergebnis: Die berechneten Reisekosten pro Tour (z.B. "120 km x 0,50 EUR = 60,00 EUR") als Grundlage für Abrechnung und Auslagenerstattung.

16.2.8 Tages-Zusammenfassung für Techniker

Was: Das System erstellt für den Techniker eine druckbare oder mobil abrufbare Tagesübersicht mit allen Terminen, Adressen, Ansprechpartnern, Aufgaben und benötigtem Material.

Warum: Der Techniker benötigt eine klare, kompakte Übersicht seines Tages, um sich auf die Kundengespräche und Aufgaben vorbereiten zu können.

Ergebnis: Eine strukturierte Tages-Zusammenfassung mit Zeitplan, Kundendetails (inkl. Telefonnummer), Aufgabenbeschreibung, benötigtem Material und geschätzter Gesamtfahrtzeit.

16.3 Ressourcen-Kapazitätsplanung

16.3.1 Nachfrage-Prognose erstellen

Was: Der Manager erstellt auf Basis historischer Daten eine Vorhersage der zukünftigen Terminanfragen für kommende Wochen und Monate.

Warum: Die vorausschauende Kapazitätsplanung ermöglicht es, rechtzeitig zusätzliches Personal bereitzustellen oder Wartungstermine in ruhigere Perioden zu verschieben.

Ergebnis: Eine Nachfrageprognose mit geschätzter Terminanzahl, Gesamtstundenaufwand und Kapazitätsauslastung in Prozent (z.B. "August: 20% mehr Anfragen erwartet wegen Umzugsperiode").

16.3.2 Personalbedarfs-Analyse

Was: Das System berechnet die benötigten Vollzeitkräfte pro Zeitraum und Qualifikationsbereich und gleicht sie mit der aktuellen Personalkapazität ab.

Warum: Ein erkannter Personalengpass kann durch frühzeitige Maßnahmen (Einstellung, Leihpersonal, Verschiebung) aufgefangen werden.

Ergebnis: Eine Bedarfsanalyse mit Vollzeitäquivalent-Bedarf, aktuellem Bestand und Defizit/Überschuss (z.B. "Defizit: 0,2 FTE = 1 Tag/Woche externe Unterstützung nötig").

16.3.3 Verfügbarkeits-Analyse

Was: Das System identifiziert Wochen mit Kapazitätsengpässen, indem es die geplante Auslastung pro Woche berechnet und Überlastungen farblich markiert.

Warum: Engpässe müssen frühzeitig erkannt werden, damit durch Terminverschiebungen, Überstundenplanung oder externe Unterstützung gegengesteuert werden kann.

Ergebnis: Eine Wochen-Übersicht mit Auslastung in Prozent pro Woche, Warnung bei Überlastung (z.B. "Woche 2: 105% -- keine Kapazität") und Empfehlungen zur Engpassvermeidung.

16.4 Service Level Agreements

16.4.1 SLA-Stufen definieren nach Priorität

Was: Der Service-Manager definiert für jede Prioritätsstufe (kritisch, hoch, mittel, niedrig) die maximale Reaktions- und Lösungszeit, z.B. Priorität 1: 1 Stunde Reaktion, 4 Stunden Lösung.

Warum: Unterschiedliche Vorfälle erfordern unterschiedliche Reaktionsgeschwindigkeiten. Die SLA-Definition schafft klare Erwartungshaltungen gegenüber dem Kunden und messbare Zielvorgaben für das Team.

Ergebnis: Definierte SLA-Stufen, die automatisch bei Ticket-Erstellung anhand der Priorität zugewiesen werden und die Eskalationsregeln steuern.

16.4.2 SLA-Status real-time überwachen

Was: Der Teamleiter sieht auf einem Live-Dashboard den SLA-Status aller offenen Tickets mit Ampelsystem: grün (im Plan), gelb (Warnung, >50% der Zeit verbraucht), rot (SLA überschritten).

Warum: Die Echtzeit-Überwachung ermöglicht es, drohende SLA-Verletzungen rechtzeitig zu erkennen und durch Umpriorisierung oder Eskalation zu verhindern.

Ergebnis: Ein Dashboard mit Ampel-Anzeige pro Ticket, das die verbrauchte SLA-Zeit im Verhältnis zur erlaubten Zeit darstellt.

16.4.3 Automatische Eskalation bei SLA-Verletzung

Was: Das System benachrichtigt automatisch stufenweise (25% SLA-Zeit: Teamleiter, 75%: Manager, 100%: SMS an Bereitschaft), wenn ein Ticket die SLA-Fristen zu verfehlen droht.

Warum: Automatische Eskalation stellt sicher, dass drohende Verletzungen nicht unbemerkt bleiben und dass die Verantwortung rechtzeitig an die nächste Eskalationsstufe übergeht.

Ergebnis: Ausgelöste Eskalationsmeldungen per E-Mail und SMS an die definierten Empfänger mit Ticket-Details und verbleibender SLA-Zeit.

16.4.4 SLA-Compliance-Report

Was: Das System erstellt einen monatlichen Bericht über die SLA-Einhaltungsquote mit Aufschlüsselung nach Priorität, häufigsten Verletzungsgründen und Verbesserungsempfehlungen.

Warum: Der regelmäßige Report ist die Grundlage für die Kundenkommunikation, Vertragsverhandlungen und die interne Prozessverbesserung.

Ergebnis: Ein PDF-Report mit Erfüllungsrate (z.B. 95%), durchschnittlichen Reaktions-/Lösungszeiten, Auswertung nach Priorität und konkreten Empfehlungen.

16.4.5 SLA-basierte Eskalation bei häufigen Verletzungen

Was: Das System erkennt Trends bei wiederkehrenden SLA-Verletzungen (z.B. >10% Verletzungen über 3 Monate bei einer Prioritätsstufe) und löst eine strategische Eskalation aus.

Warum: Einzelne SLA-Verletzungen sind unvermeidbar, aber systematische Muster erfordern strukturelle Maßnahmen (mehr Personal, angepasste SLAs, Prozessverbesserungen).

Ergebnis: Eine Trendanalyse mit Eskalation an das Management, die den Verletzungstrend quantifiziert und Handlungsoptionen vorschlägt (z.B. "P4-SLA seit 3 Monaten >15% verletzt -- Erhöhung auf 15 Tage empfohlen").

17. State Machines & Wizard-Workflows (Übergreifend)

17.1 Beleg-State-Machine

17.1.1 Kundenauftrag bis Abschluss

Was: Ein Beleg durchläuft seinen vollständigen Lebenszyklus von der Erstellung über die Bestätigung, Lieferung und Rechnungsstellung bis zum abgeschlossenen Status, wobei jeder Schritt validiert und protokolliert wird.

Warum: Der korrekte Durchlauf aller Belegstadien stellt sicher, dass Warenausgänge, Rechnungen und Zahlungen lückenlos verknüpft sind und keine Schritte übersprungen werden.

Ergebnis: Ein abgeschlossener Beleg mit vollständiger Statushistorie (Erstellt, Offen, Abgeschlossen), verbuchter Zahlung und korrekt reduziertem Lagerbestand.

17.1.2 Stornierung vor Versand

Was: Ein Mitarbeiter storniert einen Kundenauftrag, bevor die Ware das Lager verlassen hat, wobei das System prüft, dass keine Teillieferungen bereits unterwegs sind.

Warum: Kunden ändern ihre Meinung oder stornieren Bestellungen. Solange die Ware nicht versendet ist, muss eine kostenfreie Stornierung möglich sein, um Lagerreservierungen freizugeben.

Ergebnis: Ein stornierter Beleg mit freigegebener Lagerreservierung, Storno-Bestätigung an den Kunden per E-Mail und protokollierter Opportunitätskosten-Erfassung.

17.1.3 Teillieferung und Nachlieferung

Was: Wenn nicht alle bestellten Artikel sofort verfügbar sind, erstellt das System eine Teillieferung für die vorhandenen Artikel und setzt die Restmenge als Nachlieferung auf Wiedervorlage.

Warum: Der Kunde soll die verfügbare Ware möglichst schnell erhalten, anstatt auf die vollständige Verfügbarkeit warten zu müssen. Gleichzeitig muss die Nachlieferung sicher gestellt sein.

Ergebnis: Ein Lieferschein über die Teillieferung, eine Teil-Rechnung und ein offener Restauftrag für die ausstehende Menge mit voraussichtlichem Lieferdatum.

17.1.4 Rechnungsdispute und Gutschrift

Was: Ein Kunde reklamiert eine Rechnung (z.B. beschädigte Ware), woraufhin nach Prüfung eine Gutschrift erstellt und die Zahlung rückerstattet wird.

Warum: Reklamationen müssen schnell und korrekt abgewickelt werden, um die Kundenzufriedenheit zu erhalten und die Buchführung konsistent zu halten.

Ergebnis: Ein Gutschriftbeleg mit Rückbuchung des Betrags auf das Kundenkonto, Stornierung der Umsatzbuchung und optional ein neuer Auftrag für die kostenlose Ersatzlieferung.

17.2 Freigabe-System (Release)

17.2.1 Standard-Freigabe-Workflow (6 Schritte)

Was: Ein Firmenkunde legt einen Warenkorb im Web-Portal an, reicht ihn zur Prüfung ein, ein Prüfer kontrolliert Budget und Artikelfreigabe, ein Einkäufer gibt die Bestellung frei, und das System erzeugt automatisch den Kundenauftrag.

Warum: Das Vier-Augen-Prinzip im Einkaufsprozess stellt sicher, dass Bestellungen budgetkonform und genehmigt sind, bevor sie verbindlich aufgegeben werden -- eine Anforderung in vielen deutschen und schweizerischen Unternehmen.

Ergebnis: Ein freigegebener und automatisch in eine Bestellung umgewandelter Warenkorb mit vollständiger Prüfhistorie (Erstellt, In Prüfung, Geprüft, Bestellt) und Benachrichtigung aller Beteiligten.

17.2.2 Freigabe mit Rückweisung und Überarbeitung

Was: Der Prüfer weist einen Warenkorb zurück (z.B. wegen Budgetüberschreitung), der Besteller passt den Warenkorb an und reicht ihn erneut ein.

Warum: Nicht jede Bestellung wird sofort genehmigt. Der strukturierte Überarbeitungsprozess stellt sicher, dass der Besteller die Rückweisungsgründe kennt und gezielt korrigieren kann.

Ergebnis: Ein überarbeiteter und erneut eingereichter Warenkorb, der den Prüfprozess von vorne durchläuft. Alle Rückweisungsgründe und Änderungen sind lückenlos dokumentiert.

17.2.3 Freigabe-Timeout und Eskalation

Was: Verbleibt ein Warenkorb länger als die konfigurierte Frist (z.B. 4 Stunden) im Prüfstatus, eskaliert das System automatisch an den Vorgesetzten des Prüfers.

Warum: Liegengebliebene Warenkörbe verzögern die Beschaffung und beeinträchtigen die Kundenzufriedenheit. Automatische Eskalation verhindert Stillstand.

Ergebnis: Eine automatische Benachrichtigung an den Vorgesetzten mit der Möglichkeit, die Prüfung zu übernehmen oder die Freigabe im Override zu erteilen.

17.2.4 Mehrfache Überarbeitungszyklen

Was: Ein Warenkorb durchläuft mehrere Rückweisungs-/Überarbeitungs-Iterationen (erst vom Prüfer, dann vom Einkäufer), wobei der Prozess bei jeder Überarbeitung wieder beim Prüfer startet.

Warum: Der Neustart beim Prüfer nach jeder Änderung gewährleistet, dass jede Modifikation das vollständige Vier-Augen-Verfahren durchläuft und die Compliance gewahrt bleibt.

Ergebnis: Ein vollständig geprüfter und freigegebener Warenkorb nach beliebig vielen Iterationen, mit lückenloser Dokumentation aller Überarbeitungsschritte. Nach 3 Zyklen erfolgt eine automatische Eskalation an den Vertriebsleiter.

17.3 Artikel-Lifecycle

17.3.1 Artikel von Lager bis Lieferung

Was: Ein serialisierter Artikel durchläuft seinen Standard-Lebenszyklus: Wareneingang, Qualitätsprüfung, Einlagerung, Reservierung durch Kundenauftrag, Kommissionierung, Verpackung, Versand und Rechnungsstellung.

Warum: Die lückenlose Nachverfolgung jedes einzelnen Artikels per Barcode stellt sicher, dass Lagerbestände korrekt sind, Garantieansprüche nachvollziehbar bleiben und die Logistik effizient abläuft.

Ergebnis: Ein vollständig nachverfolgbarer Artikel mit Statushistorie von der Ersterfassung bis zur Auslieferung, inklusive Standort, Zeitstempel und beteiligtem Mitarbeiter bei jedem Schritt.

17.3.2 Artikel-Retoure und Wiedereinlagerung (RMA)

Was: Ein Kunde meldet einen defekten Artikel zurück, das Lager nimmt ihn entgegen, die Qualitätsprüfung entscheidet über Reparatur oder Austausch, und nach erfolgreicher Reparatur wird der Artikel wieder eingelagert.

Warum: Retouren müssen strukturiert abgewickelt werden, damit Garantieansprüche korrekt bearbeitet, die Kosten nachvollziehbar zugeordnet und reparierte Artikel wieder dem Bestand zugeführt werden.

Ergebnis: Ein reparierter und wieder eingelagerter Artikel mit vollständiger RMA-Historie (Retourengrund, Inspektionsergebnis, Reparaturkosten, Wiedereinlagerungsdatum).

17.3.3 Artikel-Verschrottung

Was: Ein retournierter Artikel wird nach der Qualitätsprüfung als wirtschaftlich nicht reparierbar eingestuft und verschrottet, wobei ein Wertabschreibungsbeleg erstellt wird.

Warum: Nicht reparierbare Artikel müssen korrekt ausgebucht werden, damit der Lagerbestand stimmt und die buchhalterische Wertberichtigung erfolgt.

Ergebnis: Ein verschrotteter Artikel mit dokumentiertem Verschrottungsgrund, abgeschlossener Wertberichtigung und aktualisiertem Lagerbestand.

17.3.4 Interner Lagerumbuchung

Was: Ein Artikel wird von einem Lagerstandort an einen anderen transferiert (z.B. von Lager A nach Lager B), wobei beide Lager den Transfer bestätigen.

Warum: Interne Transfers müssen nachvollziehbar sein, damit der Gesamtbestand korrekt bleibt und jeder Standort seinen aktuellen Bestand kennt.

Ergebnis: Ein transferierter Artikel mit aktualisiertem Standort, wobei der Gesamtbestand unverändert bleibt (Lager A: -1, Lager B: +1).

17.3.5 Ersatzartikel-Workflow

Was: Ein Kunde erhält kostenlos einen Ersatzartikel, während der defekte Artikel per Rücksendeetikett zurückgeschickt wird. Der Ersatzartikel wird ohne Berechnung versendet.

Warum: Bei Kulanz oder Garantiefällen muss der Kunde schnell einen funktionierenden Ersatz erhalten, ohne dass eine separate Bestellung mit Berechnung erforderlich ist.

Ergebnis: Ein versendeter Ersatzartikel mit Nullbetrags-Rechnung und ein retournierter Defektartikel, dessen Kosten korrekt als Garantieaufwand verbucht werden.

17.3.6 Artikel verloren bei Inventur

Was: Bei der physischen Inventur wird ein Artikel nicht am dokumentierten Lagerplatz gefunden. Das System startet eine Untersuchung, und nach Ablauf der Klärungsfrist wird der Artikel als Verlust ausgebucht.

Warum: Fehlbestände müssen erkannt, dokumentiert und buchhalterisch korrekt behandelt werden -- sei es durch Wertberichtigung, Versicherungsmeldung oder Korrektur eines Buchungsfehlers.

Ergebnis: Ein als verloren markierter Artikel mit dokumentierter Untersuchung (Ursachenvermutung: Diebstahl, Fehlbuchung, Etikettierungsfehler), Wertberichtigung und gegebenenfalls Versicherungsmeldung.

17.3.7 Seriennummer-Abweichung klären

Was: Bei der Warenannahme oder Inventur stimmt die aufgeklebte Seriennummer nicht mit der im System hinterlegten überein. Der Mitarbeiter startet einen Klärungsworkflow mit Lieferantenrückfrage.

Warum: Seriennummer-Abweichungen können auf Fehllieferungen, Tippfehler oder schwerwiegendere Probleme hinweisen und müssen vor der Einlagerung oder Auslieferung geklärt werden.

Ergebnis: Ein korrigierter Seriennummer-Eintrag nach Klärung mit dem Lieferanten, dokumentiert mit Änderungsgrund, Lieferantenbestätigung und vollständigem Audit-Trail.

17.3.8 Demo-Gerät deaktivieren

Was: Ein Demo- oder Leihgerät wird nach dem Einsatz (z.B. Messe) ins Lager zurückgebracht und je nach Zustand zur Wiederverwendung aufbereitet oder aus dem Tracking entfernt.

Warum: Demo-Geräte haben einen Sonder-Lebenszyklus und können nach Gebrauch nicht immer als Neuware verkauft werden. Der Status muss den tatsächlichen Zustand korrekt widerspiegeln.

Ergebnis: Ein deaktiviertes oder zur Wiederverwendung aufbereitetes Gerät mit Verleihhistorie und Zustandsdokumentation (Aktiv, Rückruf, Aufbereitung, Wiederverwendung/Entsorgung).

17.3.9 Artikel-Zustandsänderung

Was: Der Zustand eines Artikels wird dokumentiert geändert (z.B. von "Neu" auf "Gebraucht" oder von "Defekt" auf "Repariert/Einsatzbereit"), inklusive Grund und Auswirkung auf die Bewertung.

Warum: Die Zustandsänderung beeinflusst den Verkaufspreis, die Lagerkategorie und die buchhalterische Bewertung des Artikels.

Ergebnis: Ein aktualisierter Artikelzustand mit dokumentiertem Änderungsgrund, angepasstem Preistier (z.B. Preisreduzierung bei Zustandsabstufung) und Audit-Eintrag.

17.3.10 Batch-Wareneingang

Was: Bei einer Palettenlieferung werden mehrere Artikel gleichzeitig erfasst: Sammelerfassung von Seriennummern, Mengen, Qualitätsprüfung und Lagerortzuweisung in einem Vorgang.

Warum: Die Einzelerfassung großer Lieferungen ist zu zeitaufwändig. Der Batch-Wareneingang beschleunigt den Prozess und ermöglicht eine Stichproben-Qualitätsprüfung.

Ergebnis: Alle Artikel der Lieferung sind eingelagert oder (bei Qualitätsmängeln) aussortiert, mit Protokoll über bestandene/nicht bestandene Prüfungen und Lieferanten-Belastungsanzeige für defekte Ware.

17.4 Kommissionierungs-State-Machine

17.4.1 Vollständige Kommissionierung

Was: Alle Artikel eines Kundenauftrags werden im Lager gefunden, gepickt, verpackt und als vollständig kommissioniert zum Versand freigegeben.

Warum: Die vollständige Kommissionierung ist der Standardfall und soll so effizient wie möglich ablaufen, damit der Kunde seine Bestellung schnellstmöglich erhält.

Ergebnis: Ein vollständig kommissionierter und versandbereiter Auftrag mit Status "Geliefert" und generierten Versanddokumenten.

17.4.2 Kommissionierung mit Teilbestand

Was: Nur ein Teil der bestellten Artikel ist im Lager verfügbar. Das System schlägt entweder eine Teillieferung oder das Warten auf Vollständigkeit vor.

Warum: Der Kunde soll informiert werden und entscheiden können, ob er die verfügbare Ware sofort oder die vollständige Lieferung später möchte.

Ergebnis: Entweder eine Teillieferung mit offener Restbestellung oder ein wartender Auftrag, der bei Vollständigkeit automatisch zur Kommissionierung freigegeben wird.

17.4.3 Kommissionierung mit Bestandsfehler

Was: Das System zeigt einen Artikel als verfügbar an, aber im Lager ist er physisch nicht auffindbar. Der Mitarbeiter meldet die Abweichung.

Warum: Bestandsdifferenzen müssen sofort erkannt und dokumentiert werden, um die Ursache zu klären und den Kunden über Verzögerungen zu informieren.

Ergebnis: Ein dokumentierter Bestandsfehler, eine korrigierte Lagermenge und eine Benachrichtigung an den Kunden über die Verzögerung mit voraussichtlichem Nachliefertermin.

17.5 Marketing-Kampagnen-Lifecycle

17.5.1 Kampagnen-Lifecycle

Was: Eine Marketing-Kampagne durchläuft die Phasen Geplant, Aktiv, Pausiert und Abgeschlossen, wobei in jeder Phase spezifische Kennzahlen (Reichweite, Konversion, Kosten) erfasst werden.

Warum: Die strukturierte Kampagnensteuerung ermöglicht eine kontrollierte Durchführung mit der Möglichkeit, Kampagnen bei schlechter Performance zu pausieren oder Budgets umzuverteilen.

Ergebnis: Eine Kampagne mit vollständiger Statushistorie und Metriken-Tracking pro Phase, die als Grundlage für die Erfolgsauswertung und zukünftige Planung dient.

17.6 Kontingent-State-Machine

17.6.1 Kontingent einrichten

Was: Der Vertragsmanager erstellt einen Kontingent-Container mit definierten Gültigkeitszeitraum, Mengeneinheit und Gesamtvolumen (z.B. 100 GB Backup pro Monat).

Warum: Kontingent-basierte Verträge erfordern eine klar definierte Obergrenze, gegen die der Verbrauch laufend gemessen wird.

Ergebnis: Ein aktiver Kontingent-Container mit definiertem Rahmen, der bei Verbrauchsbuchungen automatisch reduziert wird.

17.6.2 Kontingent reservieren und verbrauchen

Was: Ein Kunde reserviert einen Anteil seines Kontingents für einen Auftrag, und nach Leistungserbringung wird die reservierte Menge als verbraucht gebucht.

Warum: Die Zweischritt-Logik (Reservierung, dann Verbrauch) verhindert Überbuchungen und gibt dem Kunden Transparenz über seinen aktuellen Verfügbarkeitsstand.

Ergebnis: Ein reduziertes Kontingent mit dokumentierter Reservierung und Verbrauchsbuchung, abrufbar als aktueller Kontingentstand.

17.6.3 Reservierung stornieren

Was: Eine nicht in Anspruch genommene Kontingent-Reservierung wird storniert und die Menge wird dem offenen Pool zurückgegeben.

Warum: Nicht genutzte Reservierungen dürfen das verfügbare Kontingent nicht dauerhaft blockieren.

Ergebnis: Ein wieder aufgefülltes Kontingent in Höhe der stornierten Reservierung mit dokumentiertem Stornierungsgrund.

17.6.4 Kontingent-Ablauf und Auffüllung

Was: Am Ende des Gültigkeitszeitraums verfallen ungenutzte Kontingente automatisch, und für die neue Periode wird ein neuer Kontingent-Container angelegt.

Warum: Zeitlich begrenzte Kontingente dürfen nicht unbegrenzt angesammelt werden. Der automatische Ablauf und die Neuanlage entsprechen den vertraglichen Vereinbarungen.

Ergebnis: Ein abgelaufener Kontingent-Container mit dokumentiertem Restbestand und ein neuer Container für die Folgeperiode.

17.6.5 Geld-Kontingent mit Overbooking

Was: Der Vertragsmanager richtet ein monatliches Budget-Kontingent ein (z.B. 5.000 EUR Support) mit konfigurierbarer Overbooking-Regelung (z.B. 10% Überschreitung erlaubt).

Warum: Starre Kontingentgrenzen können im Alltag unpraktisch sein. Eine kontrollierte Überbuchungsmöglichkeit bietet Flexibilität, ohne den Rahmen zu sprengen.

Ergebnis: Ein Geld-Kontingent, das bei Erreichen von 100% warnt und bis zur konfigurierten Überbuchungsgrenze weiter nutzbar ist, mit automatischer Warnung an den Kunden und den Vertrieb.

17.6.6 Stunden-Kontingent für Dienstleister

Was: Ein stunden-basiertes Kontingent (z.B. 40 Stunden pro Monat) wird eingerichtet und der Verbrauch automatisch aus den Helpdesk-Timern erfasst.

Warum: Dienstleistungsverträge mit Stundenkontingenten erfordern eine automatische Verbrauchserfassung, damit weder der Kunde noch der Dienstleister den Überblick verlieren.

Ergebnis: Ein aktueller Kontingentstand mit automatischer Erfassung der geleisteten Stunden aus der Zeiterfassung und Warnmeldung bei drohender Erschöpfung.

17.6.7 Quartals-Kontingent mit Warengruppen-Zuordnung

Was: Ein quartalsmäßiges Kontingent wird eingerichtet und spezifischen Warengruppen zugeordnet (z.B. 20 Stunden Hardware-Support, 20 Stunden Software-Support).

Warum: Die Aufschlüsselung nach Warengruppen ermöglicht eine differenzierte Nutzungskontrolle und verhindert, dass das gesamte Kontingent einseitig verbraucht wird.

Ergebnis: Ein Quartals-Kontingent mit separater Verbrauchsanzeige pro Warengruppe und Warnung bei ungleichmäßigem Verbrauch.

17.6.8 Kontingent-Übertrag in Folgeperiode

Was: Der Vertragsmanager konfiguriert, ob und in welchem Umfang ungenutzte Kontingent-Reste in die nächste Abrechnungsperiode übernommen werden (vollständig, anteilig oder verfallend).

Warum: Je nach Vertrag kann ein Übertrag vereinbart sein oder bewusst ausgeschlossen werden. Die Konfiguration muss die vertragliche Vereinbarung abbilden.

Ergebnis: Eine konfigurierte Übertragungsregel pro Kontingent, die am Periodenende automatisch den Übertrag (oder Verfall) berechnet und dokumentiert.

17.6.9 Gratis-Perioden (Promotions)

Was: Der Vertriebsmitarbeiter weist einem Kunden eine kostenfreie Kontingent-Periode als Werbeaktion oder Kulanzleistung zu, die nach Ablauf automatisch in die reguläre Abrechnung übergeht.

Warum: Gratis-Perioden sind ein Vertriebsinstrument zur Kundengewinnung oder Kundenbindung, deren befristete Natur im System abgebildet sein muss.

Ergebnis: Eine zeitlich befristete kostenlose Kontingent-Periode mit automatischem Übergang zur regulären Abrechnung nach Ablauf.

17.6.10 Kontingent-Umverteilung während Vertragslaufzeit

Was: Der Vertragsmanager verschiebt Kontingent-Anteile zwischen verschiedenen Verträgen oder Warengruppen innerhalb eines laufenden Vertragsverhältnisses.

Warum: Kundenanforderungen ändern sich während der Vertragslaufzeit. Flexibilität in der Kontingent-Verteilung erhöht die Kundenzufriedenheit ohne Vertragsänderung.

Ergebnis: Umverteilte Kontingent-Anteile mit dokumentiertem Änderungsgrund und unveränderbarem Gesamtvolumen.

17.7 Self-Service Formulare

17.7.1 Self-Service Formular-Lifecycle

Was: Ein Self-Service-Formular durchläuft die Phasen Entwurf, Eingereicht, Genehmigt oder Abgelehnt und Abgeschlossen, wobei bei Ablehnung eine Überarbeitung und erneute Einreichung möglich ist.

Warum: Genehmigungs-Workflows für Standardanträge (z.B. Berechtigungsanfragen, Bestellanforderungen) sollen auch ohne manuellen Eingriff strukturiert abgewickelt werden.

Ergebnis: Ein durchlaufenes Formular mit vollständiger Statushistorie und Genehmigungsdokumentation, das bei Bedarf archiviert wird.

17.8 Wizard-Workflows (Vertragsmanagement)

17.8.1 Neuer Vertrag mit Adress-/Lieferadress-Handling

Was: Der Sachbearbeiter erstellt einen neuen Vertrag im Assistenten und legt dabei Liefer-, Rechnungs- und Lizenznehmeradresse fest, wobei die Kundenadresse automatisch vorausgefüllt wird und alternative Lieferadressen aus hinterlegten Mandaten gewählt werden können.

Warum: Verträge erfordern korrekte Adressen für Lieferung, Rechnungsstellung und Lizenzierung. Die automatische Übernahme und Validierung verhindert Fehler bei der Zustellung und Rechnungsstellung.

Ergebnis: Ein Vertrag mit validierten Adressen (inkl. Postleitzahlenprüfung), wobei alternative Lieferadressen für Filialen oder Tochtergesellschaften hinterlegt werden können.

17.8.2 Geräte-Rollout-Vertrag (RMM)

Was: Der Sachbearbeiter erstellt einen Vertrag für den Rollout von Remote-Monitoring-Equipment, ordnet die betroffenen Geräte über Stammblätter zu und konfiguriert die Zähler für verbrauchsbasierte Abrechnung.

Warum: RMM-Verträge erfordern eine exakte Zuordnung der zu überwachenden Geräte und deren Zählertypen, damit die automatisierte Abrechnung korrekt funktioniert.

Ergebnis: Ein aktivierter RMM-Vertrag mit zugeordneten Stammblättern, konfigurierten Zählern und Monitoring-Positionen, der für die automatisierte Abrechnung bereit ist.

17.8.3 Service-/Produkt-/Mischvertrag

Was: Der Sachbearbeiter wählt den Vertragstyp -- stundenbasierter Dienstleistungsvertrag, Festpreis-Produktvertrag oder Mischvertrag -- und der Assistent passt die verfügbaren Konfigurationsoptionen entsprechend an.

Warum: Jeder Vertragstyp hat eigene Abrechnungslogiken, Positions- und Kontingentregeln. Die typspezifische Konfiguration stellt sicher, dass der Vertrag korrekt abgerechnet wird.

Ergebnis: Ein typengerecht konfigurierter Vertrag mit den für den jeweiligen Typ relevanten Positionen, Preisstrukturen und Abrechnungsregeln.

17.8.4 Counter-basierte Positionen

Was: Der Sachbearbeiter verknüpft eine Vertragsposition mit einem physischen Zähler (z.B. Klick-Zähler eines Druckers, Stromzähler), sodass die Abrechnung auf Basis des tatsächlichen Verbrauchs erfolgt.

Warum: Verbrauchsbasierte Abrechnung erfordert eine korrekte Verknüpfung zwischen Vertragsposition und Zähler, damit die richtigen Mengen zum richtigen Preis berechnet werden.

Ergebnis: Eine Vertragsposition mit zugeordnetem Zähler, konfiguriertem Preis pro Einheit und automatischer Mengenermittlung aus Zählerständen.

17.8.5 Kontingent-Konfiguration (Geld/Stunden/Quartals)

Was: Der Sachbearbeiter konfiguriert im Vertragsassistenten ein Kontingent -- monatliches Geld-Budget, Stundenkontingent oder Quartalskontingent -- mit Overbooking-Regeln und optionalem Periodenübertrag.

Warum: Die Kontingent-Konfiguration bestimmt die Abrechnungsgrenzen und Warnmechanismen und muss exakt die vertragliche Vereinbarung abbilden.

Ergebnis: Ein konfiguriertes Kontingent im Vertrag mit definierten Grenzen, Überbuchungstoleranz und Übertragungsregeln.

17.8.6 Vertragslaufzeit und Auto-Renewal

Was: Der Sachbearbeiter legt Vertragsbeginn, -ende, Kündigungsfrist und Verlängerungsregelung fest und definiert, ob der Vertrag sich automatisch verlängert oder ausläuft.

Warum: Die korrekte Konfiguration von Laufzeit und Verlängerung verhindert unbeabsichtigte Vertragsenden oder ungewollte Verlängerungen.

Ergebnis: Ein Vertrag mit definierten Laufzeitparametern, automatischer Verlängerung bei Nichtkündigung und Pro-Rata-Abrechnungsmöglichkeit für angebrochene Perioden.

17.8.7 Preis- und Rabattstrukturen

Was: Der Sachbearbeiter konfiguriert Staffelpreise, Mengenrabatte, Prozentrabatte und artikelspezifische Preisüberschreibungen für die Vertragspositionen.

Warum: Individuelle Preisvereinbarungen sind im B2B-Geschäft Standard. Die differenzierte Preiskonfiguration stellt sicher, dass Kunden die vereinbarten Konditionen erhalten.

Ergebnis: Vertragspositionen mit den konfigurierten Preisstrukturen, die bei der Abrechnung automatisch die korrekten Preise, Rabatte und Staffeln anwenden.

17.8.8 SLA-Level-Konfiguration (Gold/Silber/Bronze)

Was: Der Sachbearbeiter ordnet dem Vertrag ein SLA-Level zu (z.B. Gold: 1h Reaktion/4h Lösung, Silber: 4h Reaktion/24h Lösung, Bronze: 24h Reaktion/5 Tage Lösung).

Warum: Unterschiedliche Kunden zahlen für unterschiedliche Service-Niveaus. Die SLA-Zuordnung steuert die Eskalationsregeln und Priorisierung im Helpdesk.

Ergebnis: Ein Vertrag mit zugeordnetem SLA-Level, das bei der Ticket-Erstellung automatisch die entsprechenden Reaktions- und Lösungszeitfristen setzt.

17.8.9 Vertrags-Dokumentation und Versionierung

Was: Der Sachbearbeiter hängt Vertragsdokumente an, versioniert Änderungen und protokolliert jeden Zugriff auf die Vertragsdokumente.

Warum: Vertragsdokumente sind rechtsverbindlich und müssen versioniert, nachvollziehbar und vor unbefugtem Zugriff geschützt sein.

Ergebnis: Gespeicherte Vertragsdokumente mit Versionsnummer, Änderungshistorie und Zugriffs-Log.

17.8.10 Provisions-Konfiguration im Vertrag

Was: Der Sachbearbeiter konfiguriert die Provisionsregelung im Vertrag: einfache Provision, gestaffelte Provision oder keine Provision für Direktverkäufe.

Warum: Provisionsregeln müssen vertraglich festgelegt sein, damit die Vertriebsvergütung korrekt berechnet wird.

Ergebnis: Eine konfigurierte Provisionsregel im Vertrag, die bei der Abrechnung automatisch die Provisionsberechnung für den zuständigen Vertriebsmitarbeiter auslöst.

17.8.11 Budget-Tracking und Kontingent-Monitoring

Was: Der Sachbearbeiter oder Kunde verfolgt den Verbrauch des Vertragsbudgets/-kontingents über die Zeit, sieht den Plan-Ist-Vergleich und erhält Warnungen bei drohendem Kontingent-Ende.

Warum: Die transparente Verbrauchsverfolgung verhindert unerwartete Überschreitungen und ermöglicht rechtzeitige Gegenmaßnahmen (z.B. Aufstockung).

Ergebnis: Ein Verbrauchsverlauf mit Plan-Ist-Vergleich, Restbudget-Anzeige und konfigurierbaren Warn-Schwellenwerten.

17.8.12 Vertragszusammenfassung und Aktivierung

Was: Der Sachbearbeiter prüft auf der letzten Seite des Assistenten eine Gesamtübersicht des Vertrags (Adressen, Positionen, Kontingente, SLA, Preise), exportiert optional ein PDF und aktiviert den Vertrag mit einem Klick.

Warum: Die abschließende Gesamtübersicht dient als letzte Kontrollmöglichkeit vor der Aktivierung und stellt sicher, dass alle Konfigurationen korrekt sind.

Ergebnis: Ein aktivierter Vertrag mit allen konfigurierten Parametern, der ab sofort für die Abrechnung, SLA-Überwachung und Ticketzuordnung aktiv ist, optional ergänzt um eine exportierte PDF-Zusammenfassung.

18. Arbeitssicherheit & Qualitäts-Compliance

18.1 Sicherheitschecklisten

18.1.1 Sicherheitscheckliste pro Arbeitsplatz verwalten

Was: Der Sicherheitsbeauftragte erstellt und pflegt Arbeitssicherheits-Checklisten für spezifische Arbeitsplätze oder Tätigkeiten mit einzelnen Prüfpunkten, Gefahrenstufen und erforderlichen Schutzmaßnahmen.

Warum: Jeder Arbeitsplatz hat spezifische Gefahrenpotenziale. Standardisierte Checklisten stellen sicher, dass bei jeder Prüfung die gleichen Punkte kontrolliert werden und keine Gefährdung übersehen wird.

Ergebnis: Eine konfigurierte Checkliste mit Prüfpunkten, Gefahrenstufen und Schutzmaßnahmen, die für regelmäßige Durchführungen bereitsteht.

18.1.2 Sicherheitscheckliste durchführen

Was: Ein Mitarbeiter führt die regelmäßige Sicherheitsprüfung durch, bewertet jeden Prüfpunkt mit Ja/Nein/Nicht anwendbar, dokumentiert Mängel optional mit Foto und setzt Fristen für Nachbesserungen.

Warum: Die regelmäßige Durchführung ist gesetzlich vorgeschrieben und dient der Unfallverhütung. Die strukturierte Dokumentation schafft Nachweisbarkeit gegenüber Behörden.

Ergebnis: Ein ausgefülltes Prüfprotokoll mit Bewertung aller Punkte, dokumentierten Mängeln (inklusive Foto-Nachweis) und festgelegten Nachbesserungsfristen.

18.1.3 Sicherheitsmängel verfolgen

Was: Der Sicherheitsbeauftragte verfolgt alle offenen Sicherheitsmängel mit Verantwortlichem, Frist, Schweregrad und Status (Offen, In Bearbeitung, Behoben, Überfällig).

Warum: Erkannte Mängel müssen bis zur Behebung nachverfolgt werden. Überfällige Mängel erfordern eine Eskalation, um die Arbeitssicherheit nicht zu gefährden.

Ergebnis: Eine Mängelliste mit Ampelstatus, die überfällige Mängel hervorhebt und den Behebungsfortschritt aller offenen Punkte transparent macht.

18.2 Materialsicherheit

18.2.1 Gefahrstoff-Dokumentation verwalten

Was: Der Sicherheitsbeauftragte erfasst Gefahrstoffinformationen zu Artikeln: Gefahrenklasse, Sicherheitsdatenblatt, Handhabungsvorschriften und Lagerungsanforderungen.

Warum: Der Umgang mit Gefahrstoffen unterliegt strengen gesetzlichen Vorschriften (GefStoffV, REACH). Die zentrale Dokumentation stellt die Compliance sicher und schützt die Mitarbeiter.

Ergebnis: Vollständig dokumentierte Gefahrstoffinformationen pro Artikel, die bei der Lagerung, beim Versand und bei Audits als Nachweis dienen.

18.2.2 Materialsicherheit einem Artikel zuordnen

Was: Der Sachbearbeiter verknüpft Materialprüfvorschriften und Sicherheitsklassifizierungen mit Artikeln im Artikelstamm.

Warum: Die Verknüpfung stellt sicher, dass bei jedem Umgang mit dem Artikel (Lagerung, Kommissionierung, Versand) automatisch die relevanten Sicherheitshinweise angezeigt werden.

Ergebnis: Ein Artikel mit zugeordneten Sicherheitsinformationen, die bei der Lagerplatzvergabe und Kommissionierung automatisch berücksichtigt werden.

18.2.3 Materialprüfvorschriften definieren

Was: Der Qualitätsbeauftragte legt Prüfvorschriften für Materialien und Artikel fest: Prüfintervalle, Prüfmethoden, Grenzwerte und erforderliche Zertifizierungen.

Warum: Materialprüfungen stellen sicher, dass nur geprüfte und den Anforderungen entsprechende Materialien verwendet werden.

Ergebnis: Definierte Prüfvorschriften, die bei fälligen Prüfungen automatisch Erinnerungen auslösen und die Prüfergebnisse dokumentieren.

18.3 Umweltschutz

18.3.1 Umweltschutzanforderungen erfassen

Was: Der Umweltbeauftragte dokumentiert Umweltauflagen und -anforderungen pro Standort, Prozess oder Artikelgruppe (z.B. REACH, RoHS, Entsorgungsvorschriften).

Warum: Die Einhaltung von Umweltvorschriften ist gesetzlich vorgeschrieben und wird bei Audits überprüft. Die zentrale Erfassung stellt die Nachvollziehbarkeit sicher.

Ergebnis: Eine Dokumentation aller relevanten Umweltauflagen mit Zuordnung zu Standorten, Prozessen oder Artikelgruppen.

18.3.2 Umwelt-Compliance prüfen

Was: Der Umweltbeauftragte führt regelmäßige Überprüfungen der Einhaltung von Umweltschutzanforderungen durch und dokumentiert Abweichungen mit Maßnahmenplanung.

Warum: Regelmäßige Prüfungen decken Abweichungen frühzeitig auf, bevor sie zu behördlichen Sanktionen oder Umweltschäden führen.

Ergebnis: Ein Prüfbericht mit Einhaltungsstatus, dokumentierten Abweichungen und geplanten Korrekturmaßnahmen mit Fristen.

18.4 Compliance-Audits und Zertifizierungen

18.4.1 Arbeitssicherheits-Audit durchführen

Was: Der Auditor führt ein umfassendes Arbeitssicherheits-Audit über alle Arbeitsplätze durch, bewertet jeden Bereich mit einer standardisierten Skala und erstellt ein Gesamtergebnis.

Warum: Das übergreifende Audit gibt ein Gesamtbild des Arbeitssicherheitsniveaus und identifiziert systematische Schwachstellen, die über Einzelprüfungen hinausgehen.

Ergebnis: Ein vollständiger Audit-Bericht mit Gesamtbewertung, Detailergebnissen pro Arbeitsplatz und priorisierten Handlungsempfehlungen.

18.4.2 ISO-Compliance-Bericht generieren

Was: Das System erstellt einen Bericht, der die Einhaltung der Anforderungen von ISO-Normen (ISO 9001 Qualität, ISO 14001 Umwelt, ISO 45001 Arbeitssicherheit) nachweist.

Warum: Für ISO-Zertifizierungen und deren Aufrechterhaltung müssen regelmäßig Nachweise über die Einhaltung aller relevanten Prüfpunkte erbracht werden.

Ergebnis: Ein prüfungsfähiger ISO-Compliance-Bericht mit Nachweis der Einhaltung aller relevanten Normanforderungen und Kennzeichnung offener Punkte.

18.4.3 Audit-Verlauf und Verbesserungstrends

Was: Das System zeigt die Audit-Ergebnisse im Zeitverlauf an und visualisiert Verbesserungstrends, wiederkehrende Mängel und die Wirksamkeit von Korrekturmaßnahmen.

Warum: Nur durch die langfristige Betrachtung lassen sich systematische Verbesserungen erkennen und nachweisen -- eine Kernforderung aller Qualitätsmanagementsysteme.

Ergebnis: Eine zeitliche Darstellung der Audit-Ergebnisse mit Trend-Graphen, Auflistung wiederkehrender Mängel und Nachweis der Wirksamkeit eingeleiteter Maßnahmen.

19. Kundenportal / Self-Service

19.1 Kundenportal-Zugang

Was: Der Endkunde meldet sich mit seinen eigenen Zugangsdaten (Benutzername/Passwort oder Single Sign-On) am Self-Service-Portal an.

Warum: Der abgesicherte Zugang stellt sicher, dass nur berechtigte Kunden auf ihre vertraulichen Daten (Rechnungen, Verträge, Tickets) zugreifen können.

Ergebnis: Eine authentifizierte Sitzung, die dem Kunden ausschließlich seine eigenen Daten und die für seine Rolle freigegebenen Funktionen anzeigt.

19.1.2 Kunden-Dashboard

Was: Nach der Anmeldung sieht der Kunde eine personalisierte Startseite mit offenen Rechnungen, aktiven Verträgen, letzten Tickets und wichtigen Benachrichtigungen.

Warum: Der Kunde soll auf einen Blick die wichtigsten Informationen erfassen und ohne Umwege zu den relevanten Bereichen navigieren können.

Ergebnis: Ein übersichtliches Dashboard mit den wichtigsten Kennzahlen und Handlungsaufforderungen (z.B. offene Rechnungen, ungelesene Ticket-Antworten).

19.2 Beleg-Einsicht

19.2.1 Rechnungen einsehen und herunterladen

Was: Der Kunde sieht alle seine Rechnungen mit Status (Offen, Bezahlt, Überfällig) und kann jede Rechnung als PDF herunterladen.

Warum: Die Selbstbedienung bei Rechnungen reduziert Support-Anfragen ("Können Sie mir die Rechnung nochmal schicken?") und gibt dem Kunden jederzeit Zugriff auf seine Belege.

Ergebnis: Eine Rechnungsliste mit Statusanzeige und PDF-Download-Funktion, sortier- und filterbar nach Datum und Status.

19.2.2 Lieferscheine einsehen

Was: Der Kunde sieht alle Lieferscheine mit Lieferdatum, Positionen und ggf. Sendungsverfolgungsinformationen.

Warum: Der Kunde kann so eigenständig prüfen, wann welche Lieferung erfolgt ist und welche Artikel enthalten waren -- ohne den Kundendienst kontaktieren zu müssen.

Ergebnis: Eine Lieferscheinliste mit Detailansicht, Positionsaufstellung und Link zur Sendungsverfolgung.

19.2.3 Angebote einsehen

Was: Der Kunde sieht seine aktiven und abgelaufenen Angebote mit Positionen, Preisen und Gültigkeitsdauer.

Warum: Die Einsicht in Angebote ermöglicht es dem Kunden, eigenständig Angebote zu vergleichen und vor Ablauf der Gültigkeit eine Bestellung auszulösen.

Ergebnis: Eine Angebotsliste mit Gültigkeitsstatus und Positionsdetails, die bei Bedarf direkt in eine Bestellung umgewandelt werden kann.

19.2.4 Zahlungshistorie anzeigen

Was: Der Kunde sieht eine chronologische Übersicht aller Zahlungsvorgänge (Überweisungen, Lastschriften) mit Zuordnung zu den jeweiligen Rechnungen.

Warum: Die transparente Zahlungshistorie gibt dem Kunden Sicherheit über den Status seiner Zahlungen und erleichtert die Klärung bei Zahlungsdifferenzen.

Ergebnis: Eine Zahlungsübersicht mit Datum, Betrag, Zahlungsart und zugeordneter Rechnungsnummer.

19.3 Verträge und Services

19.3.1 Aktive Verträge anzeigen

Was: Der Kunde sieht alle seine laufenden Verträge mit Vertragsart, Laufzeit, Kündigungsfrist und enthaltenen Leistungen.

Warum: Die Vertragstransparenz ermöglicht es dem Kunden, seine Vertragssituation eigenständig zu überblicken und rechtzeitig vor Kündigungsfristen zu handeln.

Ergebnis: Eine Vertragsübersicht mit allen relevanten Eckdaten, die den Kunden über Laufzeiten, Kündigungsfristen und gebuchte Leistungen informiert.

19.3.2 Kontingent-Verbrauch einsehen

Was: Der Kunde sieht den aktuellen Verbrauch seiner Kontingente (Stunden, Budget, Datenvolumen) mit Restmenge und grafischem Verbrauchsverlauf.

Warum: Die Transparenz über den Kontingentverbrauch verhindert Überraschungen bei der Abrechnung und ermöglicht dem Kunden eine Steuerung seines Verbrauchs.

Ergebnis: Eine Kontingentanzeige mit aktuellem Stand, Restmenge, Verbrauchsverlauf als Grafik und Warnung bei drohender Erschöpfung.

19.3.3 SLA-Status prüfen

Was: Der Kunde sieht die aktuelle SLA-Einhaltung seiner Verträge: tatsächliche Reaktionszeiten, Verfügbarkeit und Anzahl offener Tickets im Vergleich zu den vereinbarten Zielwerten.

Warum: Der Kunde kann so eigenständig überprüfen, ob die vereinbarten Service-Level eingehalten werden, und bei Abweichungen das Gespräch mit dem Anbieter suchen.

Ergebnis: Eine SLA-Übersicht pro Vertrag mit Ist- vs. Soll-Werten für Reaktionszeit, Lösungszeit und Verfügbarkeit.

19.4 Ticket-Self-Service

19.4.1 Support-Ticket erstellen

Was: Der Kunde erstellt ein neues Support-Ticket über das Portal, beschreibt sein Problem, wählt die Priorität und fügt bei Bedarf Dateien (z.B. Screenshots) an.

Warum: Die Ticket-Erstellung über das Portal ist rund um die Uhr möglich und entlastet den telefonischen Support, während alle relevanten Informationen strukturiert erfasst werden.

Ergebnis: Ein neues Support-Ticket, das im Helpdesk-System des Anbieters erscheint und dem Kunden eine Bestätigung mit Ticketnummer anzeigt.

19.4.2 Eigene Tickets einsehen und kommentieren

Was: Der Kunde sieht alle seine Tickets mit Status und Bearbeitungsfortschritt und kann Kommentare oder zusätzliche Dateien ergänzen.

Warum: Die Transparenz über den Bearbeitungsstand reduziert Rückfragen und ermöglicht es dem Kunden, ergänzende Informationen beizusteuern.

Ergebnis: Eine Ticket-Übersicht mit Detailansicht, Kommentarfunktion und Dateianhang-Möglichkeit, die eine bidirektionale Kommunikation mit dem Support-Team ermöglicht.

19.4.3 Ticket-Status verfolgen

Was: Der Kunde verfolgt den Bearbeitungsstatus seines Tickets (Offen, In Bearbeitung, Warten auf Kunde, Gelöst, Geschlossen) und wird bei Statusänderungen benachrichtigt.

Warum: Die Statusverfolgung gibt dem Kunden Sicherheit, dass sein Anliegen bearbeitet wird, und informiert ihn über erforderliche eigene Aktionen (z.B. Rückmeldung bei "Warten auf Kunde").

Ergebnis: Eine Statusanzeige mit Verlaufshistorie und automatischen Benachrichtigungen per E-Mail bei Statuswechseln.

19.5 Kontakt und Stammdaten

19.5.1 Eigene Kontaktinformationen einsehen

Was: Der Kunde sieht die im System hinterlegten Firmendaten, Adressen und Ansprechpartner, um deren Aktualität zu prüfen.

Warum: Veraltete Stammdaten führen zu Zustellproblemen bei Lieferungen und Rechnungen. Der Kunde soll seine hinterlegten Daten jederzeit prüfen können.

Ergebnis: Eine Anzeige aller gespeicherten Kontaktdaten des Kunden mit Adresse, Ansprechpartnern und Kommunikationsdaten.

19.5.2 Kontaktdaten-Änderung anfordern

Was: Der Kunde stellt eine Änderungsanforderung für seine Stammdaten (Adresse, Ansprechpartner, E-Mail), die vom zuständigen Kundenbetreuer geprüft und freigegeben wird.

Warum: Stammdatenänderungen können steuer- und vertragsrelevant sein (z.B. Adressänderung, neuer Rechnungsempfänger) und erfordern daher eine Verifizierung vor der Übernahme.

Ergebnis: Eine eingereichte Änderungsanforderung, die nach Freigabe durch den Kundenbetreuer automatisch in die Stammdaten übernommen wird, mit Dokumentation der Änderungshistorie.

442 KiB Raw Blame History Unescape Escape

c-entron.NET – Strukturierte Use-Case-Beschreibungen

Inhaltsverzeichnis

1. Abrechnung (Billing)

1.1 Vertragsabrechnung

1.1.1 Verträge nach Datum filtern