Beschreibung
Wie soll der zukünftige Prozess aussehen, mit dem gearbeitet werden soll. Hier ist der Hauptfokus auf dem, wie zukünftig gearbeitet werden soll, relevant. Genauso wichtig ist aber auch die Herkunft. Wie wird der Prozess aktuell gelebt und welche Veränderung ist geplant?
Das kann folgende Herangehensweise bedeuten:
Den Prozess und die Arbeitsweise gab es vorher nicht, und es wird eine neue Arbeitsweise hinzugenommen.
Es war zwar nicht allen klar, aber der Prozess wird schon gelebt.
Der Prozess wird gelebt und soll optimiert werden.
Der Prozess darf nicht verändert, aber in einer neuen Software realisiert werden.
Hieraus ergibt sich in jedem Fall eine Formulierung des Soll und ein Bezug zu dem IST der bisherigen Arbeitsweise.
Es bietet sich an, den Soll-Prozess erst mal neu zu visualisieren und dann den Bezug zu dem IST herzustellen, um die Veränderung für den Ablauf und die Menschen, die damit zukünftig arbeiten sollen, zu identifizieren. Zudem lässt sich aus der Liste der Veränderungen auch ableiten, welche Vorteile der neue Prozess mit sich bringt. Das können Arbeitserleichterungen im Ablauf oder medienbruchreduzierte Schritte sein, aber auch neue oder veränderte Zuständigkeiten.
Daher sollten die zukünftigen Rollen mit ihren Verantwortungen in der Soll-Definition klar formuliert werden. Wenn die Rollen, die auf Menschen später angewendet werden, noch nicht klar sind, kann es Auswirkungen auf den Prozess haben. Ein Angebot wurde zum Beispiel bisher vom Aussendienst aufgenommen und vom Innendient erstellt. Jetzt hat der Aussendienst die Möglichkeit, mit einfachen Klicks ein Angebot selbst zu erstellen. Hier baucht es den Innendienst dann für diese Schritte nicht mehr und der Innendienst kann sich auf andere Themen konzentrieren.
Aus dieser Ablaufbeschreibung mit Verantwortungen der Schritte pro Rolle heraus lassen sich Use Cases Test-Cases und daraus User Stories für die neuen o der überarbeiteten Prozesse ableiten.
Eine Standardsoftware hat oft schon vorgefertigte Lösungen, die hier initial identifiziert und geplant werden kann. Daher kann aus den neuen Prozessen eine Zielarchitektur initial erstellt werden, die aber in der nächsten Phase überprüft und weiter konkretisiert werden muss.
Bei der Soll-Prozess-Beschreibung sollte Folgendes berücksichtigt werden:
Wenn es schon immer so war, warum braucht es das zukünftig auch? Über lange Zeit gelebte Arbeitsweisen sind oft so stark in den Köpfen, dass sie gar nicht infrage gestellt werden. Es ist eine Frage der Ziele, ob sie angepasst werden sollen. Wenn dem so ist, muss jeder Arbeitsschritt hinterfragt werden. Das kann dazu führen, dass Schritte nicht mehr benötigt werden, wenn eine andere Herangehensweise gewählt wird. Das wiederum kann zur Folge haben, dass die aktuellen Ausführenden der Schritte weniger zu tun haben mit allen seinen Auswirkungen. Das heisst, es sensibel und offen anzugehen.
Braucht es das „Detail“ oder die Herangehensweise wirklich, sollte auch immer stark hinterfragt werden. Bei einer Prozessmodellierung kommen sehr schnell Anregungen und Wünsche, das ist auch gewollt. Ziel eines Prozesses ist aber die optimale Beschreibung und nicht jede Besonderheit.
Das Vorgehen sollte nicht zu komplex werden. Ein Soll-Prozess sollte auch von nicht in der Besprechung beteiligten Personen einfach gelesen werden können. Wenn es viele Abzweigungen gibt, sollten die Prozesse besser in mehrere Bilder mit den Anwendungsfällen aufgeteilt werden.
Sind die Soll-Prozesse aufgenommen, können aus der IST-Aufnahme die prozessualen Verbesserungsvorschläge gegengeprüft werden, ob sie schon formuliert wurden oder jetzt eingebunden werden, oder ob sie doch nicht mehr so richtig in den neuen Prozess passen.
Die Ziele und der Scope sollten abschliessend auch gegengeprüft werden, ob das Ergebnis diesen entspricht oder ob sie zurück an die höhere Instanz zurückgegeben werden müssen, zur eventuellen Anpassung.
Auf LinkedIn vernetzen
Auf Xing vernetzen
