Business process documentation

As a first step, it is important to record the business process as it is currently "lived", i.e. as it is actually carried out - even if this does not correspond exactly to the specifications or contains abbreviations or duplicate work. Map the process with those involved in carrying it out. You can start with the employees involved in your department, but don't forget those involved from other departments.

This is not yet about a detailed process model, but about the rough sequence of process steps. Possible guiding questions could be

• When or by what exactly is the process started - e. g. by an enquiry, the receipt of a form, the announcement of a decision?
• Organisational transitions are suitable for structuring a process: Does the processor or the processing unit change? Is the location changed? Are special systems used for one step or is there a switch between them?
• What information is required in each case and how does it enter the process? Examples could be: via a form, via enquiries, via own research, from SAP or a database.
• What is the output of the process? What is the goal of the process, if applicable? What forms, information, documents are produced as a result of the process? What happens to this information?
• If there is confusion in your group about certain points or if there is disagreement about where one step ends or the next begins - make a note of this, as this can be an indication of points of friction that can be improved.
• After recording your perspective of the process, also consider how it might look from the point of view of other parties involved in the process (e.g. Offices of the Dean, chairs or students). If it makes sense and is possible, you should obtain information from these process participants.

To document the actual process, we recommend that you organise a workshop with those involved. The individual process steps can be noted down on Post-It notes for illustration purposes - initially by each workshop participant individually, then collated as a group. In this way, the "quieter" employees can also contribute their views, while the common process model is worked out in the group phase. The sticky notes can be stuck up and down on a table or a metaplan wall and thus visually support the discussion of process variants.

Almost every process has different variants (also known as branches). Concentrate on the common cases first (approx. 70-80% of your cases are sufficient). Make a note of the individual variants of your employees if they seem relevant to you - but avoid getting lost in individual details. The result should be a process description of the actual process for your unit or department.

In some cases, a survey of the processes by interviewing individuals is more effective than a workshop. This eliminates group pressure and the possible fear of having to justify your own process implementation or being corrected by others in front of the group.

Before an individual interview, think about what the role of the interviewee is, which topics you want to focus on and in which order you want to work through your topics. Make it clear what your role is towards the interviewee and to what extent he or she can trust that the answers they give will not harm them. Be honest and open about your intentions. If necessary, grant anonymity and record the interviewee's answers without doubt. But also be aware of his or her view of the process.

Process interviews can take place in writing, by telephone/digital or face to face. We recommend that you pre-structure the interview with key questions to ensure that all intended topics are addressed. However, also leave room for additional aspects. Open questions (How? Which? Why?) encourage more detailed answers than closed yes/no questions. In special cases, however, a questionnaire with predefined answer options may also be suitable, e.g. if you want to record the frequency of certain process variants or problems.

You can obtain further information by researching other sources - What specifications are there for the process in question? What is known or documented about case numbers, problems and solution approaches, complaints? Look at a sample of process-relevant files or documents.

Another method is (participatory) observation of the process, i.e. simply going through the process with those involved and asking questions: Why are you writing this down? What do you learn from it? Who is reading this information? Why are you entering this? etc. However, it is important to have a rough overall understanding of the process beforehand, otherwise you will quickly lose the overview in this "ant's-eye view".