Various business processes exist in every organization. As we discussed in the article “And let’s talk about control…” every business needs control, but before we talk about control we should define the business processes. The way of describing and documenting the processes can take different forms and depends on the experience of the relevant methodologist, the available software and other technical solutions, as well as on the process type and the persons involved (for example, a process for the manufacturing bolts is very different from the process for payments approval).
The documentation of business process consists of:
- Description and documentation of a typical process
- Documentation of the execution of a concrete initiated (started) process
Why is documenting processes so important?
Describing and documenting of a typical process allows the current organizational knowledge for the process to be depicted in a document, the process to be analyzed and all inaccuracies to be removed. The next step is a process version, which is approved for application in the company, all involved persons are informed, so that the concrete process is performed in one and the same standardized way by each employee. In addition, when the process must be implemented (in software, for example), the description will serve as basis for the software implementer for a successful implementation.
Documenting the execution of the concrete initiated process is a very important element, which allows control over the system. For example, the scheduled audits will seek and review relevant documents and evidence for the performance process way and will compare these with the typical (template) process.
Description and documentation of a typical (template) process
The Business Process Model and Notation (BPMN) Standard was published in 2004. It describes in details the process elements, the way of their visualization and the relations between them. A programming language (BPEL) was also created, through which the business description of a typical process could be executed by a computer, as BPMN and BPEL eventually aimed to allow non-programmers (e.g. methodologists, managers) to moderate a business processes themselves via an appropriate software application without using programmers and implementers. I think that all above are great efforts of dedicated teams of experts which are practically wasted. Although BPMN provides a good idea about the process structure, it is generally too heavy to be implemented in its full scope and, at the same time, it is not exhaustive, while BPEL cannot compete with any serious programming language. I have examined various BPM software, which claim that non-programmer can develop and create a process with the help of a BPM designer (an application to the BPM software for graphical modeling of processes) and I think that a serious model which meets the real needs of the company cannot be created without involving a programmer. This is due to the fact that processes are as diverse as life itself and at this stage a BPM software (either based on a standard or not) cannot describe everything. On the other hand, programming process can completely describe everything, but non-programmers just cannot do it.
In my practice, I use a small part of BPMN for business processes description and none of BPEL. I have replaced BPEL with PHP and Java Script in all my web applications.
At the beginning, the processes are usually described in documents, called “procedures”. The procedures include one or more processes with similar characteristics. The methodologist decided which processes shall be included in one procedure.
The general rules for the processes implementation are specified in the procedure, as well as specific rules can be identified for each concrete process. Determining the moment of the process initiation is an important element. The process can start as of a certain date (for example, every Tuesday – in this case, we know exactly when it will be started), as well as upon occurrence of a given event (for example, when a customer files a complaint – in this case we do not know exactly when it will start, it is necessary to “catch” the event, when it occurs).
Depending on the available technical solutions in the company, the process can be initiated manually or automatically. Process initiation can also be set with pre-defined repetition (applicable for processes which start as a certain date – for example, every third day of the month).
Each process consist of various stages (we can call these “tasks”). Each task consists of a group of various tasks (a task usually consists various tasks, where the the responsible person and the timeframes match) and should answer the following questions:
- Who – who is the person, performing the task. Performers are usually described by roles, because different positions might need to have a certain role in a task, thus the disadvantages of describing various departments and positions are easily avoided. One or more persons simultaneously can be set as responsible for a given task. In case of a more complex corporate structure, for example several working sites are available, for which the process is launched separately, despite that the performer (role) is the same, the entity is an additional criterion for determining of who the task should be assigned to (e.g. a process for a sale of goods, performed separately in each of the eight stores). If the process is implemented in software, certain tasks might be performed by the software separately and automatically (e.g., it can copy information from one place to another or send an email or message, start another process, etc.).
- What – this is the essence of the task. I.e. the task details are described here. The methodologist should decide how detailed the description should be (as I am sometimes joking, the description can be even “… I inhale, grab a pencil, exhale, move my hand to the notebook, inhale, begin to write the first letter, exhale again …” although such a description makes no sense, of course). In my opinion how detailed the task description should be depends on the knowledge level in the company on the relevant problem which needs to be solved. If I consider the described activities as common, the description is usually more general, otherwise – if activities are uncommon – the description is more detailed. The task aims to correctly navigate the performer. I sometimes use another approach: for example, when the process is implemented into a software system, instead of presenting detailed information I only indicate what should be done, and the rest is “hidden” behind an info-button, which (when pressed) leads to presenting the more detailed information. Thus, an experienced employee does not need to go through unnecessary detailed texts, but a less experienced one still has the opportunity to review the requested way of performing the task. Since a given task might include various performance routes, a software implementation can allow that texts and performance routes are not presented, so that the concrete performer is not burdened with unnecessary information.
- Where –it indicates the space, where the task shall be performed.
- When – start and end date for completing the task, as well as the occurrence conditions (i.e. on what date, upon occurrence of what event, whether other task should be completed, in case of what result from completion of other tasks, etc.).
Each organization has to decide in which processes the group of tasks which are performed within the organizational structure should be included. Sometimes I start with a process and it turns out that it is practically better to split the process into two separate ones, as the second process starts only when the first one is completed, but under certain conditions.
Any change in the process is documented by a new version. The company must have a clear policy what happens to already running processes with a new version – whether these shall continue according to the previous or the new version. My usual policy is that running processes are to be completed according to the old version, but I assume that this might not be correct in certain systems and processes.
Processes can be further supported with Instructions and similar documents, which usually cover specific cases.
Implementation of business process
Implementation of a process presents concrete adjustments of the system, so that it can work with the process. Within a given company different process groups can be implemented in various ways. For instance, administrative and management processes can be implemented in a software system, which assigns tasks (for sending an offer, for payment approval, for contract review, etc.) or a system where business rules are adapted, so that the software leads the employee through the correct steps without explicitly assigning tasks (e.g. goods cannot leave the warehouse if not paid and stock receipt is issued; an invoice cannot be issued unless a delivery confirmation from customer is received or a supplier invoice cannot be processed, unless the goods were received in the warehouse, which is verified via an explicit entry by the responsible person in the ERP system). Production processes can be implemented both via graphical description of the production cycle, which refers to the respective performer and detail, as well as via specific technical adjustments and equipment. Paper and electronic check lists, web forms, email messages (I do not recommend emails for this), initiating tasks and other similar options can be used for implementing a process.
Software and technical implementations significantly accelerate the process performance, reduce information duplication, accelerate on-time information of the responsible employees for the progress stages, reduce errors (using different models for the validation of the information) and generally increase significantly the quality of the process performance, which directly leads to goods and services of higher quality and more satisfied customers and employees.
Documenting performance of a concrete initiated process
Following initiation of a specific process, completion of each task leads to a documentary trace of the progress of the process.
As already mentioned above, depending on the methodologist experience, hardware and software systems at the company, as well as the process type, documenting can be accomplished in various ways.
For example, if the process is not implemented in a software system, the company can use paper checklists. If the process does not suggest checklists, the company can present it graphically or as a text to the responsible individuals and require that they know and conform to it. In the first case, each step in the process is covered by a checklist and the performer is practically supported by it during the process performance, while in the second case, the performer does not possess with a current explicit document through which the process is performed and can use the methodology described in a relevant procedure.
In case of software implementation, checklists can be replaced by a web form or other, where the performer fills in the results of the performance and which indicates what needs to be done next. If the web form is not a suitable approach for the relevant process, the latter can be implemented in the respective ERP or other system and the system itself leads the performer through the way established during the implementation (e.g. for a “sale of goods” process, the ERP system requires issuance of a stock receipt, processing payment and following issuance of an invoice and sending via email).
Regardless of the documenting approach of the performance it is necessary to have a “trace” which indicates how each specifically initiated process was completed. A “trace” means any documents, records and other information which are generated during the process performance. “Traces” are checklists, issued invoices and stock receipt, offers and contracts, acceptance protocols for delivered goods or performed services, records made in relevant registers, issued orders, approved orders, and any other thousands of variations of documents and information, which can serve as proofs of process performance and completion.