Wenn es um einen bestehenden Prozess geht, der in ein neues System überführt und /oder optimiert werden soll, muss der Ist-Prozess klar formuliert sein. Hierzu gibt es oftmals Dokumentationen, die mehr oder weniger gelebt werden. Daher ist es wichtig, die aktuelle Dokumentation des aktuellen Prozesses aufzunehmen und mit dem gelebten Prozess abzugleichen. Hier habe ich schon oft sehr interessante Abweichungen oder gar komplett andere Prozesse oder Arbeitsweisen erlebt, die um die Definition herumgehen oder ihn ganz aushebeln.
Daher ist es neben dem Einlesen der Dokumentation wichtig, mit dem Anwenderkreis des Prozesses zu sprechen und die Erfahrungen in der Anwendung der Prozesse, also den gelebten Prozess auch zu verstehen. Das ist der echte Ist-Prozess.
Um einen Prozess aufzunehmen, gibt es von Text schreiben hin zu einer sehr komplexen Visualisierungs-Methode wie beispielsweise BPMN (Business Process Modelling Notation), die aus meiner Erfahrung in der vollen Ausbaustufe fast niemand versteht. Daher bin ich über die Jahre auf eine einfache Visualisierung mit kurzer Erläuterung von Prozessen gekommen. Es sind wenige Elemente in der Visualisierung und eine kurze schriftliche Erklärung zu der Visualisierung. (Siehe hierzu meinen Post "Das Prozess Ablaufdiagramm")
Um einen Prozess aufzunehmen, ist das System, in dem es genutzt wird, erst einmal zweitrangig, sie sollten jedoch für später bekannt sein. Die Phasen und deren Schritte eines Prozesses sind ausschlaggebend bei der Ist-Aufnahme.
Die Ist-Rollen, also welche Benutzergruppen es gibt und wie sie die Prozesse nutzen müssen auch beschrieben sein.
Sind die Ist-Prozesse aufgeschrieben (Visualisiert und mit kurzer Beschreibung versehen) können erste Verbesserungsvorschläge aufgenommen werden. Diese können prozessual und funktional sein. Prozessual ist eine abweichende Vorgehensweise und Funktional ist eine andere Handhabung und Anwendung der Schritte. Der Unterschied ist wichtig, weil wir in den nächsten 2 Phasen zuerst den Soll-Prozess Prozessual beschreiben, um damit eine Grundlage für die Software Entscheidung treffen können, die dann ihre Funktionalen Schritte hat und später erst behandelt wird.
Mit der Ist-Aufnahme sollten auch die bestehenden Systeme und die Datenmengen grob aufgenommen sein und alle Beteiligte haben das gleiche Verständnis als Grundlage für den nächsten Schritt, die Definition des "neuen Soll".