Files
Masterarbeit/Ergebnisse/Ergebnisse 03/USE_CASES_NEW.md

35 KiB
Raw Blame History

c-entron.NET - Neue Modul-Use-Cases: Asset Management & Scheduling

Generiert: 2025-11-11 Version: 2025 1.0.0.0 Zweck: Dokumentation der neu entdeckten Use Cases für Asset Management und Scheduling Module Quellen: SSMS_DB_SCHEMA.sql, Code-Analyse, REST API Endpoints


Inhaltsverzeichnis

  1. Asset Management (IT-Verwaltung)

  2. Terminverwaltung & Planung (Scheduling)


16. Asset Management (IT-Verwaltung)

Category: IT-Asset Management Primary Module: MSP/Managed Services Database Tables: 35+ (AssetManagement*, AccountDevices*, AccountDevicesToTickets*) REST API Endpoints: 6 Endpunkte Status: Komplett neue Funktionalität

16.1 Geräte-Inventarverwaltung (Device Inventory Management)

Modultyp: Asset Management System Datenbanktabellen: AssetManagementDevices, AssetManagementApplication, AssetManagementWindowsSystems, AssetManagementWindowsServices, AccountDevices, AccountDevicesToTickets REST API: /GetAssetInventory, /UpdateAssetDevice, /GetDeviceDetails Category: Asset Management (IT-Verwaltung) License: LicenseGuids.AssetManagement OR LicenseGuids.Centron Rights: UserRightsConst.Administration.ASSET_MANAGEMENT, UserRightsConst.Administration.ASSET_VIEW

Modul-Architektur

Dieses Modul verwaltet die komplette IT-Infrastruktur und Hardware-Bestände eines Unternehmens:

  1. Geräte-Erfassung

    • Hardware-Informationen automatisch erfassen
    • Manuelle Ergänzung möglich
    • Seriennummern und Asset-Tags
  2. Geräte-Kategorisierung

    • Desktop/Laptop/Server
    • Betriebssystem-Klassifizierung
    • Hersteller und Modell
  3. Verlinkung zu Tickets

    • Geräte-zu-Ticket Zuordnung
    • Service-Historie pro Gerät
    • Zuweisen von Tickets zu Assets
  4. Bestandsverwaltung

    • Inventar-Listen
    • Abteilungs-Zuordnung
    • Depreciation-Tracking

Vollständige Use Cases

1. Geräteverwaltung und -erfassung

1.1 Neue IT-Geräte erfassen

Purpose: Erfassen von neuen Hardware-Geräten im System Tables: AssetManagementDevices, AccountDevices Properties: DeviceName, DeviceType, Manufacturer, ModelNumber, SerialNumber Workflow:

  • Gerät identifizieren (Typ: Desktop, Laptop, Server, Drucker, etc.)
  • Hardware-Informationen eingeben
  • Asset-Tag zuweisen
  • Abteilung/Standort zuordnen
  • Status: "Aktiv" setzen

Use Case: Techniker erfasst neuen Kundencomputer nach Kauf

1.2 Geräte-Details anzeigen und bearbeiten

Purpose: Anzeige und Aktualisierung von Geräteinformationen Properties: Hostname, IP-Adresse, MAC-Adresse, RAM, Festplatte, CPU, Betriebssystem Method: GetDeviceDetails(int deviceI3D) Returns: Vollständige Geräteinformationen mit Historie

Use Case: Support-Agent überprüft Spezifikationen vor Remote-Support

1.3 Geräte-Bestände nach Abteilung verwalten

Purpose: Bestandsverwaltung pro Abteilung Filter: DepartmentI3D, LocationI3D, StatusKind Reporting: Geräte-Liste pro Abteilung Method: GetInventoryByDepartment(int departmentI3D)

Use Case: IT-Manager sieht welche Geräte in Vertrieb vorhanden sind

1.4 Geräte-Lebenszyklusmanagement

Purpose: Tracking von Anschaffung über Verschrottung Stages:

  • Beschaffung: Bestellung und Empfang
  • Aktiv: Im Einsatz
  • Wartung: Reparatur läuft
  • Ruhestand: Außer Betrieb
  • Entsorgung: Geschreddert/Weitergabe

Properties: AcquisitionDate, DeactivationDate, DepreciationMonths Method: UpdateDeviceLifecycle(int deviceI3D, LifecycleStage newStage)

Use Case: Buchhaltung ermittelt Restwert für Abschreibung

1.5 Batch-Import von Geräteinventaren

Purpose: Massenimport aus CMDB oder Scanner-Tools API: POST /ImportAssetInventory Format: CSV mit MAC-Adresse, Hostname, Typ, Abteilung Validation: Duplikat-Erkennung, Format-Überprüfung

Use Case: Import von 500 Computern nach Netzwerk-Scan


2. Geräte-Zuordnung und Tracking

2.1 Geräte zu Helpdesk-Tickets verknüpfen

Purpose: Zuordnung eines Geräts zu einem Support-Ticket Table: AccountDevicesToTickets Properties: DeviceI3D, TicketI3D, DateAssigned, ReasonCode Method: LinkDeviceToTicket(int deviceI3D, int ticketI3D)

