BPM: Chess vs. Checkers

BPM: Chess vs. Checkers Jonathon Struthers Introducing the Games Business relies upon IT systems to perform many of its tasks. While many times systems don t really do what the business wants them to do, it is what they have to live with, and because they lack the necessary technical skills to change the system to meet their needs, they are forced into live with the structure in place. But what if the rules were to change? What if we made technical system definitions available in a format that the business can understand and change? Do you want to play checkers? In a traditional technology based software implementation it is standard to get business requirements, convert them to technical requirements and then pass those technical requirements to a developer who deals with the technical implementation of the system described. In so doing we remove the direct input of business users in favor of the direct input of technical/business hybrid people who can interpret the business language and translate it into technical speak. This means that to the business (end users of the system) all the pieces of the system look the same. They may see shades of difference in the parts of the system which deliver different parts of their requirements, but at no point do they control the shape of the system or how they move. Effectively every part of the system is as important as each other because they all deliver on technical requirements. And the hope is that the combined effect of those technical requirements is that the business requirements are delivered. All things have a familiar process in which they are able to develop across the board, and once a piece has reached the end of the board it is considered mature and protected as one of the more valuable pieces on the board. Let s play chess instead! Business Process Management (BPM) seeks to change the rules of the game. It effectively sets up the business requirements to be king of the board; the thing which everything else exists to protect and serve. The biggest difference between the traditional view of converting business requirements into technical terms is that now we have made the business a key player in the system rather than telling it to sit on the sidelines. Instantly the aim of the game changes, instead of simply trying to use our pieces to win the game through dominance of the board, we add a layer of strategy where dominance of the board must be achieved. However, we also need to consider keeping our king safe because if he is not supported it is game over. It is important to note at this point that, the field of BPM is much broader than just those instances which use a BPMS in order to deliver the process management initiative required. However, readers should be aware that this paper focuses on the creation of a BPM initiative through the use of a Business Process Management System (BPMS). Introducing the pieces If the king (business) is the most important piece on the board, it is acceptable to consider any chess game as if it were coordinating the movement of every other piece in order to achieve its end game. We can therefore think of the king as a set of business goals, but by themselves they are unable to win the game. However, they provide the strategy and a foundation for all the other pieces to move around the board. A piece can t move if doing so would place the king in danger, and likewise if the king is in danger either its position will change or another piece will come to its rescue. Let s look at the other pieces on the board. We will consider the two kings on the board (although will ignore all other enemy pieces), with the friendly king being the elements of our business we must protect (revenue targets etc.), and the enemy king being the goal we are trying 1

to achieve (deliver a widget etc.). I will suggest that our king provides the B usiness, the other pieces on the board form our P rocess, and the overall game strategy is our M anagement. The queen The queen on a chess board is the most powerful unit simply because it can move in all directions. This flexibility however also makes it a unit that is typically used with reserve and remains well supported and protected by other units. In our analogy, if the business goals are king, then the business process is our queen. A queen will always start with the king, but once the game commences the queen can travel to any square on the board and can react with the flexibility necessary to both attack the enemy king and protect her own king. Rooks and bishops The rook and bishop assume the role of subprocesses. They have a great deal of mobility and are capable pieces, but they do not have the mobility of the queen. Each one provides a vital role in the strategy, and when the movement capabilities of these pieces are combined, the net effect is that their movement capability matches that of the queen. They are capable of achieving a part of what the queen can deliver, and along with the knight are used as the cutting edge of an offensive. Just as a bishop s movement is a sub-set of that allowed by the queen, so is a subprocess a sub-set of the business process in general, defined and executed in business terms to fulfill a business need. Each will move where and when needed to support the king or attack the enemy king. Knights A knight can move unlike any other on the board, and can disregard rules that restrict other pieces. Specifically, it can jump other pieces, thus making it a vital part of any strategy. However, it lacks the speed with which other backline pieces are capable of moving. The humble knight on our board represents the human element in the process, capable of doing things that a piece of software cannot, but simultaneously incapable of performing tasks with the same speed, precision and repetition of software. The pawn In a game of chess the pawn is the workhorse, the front line. They are a vital part of any game and often are the first point of contact. They are also the most expendable pieces. In the BPMS world our technical components are the pawns of the game, they exist to provide support. A good player however, will know where the pawns need to be positioned to help achieve the strategy; and they will also know when it is necessary to sacrifice a pawn in order to enable greater freedom for the other pieces on the board. Most players will concede that while pawns are vital to the game and form an integral part of strategy, they are the least important pieces on the board and one can not win the game simply by moving pawns around the board. That s not how you play Now that we have identified and defined the roles of the pieces in our game, I will discuss some of the challenges which new players (and some old players) will confront that have the potential to impede their ability to play the game properly. I don t get this game One of the biggest problems that a new BPMS project may face (particularly in a company that is not mature with the technology) is the tendency not to understand the game before they start moving the pieces around. We have got a new board with new pieces. The board that we see looks remarkably like a checkers board causing us to assume that checkers rules will apply. Thus a project is created, and the same old methodologies are used in order to scope, estimate, 2

