Business Process Management (BPM)

As business analysts, we know that a business process model is a crucial technique for transforming a business and redesigning automated business systems. Yet, we struggle with the best way to represent the business rules that guide it. This is not a surprise, but disappointing. Ironically, business rules may be the most important dimension of an enterprise. They are the core of business decisions and actions, whether automated or not. How do we treat them today?

In a process improvement project, the analysis team needs to model and examine several aspects of the current (AS-IS) value chain under study. The purpose of the analysis is to create a visual diagram of the value chain along with its associated text and metrics and determine if there are possible areas of improvement (e.g., reductions in cost or time). If improvements are identified, the team constructs a modified value chain model (TO-BE) with the improvements and then conducts a gap analysis on how to transition to the new value chain. This article focuses on the analysis of the current value chain by providing a method for structuring the AS-IS and TO-BE process improvement discussion.

This article provides the business analyst an analogy on how process owners manage value chains by monitoring leading and lagging metrics. The article highlights the need for business analysts to provide process owners with these metrics. These metrics provide indications of positive and negative process and business risks. Examples of the traditional risk response types of accept, avoid, mitigate, transfer, exploit, enhance, and share are provided.

Last month's column introduced a missing model for business analysts. The Decision Model is a normalized rigorous model for business logic like the Relational Model is for data. "Business logic is simply a set of business rules represented as atomic elements of conditions leading to conclusions. As such, business logic represents business thinking about the way important business decisions are made."

Businesses cope with manual, repetitive tasks to get the job done. Email, conference calls, and "walking the cubes" are too frequently the process for requesting information, getting approvals, and checking project status. Time and resources are wasted, errors abound, and everyone is less productive.

Automating these everyday business processes is the way to improve productivity and gain efficiency. Traditional Business Process Management (BPM) systems can provide a solution, but the cost and complexity to implement simple processes is often too expensive for many business units.
 

Systems work is not as hard as you might think. However, we have a tendency in this business to complicate things by changing the vocabulary of systems work and introducing convoluted concepts and techniques, all of which makes it difficult to produce systems in a consistent manner. Consequently, there is a tendency to reinvent the wheel with each systems development project. I believe I owe it to my predecessors and the industry overall to describe basic systems theory, so that people can find the common ground needed to communicate and work. Fortunately, there are only four easy, yet important, concepts to grasp which I will try to define as succinctly as possible.

Much of the current buzz about SOA has been focussed on the technology (inevitably Web Services) or the importance of reusability. However the real value of SOA is in the improvement to processes and ways of working that reflect the alignment of an organisation with its customers and suppliers.  The approach we favour is one that begins by aligning the business and technical understanding of the concepts of SOA, from both the business process and technical architecture perspective.
 

With current economic conditions, companies are striving to do more with fewer resources, both human and material. So it should be no surprise that the fusion of business processes and practices is both relevant and necessary. Over the past two decades business methodologies and corporate programs have established track records that demonstrate performance and quality improvements within their organizations.

When the first flowcharts were applied to manufacturing processes, they followed the flow of a single part through its manufacture.  They displayed, in sequence, the steps it took to make the part and they made sense.  They were easy to visualize, easy to follow, easy to work with, and they resulted in millions of dollars worth of productivity gain. 

This same concept was applied to information process charting in the 1940’s.  However, rather than following a single flow, multi-flow process charts were used.  They showed all of the records in a business process in order to make clear the exchange of information between records.  Once again the effort generated millions of dollars worth of productivity gain.

A process is a series of steps completed to achieve a particular result. It is hard to imagine a process improvement effort that doesn’t start with a focus on that result with a question like “What is the purpose of this process?” - whether the customer is actually engaged or not. Sometimes we have a strong sense that our product or service is good. Sometimes we choose to “get our own house in order” before we step outside the organization. Sometimes we base the result on a prescription provided by the customer. However, sometimes, our focus may be misdirected to how we do the work without considering why it is done in the first place...particularly where slick new technologies are involved. In any case, without actually engaging the customer, we can’t really know how well the process is working to provide the customer with what the customer needs or wants.

In this SOA article I would like to begin by defining what SOA is and what you need to know about it. In future articles, I will explore some of the challenges and benefits of SOA to the analyst community. Let’s start off with a definition of SOA. You can, of course, look at a number of definitions of SOA on the Web, but you will find them confusing and contradictory as there are a number of views on this ranging from SOA is everything, to SOA is just Web Services, neither of which is true.

Processes are the user interface to a solution – as such they are highly visible and a lot of project effort is focussed on process modelling. In fact, there is a perception in some quarters that Business Analysts just draw process models and this is all they do. However, process models (the drawings of processes) are only one facet of the specification of a process.

Before starting, it is important to understand process mapping’s place in the larger context of business process improvement.  Improving your process typically starts with documenting how it works today, what we call the “as-is” process.

Business-process-modeling technology provides a powerful set of tools for describing and automating processes. The technology is so powerful that it often seems there are no limits to what BPM can do. But not every process that is automated needs BPM. Following on last week's discussion of process discovery, the JargonSpy asks the question: What sort of processes should be automated using BPM?

Businesspeople and technologists alike quickly get drunk on business-process modeling when they first become competent in the technique. Like wikis, business-process modeling allows you to capture the detail that you have in your head and then leave placeholders for what is not yet baked. In wikis, this takes the form of pages of text that link to other pages covering concepts that you will fill in later. Wikipedia is full of links to pages waiting to be completed.

The analogous act in business-process modeling is to put a box in to cover a step ("solve the halting problem" or "find qualified leads") that is part of the process but that you don't want to worry about just then.

Author: Dan Woods

Many people on our Business Analysis workshop ask why we use dataflow diagrams (DFDs). Why not Use Case…or even BPMN? After all DFDs have been around for 20 years, surely the world has moved on?

Well, has it? The primary purpose of a business analyst is to communicate – to stakeholders and to solution providers – and when it comes to communication we all know that pictures (diagrams) are much more effective and less ambiguous than words. Remember the phrase "A picture is worth a thousand words". The question is – which type of diagram best suits our needs? In this article, written by IRM's Training Services Manager Jan Kusiak, we’ll look at using diagrams for stakeholder communications.

Author: Jan Kusiak