Use Case: Techniker notiert: "Ticket #12345 betrifft Laptop von Hans Müller"

2.2 Service-Historie pro Gerät anzeigen

Purpose: Komplette Wartungs- und Service-Geschichte eines Geräts Query: Alle Tickets, die dieses Gerät betreffen (Zeitabfallen, offene Issues, geschlossene Fälle) Properties: TicketI3D, Datum, Beschreibung, Techniker, Lösung Report: Chronologische Liste

Use Case: Kundenberater sieht dass Laptop schon 5x zum gleichen Problem repariert wurde

2.3 Geräte-Zuordnung zu Benutzern

Purpose: Verfolgung welcher Benutzer welches Gerät nutzt Table: AccountDevices (mit Benutzer-Zuordnung) Properties: UserI3D, EmployeeI3D, DeviceI3D, AssignmentDate Method: AssignDeviceToUser(int deviceI3D, int userI3D)

Use Case: IT-Abteilung sieht dass Laptop vom Buchhalter verwendet wird

2.4 Geräte-Abhängigkeiten verwalten

Purpose: Definition von Abhängigkeiten zwischen Geräten Table: AssetManagementDeviceDependencies Types:

  • Server → Drucker (druckt darauf)
  • Workstation → Server (verbunden mit)
  • Switch → Geräte (verwaltet)

Method: CreateDeviceDependency(int parentDeviceI3D, int childDeviceI3D, DependencyKind kind)

Use Case: "Wenn Server down ist, müssen alle 15 verbundenen Workstations auch gewarnt werden"


3. System-Informationen und Monitoring

3.1 Betriebssystem und installierte Software erfassen

Purpose: Automatisches Erfassen von OS und Applikationen Table: AssetManagementWindowsSystems, AssetManagementApplication, AssetManagementWindowsServices Data:

  • Betriebssystem (Windows 10, Windows Server 2019, etc.)
  • Service Pack Level
  • Installierte Anwendungen (Office, Adobe, Antivirus, etc.)
  • Laufende Services

Method: ScanDeviceForApplications(int deviceI3D) Integration: ServiceConnector-Logs für Scan-Ergebnisse

Use Case: Automatischer Scan zeigt dass 50 Geräte veraltete Office-Version haben

3.2 Hardware-Spezifikationen verwalten

Purpose: CPU, RAM, Storage, Netzwerk-Interface Details Properties:

  • Prozessor (CPU Name, Cores, Speed)
  • RAM (Anzahl GB, Typ DDR3/DDR4)
  • Storage (HDD/SSD, Größe, Partitionen)
  • Netzwerk (MAC-Adressen, IP-Adressen, Interfaces)

Table: AssetManagementWindowsSystems

Use Case: Support prüft ob Gerät für neue Software-Version geeignet ist

3.3 Gerät-Abhängigkeitsanalyse

Purpose: Erkennung kritischer Abhängigkeiten für Disaster Recovery Table: AssetManagementDeviceDependencies Calculation: Welche anderen Geräte fallen aus wenn dieses Gerät ausfällt?

Method: GetDeviceDependencies(int deviceI3D) → Returns abhängige Geräte Report: Kritikalitäts-Matrix

Use Case: "Mail-Server fällt aus → 800 Benutzer betroffen. Priorität: KRITISCH"


16.2 Patch- und Update-Management (Patch Management)

Modultyp: Software-Patch und Security-Update Verwaltung Datenbanktabellen: AssetManagementPatch, AssetManagementCheckResults, AssetManagementServiceConnectorLogs REST API: /GetPendingPatches, /ApplyPatchUpdate, /GetPatchStatus

Vollständige Use Cases

1. Patch-Verwaltung

1.1 Ausstehende Patches ermitteln

Purpose: Anzeige aller Security- und Bug-Fix Patches Table: AssetManagementPatch Filter: DeviceI3D, PatchKind (Security, Critical, Standard) Status: Pending, Approved, Deployed, Rolled Back Method: GetPendingPatches(int deviceI3D, FilterKind kind)

Use Case: IT-Manager sieht 200 fehlende Windows-Updates

1.2 Patch-Bereitstellung planen

Purpose: Zeitliche Planung von Patch-Installation Properties: ScheduledDate, MaintenanceWindow, RollbackPlan Validation:

  • Backup vor Patch?
  • Abhängigkeiten OK?
  • Services müssen stoppen?

Method: SchedulePatchDeployment(int patchI3D, DateTime deploymentDate)

Use Case: Patch für Critical-Bug wird für Sonntag 22:00-00:00 geplant

1.3 Patch-Deployment-Kampagne

Purpose: Koordiniertes Ausrollen auf mehrere Geräte Scope:

  • Alle Server: Phase 1 (Samstag Nacht)
  • Alle Workstations: Phase 2 (Sonntag Nacht)
  • Externe VPN-Clients: Phase 3 (Montag)

Method: CreatePatchCampaign(List<int> deviceI3Ds, int patchI3D, CampaignStrategy strategy)

Use Case: Deployment von Windows-Sicherheitsupdate auf 500 Computern in 3 Phasen

1.4 Patch-Kompatibilität überprüfen