manage and develop a system based on the new BPMS technology, while inadvertently neglecting to actually implement a Business Process Management initiative alongside. The result is that although players think they are playing BPM, by applying the old rules they are restricting pieces from moving how they were designed to move in the new game. One of the most damaging results of applying checkers rules to a chess game is that the potential benefits that chess offers are lost and expectations of a game change are not realized. Ultimately, the participants think that despite their efforts to implement a BPM initiative, there s little difference in outcome between the old and the new. The game simply proves more complicated than the original that we understood, and so we label BPM as a failed experiment and revert to checkers. I understand the pawn, just give me a bunch of pawns Another result of applying the rules of checkers is that, as the most familiar piece on the board, the pawn is looked to to solve problems that other pieces are more capable of addressing. Thus the potential for flexibility and power by the queen, the bishop and the knight are ignored, and the pawns are sent to attack the enemy king. Such a board looks much more comfortable to technical resources. Conversely, when business resources look at the board, they can t identify any pieces capable of achieving their needs, so they resort to asking the technical resources to make things happen. This is the game that is typically played when technical resources are asked to sort out a BPMS solution, but it is a game played to the detriment of the king as he loses the most powerful pieces on the board. Wow I can move! Another potential pitfall can occur when a business plans their game strategy, and the newly found mobility of some pieces becomes a novelty that they enjoy. In this case moves are not well planned but instead opportunities are wasted on frivolous moves that don t provide a winning strategy. Good chess players will tell you that they are not only playing the current move but are always plotting at least a few moves in advance. No move is ever made without thinking of the implications on other pieces on the board. Good chess players will envision a simulation of the game before making a decision on what move should be made. In contrast to the above scenario, a good BPMS implementation will include a tool kit that will provide simulation, process metrics and other information that will facilitate effective management of not only our current state, but our future state as well. We can identify where we want the pieces to be and formulate a step by step plan to get them there. To simply make a change without ensuring that it takes us in the right direction is foolhardy and risks game failure. But I liked some checkers rules Mature software development teams will have some standard practices which they use in order to develop their systems. The old way of scoping a change probably involved gathering business requirements and converting them to technical requirements. This approach is comfortable because it s familiar. The new game, however, does not involve the same components, nonetheless we try to work them in thus restricting pieces and limiting their usefulness in the new game. When the bishop must follow the rules of checkers, he is, in effect, being treated like a pawn that can move diagonally. While there are some benefits to employing traditional coding reviews, testing cycles, etc. when writing a system using traditional programming languages, the benefit of these standard practices is not as clear when we start working with a BPMS. It is true that rigor still needs to be applied, but where technical reviews were once performed we should consider business reviews as an alternative. Where unit tests were performed, we now might want to replace them with process simulation techniques. So what does BPM Offer to Change the Game? Traditional IT systems are just that IT systems. There may be a layer of business analysis and requirements-gathering performed, but at the end of it all everything that makes it into the final 3

