Projektplanung: Einführung, Ausbau und Betrieb

Ein erfolgreich eingeführter Produktkonfigurator wird zum unverzichtbaren Modul der Unternehmenssoftware. Die weitsichtige Planung umfaßt daher die gesamte Nutzungsdauer der Software, wie in folgenden Kapiteln beschrieben:

1. Einstand bis zum ersten GoLive
2. Ausbau und langfristige Planung →
3. Support des laufenden Betriebs →
4. Einbindung in das Änderungswesen →

1. Einstand bis zum ersten GoLive

Beim Einstand ist vorausgesetzt, dass die Digitalisierung ihres Produkts technisch machbar und wirtschaftlich lohnenswert ist. Die EDV-technische Integration des Moduls ist zumindest in den Grundzügen geklärt. Das Pensum des GoLive (welche Produkte mit welchem Funktionsumfang) ist abgesteckt. Die wesentlichen Aufgabenbereiche bis zum GoLive sind:

• Die zunächst wichtigste Frage ist die nach Zuständigkeit und Rollenverteilung:
  • Wer liefert/spezifiziert welche Regelwerke.
  • Wer trifft Festlegungen in welchen Regelwerksdomänen.
  • Wer steht als Regelwerker∗in zur Verfügung.
• Planung und Bereitstellung der EDV-Infrastruktur (Server, Software, Lizenzen)
• Schnittstellen zu angrenzenden Systemen ausarbeiten und implementieren.
• Planung der Applikationserstellung in RuleBook:
  • Meilensteine und Zeitplan.
  • Planung der Zusammenarbeit mehrerer Regelwerker∗innen.
  • Ausbildung und Begleitung angehender Regelwerker∗innen.
  • Verifikation von Meilensteinen (z.B. Dialoge und Ergebnisdokumente werden durch erfahrene Projektierer∗innen und Fertiger bewertet).
• Planung der Testphase vor dem GoLive:
  • Wie kann der Echtbetrieb getestet werden?
  • Testplan: welche Produktvarianten mussen explizit getestet werden.
  • Erkenntnisse der Tests in Verbesserungen umsetzen.
• Vorbereitung auf den Zielprozess: es können sich Unterschiede im Tätigkeitsprofil der Protagonisten ergeben. Bisherige Tätigkeiten entfallen, andere entstehen.

2. Ausbau und langfristige Planung ↑

Für die sukzessiven Digitalisierung der gesamten Produktpalette, ist zu entscheiden, in welcher Reihenfolge Produkte/Ausstattungen/Zubehöre erfasst werden und welche Stände in den Echtbetrieb gehen sollen.

In Abb. 1 ist der paketweise Ausbau der Produktkonfiguration dargestellt, und in Abb. 2 der beschleunigte Aufbau durch Manpower. Die Produkte A/B/C... in den Abbildungen können auch Erweiterungen eines Produkts sein, wie neue optionale Teile oder neue Bauteilfunktionen etc..

  Abb. 1: sukzessiver Aufbau der Konfiguration

  Abb. 2: Beschleunigter Aufbau durch Manpower

3. Support des laufenden Betriebs ↑

Wie bereits gesagt, wird ein erfolgreich eingeführter Produktkonfigurator zum unverzichtbaren Modul und der Ausfall des Moduls bedeutet Stillstand - der störungs- und fehlerfreie Betrieb hat daher oberste Priorität. Außerdem muss die Akzeptanz des Systems gefördert und Frustration vermieden werden. Die Aufgaben des Supports sind:

• Sicherung des Betriebs: eine Störung des Betriebs kann viele Ursachen haben. Für das Auffinden und Beheben einer Störung, muss, zusätzlich zur EDV-Kompetenz (Netzwerk, Server, Sicherheit), das spezielle Know-how zur Fehleranalyse des customX-Betriebs abrufbar sein.
• Fehlerkorrektur: Fehler, die erst im laufenden Betrieb auffallen, müssen zeitnah korrigiert und die Korrektur im Echtsystem bereitgestellt werden. Dafür muss es einen Ablaufplan und versierte Ansprechpartner∗innen geben.
• Betreuung der Anwender∗innen: Fragen zur Bedienung von Dialogen und zu Ergebnisdokumenten bleiben nicht aus - dafür muss es Ansprechpartner geben.
• Kontinuierlicher Verbesserungsprozess: im täglichen Umgang mit Dialogen und Ergebnissen entstehen Verbesserungsvorschläge und Änderungswünsche, sowie eine Priorisierung der Ausbauwünsche. Für die Überführung dieser Anforderungen in das Echtsystem wird ein Ablaufplan benötigt. Qualitätszirkel für die Bewertung von Anforderungen und Diskussion von Lösungsmöglichkeiten, benötigen das Know-how der Regelwerker∗innen.

4. Einbindung des Produktkonfigurators in das Änderungswesen ↑

Im customX-Teamserver wird durch die Regelwerker∗innen eine serielle Folge von (versionierten) Modellierungständen (Änderungsberichten) erzeugt. Lesen sie hier mehr über:
→ Test und Abnahme eines Änderungsberichts
→ Organisation von Änderungsberichten im Teamserver

Die Versionsnummer eines Änderungsberichts, dokumentiert eindeutig und reproduzierbar (im Sinne der ISO9001 rückverfolgbar), die angewendeten Konstruktionsregeln und die damit erzeugten Ergebnisdokumente.