Purpose: Vor Deployment testen ob Patch mit andere Software kompatibel Method: CheckPatchCompatibility(int deviceI3D, int patchI3D) Validation: Abhängigkeiten, Versionskonflikt, Lizenz-Checks

Use Case: Patch könnte Treiber beschädigen → Warnmeldung für Admin

1.5 Patch-Rollback durchführen

Purpose: Zurückfahren bei fehlgeschlagenem Patch Method: RollbackPatch(int deviceI3D, int patchI3D) Requirement: Backup muss existieren (Pre-Patch State) Logging: Vollständige Rollback-Historie

Use Case: Patch beschädigt Netzwerk-Treiber → Rollback in 5 Minuten zurück zu vorherigem State


16.3 SNMP-Netzwerk-Überwachung (SNMP Monitoring)

Modultyp: Netzwerk-Device Überwachung via SNMP Datenbanktabellen: AssetManagementSnmpMibDetails, AssetManagementSnmpMibChecks, AssetManagementCheckResults REST API: /GetSnmpMetrics, /ConfigureSnmpDevice, /GetNetworkHealth

Vollständige Use Cases

1. SNMP-Geräte-Konfiguration

1.1 SNMP-fähige Netzwerk-Geräte erfassen

Purpose: Erfassung von Switches, Router, Drucker mit SNMP Protocol: SNMP v2/v3 Community: Read-Only String Configuration Table: AssetManagementSnmpMibChecks

Method: RegisterSnmpDevice(string ipAddress, string community, SnmpVersion version)

Use Case: Erfassung eines neuen Cisco-Switch in HQ für Netzwerk-Monitoring

1.2 SNMP-Monitoring konfigurieren

Purpose: Auswahl welche Metriken überwacht werden sollen Available Metrics:

  • CPU-Auslastung
  • Speichernutzung
  • Port-Status
  • Fehlerrate
  • Uptime

Method: ConfigureSnmpMonitoring(int deviceI3D, List<SnmpOidKind> metricsToMonitor)

Use Case: Admin konfiguriert CPU-Warnung bei >90% auf Switch

1.3 Schwellenwerte definieren

Purpose: Alert-Auslösung bei bestimmten Metriken-Werten Properties: ThresholdValue, AlertKind (Warning/Critical), ActionCode Actions: Email, SMS, automatischer Reboot, Service-Neustart

Method: SetSnmpThreshold(int deviceI3D, SnmpOidKind metric, int warningLevel, int criticalLevel)

Use Case: "Warnung wenn RAM > 80%, kritisch wenn > 95%"


2. Netzwerk-Überwachung und Reporting

2.1 Real-Time Netzwerk-Health Dashboard

Purpose: Live-Anzeige des Netzwerk-Status Metrics Displayed:

  • Alle Geräte Status (Online/Offline/Warning)
  • CPU/RAM/Disk pro Gerät
  • Fehlerrate
  • Top talkers (Datenflusss)

Method: GetNetworkHealthStatus() Update Frequency: Alle 5 Minuten

Use Case: IT-Leiter sieht auf Monitor dass Router Nord überlastet ist

2.2 Netzwerk-Performance-Berichte

Purpose: Historische Analyse der Netzwerk-Metriken Report Types:

  • Durchschnittliche Auslastung pro Gerät (täglich/wöchentlich/monatlich)
  • Spitzenlast-Zeiten
  • Trend-Analyse (wachsende Last?)
  • Fehler-Statistik

Table: AssetManagementCheckResults Method: GenerateNetworkPerformanceReport(DateTime startDate, DateTime endDate, ReportGranularity granularity)

Use Case: Report zeigt dass Bandbreite kontinuierlich um 20% pro Monat wächst → Upgrade planen

2.3 Netzwerk-Anomalie-Erkennung

Purpose: Automatische Warnung bei ungewöhnlichem Verhalten Examples:

  • Plötzliche CPU-Spike auf normalerweise leise Gerät
  • Port wird plötzlich sehr aktiv (Malware?)
  • Gerät antwortet nicht mehr (Hardware-Fehler?)

Method: DetectNetworkAnomalies() Alert: Automatische Benachrichtigung an Admin

Use Case: Anomalie erkannt: "Server antwortet nicht auf SNMP → möglicher Stromausfall oder Crash"


16.4 Software-Lizenz-Verwaltung (Software License Management)

Modultyp: Lizenz-Compliance und -Tracking Datenbanktabellen: AssetManagementApplication, AccountDevices, ApplicationVersions REST API: /GetLicenseInventory, /CheckLicenseCompliance, /GetUnlicensedSoftware

Vollständige Use Cases

1. Lizenz-Tracking

1.1 Installierte Software-Lizenzen erfassen

Purpose: Kataloging aller bezahlten Software Properties:

  • Produkt-Name
  • Version
  • Lizenz-Typ (Home, Pro, Enterprise)
  • Kaufdatum
  • Ablauf-Datum
  • Lizenz-Schlüssel
  • Lizenzierte Anzahl (Seats)

Table: AssetManagementApplication Method: RegisterSoftwareLicense(string productName, LicenseDetails details)

Use Case: Adobe Creative Cloud Lizenz für 10 Designer registrieren

1.2 Installationen pro Lizenz verfolgen

