zaterdag 11 juni 2016

BPM

Why do we do business process modelling (BPM)? What is Business Process design? Why do we gather requirements? How does BPM relate to requirements gathering? How does BPM relate to agile environments? What is the role of requirements in agile development? These are the questions I have been asking myself over the pas few months, and I intend to do a series of posts on these questions on this blog.

Let’s start with the question:
What is business process modelling (BPM)? Why do we do it?

What is Business Process Modelling?
Let’s start with three definitions:
Definitions:
(Business) Process design is the activity of determining the workflow, equipment needs, and implementation requirements for a particular process. Process design typically uses a number of tools including flowcharting, process simulation software, and scale models.

What is a business process?
A business process is a set of logically related business activities that combine to deliver something of value (e.g. products, goods, services or information) to a
customer.

Business process modeling (BPM) in systems engineering is the activity of representing processes of an enterprise, so that the current process may be analyzed or improved

These three definitions, divers as they are, do cover most or all of the aspects of BPM. A business process is a set of related activities that combine to deliver something of value.

Business Process Modelling is the art of describing processes in such a way that all stakeholders understand the entire process. It is not uncommon that, when a process is being modeled for the first time, some participants understand the process for the first time.

Now why do we do it?
(1) Historically, organization charts were drawn, and responsibilities were assigned to the managers of the various departments.
For example, a factory could be described by the following chart:
n
Purchase


During the 20th century, people increasingly became aware that this distribution of responsibilities had its limits, as some processes spanned one or more departments. For example, when a company switches to Just-In-Time delivery, the first step might be to sell a product. When the product is sold, Production might be ordered to produce the product, which in turn asks the Purchase department to buy the necessary resources.

But there are more benefits to BPM than spanning departments.
Let’s have a look at an imaginary business process. In a large software firm, customers can hire consultants. It is the task of the account manager to find the right consultant for a temporary job at a customer.


The process consists of a number of steps:
  • The account manager receives a request from a customer for a consultant.
  • The account manager reads the request and elicits the required skills from the request.
  • The account manager is responsible for matching the required skills with the skills of the available consultants. This matching results in 0, 1 or more consultants.
  • The account manager selects a consultant from the list
  • The account manager writes an offer
  • The account manager sends the offer to the customer
  • The account manager introduces the consultant to the customer.
  • After the customer decides to hire the consultant, he returns the signed contract. 
  • The account manager receives it,
  • The consultant start his job.
Why do we do it?
(2) Process modelling is a powerful tool. It gives all stakeholders a view of what happens by whom. Note that roles are applied, not departments, because roles are much more stable than departments. The flowchart listed above is an excellent tool to ask further questions, such as:
  • What do we do if there are no consultants available with all the required skills?
  • What happens when the customer wants to interview several consultants?
  • What do we do if the customer does not return a signed contract?
  • Does the account manager ever has to adapt his offer?
What-if questions like the above are a great way to complete our understanding of what happens. Usually, this results in extra branches. In the following diagram, if he finds 0 matches, he re-evaluates the required skills. Perhaps not all skills are as b=necessary as he thought? Perhaps he misread something? He may also contact the customer for any clarifications as part of this sub-process.



(3) A third benefit is that describing a business process makes it possible to analyze what is happening. How many offers do the account managers write? How many hours do they spend on writing? How many are granted? What process takes most time?

Optimizing a process is an important step before we start automating tasks. For example, it may turn out that a low percentage of the offers we send get accepted, because the offers do not match the customers expectation.
By changing the sequence of the process steps, we can increase our hit rate:


In the above diagram, the consultant is first introduced to the customer, and only if the interview is successful, the account manager writes an offer. An added advantage is that, if during the interview extra conditions are demanded, such as a free first week, the account manager can write them into the offer right away instead of writing a second version later.

So far we have seen three advantages of BPM:
  1. Crossing department borders
  2. Giving all participants an overview of ‘what are we talking about?’
  3. Tool for optimizing a process
And let me stress again that we should optimize a process before we start to develop software to automate sub-processes.

(4) A 4th advantage is that a good business model is a tool to pinpoint problems. We already saw an example in the previous step, where the offers had a low hit rate. The cause of the problem was that the offer was written before all information was complete, it is, before the interview. During the interview, additional information and condition for the interview could surface.

(5) A 5th advantage is that we can simply pinpoint which sub-processes or which activities we want to develop software for.

In our example, we might color the sub-processes:
In the above diagram, the sub-processes “match skills” and “write offer” will be the target of a drive to improve process execution by software development. In other environments, many more sub-processes can be automated. Think, for example, of a web bookstore where both the purchase of books and the sales of books, as well as the payments involved, are automated, with only the shipping and complaint handling remaining as manual operational processes.

(6) A 6th benefit of BPM is as a tool to gather the requirements for an information system. In the example above, for the “match skills” application, the model will lead us to ask questions like:
  • Do we still want the account manager to extract the required skills from the process? (=do we have the right scope?)
  • Are the skills a fixed list, a free list, or a combination of both?
  • How do we gather the skills of all consultants? Do we have already a registration of them? Or should this be a new data collection?
  • Should the “match skills” sub-process take into account if a consultant is available now or in the near future?
  • What exactly is the output of this process step? Just a list, or is there more? What is on this list? Name, skills, availability, current jobs?
  • Should the system support free text search on the resumes of the consultants?
  • And so on

(7) A last benefit of BPM is making sure that we are automating the right processes and elicit the right requirements (https://en.wikipedia.org/wiki/Business_analysis#Document_the_right_requirements). We do this mainly by restructuring and optimizing the process first and automating it later. But the definition of the process steps also helps to define the right requirements. If we know there are two flows entering a process step, we know that we likely have 2 types of input, and will want to specify the information in these flows. It may turn out that we need information which is collected three process steps earlier, and we may want to adapt some of the previous or training process steps.

In the description above, I have deliberately skipped some concepts, such as the distinction between process analysis and process design. Another concept I have skipped is that of detailing processes in sub-processes, process boundaries, iterative analysis, and so on.
In subsequent posts I intend to write more about questions like: How does BPM relate to requirements gathering? How does BPM relate to agile environments? What is the role of requirements in agile development?


Geen opmerkingen:

Een reactie posten