GCC Teaching/IBM: W2322 Collaborative e-Business Solutions - Zertifizierungsprogramm, Groupware Competence Center, Paderborn 2008.

Logbuch zur Veranstaltung

THEMES: GCC Teaching\Lecture 2008/0... | IBM\Certification
META STRUCTURES: GCC Teaching\Lecture 2008/0... | Projects\...\Student Traini...
YEAR: 2008
PERM. URL: http://gcc.upb.de/K-Pool/W2322_WS0809
Login Login
User: Anonymous


LABEL: IBM CP
ORGANIZATIONS: GCC - Groupware Competence Center
PEOPLE: Hesse, Bernd | Nastansky, Ludwig
PLACES: Paderborn
THINGS: Certification | Logbuch | Modul
TIME: 2008´09_WS
 
Projektteil

    Aufgabe des Projektteils

    Szenario: Ein Softwareunternehmen aus Paderborn, das im B2B-Markt agiert, offeriert einerseits diverse Standardsoftwareprodukte und bietet andererseits die Implementierung von Individualsoftwarelösungen an.

    Technischer Support wird über mehrere Kanäle angeboten:
    • Online wird eine Wissensdatenbank bereitgestellt, mit deren Hilfe Kunden Lösungen häufig vorkommender Probleme selbst finden können.
    • Zusätzlich wird ein Online-Forum angeboten, in dem Kunden sich gegenseitig helfen sollen, das aber auch von Support-Mitarbeitern überwacht wird.
    • Über ein Kontakt-Formular auf der Homepage können sich Kunden direkt an den Support wenden.
    • Darüber hinaus wird eine kostenpflichtige Telefonhotline angeboten.
    • Besonders wichtige Kunden erhalten einen direkten Ansprechpartner, der per Telefon oder E-Mail für sie erreichbar ist.

    Innerhalb des Support-Teams existieren verschiedene Rollen:
    • Der First-Level-Support (die Frontline) überwacht das Online-Forum, nimmt die Anfragen über das Kontakt-Formular auf und betreut die Telefonhotline. Die Mitarbeiter sollen alle Anfragen sammeln und möglichst viele davon mit Hilfe einer internen Wissensbasis eigenständig bearbeiten.
    • Der Second-Level-Support (die Backline) besteht aus technisch versierten Mitarbeitern, die dem First-Level-Support als Ansprechpartner zur Verfügung stehen. Die Mitarbeiter füllen darüber hinaus die interne und öffentliche Wissensdatenbank.
    • Der Key-Account-Support bearbeitet die Anfragen besonders wichtiger Kunden.
    • Das Support- und Produkt-Management entscheidet darüber, mit welchen Prioritäten die vom Second-Level-Support identifizierten Bugs behoben werden sollen.

    Zu implementieren ist ein geeignetes Unterstützungssystem als Datenbank auf Basis von Notes/Domino 8. Je funktionaler das System am Ende sein wird, desto besser wird auch die Note. Gesucht werden daher kreative und eigenständige Lösungen.

    Folgende Liste möglicher Must-have-Bestandteile soll eine Ausgangsbasis für die Konzeptionsphase darstellen:
    • Notes-Frontend:
      • Öffentliches Diskussionsforum.
      • Öffentliche Wissendatenbank.
      • Interne Wissensdatenbank.
      • Verwaltung der Kunden.
      • Verwaltung der Zuständigkeiten und Kenntnisse der Supportmitarbeiter.
      • Verwaltung der angebotenen Produkte.
      • Verwaltung der Support-Anfragen (Trouble Tickets) von der ersten Kontaktaufnahme bis zum Abschluss des Falls.
      • Dokumentation sämtlicher interner und externer Kommunikationsvorgänge zu den Trouble Tickets, auch über Telefon, E-Mail oder Instant Messaging.
      • Management-Funktionen (Genehmigungsprozesse, Überwachungsprozesse, Analyseprozesse).
    • Browser-Frontend:
      • Diskussionsforum.
      • Wissensdatenbank im Lesemodus.

    Basiseigenschaften der Architektur:
    • Durchgängiger Praxisbezug.
    • Benötigte Masken, Ansichten, Schaltflächen etc. mit zugehöriger Geschäftslogik.
    • Datensicherheit und Trennung von Zuständigkeiten.
    • Geschäftsprozessunterstützung.
    • Speicherkonfliktvermeidung bzw. Konfliktbehandlung.
    • Fehlerrobustheit bzw.Fehlerbehandlung.
    • Wiederverwendbare Designelemente.
    • Dokumentation z. B. in Form von Quelltext-Kommentaren.

    Folgende Liste soll nur einige Ideen für besondere Nice-to-have-Funktionalitäten aufzeigen:
    • Presence-Awareness- und Instant-Messaging-Integration für die Kontaktaufnahme vom First-Level-Support zum Second-Level-Support.
    • Java-basierte Diagramme, z. B. zur Rate der erfolgreich abgeschlossenen Trouble Tickets eines Mitarbeiters oder Teams.
    • Verwendung von Javascript-Frameworks wie Dojo für zeitgemäße Browser-Frontends.
    • Personalisierungsfunktionen, damit z. B. der Key-Account-Support z. B. nur die Daten der selbst betreuten Key-Accounts angezeigt bekommt, oder damit ein Kunde im Forum nur die Unterforen zu den von ihm gekauften Produkten angezeigt bekommt.
    • Urlaubsvertretungsfunktion für Second-Level- und Key-Account-Support.
    • Wiedervorlagefunktion für First-Level-Support.
    • Automatisierung von Feedbackmechanismen.
    • Nutzung von Signaturen und Verschlüsselung.
    • Konsistente Verschlagwortung von Produkten und Experten zur automatisierten Expertenermittlung.
    • Administrationsumgebung zur Konfiguration der Datenbank, z. B. zentrale Speicherung der angebotenen Produkte.

    Am Ende abzugeben sind drei Dinge:
    • Deployment-Template eurer Lösung.
    • Lauffähige und mit Testdaten gefüllte Beispiel-Datenbank.
    • Technische Dokumentation.

    Die Bewertungskriterien lauten in absteigender Wichtigkeit:
    • Funktionalität
    • Architektur und Entwicklungsstil
    • Fehlerfreiheit
    • Dokumentation
    • Layout
    • Testdaten


    Hinweise zur Abgabe

    Zur Bewertung werden die bereitgestellten Projektdatenbanken auf dem Server verwendet. Diese müssen also zum Abschluss von Unerwünschtem bereinigt und mit sinnvollen Testdaten gefüllt werden.
    Zur Archivierung der Prüfungsleistungen muss jede Gruppe zusätzlich noch eine unverschlüsselte Kopie der eigenen Datenbank anlegen, diese als ZIP-Datei komprimieren und gemeinsam mit der Dokumentation im Modul-Forum hinterlegen. Achtung: Dies ist nur VOR Ablauf der Bearbeitungszeit möglich! Überprüft außerdem mit einer anderen ID, ob die Datenbank von anderen Personen verwendet werden kann.