Purpose: Überblick wie viele Installationen pro Lizenz vorhanden sind Calculation:

  • Adobe CC: 10 Lizenzen gekauft
  • 15 Geräte haben Adobe installiert
  • Ergebnis: 5 Geräte ohne Lizenz (Compliance-Problem)

Method: GetSoftwareInstallationCount(string productName) → Returns: Lizenziert vs. Installiert

Use Case: "Office 365: 50 Lizenzen, 48 installiert → OK. Aber 3 weitere User brauchen Office → 53 benötigt"

1.3 Lizenz-Compliance-Bericht

Purpose: Audit-ready Compliance-Report für Finance/Legal Report Details:

  • Software mit abgelaufenen Lizenzen
  • Software über-lizenziert (zu viele Installationen)
  • Vermisste Lizenzen (Software installiert aber keine Lizenz registriert)
  • Günstige Wechsel (Konkurrenzprodukte mit besseren Lizenzbedingungen)

Method: GenerateLicenseComplianceReport() Output: PDF, Excel

Use Case: Auditor erhält Report für externe Compliance-Prüfung (GITC, SOX)

1.4 Lizenz-Ablauf-Warnungen

Purpose: Proaktive Benachrichtigung vor Lizenz-Ablauf Trigger: 90 Tage, 60 Tage, 30 Tage, 7 Tage vor Ablauf Action: Automatische Email an Procurement Properties: ProductName, ExpirationDate, DaysRemaining

Use Case: Automatische Benachrichtigung: "Antivirus-Lizenz läuft in 30 Tagen ab"

1.5 Lizenz-Optimierungsempfehlungen

Purpose: Cost-Reduction durch bessere Lizenzierung Analysis:

  • Welche Software ist installiert aber wird nicht genutzt?
  • Kann teurere Pro-Lizenz durch Home-Lizenz ersetzt werden?
  • Bulk-Kaufrabatt möglich?

Method: GenerateLicenseOptimizationRecommendations()

Use Case: System findet dass WinRAR auf 30 Geräten installiert aber nur 2x pro Tag verwendet wird → Deinstallation empfohlen


16.5 Compliance und Asset-Depreciierung (Compliance and Depreciation)

Modultyp: Finanzielle Compliance und Abschreibung Datenbanktabellen: AssetManagementDevices, AccountDevices, ApplicationVersions REST API: /GetDepreciationSchedule, /GetComplianceStatus, /GenerateAuditReport

Vollständige Use Cases

1. Asset-Depreciation für Buchhaltung

1.1 Abschreibungsplan erstellen

Purpose: Berechnung der Wertminderung für Bilanzierung Method: CalculateDepreciation(int deviceI3D) Formula:

  • Anschaffungswert: €1000
  • Nutzungsdauer: 36 Monate
  • Abschreibung pro Monat: €27.78

Properties: AcquisitionCost, UsefulLifeMonths, ResidualValue, DepreciationMethod (Linear/Accelerated)

Use Case: IT-Manager erstellt Abschreibungsplan für 100 neue Laptops

1.2 Restwert für Disposal ermitteln

Purpose: Bestimmung des Verkaufswertes beim Ausmustern Calculation:

  • Laptop gekauft vor 3 Jahren für €1500
  • Nach 3 Jahren (vollständige Abschreibung): Restwert € 100
  • Verkäufer (refurbished): €120 möglich

Method: CalculateResidualValue(int deviceI3D)

Use Case: Disposition plant Verkauf von 50 alten Computern mit erwarteter Erlös

1.3 Compliance-Audit für IT-Bestände

Purpose: Überprüfung ob Bestände in Buchhaltung mit physischem Inventar übereinstimmen Validation:

  • Alle erfassten Geräte noch im System?
  • Alle Geräte noch Aktiv/im Einsatz?
  • Physisches Audit vs. Datenbank abgleichen

Method: PerformInventoryAudit() Output: Audit-Bericht mit Abweichungen

Use Case: Jahresend-Audit zeigt dass 3 Laptops in Datenbank aber nicht physisch vorhanden sind

1.4 Asset-Tag und Barcode-Verwaltung

Purpose: Physische Identifizierung und Tracking Properties:

  • Asset-Tag-Nummer (eindeutig pro Gerät)
  • Barcode (für Scanner-Inventur)
  • QR-Code (für schnelle Erfassung)
  • Etikett auf Gerät anbringen

Method: GenerateAssetTag(int deviceI3D) → Returns Barcode/QR-Code

Use Case: IT-Abteilung druckt Asset-Tags und klebt auf 500 neuen Geräten

1.5 Compliance-Report für Sicherheit und Datenschutz

Purpose: Dokumentation für DSGVO, ISO27001, SOX Reports:

  • Inventar aller Geräte (Standort, Benutzer, Daten-Klassifizierung)
  • Encryption-Status (verschlüsselt/nicht verschlüsselt)
  • Backup-Status
  • Antivirus/Firewall-Status
  • Einhaltung von Sicherheitsrichtlinien

Method: GenerateComplianceAuditReport(ComplianceStandard standard)

Use Case: DSGVO-Audit: "Wo werden Kundendaten gespeichert? Sind die Geräte verschlüsselt?"



