Ergebnisse 1-3 + Typs Debug
This commit is contained in:
996
Ergebnisse/Ergebnisse 03/USE_CASES_NEW.md
Normal file
996
Ergebnisse/Ergebnisse 03/USE_CASES_NEW.md
Normal file
@@ -0,0 +1,996 @@
|
||||
# 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)](#16-asset-management-it-verwaltung)
|
||||
- [16.1 Geräte-Inventarverwaltung](#161-geräte-inventarverwaltung-device-inventory-management)
|
||||
- [16.2 Patch- und Update-Management](#162-patch--und-update-management-patch-management)
|
||||
- [16.3 SNMP-Netzwerk-Überwachung](#163-snmp-netzwerk-überwachung-snmp-monitoring)
|
||||
- [16.4 Software-Lizenz-Verwaltung](#164-software-lizenz-verwaltung-software-license-management)
|
||||
- [16.5 Compliance und Asset-Depreciierung](#165-compliance-und-asset-depreciierung-compliance-and-depreciation)
|
||||
|
||||
2. [Terminverwaltung & Planung (Scheduling)](#17-terminverwaltung--planung-scheduling)
|
||||
- [17.1 Termine und Buchungen](#171-termine-und-buchungen-appointments-and-bookings)
|
||||
- [17.2 Techniker-Routenoptimierung](#172-techniker-routenoptimierung-technician-route-optimization)
|
||||
- [17.3 Ressourcen-Kapazitätsplanung](#173-ressourcen-kapazitätsplanung-resource-capacity-planning)
|
||||
- [17.4 Service Level Agreements (SLA)](#174-service-level-agreements-sla-sla-management)
|
||||
|
||||
---
|
||||
|
||||
# 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
|
||||
Reference in New Issue
Block a user