bestehende systeme bei IXOS
 - cid/mkis
   - customer information database
   - enthaelt stammdaten der kunden (im mkis)
     und installationsdaten (im cid)
   - mkis per rfc auf hydra und cid-daten auf per nfs von bill:/as/ar unter /ixos/ar/cst/cust
   - pflege durch vertrieb (mkis) und support (mkis/cid)
   - kunden haben bisher keinen zugriff
   - cid wird ins R/3 migriert
   - Sicherheit:
     - mkis
       - authentifizierung durch benutzername und passwort (r/3-account)
       - authorisierungskonzept: r/3
     - cid
       - authentifizierung durch benutzername und passwort (unix)
       - authorisierungskonzept: keines
 - pts
   - problem tracking system
   - enthaelt supportfaelle
   - pflege durch hotliner und indirekt durch kunden
   - Sicherheit:
     - authentifizierung durch benutzername und passwort (unix, siehe cid)
     - authorisierungskonzept: gruppen (sog. supportpools)
 - esc
   - expert service center
   - enthaelt expertenwissen, patches, doku
   - eigener Rechner (beaulieu) im intranet, dessen https-port in der firewall fuer
     externe zugriffe freigegeben ist
   - pflege durch moderatoren
   - kunden koennen es bereits verwenden (abfragen)
   - Sicherheit:
     - https
     - authentifizierung durch benutzername und passwort
     - authorisierungskonzept: benutzergruppen (kunde, partner, admin)

andere systeme
   - SAP Online Service System
     - Sicherheit:
       - authentifizierung durch benutzername und passwort (oss benutzer)
       - authorisierungskonzept: berechtigungsobjekte mit werten
   - Red Hat Support
     - http://www.redhat.com/support/programs.html

anforderungen
 use-cases
 - pts
   - anlegen neuer supportfaelle durch kunden
     - hilfestellung durch cid-daten (server-, client-versionen)
     - hilfestellung durch bestehende faelle (folgefall)
     - falls installation nicht dem account zugeordnet ist
       (nicht gepflegte stammdaten im cid!), nur
       indirektes triggern eines supportfalls durch email an support
   - abfragen (suchen) offener und evtl. schon geschlossener faelle
     - faelle, die dem account zugeordnet sind
     - faelle, die explizit fuer den account freigegeben sind
     - eingeschraenkte sicht!
     - suche auch in fremden faellen, die aber anonymisiert
       angezeigt werden (ausblick! :))
   - aendern bestehender offener faelle
     - anhaengen von kommentaren und dateien (logs)
     - prioritaet (nicht direkt)
     - schliessen
     - vertagen
     - eskalation (nicht direkt)
 - cid
   - anlegen neuer eintraege durch partner
   - anzeige der stammdaten (mkis + cid)
   - aendern bestimmer! daten
     - entweder direkt oder indirekt durch bestaetigung der
       daten durch mitarbeiter (rechtliche frage?)

design
 - berechtigungskonzept (aehnlich sapnet)
   use-cases erfordern unterscheidung aktoren nach Kunde, Partner,
   ixos-mitarbeiter und ixos-supportmitarbeiter. das erfordert eine
   unterscheidung der jeweiligen berechtigungen.
   - berechtigungsobjekte
     werden mit der jeweiligen funktion implementiert
     auspraegungen der b.objekte werden zu berechtigungsprofilen gruppiert
   - berechtigungsprofile sind gruppierungen von auspraegungen
     von berechtigungsobjekten und spiegeln eine rolle wieder
   - evtl. benoetigte b.objekte: für jede transaktion bzw. jedes
     ein- und ausgabefeld.
   - evtl. benoetigte b.profile: Administrator-Berechtigung,
     Benutzerdaten verwalten, CID-Daten verwalten,
     Meldungen senden, Fall anlegen, Fall schließen, Folge-Fall anlegen
   - vorteile:
     - sehr flexibel durch die trennung von objekt und auspraegung
   - nachteile:
     - ?
 - hierarchische administration
   administratoren sollen selbst benutzer anlegen und
   ihnen maximal die eigenen berechtigungen uebertragen koennen
   - vorteile:
     - einfache implementierung bei wie vorher beschriebenem vorhandenem
       berechtigungskonzept
   - nachteile:
     - ?
 - schnittstellen zu PTS/CID
   - verwendung bestehender funktionen
   - alternativ: interface-objekte als bindeglied, um die schnittstelle
     unabhaengiger zu halten
 - integration in das ESC
   - eigener punkt im navigationsbaum
   - fälle mit status open_feedback auf der einstiegsseite auflisten,
     um benutzer darauf aufmerksam zu machen, dass eine reaktion
     notwendig ist.
 - navigation (???)
   - baumartig an kundennummer aufgehaengt
     - installationen zur kundennummer (bei ccc kundeninstallation)
       - faelle zur installation

implementierung
 - sprache: perl, weil esc, pts und cid bereits existieren und in
   perl implementiert sind
 - objektorientiert, um die komplexitaet ueberschaubar zu halten.
 

zusammenfassung

ausblick
 - uebernahme von supportfaellen aus dem pts in das esc