17. Terminverwaltung & Planung (Scheduling)

Category: Terminverwaltung Primary Module: Helpdesk/Service Database Tables: 8+ (AppointmentProposals, AppointmentRequests, AnfahrtZonen, ToDoListe) REST API Endpoints: 5 Endpunkte Status: Komplett neue Funktionalität

17.1 Termine und Buchungen (Appointments and Bookings)

Modultyp: Terminplanungs- und Buchungs-System Datenbanktabellen: AppointmentProposals, AppointmentRequests, ToDoListe REST API: /GetAvailableAppointments, /BookAppointment, /GetAppointmentSlots Category: Terminverwaltung License: LicenseGuids.Helpdesk OR LicenseGuids.Centron Rights: UserRightsConst.Helpdesk.MANAGE_APPOINTMENTS, UserRightsConst.Helpdesk.VIEW_SCHEDULE

Modul-Architektur

Dieses Modul verwaltet Termine für Support-Besuche, Wartungen und Besprechungen:

  1. Termein-Anfragen

    • Kunde fordert Termin an
    • System schlägt freie Slots vor
    • Kunde bucht einen Termin
  2. Verfügbarkeits-Verwaltung

    • Techniker-Kalender
    • Urlaub/Krankheit
    • Arbeitszeit-Fenster
  3. Route-Optimierung

    • Mehrere Besuche an einem Tag
    • Fahrtzeit-Berechnung
    • Zone-basierte Planung
  4. Bestätigung und Benachrichtigungen

    • SMS/Email an Techniker
    • Erinnerung an Kunde
    • Rescheduling-Handling

Vollständige Use Cases

1. Terminanfrage und Slot-Vorschlag

1.1 Kunde fordert Termin an

Purpose: Eröffnung einer Terminanfrage Table: AppointmentRequests Properties:

  • CustomerI3D, TicketI3D
  • RequestedDateRange (Wunsch-Wochenbereich)
  • ServiceType (Installation, Maintenance, Repair)
  • EstimatedDuration (Dauer in Stunden)
  • LocationAddress (wo soll der Termin stattfinden?)

Method: RequestAppointment(int ticketI3D, AppointmentRequest request) Returns: AppointmentRequestI3D (für Tracking)

Use Case: Kunde ruft an: "Ich brauche einen Techniker zur Netzwerk-Installation, am liebsten Mittwoch oder Donnerstag"

1.2 System schlägt verfügbare Slots vor

Purpose: Automatische Slot-Vorschläge basierend auf Techniker-Verfügbarkeit Method: GetAvailableAppointmentSlots(int ticketI3D, DateRange preferredRange) Calculation:

  • Suche Techniker mit passenden Qualifikationen
  • Checke deren Kalender auf freie Slots
  • Berücksichtige Fahrtzeit zwischen Terminen
  • Sortiere nach Kundenzonenpräferenz

Table: AppointmentProposals Returns: Liste mit vorgeschlagenen Slots (z.B. 4-5 Vorschläge)

Proposal Example:

1. Mittwoch, 10:00-11:30 (Techniker: Hans M., Fahrtzeit: 15 Min)
2. Mittwoch, 14:00-15:30 (Techniker: Max B., Fahrtzeit: 25 Min)
3. Donnerstag, 09:00-10:30 (Techniker: Anna K., Fahrtzeit: 10 Min)
4. Donnerstag, 15:00-16:30 (Techniker: Hans M., Fahrtzeit: 20 Min)

Use Case: System findet 4 passende Slots für Montage

1.3 Kunde wählt Termin-Slot

Purpose: Bestätigung eines Slot-Vorschlags Method: BookAppointment(int appointmentProposalI3D) Action:

  • Speichere in ToDoListe als Aufgabe für Techniker
  • Sende Bestätigung an Kunde (Email/SMS)
  • Sende Terminerinnerung an Techniker

Use Case: Kunde bestätigt: "Donnerstag 09:00 bei Anna" → Appointment wird gebucht

1.4 Terminbestätigung an Kunde

Purpose: Schriftliche Bestätigung mit allen Details Content:

  • Termin-Datum und -Uhrzeit
  • Techniker-Name
  • Adresse/Standort
  • Handynummer des Technikers
  • Vorbereitung-Hinweise

Method: SendAppointmentConfirmation(int appointmentI3D, CommunicationChannel channel) Channels: Email, SMS, Both

Use Case: Kunde erhält Email: "Montag 10:00-11:00 besucht Sie Hans zum Netzwerk-Setup"

1.5 Termine verschieben/absagen

Purpose: Flexibles Handling von Änderungen Scenarios:

  • Kunde: "Passt nicht mehr, können wir einen anderen Tag machen?"
  • Techniker: "Bin krank, kann Montag-Termin nicht schaffen"
  • System: Automatische Eskalation wenn Termin nicht 24h vorher bestätigt

Method: RescheduleAppointment(int appointmentI3D, int newProposalI3D) OR CancelAppointment(int appointmentI3D, string reason)

Notifications: Alle beteiligten werden benachrichtigt

Use Case: Techniker wird krank → System schlägt Ersatz-Termin mit anderem Techniker vor


2. Techniker-Verfügbarkeit und Kapazität

