Das Management der Produktion von SAP A1S  (All in One Services) und den damit verbundenen internetbasierten „On Demand“ Services für klein- und mittelständische Unternehmen (KMU) stellt neue Anforderungen an die T-Systems.

Der KMU Kunde macht mit diesem Ansatz sein Geschäft von einem Service abhängig, dessen Produzent und dessen Qualität ihm nicht näher bekannt sind. Bei ASP (Application Service Providing) hat diese Wahrnehmung breite Erfolge sowohl vertrieblich behindert. Erschwerend kam hinzu, dass durch fehlende „End to End“ Verantwortung des Anbieters die ASP Lösungen auch technisch nicht reibungslos funktionierten.

Die Anforderungen von „On Demand“ Services lassen sich nur bewältigen durch:

• eine radikale Automatisierung der Produktion der Services,
• die Nutzung präziser mittel- und kurzfristiger Planungs-, Controlling- und Steuerungsinstrumenten der Produktion,
• die Definition von Serviceprodukten als Basis für Marketingaktivitäten sowie als Träger von Kosten, Qualitätsmerkmalen und Erlösen 
• und ein explizites Management der Anwenderzufriedenheit.

Notwendig ist weiterhin ein diesem Ansatz entsprechender „End to End“ Remote Service aus einer Hand zur Beratung der Anwender und zur Entstörung, sowie einem „Single Point of Contact” als eindeutiger Anlaufpunkt für den Anwender. Natürlich ist eine an den Produktionsprozessen orientierte Kostenrechnung notwendig, die Auslastung der Produktionsmittel, Effizienz der Produktionsprozesse und Cost of Poor Quality ausweisen kann. Dieser Grad an „End to End“-bezogener Integration zwischen der kaufmännischen und technischen Planung und Steuerung des Geschäfts ist neu für IT Service Provider. Sie ist jedoch in Industriebetrieben seit längerem Normalität.

Die vorliegenden Ergebnisse des Competence Centers „Industrialisiertes Informationsmanagement“ (CC IIM) der Universität St. Gallen bieten als Einzige die Voraussetzung, neue, wettbewerbsentscheidende Lösungen für die Gestaltung und Abwicklung der Produktion dieser „On Demand“ Lösung zu implementieren.

Wir schlagen daher vor, einen auf einem R3 Wirksystem abgestützten IIM Prototypen und mit zeitlichem Versatz einen A1S Prototypen aufzubauen. Beide Aktivitäten sind eng verzahnt. Der IIM Prototyp kann wegen seiner Basis auf einem Wirksystem „Proof of Concept“ Tests ausführen, deren Ergebnisse dann im A1S Prototyp verwendet werden. Beide Prototypen umfassen den kompletten Umfang der Einführung neuer Produkte nach dem „On Demand“ Geschäftsmodell, beim IIM Prototyp jedoch ohne Bereitstellung der Produktionskapazitäten für einen Pilotbetrieb.

Ziel des Partnerprojektes bei der Deutschen Bank war, die Qualität der Anforderungsdokumente für neue Software und IT Produkte zu erhöhen. Der Fokus lag dabei insbesondere bei den sogenannten „nicht-funktionalen Anforderungen“.

In der ersten Phase des Projektes wurden Anforderungsspezifikationen aus abgeschlossenen Projekten analysiert und auf ihre Eignung als Spezifikationsdokument für IT Produkte geprüft. Im Anschluss an die Analyse wurde ein Template für die Erfassung nicht-funktionaler Anforderungen erstellt. Bei der Erstellung wurde von den vier grundlegenden Eigenschaften des IT Produktes ausgegangen: Funktion, Preis, Menge und Qualität. Aus diesen vier Bereichen wurden die einzelnen Punkte abgeleitet, die mit Hilfe des Templates erfasst werden sollen. Zur Überprüfung der Vollständigkeit der Dokumente wurden Anforderungsdokumente aus verschiedenen, in der Praxis erprobten, Standard-Referenzmodellen, bspw. der ITIL oder dem V-Modell XT sowie die einschlägige Literatur aus dem Bereich Anforderungsmanagement verwendet. Im Rahmen eines Entwicklungsprojektes bei der Deutschen Bank wurde die Funktionalität des Templates in der Praxis validiert.

