[Spezifikation] ››› Anforderungsdefinition

1. Initial werden die von der Systemunterstützung betroffenen Geschäfts- und Arbeitsprozesse erfasst – toolgestützt mittels des Change Control Centers (threec). Dieser Schritt erfolgt so fokussiert wie möglich, ist aber zur Absicherung der Fachlichkeit unumgänglich. Hierbei wird auf bestehende Dokumentationen zurückgegriffen und über ein langjährig erprobtes Workshop-Verfahren die erforderlichen Informationen erfasst.

 

2. Danach erfolgt bereits der erste Abstimmungslauf mit den betroffenen Stakeholdern. Fehlende Stakeholder sollten hier durch die Beteiligten identifiziert werden und können so noch hinzugezogen werden. Ferner erfolgt hier bereits die Vorbereitung der Organisation auf die bevorstehende Veränderung, da eine mangelnde Kommunikation ein hohes Veränderungsrisiko bedeutet.

 

3. In direkter Fortsetzung werden im threec die Anforderungen an die Systemunterstützung der Arbeitsprozesse erfasst. Eine bestehende Systemunterstützung oder zu nutzende Standard-Software können hierbei abgebildet und Anpassungsbedarfe dokumentiert werden.

 

4. Per Report werden durch den threec hieraus Lastenhefte und Ausschreibungsdokumente generiert, über die die erforderlichen Aufwände bestimmt oder Anbieter zur Angebotserstellung aufgefordert werden können. Verschiedene Implementierungsalternativen können nach Bereitstellung durch den Systemdienstleister direkt aus den Arbeitsprozessen verlinkt werden, um diese hinsichtlich ihres Lösungspotentials zu bewerten.

 

5. Im zweiten Abstimmungslauf werden die kalkulierten Kosten und Aufwände direkt in die Arbeitsprozesse und hieraus in die Geschäftsprozesse zurückgespielt. Auf Basis der auf diese Weise gewonnenen Kosten-Nutzen-Analyse können die Systemunterstützung, die Arbeits- oder die Geschäftsprozesse so angepasst werden, dass eine Umsetzung in Time and Budget möglich ist. Die so geplante Systemunterstützung wird dann durch die betroffenen Stakeholder evaluiert, so dass fehlende oder falsche Funktionalitäten/Anforderungen vor der Implementierung abgefangen werden können.

 

6. Per Report werden dann mittels des threecs die von der geänderten Systemunterstützung betroffenen Anwender über deren Rollenzugehörigkeit identifiziert, um hieraus ein Schulungskonzept zu erstellen. Die Qualifizierung der Mitarbeiter kann toolgestützt über die Knowledge-Management-Komponente des threecs erfolgen – sogar bevor die Implementierung abgeschlossen ist, wenn die erforderlichen Quellen entsprechend verlinkt sind. Ferner kann per Report durch die Generierung fachlicher Testfälle das Testen vorbereitet werden.

 

CCaaS ‘Requirements Defintion’ führt soweit möglich alle erforderlichen Entscheidungen im Voraus herbei, d.h. die im Bedarf als häufiger Praxisfehler genannte “nachgelagerte Realitätsprüfung” wird dadurch ausgeschlossen, indem die “Verprobung” in der Organisation kontinuierlich stattfindet. In gleicher Weise werden die fachlichen Folgen von Anfang an berücksichtigt bzw. alle Anforderungen aus der eigentlichen Fachlichkeit abgeleitet und nicht umgekehrt.

 

>>> Zurück zur Service-Übersicht

[Bedarf] ››› Anforderungsdefinition

Einer der häufigsten Veränderungstreiber ist die Anpassung, Umstellung oder Einführung von IT-Systemen. Meist wird das Veränderungspotential hierbei maßlos unterschätzt. Beispielsweise soll “nur” das Altsystem einer Abteilung abgelöst werden. Das neue System bietet aber neue Möglichkeiten, die gerne genutzt werden. Dies verändert nachfolgend die Abläufe der Abteilung, wodurch sich auch das Umfeld der Mitarbeiter ändert und die Aufbauorganisation angepasst werden muss. Dann ändern sich noch die Schnittstellen – technisch oder organisatorisch – zu anderen Einheiten, gegebenenfalls verschieben sich sogar Zuständigkeiten. Dies ergibt dann in Summe eine Reorganisation durch die Hintertür.

Ein weiterer Praxisfehler ist die nachgelagerte organisatorische “Realitätsprüfung”: Zur Einführung oder Anpassung eines IT-Systems wird ein Projektteam gebildet – alles gute Leute. Besten Wissens und Gewissens werden Anforderungen formuliert und durch den Implementierungspartner umgesetzt. Anschließend wird in der Testphase durch möglichst viele Stakeholder fachlich getestet. Was dann kommt, ist nicht schön – fachlich-organisatorische Spezialfälle werden erst jetzt sichtbar und zahlreiche neue Anforderungen an das System formuliert. Die Akzeptanz für das neue System ist schon jetzt nicht mehr gegeben. Das Projektteam und der Implementierungspartner finden sich zu Unrecht auf der Anklagebank wieder. Der Schaden für die Organisation ist aber real und kann nur mit zusätzlichen Aufwänden, Zeitverzug oder Folgeprojekten “geheilt” werden.

 

>>> Zurück zur Service-Übersicht