2.1 Techniker-Arbeitskalender verwalten

Purpose: Verfügbarkeit pro Techniker Table: ToDoListe (oder Kalender-Modul) Properties:

  • EmployeeI3D
  • WorkingHours (z.B. Mo-Fr 08:00-17:00)
  • Vacation (Urlaubs-Tage)
  • SickLeave (Krankheitstage)
  • SpecialOffDays (extra freie Tage)

Method: SetEmployeeWorkingHours(int employeeI3D, WorkSchedule schedule)

Use Case: Anna hat Urlaub 15.-21. Juli → wird nicht für Termine vorgeschlagen

2.2 Techniker-Qualifikationen und Spezialisierung

Purpose: Nur qualifizierte Techniker für bestimmte Aufgaben Properties:

  • RequiredSkills (z.B. "Linux", "Netzwerk", "Datenbank")
  • Techniker.SkillList (Qualifikationen)
  • Match: Haben alle geforderten Skills?

Method: FilterTechniciansBySkills(List<string> requiredSkills)

Use Case: "Netzwerk-Installation braucht Netzwerk-Experte" → System schlägt nur Network-Techniker vor

2.3 Maximale Tagesauslastung begrenzen

Purpose: Techniker übernehmen nicht zu viele Termine Rule: Z.B. maximal 4 Termine pro Tag, maximal 8 Std Fahrtzeit Method: CheckDailyCapacity(int employeeI3D, DateTime date) → Returns verfügbare Slots

Use Case: Hans hat schon 4 Termine Montag, nächster Slot erst Dienstag frei

2.4 Überstunden-Tracking

Purpose: Vermeidung von Überbelastung Tracking:

  • Geplante Stunden vs. Tatsächliche Stunden
  • Überstunden-Stunden
  • Flexzeit-Ausgleich

Method: GetEmployeeUtilization(int employeeI3D, DateTime startDate, DateTime endDate) Report: "Hans: 40 Std geplant, 45 Std tatsächlich, 5 Std Überstunden"

Use Case: Manager sieht dass Anna seit 3 Wochen Überstunden macht → weitere Termine für sie absagen


17.2 Techniker-Routenoptimierung (Technician Route Optimization)

Modultyp: Geografische Optimierung von Techniker-Routen Datenbanktabellen: AnfahrtZonen, AppointmentProposals, ToDoListe REST API: /OptimizeRoute, /GetTravelTime, /GetZoneAssignment

Vollständige Use Cases

1. Zone-basierte Terminvergabe

1.1 Fahrt-Zonen definieren

Purpose: Geografische Einteilung für Effizienz Table: AnfahrtZonen Zones:

  • Zone "München-Mitte"
  • Zone "München-Nord"
  • Zone "München-Süd"
  • Zone "Umland"

Properties: ZoneName, Coordinates (Grenzen), PrimaryTechnician, BackupTechnician Method: DefineZone(ZoneDetails zone)

Use Case: "Alle Kundenaufträge in PLZ 80-82 → Zone Nord → Hans zuweisen"

1.2 Kunde-Standort zu Zone zuordnen

Purpose: Automatische Zone-Bestimmung basierend auf Adresse Method: AssignCustomerToZone(int customerI3D, string address) Logic: Postleitzahl/Geocoding → Zone bestimmen

Use Case: Neuer Kunde München Schwabing → automatisch Zone Nord

1.3 Route-Vorschlag pro Techniker/Tag

Purpose: Optimierte Reihenfolge der Besuche Calculation:

  • Alle Termine für Hans am Montag: Kundenort A, B, C, D
  • Route-Engine: Welche Reihenfolge minimiert Fahrtzeit?
  • Optimale Route: Start HQ → A → C → B → D → HQ (Fahrtzeit 3h vs. 4.5h bei anderer Reihenfolge)

Method: OptimizeRoute(int employeeI3D, DateTime date) → Returns: Optimierte Reihenfolge mit Fahrtzeiten

Output:

Montag für Hans:
09:00-10:30  Kunde A (München Zentrum)
10:45-11:30  Kunde C (München Nord, 15 Min Fahrt)
12:00-13:00  Mittagspause
13:00-14:15  Kunde B (München Süd, 30 Min Fahrt)
14:30-15:30  Kunde D (Umland, 15 Min Fahrt)

Use Case: Manager optimiert Montag-Route → 45 Min Fahrtzeit gespart, mehr Kunden pro Tag möglich

1.4 Fahrtzeit-Berechnung zwischen Punkten

Purpose: Realistische Reisezeit zwischen Kundenorten Method: CalculateTravelTime(string addressA, string addressB) Data Source: Google Maps API Integration Returns: Fahrtzeit (normale Verkehrslage), Fahrtzeit (Spitzenlast), Entfernung

Use Case: "Von Kunde A zu Kunde B: 25 Min normal, 45 Min in Stoßzeit"

1.5 Puffer und Flexibilität einplanen

Purpose: Nicht alle Zeiten fest planen, Puffer für Überläufer Buffer:

  • 15 Min Puffer pro Besuch (Parken, Warten auf Kunde)
  • 30 Min Emergency-Slot für dringende Reparaturen
  • Mittagspause