Das Ziel der Überarbeitung des Kostenrechnungssystems war, die Kosten für eine Abrechnung (in diesem Fall das IT Produkt) zu bestimmen. Eine Schwierigkeit bestand unter anderen darin, dass sich eine Rechnung in unterschiedliche Rechnungspositionen unterteilt, die jeweils gemeinsame Anwendungsleistungen aber auch individuelle Anwendungsleistungen nutzen. Als Konsequenz wurde deswegen zunächst das Vertriebsprodukte- und Fertigungsprodukteportfolio definiert und ausgearbeitet. Charakteristisch für die Fertigungsprodukte war ein hoher Wiederverwendungsgrad in verschiedenen Vertriebsprodukten. Vertriebsprodukte hingegen konnten auf Basis der standardisierten Fertigungsprodukte kundenindividuell aufgebaut und angeboten werden.

Grundsätzlich wurde die Fragestellung erhoben, wie die bisher erfassten Kostenstellenkosten auf die gebildeten Fertigungsprodukteinheiten und später auf Vertriebsprodukte zugerechnet werden sollten. Wegen sehr hoher Gemeinkostenanteile, entschied man sich zur Einführung einer Prozesskostenrechnung im Bereich der Produktion. 

Das Ziel des Projektes war die Überprüfung, inwiefern das Qualitätsmanagementkonzept Six Sigma auf Prozesse des IT Managements übertragbar ist.

Die Überprüfung erfolgte anhand der IT Support-Prozesse für eine der datenintensivsten T-Com-Anwendungen zur Verwaltung der Kundendaten und Ortsnetzinformationen der Deutschen Telekom. Für die Anwendung von Six Sigma werden repetitive Prozesse benötigt. Diese Forderung konnte mit den ausgewählten Support-Prozessen erfüllt werden.

Für die IT Prozesse der T-Com existiert ein allgemeingültiges Prozessmodell, welches auch die Support-Prozesse abdeckt. In einer ersten, sogenannten „Define“-Phase wurden die Support-Prozesse für die Anwendung analysiert und mit den im Modell definierten Prozessen verglichen, wobei eine ca. 85%-95%-ige Konformität festgestellt wurde. In der anschliessenden „Measure“-Phase wurden die eingehenden Fehlermeldungen (Tickets) im Prozessablauf mit Hilfe von automatischen Tools nachverfolgt und in vier verschiedene Fehlerkategorien eingeordnet. Neben der mangelnden Qualität der eingehenden Fehlermeldungen wurden in der „Analyse“-Phase drei entscheidende Erkenntnisse gesammelt: 1. Die Haupfehlerursache sind Datenfehler. 2. Die Ursache für die Entstehung von Datenfehlern ist nicht bekannt. 3. Ein ITIL-konformes Problem-Management zur Identifizierung von Ursachen für Datenfehler ist im Prozessmodell der T-Com nicht vorgesehen. Dementsprechend werden auch keine entsprechenden Ressourcen bereitgestellt.

Es zeigte sich, dass durch die Six-Sigma-Methode mit relativ wenig Aufwand wertvolle Einsichten gewonnen und kritische Problemfelder im Support-Prozess identifiziert werden konnten und somit eine Übertragung der Methode auf IT Management-Prozesse sinnvoll ist. Die Six-Sigma-Phasen „Improve“ und „Control“ wurden aufgrund fehlender Akzeptanz der Mitarbeiter nicht durchgeführt. Daran lässt sich erkennen, dass die in dem Projekt unberücksichtige, organisatorische Komponente des Six-Sigma-Konzeptes letztlich für die Umsetzung von Verbesserungsmassnahmen notwendig ist.