Die Inputs für den Anforderungserwerb kommen aus unserem Wissen über den Anwendungsbereich bzw. den Vergleich mit bereits existierenden Systemen. Durch unsere Erfahrungen im technischen Kundendienst haben wir eine genaue Vorstellung aus der Praxis, welche Abläufe durch ein System verbessert werden können.  

Wir haben eine klare und eindeutige Vorstellung was wir mit der Entwicklung und Einführung der Applikation erreichen wollen und orientieren dabei an einer bekannten Zielvorstellung des Unternehmens Wien-Strom. Wien-Strom will den Verkauf des Servicepakets AllesSicher forcieren. Das soll speziell mit den damit verbundnen exzellenten Serviceleistungen geschehen, welche z.B. ein 24 Stunden, 365 Tage im Jahr - Service vorsehen. Das vom Unternehmen selbst formulierte Ziel in Form von beschriebenen Serviceleistungen kann im folgenden Link nachgelesen werden –> «"AllesSicher" Wien-Energie». 

 

Zu erreichen ist dieses (Teil)Ziel ausschließlich durch eine hohe Kundenzufriedenheit (Tiefere Bedeutung=Unterstützung zur Erreichung einer höheren Kundenzufriedenheit). Hier setzt unsere Applikation auf. Durch eine nachhaltige Dokumentation der Servicezeiten (v.a. der Responsezeit) kann Wien-Strom jederzeit, tagesaktuell Auswertungen darüber machen, ob die geplanten Servicezeiten eingehalten wurden. Bei Abweichungen können entsprechende Gegenmaßnahmen, wie z.B. das Einstellen von mehr Servicepersonal rasch eingeleitet werden. Die Kundenzufriedenheit kann aus unserer Sicht nur erreicht werden, wenn auch das Servicepersonal motiviert ist. D.h. dass die Anforderungen an das System u.a. auch so gestaltet werden müssen, dass die Akteure (Servicepersonal) einfach und bequem damit umgehen können. Kundenzufriedenheit erreichen wir auch durch die Kommunikation mit der Verrechnung, da wir durch Systemvorgaben eine unrichtige oder ungerechtfertigte Rechnungslegung ausschließen werden. 

Oder warum ist es eigentlich notwendig, ein derartiges System zu entwickeln bzw. im Unternehmen einzuführen?  

 

Faktum 1: Die geplanten Verkaufsziele für das AllesSicher Paket konnten bisher noch nicht erreicht werden. 

Faktum 2: Gleichzeitig liegen etliche schriftliche Kundenbeschwerden über zu lange Wartezeiten im Störungfall vor. 

Faktum 3: Die Rechnungslegung führt zu weiteren Kundenbeschwerden, da teilweise falsch bzw. die Rechnung selbst nicht nicht genügend Fakten über den Reparatureinsatz aufweist.  

 

Diese Fakten haben die Unternehmensleitung dazu bewogen, die Entwicklung eines Systems in Auftrag zu geben. Man glaubt, dadurch die Servicezeiten erheblich zu verbessern bzw. für eine qualitativ bessere Rechnungslegung sorgen zu können.  

Kontext: Unternehmen Wien-Strom 

Z1 - Verbesserte Einsatzlenkung des Servicepersonals 

Z2 - Höhere Kundenzufriedenheit 

Z3 - Verbesserterter Rechnungslegungsprozess 

Z4 - Übersichtlichere Darstellung der offenen Störungen 

Z5 - Vereinfachung der Störungszuleitung an das Servicepersonal 

Z6 - Reduzierung der Kunden Wartezeit auf Servicepersonal 

Z7 - Verbesserte Dokumentation der Reparatureinsätze des Servicepersonals (gibt Rückschlüsse für Nachschulungen, Kundeninformationen, etc.)  

Z8 - Bessere Auswertungen über Reparaturzeiten 

Z9 - Verbesserte Kommunikation zwischen Servicepersonal und Fakturierabteilung 

Z10- Bessere Routenplanung und dadurch kürzere Raktionszeiten 

Z11- Höherer Informatiosgrad des Servicepersonals 

Z12- Reduktion der administrativen Tätigkeiten in der Verrechnung 

Z13- Bessere "Eigen Organisation" des Servicepersonals durch übersichtliche Darstellung aller offenen Störungen 

Z14- Vermeidung von Vor-Ort Einsätzen durch genaue Beschreibung des Störungsgrundes (kann evtl. tel. gelöst werden) 

 

Wir unterstellen, dass Wien-Strom derzeit noch kein geeignetes System für die Einsatzlenkung des Servicepersonals hat (in Wahrheit wird ein derartiges System wohl vorhanden sein ;-). Deswegen fordert das Unternehmen ein System, das zuverlässige und von Kunden erwartete Servicezeiten garantiert. Gleichzeitig sollen die Kundenrechnungen mehr Informationen enthalten, welche die Richtigkeit des Rechnungsbetrages untermauert.  

Das Servicepersonal will eine tägliche Vorlage an offenen (vom Kunden gemeldete) Störungen mit Kundeninformationen, Informationen über die Störung selbst (was funktioniert nicht?), Terminvereinbarungen und Anfahrtsbeschreibungen abrufen können.  

Ausserdem will das Servicepersonal eine vereinfachte Möglichkeit, alle für den Betrieb notwendigen administrativen Tätigkeiten, wie z.B. das Berichten der Einsatzzeiten mit möglichst wenig Aufwand durchführen zu können. Es soll ein übersichtliches Eingabeformular mit allen für die interne und externe Verrechnung notwendigen Feldern geben. 

Nach erfogreicher Eingabe aller Daten durch das Servicepersonal wird im Falle einer Verrechung eine automatische Email Nachricht an die Fakturierabteilung versandt. Übertragen werden hier nur die für die Verrrechnung notwendigen Informationen. Dabei ist darauf zu achten, dass nur eindeutige (auswählbare) und für die Verrechnung verständlich Begriffe gewählt werden.  

Wir konzentrieren uns hier, in Absprache mit dem Leiter des Praktikums auf die einzusetzende Technologie mit welcher wir unsere Lösung umsetzen werden. 

Hier sehen wir im Rahmen des Praktikums keine speziellen Vorgaben ausser dass das System natürlich fehlerfrei mit einer entsprechenden Performance läuft. Aufgrund der Anforderungen können wir die Performance eher vernachlässigen und uns auf leicht bedienbares User-Interface konzentrieren. 

Wir werden mit unserem vorhandenen Wissen das System entwicklen. Time to Market ist vorgegeben –> Ende des Semesters ;-) Auf unser Zeitbudget werden wir ebenfalls achten, da wir auch noch andere Übungen im laufenden Semester erledigen müssen. D.h.: unser System wird den Anforderungen dieses Praktikums entsprechen; wir werden uns aber gleichzeitg darauf konzentrieren, unsere Lösung nicht zu groß anzulegen, da wir sonst Gefahr laufen, nicht fertig zu werden.  

 

Use Case Beschreibung 

 

use Case Pitfalls