Method: AddScheduleBuffer(int employeeI3D, DateTime date, int bufferMinutes)

Use Case: Hans hat nach jedem Termin 15 Min Puffer → kann schnelle Wartung oder Dokumentation machen


2. Tourenmanagement und Deklaration

2.1 Tages-Tournee zusammenstellen

Purpose: Gruppierung von Terminen zu einer Tour Properties:

  • ToursI3D, EmployeeI3D, TourDate
  • StartTime, EndTime
  • EstimatedMileage, ActualMileage
  • Stops (Liste der Kundenbesuche)

Method: CreateTour(int employeeI3D, DateTime tourDate, List<int> appointmentI3Ds)

Use Case: "Erstelle Montag-Tour für Hans mit 5 Kundenbesuchen"

2.2 Fahrt-Kosten berechnen

Purpose: Kilometerabrechnung und Fahrtkosten Calculation:

  • Geplante Kilometer: 120 km
  • Sätze: €0.30/km (Benzin) + €0.20/km (Verschleiß) = €0.50/km
  • Kosten: 120 km × €0.50 = €60

Method: CalculateTravelCosts(int tourI3D, decimal ratePerKm)

Use Case: Abrechnung der Fahrt-Kosten für Lohn/Auslagen

2.3 Tages-Zusammenfassung für Techniker

Purpose: Übersicht was Techniker heute machen soll Output: Bedruckter Zettel oder Mobile-App

Montag 10. Juli - Tour für Hans M.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
09:00-10:30  Müller GmbH, Seestr. 15, Tel. 089-123456
             Task: Netzwerk-Installation, Material: Switch x2

10:45-11:30  Schmidt KG, Hauptstr. 42
             Task: Drucker-Setup

13:00-14:15  Reisebüro am Markt, Marienplatz 5
             Task: Backup-Test

14:30-15:30  Bauunternehmen XY, Gewerbepark Nord 10
             Task: Firewall-Update

Geschätzte Fahrtzeit: 2h 30 Min, 85 km

Use Case: Techniker hat klare Übersicht für seinen Tag


17.3 Ressourcen-Kapazitätsplanung (Resource Capacity Planning)

Modultyp: Mittelfristige Planung von Personaleinsatz Datenbanktabellen: AppointmentProposals, ToDoListe, Personal REST API: /GetCapacityForecast, /PredictResourceNeeds

Vollständige Use Cases

1. Kapazitäts-Prognose und Planung

1.1 Nachfrage-Prognose erstellen

Purpose: Vorhersage künftiger Termine Calculation:

  • Durchschnittliche Anfragen pro Woche: 50
  • Durchschnittliche Dauer pro Termin: 3 Stunden
  • Total benötigte Stunden: 150 Std/Woche
  • Verfügbar (5 Techniker × 40 Std): 200 Std
  • Kapazitätsauslastung: 75%

Method: ForecastDemand(DateRange forecastPeriod) → Returns: Prognostizierte Termine

Use Case: Manager plant für August: "Erwartet 20% mehr Anfragen wegen Umzugsperiode"

1.2 Personalbedarfs-Analyse

Purpose: Wieviele Techniker werden benötigt? Scenario:

  • Nachfrage: 200 Anfragen/Monat (50h)
  • Pro Techniker: 160 Stunden/Monat möglich (40h × 4 Wochen)
  • Benötigte Vollzeitäquivalente: 312/160 = 2 FTE nötig
  • Aktuell vorhanden: 1.8 FTE
  • Defizit: 0.2 FTE = 1 Tag/Woche externe Unterstützung nötig

Method: AnalyzeResourceNeeds(DateRange period) → Returns: FTE-Bedarf und Defizite

Use Case: "Wir brauchen 1 zusätzliche Teilzeitkraft für August-September"

1.3 Verfügbarkeits-Analyse

Purpose: Wann sind Engpässe? Analysis:

  • Woche 1: 70% Auslastung (OK)
  • Woche 2: 105% Auslastung (PROBLEM - keine Kapazität!)
  • Woche 3: 80% Auslastung (OK)
  • Woche 4: 90% Auslastung (gut)

Method: AnalyzeCapacityBottlenecks(DateRange period) → Returns: Engpass-Wochen mit Empfehlungen

Recommendations:

  • Freie Termine bündeln auf Woche 1 & 3
  • Woche 2 externe Ressourcen anfordern
  • Oder Wartungs-Termine auf ruhigere Wochen verschieben

Use Case: Manager plant Urlaub-Rotation um Engpässe zu vermeiden


17.4 Service Level Agreements (SLA Management)

Modultyp: SLA-Definition, -Tracking und -Reporting Datenbanktabellen: AppointmentProposals, hlpdsk_requests, CacheTicketStatistic REST API: /GetSLAStatus, /BreachAlert, /SLAReport

Vollständige Use Cases

1. SLA-Definition und -Durchsetzung

1.1 SLA-Stufen definieren nach Priorität

Purpose: Unterschiedliche Response-Zeiten je nach Kritikalität Definition:

Priority 1 (Kritisch):
  - Response: 1 Stunde
  - Lösung: 4 Stunden
  - Beispiel: Mail-Server ausfallen, 500 Benutzer betroffen

