Kontakt

Schreiben Sie uns

E-Mail

Oder rufen Sie an

+49 (0)40 / 226 34 80-0

Wer hat das entschieden? Wo steht das? – Dokumentation von Dynamics-Systemen

Von | Aus der Praxis, Dynamics 365 for Finance and Operations / Dynamics 365 Finance und Supply Chain Management, Dynamics AX, ERP allgemein, Implementierung

Wir Menschen treffen jeden Tag unzählige Entscheidungen. Viele Entscheidungen haben nur kurzfristige, aber manche haben langfristige Auswirkungen.

In Projekten ist es genauso. Die Auswirkungen von Entscheidungen sind oft nicht mit allen Konsequenzen im Vorhinein klar und wenn diese dann offensichtlich werden, hört man oft „Warum ist das so?“, „Wer hat das so entschieden?“ und „Wo steht das?“.

Wer hat das entschieden? Wo steht das? – Dokumentation von Dynamics-SystemenWie also kann man Entscheidungen im Projekt sinnvoll dokumentieren und mit ihren Auswirkungen verknüpfen? Wie stellt man die Transparenz her, wo der Ursprung einer Design-Entscheidung liegt, wie die Kette der Auswirkungen von den Anforderungen bis zu den Umsetzungen im produktiven System zusammenhängt?

Langfristiger Erfolg eines Dynamics-Systems basiert auf der Grundlage eines effektiven und effizienten Informationsmanagements und des dazu genutzten Dokumentationssystems, das vor allem auf die Bedürfnisse der Nutzer ausgerichtet ist.

Die Aufgaben und Abläufe müssen in ihrer Wechselwirkung erkannt und beschrieben werden, um die

  • Geschäftsprozesse zu präzisieren,
  • Transparenz im Unternehmen zu erhalten,
  • Verbesserungsmöglichkeiten zu erkennen und zu nutzen sowie
  • klare, rationelle Abläufe und deren Umsetzung im System zu erreichen.

Mit Augenmaß sind Umfang und Tiefe der Projekt- und der Systemdokumentation festzulegen, um sie schlank und übersichtlich zu gestalten. Die Dokumentation soll einerseits umfassend, aber gleichzeitig effizient und einfach nutzbar sein.

Transparenz und Akzeptanz bei den Mitarbeitern und Führungskräften wird erreicht durch

  • Angemessenheit,
  • Funktionalität,
  • Kontinuität und
  • aktuellen Nutzen.

Was ist das Problem?

Allein Dynamics 365 for Finance and Operations umfasst etwa fünfzehntausend Tabellen mit Daten. Im Standard sind etwa zweitausend Prozesse bereits enthalten. Im Design eines neuen Systems werden die Prozesse des Unternehmens mit den gegebenen Abläufen im Dynamics-Systems abgeglichen. In der Implementierung werden diese Prozesse entsprechend den Anfordernissen des Unternehmens angepasst, modifiziert und erweitert. Dazu kommen noch Schnittstellen und Datenaustausch-Prozeduren mit umliegenden Systemen. Dieses summiert sich zu einer solch großen Menge an Informationen, dass es eine große Herausforderung darstellt, alles zusammenhängend zu dokumentieren.

Wer hat das entschieden? Wo steht das? – Dokumentation von Dynamics-SystemenAus unserer Sicht gibt es noch immer keine gute Lösung in IT-Projekten, die Zusammenhänge und Verzahnung von Businessprozessen zu Anforderungen zu funktionalem und technischen Design bis hinunter zu den speziellen Entwicklungen und Releases zu dokumentieren. Ja, es gibt für viele Bereiche sehr gute Werkzeuge: Business Process Modeller, viele Möglichkeiten die Anforderungen zu dokumentieren (ob nun mit Word oder Excel oder Datenbanken) und mächtige Werkzeuge, um Projekte zu managen oder um Softwareentwicklungen zu unterstützen, zu dokumentieren zu testen und für die Nutzung auszurollen (zu deployen). Aber wo bitte ist die Lösung, in der auch nach den ersten dutzend Change Requests oder dem ersten Jahr des Systems in Produktion die Gesamtheit des Systems klar nachvollziehbar ist?

Was ist zu dokumentieren?