system must first be converted into technical speak whether it be a UML diagram or a BA requirements report, or even just cutting code based on what a customer says. A BPMS offers the chance to step away from technical speak. It is in essence a business system in business speak by people who understand the business needs. There is no need to convert what the business has said because the technical layer has been designed to operate in a more business friendly manner through execution of business processes. Imagine a system in which all the business requirements remain undiluted or polluted by a technical resource. Imagine a system in which the technical resources know exactly what you mean, because you have handed them the structure of the system that they will implement. Imagine if, without any special technical training, you were able to design your own IT system and then tell IT to get it running with the design you provided. Getting you the exact system you wanted. This is what BPM through a BPMS offers. Business have direct control At the core of a BPMS is the goal to provide a process model that business people can understand, and then allow that model to run. If business people can understand the model, then business people are capable of writing the model too! Specifically, you write the process for your business much like a standard flowchart, and then the BPMS interprets and runs that process model according to your specifications. For some changes, you will need to include a technical resource to handle some of the integration with legacy systems, but you can control and define most of what is running in the system as long as you understand how to write a process map of what you do and tell the system what information is used and captured at any given step. Changes happen quicker A BPMS aims to remove the need to translate from business to technical speak. In making changes to a traditional system, much time is spent in requirements-gathering and testing cycles. Typically, to produce a system traditionally the business determines what is needed then conveys that information to a Business Analyst (BA) (often using a business requirements document), and the BA acts as a translator between the business and the coders. The BA then produces a technical requirements document and gives that document to a technical resource. In situations requiring a large change, an Architect takes the technical requirements and creates a system architecture which is then passed on to a developer to produce a design for the components. The developer designs the code changes and codes them. That done, the developer will perform unit testing and pass the changes on to the BA for further testing. Once the BA approves it, it is sent to the customer who will perform UAT on the changes. It is only at this juncture that the business actually knows if the changes made are what they really needed. A good BPMS change however will proceed differently. The business determines what changes are needed and adjusts the process model, either with or without the BA s help. This process is then either simulated to see if further changes are required or run verbatim. If the process requires developer input, the developers work with the process model the business provided and then pass it back to the business. Because the business has made a direct change to the system code without the other layers of translation, the changes made are more robust and accurate in delivering the business requirements and far quicker and less costly to implement. There is clear visibility of what is happening A key component of a BPMS is the ability to provide business dashboards. The dashboards can provide metrics on the way the processes are running. Since the processes are directly implemented as the business defines them, it follows that those dashboards would be reporting on the business process that is actually being performed by the business. If in that process the business highlights the key things they want to know, how long does it take to put part A in widget B?, how long do I wait for an order of part A from suppliers?, what are the volumes of 4

widgets my customers are ordering compared to my production?, what teams are over utilized?, what teams are over staffed?, then the dashboard will be able to answer them in real time, allowing for process improvements or organizational decisions to be made from a position that is accurately and timely informed for the choice at hand. People components can be modeled Just because an item appears on the business process model doesn t mean that it has a technical implementation behind it. Often with traditional systems the IT components are coded up and given an interface to the people who work with them. The use of the system is then guided through a series of user manuals and user interfaces that were created for the system. There is no clear visibility of exactly how the users and the system are meant to work together in order to achieve the end result. In a BPMS the users form an intricate part of the system. Not only is their place in the system well defined and modeled according to the business requirements, but the work they do is seen and captured as any other part of the process would be. This results in better visibility of what people are actually doing in the system, clearer tracking of exceptional performance by employees, and the ability to seamlessly perform human tasks and system tasks in the process, incorporating the benefits of either human resources where appropriate without losing the structure of a well defined process. This means that instead of business process being built around an IT system (and often changed to cater to weaknesses in the IT solution) the business process becomes the system and IT falls into place and supports it. Conclusion BPM is a powerful tool for businesses that will allow unparalleled alignment of technical systems with business requirements. But in order to realize the benefits of the technology we also have to change the rules of the game that we are playing, if we continue to use traditional software development approaches to craft BPMS based solutions we will not realize the potential that the technology set (and associated BPM discipline) offers. ------- Author Jon is a BPM Consultant currently working for Princeton Blue, he has 6 years industry experience and a background of academic research in the Business Process Management field. Jon has helped shape the BPM practices of a multi-national IT Service Provider through innovation and a readiness to challenge the norms, as well as suggest innovative ways to approach solutions and solve problems. Bringing a firm understanding of theoretical process management concepts, alongside a strong technical skillset he ensures that strong business results are delivered, without sacrificing a solid technical implementation. Striving for perfection in both the technical and business domain. BPTrends Linkedin Discussion Group We recently created a BPTrends Discussion Group on Linkedin to allow our members, readers and friends to freely exchange ideas on a wide variety of BPM related topics. We encourage you to initiate a new discussion on this publication or on other BPM related topics of interest to you, or to contribute to existing discussions. Go to Linkedin and join the BPTrends Discussion Group. 5