Priority 2 (Hoch):
  - Response: 4 Stunden
  - Lösung: 24 Stunden
  - Beispiel: 50 Benutzer können nicht arbeiten

Priority 3 (Mittel):
  - Response: 8 Stunden
  - Lösung: 5 Tage
  - Beispiel: Drucker funktioniert nicht

Priority 4 (Niedrig):
  - Response: 24 Stunden
  - Lösung: 10 Tage
  - Beispiel: Benutzer möchte neues Feature

Table: SLA-Konfiguration Method: DefineSLA(PriorityLevel priority, TimeSpan responseTime, TimeSpan resolutionTime)

Use Case: Support-Manager definiert SLAs für Kundenvertrag

1.2 SLA-Status real-time überwachen

Purpose: Live-Übersicht welche Tickets im Plan sind Dashboard:

🟢 OK (28 Tickets):  Im Plan, genug Zeit
🟡 WARNING (5 Tickets): <50% der SLA-Zeit verbraucht
🔴 BREACH (2 Tickets): SLA überschritten!

Method: GetSLAStatus() → Returns: Pro Ticket, ob OK/Warning/Breach Calculation: Vergleiche Elapsed Time vs. SLA Time

Use Case: Manager sieht auf Dashboard dass 2 Tickets SLA überschritten haben

1.3 Automatische Eskalation bei SLA-Verletzung

Purpose: Automatische Benachrichtigung und Maßnahmen Trigger: 80% SLA-Zeit verbraucht, kein Fortschritt Actions:

  • Email an Team-Lead: "Ticket #12345 droht SLA-Verfehlung"
  • Email an Manager: "2 Tickets haben SLA überschritten"
  • SMS an On-Call-Manager: "KRITISCH: Mail-Server noch nicht repariert!"

Method: MonitorSLABreaches()

Escalation Path:

Ticket erstellt → 25% SLA → Email Team Lead
               → 50% SLA → keine Aktion
               → 75% SLA → Email Manager + SMS
               → 100% SLA → BREACH! SMS + Phone Call

Use Case: Ticket-Zeit läuft ab → automatische Eskalation zu Manager

1.4 SLA-Compliance-Report

Purpose: Monatliche Reporting über SLA-Einhaltung Metrics:

  • SLA-Erfüllungsrate: 95% (von 100 Tickets, 95 eingehalten, 5 verletzt)
  • Average Response Time: 2.5h (gegen SLA 4h)
  • Average Resolution Time: 18h (gegen SLA 24h)
  • Durchschnittliche Kundenzufriedenheit: 4.2/5

Table: CacheTicketStatistic Method: GenerateSLAReport(DateTime startDate, DateTime endDate) → Returns: PDF Report

Report Output:

═══════════════════════════════════════════════
SLA-COMPLIANCE REPORT - OKTOBER 2025
═══════════════════════════════════════════════

Gesamt Tickets: 247
SLA Erfüllt: 235 (95.1%)
SLA Verletzt: 12 (4.9%)

Nach Priorität:
P1: 50 Tickets, 48 erfüllt (96%)
P2: 100 Tickets, 98 erfüllt (98%)
P3: 80 Tickets, 78 erfüllt (97.5%)
P4: 17 Tickets, 11 erfüllt (65%) ← PROBLEM!

Häufigste Gründe für Verletzung:
1. Warten auf Kunden-Info (5 Tickets)
2. Techniker-Kapazität erreicht (4 Tickets)
3. Material nicht lieferbar (3 Tickets)

Empfehlungen:
- P4-SLA prüfen (zu aggressiv?)
- Techniker-Kapazität erhöhen für P1/P2
- Lagerverwaltung optimieren

Use Case: SLA-Report wird dem Kunden monatlich übermittelt

1.5 SLA-basierte Eskalation bei häufigen Verletzungen

Purpose: Handeln wenn SLA regelmäßig verletzt wird Trigger: >10% Verletzungen über 3 Monate Actions:

  • Team retraining
  • Kapazitätserhöhung
  • Kundenbenachrichtigung mit Verbesserungsplan

Method: AnalyzeSLAtrends(int monthsToAnalyze) → Trending Analysis

Use Case: Manager sieht dass P4-SLA seit 3 Monaten >15% verletzt ist → beschließt auf 15 Tage zu erhöhen


Ende Asset Management & Scheduling Documentation


Zusammenfassung neue Module

Modul Tabellen Use Cases REST APIs Status
Asset Management 35+ 50+ 6 Neu
Scheduling 8+ 20+ 5 Neu
TOTAL 43+ 70+ 11 Dokumentiert

Integration in USE_CASES.md

Diese neuen Module können wie folgt in die Hauptdokumentation integriert werden:

Option 1: Als Kapitel 16 & 17 anhängen (nach Kapitel 15 "Verträge") Option 2: In bestehende Module integrieren (Asset → Hilfe, Scheduling → Helpdesk) Option 3: Separate Module-Guides als Links

Empfohlen: Option 1 - Neue eigenständige Kapitel für bessere Organisierung.


Status: Dokumentation abgeschlossen | 70+ Use Cases | Deutsche Sprache | USE_CASES.md-Format