Im Laufe eines Projektes werden typischerweise folgende Dokumente erstellt:

  • Liste der Entscheidungen: Entscheidungsvorlagen und Ergebniss & Genehmigungen aller Art
  • Business-Prozess-Dokumentation: Tool & Verlinkung
  • Projektpläne
  • Systemarchitekturpläne
  • Liste der Anforderungen zu den Prozessen
  • Liste der funktionalen Design-Entscheidungen
  • Liste der technischen Design-Entscheidungen
  • Dokumentation der Anpassungen (Customizations)
  • Dokumentation der Entwicklungen (Developments) und Schnittstellen
  • Entitätenmodell der Daten
  • Testfälle und Testketten
  • Protokollierung der Testdurchführung und deren Ergebnisse
  • Dokumentation der Konfigurationen (Parameter)
  • Protokollierung der Softwarereleases mit genauer Liste der Anpassungen
  • Dokumentation der Probleme (Issues) und Vorschläge zu deren Lösung
  • Vorschläge für Änderungen zur Verbesserung des Systems (Change Request Dokumentation)
  • … (denn da fehlt sicher noch etwas)

Warum ist das so (kompliziert)?

Ein Dynamics-Projekt durchläuft typischerweise folgende Phasen:Wer hat das entschieden? Wo steht das? – Dokumentation von Dynamics-SystemenEs ist also bereits am Beginn zu entscheiden, wie die Ergebnisse der Phasen verzahnt werden können. Wird eine Anforderung definiert, so soll später die Umsetzung der Anforderung in der Entwicklung und in dem produktiven System mit dieser verknüpft sein. Wird eine Veränderung des Systems gewünscht, weil ein Geschäftsprozess verändert werden soll, so muss ersichtlich sein, welche Systemkomponenten von der Veränderung betroffen sind. Also muss bereits in der Definition der Anforderungen auf die Einhaltung folgender Kriterien großen Wert gelegt werden.

Was sind Kriterien an die Dokumentation von Anforderungen?

Folgende Kriterien sollten erfüllt werden:

  • Für jede Anforderung gibt es einen Schlüssel
  • Eine Anforderung ist einzigartig
  • Jede Anforderung ist mit mindestens einem Prozess verknüpft
  • Die Anforderung widerspricht sich nicht mit anderen Anforderungen
  • Eine Anforderung ist objektiv (im Gegensatz zu subjektiv), präzise beschrieben (im Gegensatz zu vage) und das Ergebnis ist messbar oder erkennbar.
  • Was ist der Auslöser? Welche Voraussetzung muss gegeben sein?
  • Welche Daten werden als Eingabe benötigt?
  • Was genau ist die Aktivität, die durchgeführt werden soll?
  • Was ist ein (mögliches) Ergebnis? Woran erkennt man, dass die Anforderung erfüllt ist?
  • Wie soll das Ergebnis abgelegt oder weiterverarbeitet werden?
  • Eine Anforderung kann durch einen Test verifiziert werden

Um die Dokumentation der Anforderungen in der Zukunft und in der Umsetzung des Projektes sinnvoll zu nutzen, sollten diese

  • In einer durchgängigen Struktur dokumentiert werden
  • Mit den Prozessen verknüpft werden
  • Die Möglichkeit bieten, mit anderen Anforderungen verknüpft zu werden
  • Die Möglichkeit bieten, sich auf andere Dokumente oder Objekte zu beziehen

Wie das ermöglicht werden kann, werden wir in einem folgenden Beitrag erläutern … Stay tuned!

Schreiben Sie einen Kommentar

* Pflichtfeld

Sven Mahn IT bloggt

Dynamics Views ist der Blog von Sven Mahn IT. Die Mitglieder unseres Führungsteams sowie einige unserer erfahrenen Berater und Entwickler möchten hier ihre Einblicke, Erkenntnisse und Meinungen rund um Microsoft Dynamics AX sowie Dynamics 365 Finance und Supply Chain Management mit Ihnen teilen. Außerdem berichten sie über spannende Neuigkeiten.

Dynamics Views soll Ihnen in regelmäßigen Abständen über unsere Website hinaus fokussierte Informationen und interessante Impulse bieten. Gerne möchten wir dazu mit Ihnen in Dialog treten. Insofern freuen wir uns auf Ihre Besuche und sind gespannt auf Ihre Kommentare!