35 KiB
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
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:
-
Geräte-Erfassung
- Hardware-Informationen automatisch erfassen
- Manuelle Ergänzung möglich
- Seriennummern und Asset-Tags
-
Geräte-Kategorisierung
- Desktop/Laptop/Server
- Betriebssystem-Klassifizierung
- Hersteller und Modell
-
Verlinkung zu Tickets
- Geräte-zu-Ticket Zuordnung
- Service-Historie pro Gerät
- Zuweisen von Tickets zu Assets
-
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:
-
Termein-Anfragen
- Kunde fordert Termin an
- System schlägt freie Slots vor
- Kunde bucht einen Termin
-
Verfügbarkeits-Verwaltung
- Techniker-Kalender
- Urlaub/Krankheit
- Arbeitszeit-Fenster
-
Route-Optimierung
- Mehrere Besuche an einem Tag
- Fahrtzeit-Berechnung
- Zone-basierte Planung
-
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,TicketI3DRequestedDateRange(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
ToDoListeals 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:
EmployeeI3DWorkingHours(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,TourDateStartTime,EndTimeEstimatedMileage,ActualMileageStops(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