Your SlideShare is downloading. ×

Trends In Bpm Site


Published on

BPM – Business Process Management - is a discipline that attracts a lot of interest. Probably even more nowadays, because of the economic turmoil... By placing business processes on centre stage, …

BPM – Business Process Management - is a discipline that attracts a lot of interest. Probably even more nowadays, because of the economic turmoil... By placing business processes on centre stage, companies can gain the capabilities they need to innovate, reenergize performance and deliver the value today’s markets demand. An enterprise where BPM is really implemented as a management discipline can make agile course corrections, embeds continuous improvement methods and reduces cumulative costs across the value chain. BPM supports the pursuit of today’s strategic initiatives, including mergers, consolidation, alliances, acquisitions, outsourcing and global expansion.
BPM discovers what you do and then manages the lifecycle of improvement and optimisation, in a way that translates directly to daily operation.
In a collaboration of Capgemini Technology and Capgemini Consulting the publication “Trends in BPM” is a collection of state-of-the-art trends Capgemini’s experts see in the BPM discipline. It includes topics like Lean, Human Centric Processes, process design for agility and Business Activity Monitoring.

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Consulting the way we see it Trends in BPM Eight state-of-the-art trends within the Business Process Management working field.
  • 2. | the way we see it Trends in BPM Name author(s): Hans Toebak Frank van den Ende Company name: Capgemini N.V. Place: Utrecht Date: August 2009 © 2009 Capgemini. No part of this document may be modified, deleted or expanded by any process or means without prior written approval from Capgemini
  • 3. | the way we see it Preface Almost five years ago, some colleagues wrote the booklet „Business Process 1 Management: Introduction to the working field and supporting tools‟. The demand and enthusiasm for this booklet slightly surprised us, but emphasized our belief that Business Process Management (BPM) is a discipline that attracts a lot of interest. Probably even more nowadays, because of the economic turmoil... Encouraged by this success we decided to produce a sequel. The focus of this new publication is on state-of-the-art trends we see in the BPM discipline. Why this as the focus? In my opinion, by placing business processes on centre stage, companies can gain the capabilities they need to innovate, reenergize performance and deliver the value today‟s markets demand. An enterprise where BPM is really implemented as a management discipline can make agile course corrections, embeds continuous improvement methods and reduces cumulative costs across the value chain. BPM supports the pursuit of today‟s strategic initiatives, including mergers, consolidation, alliances, acquisitions, outsourcing and global expansion. BPM discovers what you do and then manages the lifecycle of improvement and optimisation, in a way that translates directly to daily operation. Whether you wish to adopt industry best practices for efficiency or pursue competitive differentiation, you will need BPM. Although this is primarily a book for business people, we do not shy away from technology topics, because the management of a company's business processes is inseparably about both business and technology. I hope that you will profit from the ideas and information we present, and your company will profit from your new ideas and inspiration... Finally, I gratefully acknowledge many colleagues who shaped, supported and otherwise contributed to this book, particularly Hans Toebak and Frank van den Ende, as the driving forces. René Roest, Head FS Consulting Europe & NL, Global Head Business Analysis. Utrecht, August 2009 1 ISBN 90-75498-72-1 ii
  • 4. | the way we see it Table of Contents 1 Introduction 1 2 Trends 2 2.1 Process design for agility 2 2.2 Tooling 8 ® 2.3 BeLean , an approach to deliver results that last 15 2.4 BPM as key element in alignment of business and technology 20 2.5 BPM as crucial factor for outsourcing IT development 30 2.6 Process change on (big) wheels 41 2.7 Human Centric Processes – the next challenge for BPM 44 2.8 BPM and training 58 3 Point of View 63 3.1 Introduction 63 3.2 BPM as management discipline 63 3.3 BPM Maturity 64 3.4 BPM Infrastructure 65 3.5 Where is BPM heading to? 67 3.6 Recapitulation 70 iii
  • 5. | the way we see it 1 Introduction As the name of this publication indicates, in this booklet an overview is given of trends we at Capgemini distinguish within the Business Process Management 2 (BPM) working field. These trends have been deducted from several surveys, researches and daily observations:  Results of Dutch BPM Survey performed by Capgemini & Hogeschool Utrecht in 2008 (Business Process Management in the Netherlands).[1]  Indications by international research and advisory companies.  Developments we see daily at our customers. We as editors realise that this list is never ending and never complete. However, we think that the trends included represent a current market view and will be recognisable for BPM professionals and managers. For all trends stated underneath, a separate paragraph is provided within the next chapter: Trend 1. Process design for agility Processes cannot – as done in the past – be designed to last for ages. They have to be agile in order to enable an organisation to adjust quickly (agile) to changing circumstances, new products etc. In other words: agility needs to be one of the key considerations in designing processes (including the supporting IT). Trend 2. Tooling One can roughly distinguish a limited number of directions the BPM tooling is developing into. What are those directions, why is this development there? To mention one example - Common BPM (drawing) tools versus BPM Suites. Another distinction that can be made is between tools that offer one stop shopping versus niche-tools. But do the clients need all these features and are they willing to pay? Trend 3. BeLean®, an approach to deliver results that last Companies are under constant pressure to deliver exceptional customer experiences alongside maximum efficiency. Customers rightly expect everything to be cheaper, faster and better; organisations therefore need to use all the means at their disposal to become more customer focused and at the same time leaner. What we see is that organisations now have a strong interest in proven process improvement methodologies like Lean. 2 BPM is a management discipline that requires and enables organizations to manage - plan, change and act - the complete revision cycles of their business processes, from process design to monitoring (measurement) and continuous optimization. 1
  • 6. | the way we see it Trend 4. BPM as key element of a holistic approach to successful alignment of business and technology The continuous struggle for power between business and technology may be compared to a dancing couple where both want to be in the lead. Consequently, both dance partners are not in sync and often stumble or even fall. The solution could be to evaluate per dance style who has more experience and thus should guide their combined skills into the excellent performance both have in mind. Now, if we translate dance style into process type, can Business Process Management be the key element of a holistic approach to successfully align business and technology for an excellent business performance? Trend 5. BPM as crucial factor for outsourcing IT development Terms like Voice of the Customer and Voice of the Business become more and more important. These voices (requirements) will often be recorded at an early stage when a new information system is built. But in fact these requirements are already needed when (re)designing processes: the business process has to deliver in conformity with the requirements. The supporting IT solutions for their part have to be in line. Trend 6. Process change on (big)wheels Organisations have made the first steps in their BPM maturity. For instance, they have their processes documented. One of the next steps can be Business Activity Monitoring (BAM). Being (more) in control of your processes by measuring, analysing and continuous improvement based on real-life, real-time experiences. Trend 7. Human centric processes-the next challenge for BPM Nowadays BPM seems to be focused on processes that are limited in complexity/predictability as well as limited in number of parties involved. We see the trend that there is an interest shift to more complex/unpredictable processes where larger numbers of parties are involved. How are we going to deal with those when the traditional BPM does not seem to offer an appropriate solution? Trend 8. BPM and training BPM and education do not seem to be closely related. However, if you take a close look you will see that BPM will not be successful without proper training or education. Implementing the new designed business processes starts with education about the change. On the other hand BPM products can be a learning source in themselves. Although it looks like the eight trends do have only one connecting subject, BPM, the opposite is true. There are many cross relationships. For example BAM and process improvement method like Lean & Six Sigma both require measurement of operational performance data. Another obvious link is between requirements management and business & IT alignment. Both subjects need an 2
  • 7. | the way we see it unequivocal documentation of business understandings. However, the most important relationship is of course: Business Process Management. For a closer look see figure 3, the BPM umbrella, in chapter 3. All the authors are experienced and skilled professionals working as consultants in different market sectors for Capgemini and Capgemini Consulting. Result of the cross sector selection of authors is a broad view/vision on BPM. We, as initiators and editors of this publication, hope that this publication amongst others will help readers, guiding them in their road through the BPM maturity stages as described in the concluding chapter. Hans Toebak Frank van den Ende Literature [1] Business Process Management in the Netherlands – Capgemini & Hogeschool Utrecht, 2008 Hans Toebak is Principal Consultant within the Operational Excellence practice of Capgemini Consulting. Frank van den Ende is Senior Consultant within the Financial Services Consulting practice of Capgemini. 3
  • 8. | the way we see it 2 Trends This chapter contains a paragraph for each trend named in the introducing chapter. Different authors – all experts in their field – give their view on BPM trends from completely different perspectives. 2.1 Process design for agility 2.1.1 Introduction The world is moving fast. New market developments, mergers and acquisitions, and international competition ensure that traditional companies are looking for new ways to react fast on external developments. Corporations find that well- known strategies are not enough to stay in the front lines. The traditional generic strategies for success are being best at customer intimacy, being innovative or being a cost leader. However, we must realise that these strategies were defined in the 70s and 80s of the last century, in times when change was not as predominant as it is today. Several business drivers, such as globalisation and internet, are enforcing and still increasing the pace of change of the businesses. Change as such is becoming a dominant factor and the consequence is that the three generic strategies by themselves are not sufficient anymore. Changeability, or the speed and efficiency in which a company is able to react on external factors, is a determining factor for survival. The automotive industry is scrambling to produce green, fuel-efficient cars; a development that was unthinkable only a few years ago. Nowadays, agility is the keyword. An agile corporation is able to change its services and products at the same rate, or even faster, than is dictated by the market. Services and products are the outcome of business processes and therefore an organisation‟s agility is also determined by the agility of its business processes. A corporation that can „outchange‟ its opponent has a competitive advantage. Change is a thing of all times, but the pace of change in the world has increased to such a point that the change ability itself provides benefits to businesses. Corporations can choose agility as a strategic weapon against their competitors. Yet, change is experienced as difficult, time-consuming and expensive. Millions are spent already to change business and IT environments. Does agility mean that we need to spend even more on change? Clearly, spending more is not the answer in the current market circumstances where cost-effectiveness is one of the key issues. Instead of spending more, we need to apply our limited resources smarter. The basic idea is to spend resources not (only) to create change, but also to improve the change ability of the organisation itself. An agile corporation has incorporated change as a characteristic feature, and spends time and effort on improving the changeability of the organisation. This allows these companies to change fast and with less effort than their competitors. Considering the turmoil in many markets, it is a safe bet to assert that agility and survival are two words that go well together. 2
  • 9. | the way we see it 2.1.2 Business process agility Business processes are the cornerstone for providing services and products to customers. No business change can be accomplished without changing the processes that bring forth these products and activities. Traditionally, business process design focuses almost exclusively on creating effective and efficient processes. Agility is traditionally not a design goal for processes. Business processes (and the supporting IT) are not designed for ease of change; the basic focus was on „getting things running‟ and not on „getting things ready for the future‟. This attitude is not sufficient anymore. Agility needs to be one of the key considerations in designing processes (including the supporting IT). This means that in the design of the business processes we should incorporate the necessary measures that make future change easier instead of more difficult. Theoretically, this sounds very good. Implementing change in such a way that also facilitates easier change in the future, allows large corporations to react on changing demands like small companies. But is this realistic? Is this possible? Are we able to make business processes and the products that they deliver flexible enough in a way that they support fast change? The following paragraphs describe some new developments in process design, and the supporting IT, which allows business management to implement processes, which are easily changeable. This is based on new insights in the strategic importance of change and also upon new technological developments, which allow supportive IT systems to change as fast as the business. If the processes and the supporting IT are not designed for change then an IT change cycle may take up multiple years. Business processes change typically much more frequently. As a consequence, the maximal change rate of a business process is often restricted by the limited pace of change of the underlying IT systems. How to break this bottleneck? How to make sure that, when changing processes, IT is not on the critical path? How can you bring agility into your organisation? In the following paragraphs, we discuss some new developments, which make agility a practical reality. 2.1.3 Agility in practice One of the most promising developments to implement agility is the use of Business Rules technology combined with a Service Oriented Architecture. 2.1.4 Business rule technology Business rules represent the business logic that underpins your business operations. Rules are representing the business knowledge you find in policies, regulations, and product definitions. For example, a bank can have a mortgage policy for their customers. New customers applying for mortgage may not be on a black list. For all customers there is a check on income if the requested amount is higher the EUR 10,000. This can be translated into the rules: 3
  • 10. | the way we see it IF a customer is new and applying for mortgage THEN customer may not be on a blacklist IF the amount of requested mortgage is more than EUR 10,000 THEN check if income is sufficient A typical organisation uses several thousand business rules. Of course, not all the rules are equally important. Traditionally, the business rules of companies are implicitly embedded into the IT systems. The terms „implicitly embedded‟ are essential. It means that the key-rules of your company are scattered throughout hundreds of applications, containing millions of lines of program code. Any change in your business process means that the corresponding program code and data need to be identified, changed, tested, and taken into production. This costly process repeats itself over and over again for every business process change. It is not hard to understand that this process results in a maintenance nightmare – and the corresponding long change cycle times that many companies experience. Business rule technology changes all this. The objective of this technology is to store the rules centrally in one place, which makes it much easier to update and change them. Business process change is then limited (very often) to changing some statements in a business rule repository. This change process is far easier to conduct and test, compared to the complex application change-process. If, for instance, in the example given above, the limit changes from EUR 10,000 to EUR 100,000, then the only change required is the change of the number in the business rule. The process itself (including underlying IT) does not require any change at all! This is a major change from the old days when such rules were hard-coded in the software. 2.1.5 Defining and maintaining business rules Business rules are mostly written in a formal but still natural language, close to the business nature. They are maintained by one or more business subject matter experts in a rule repository. Although changing business rules in a business rules engine is far easier then changing them in a more traditional environment – think about the example of the changing credit limit. Still the complexity of business rules management is a factor, which should not be underestimated. To achieve business agility with business rules you have to organise business processes in terms of services and business goals. Instead of thinking in sequential procedures (the classic approach), you apply a more goal–driven approach to your business processes. 4
  • 11. | the way we see it In our example, applying for a mortgage product consists of two checks: the blacklist check and the check on income. Business processes need to be considered as an orchestration of business services instead of sequential procedures. This is for many people an unusual way of considering their business. A set of business rules has to be complete and consistent. A small adjustment in a rule may affect the interactions between rules resulting in a different behaviour of a service. Starting with a small set and letting it grow incrementally is the best strategy for not being overruled by your own business rules. Business rules are acting like a steering wheel of your organisation. By turning it a little to the left or to the right your organisation will go towards the desired direction. 2.1.6 Business Rules and Agility Business rules are most effective for those business processes that are likely to change often. It is useless to create flexibility when there is always a fixed sequential dependency between two services. Take, for example, the business rule that your customer has to pay before you ship a delivery. When this is always the case, it makes sense to implement it hard-coded. The strategy is to use business rules in that area of your business where flexibility is needed the most, such as the front office of an organisation. This strategy decreases the overall number of business rules and, therefore, makes setting-up and maintaining the rule database easier. Furthermore, a more powerful usage of business rules technology is when the business rules engine uses inference techniques to achieve your goals. This mechanism walks through all the IF..THEN .. statements and selects only the relevant rules for execution. Therefore, if your business needs complex decision making based on many rules, business rule technology is just the right thing for your company. In the previous example, depending on whether the customer is new, the blacklists check will be selected by the business rule engine. 5
  • 12. | the way we see it 2.1.7 Service Oriented Architecture Service Oriented Architecture (SOA) is a method of building and connecting applications, which allows maximum agility. As such, it is a perfect companion to business rules technology. How does SOA accomplish agility and why is a SOA IT environment more flexible than a traditional environment? The analogy of a supermarket versus specialised stores may clarify this concept. In the past, applications were built like supermarkets, where you were forced to buy every required item (bread, meat, vegetables, etc) in this one supermarket. This is a good solution, as long as there is little change in the provided services, because when the provided services change (e.g., the supermarket is also to sell cars) then the whole supermarket needs to be rebuilt. A Service Oriented Architecture can be compared to a situation with separate, specialised stores, where each store provides its own unique service. So you go to the greengrocer for your vegetables, to the butcher for your meat and to the baker for your bread. If you want to buy also cars, you go, in addition to this, to the car dealer. In traditional application development, a single large application provides all the required functionality. If this functionality changes, then the whole application need to be rebuilt, which is expensive, risky, and takes a long time. Service Orientation changes this. SOA splits up the totality of required functionality into small, individual services and, consequently, it becomes easier to add or extend services when required, without negative effects on the existing services. 2.1.8 Agility and SOA Because of this easy changeability, SOA and business rule technology go very well together. In our mortgage example, there are three SOA services; an Apply for Mortgage service, a Check Blacklist service and a Check Income service. Check Blacklist and Check Income function independently from each other. The Blacklist service, for one, just provides generic blacklisting functionality and does not „know‟ that it is part of an overall Apply for Mortgage service. Business rules describe how these three services collaborate, to provide an overall Mortgage service. This „isolation‟ of functionality in generic services is a main characteristic of a service-oriented architecture. 6
  • 13. | the way we see it A SOA allows IT to build applications which are flexible and easily extensible. Business rules manage the sequence and relationships between services (the orchestration of the services) while individual services execute single business process tasks. Change in business processes – for instance interchanging two business process steps – affects only the business rules, not the underlying services. In the previous paragraph we saw that changing business rules is relatively easy, compared to application change. Adding new services is also straightforward, because no existing services need to be rebuilt or adapted. This increases the speed of change of business processes considerably. Experience shows that – in an SOA environment –process changes are far re easier to implement, because up to 80% of the underlying services can be reused. Consequently, the reuse of services reduces the required effort for building new applications considerably. 2.1.9 Summary and conclusions Business rule management and service oriented architecture, bring together two apparently contradictory business goals; the ability to innovate and change fast, in combination with a low-cost operation. Being able to change your business processes fast and without excessive costs, is nowadays a premium characteristic for corporations. Agility as a strategic objective should be considered as a key asset. Organisational changes (sourcing, shared service centers, centralisation or decentralisation) may require major changes in processes and supportive systems, but agile companies can absorb these changes without being overturned by them. This chapter gave an overview of the state-of-the-art thinking and technological possibilities to achieve organisational agility, which is both practical and feasible. Using new insights into the nature of organisational agility and new technology, companies are implementing agile business processes that will help them to grow and survive in the dynamic business environment of the 21st century. Raymond Slot is Principal Consultant and certified Enterprise Architect. He is lead author of Capgemini´s security architecture method. Yvette Hoekstra is Senior Consultant at Capgemini and certified business architect in the area of business rules and business process modelling. 7
  • 14. | the way we see it 2.2 Tooling 2.2.1 Introduction One can roughly distinguish a limited number of directions the BPM tooling is developing to. What are those directions, why is this development there, what is the difference between a Case Management Tool versus BPM Suites? Tools that offer one stop shopping versus niche-tools… In this paragraph the author will discuss these developments. 2.2.2 A glance at history The early 1980's can be seen as the start of the ICT revolution. The prices in ICT dropped to a fairly low level which stimulated the development of new software. Computer technology made its appearance in the administrative processes of the trade and industry business. And was here to stay. One of the results of the introduction of more and more automated processes was an increasing complexity of these processes. In order to diminish this complexity a new software program was developed by Capgemini in the Netherlands, named SDW- AO. With this software it became possible to document all your business processes. The success of this first Dutch BPM Tool was rather great, mainly because of the fact that the ideas of the Dutch guru in the area of Internal Control R.W. Starreveld [1] suited very well upon the method of designing the business processes. Many internal controllers and accountants were very pleased. At the same time there were limited possibilities to adjust the modelling method. This brought many developers in desperation. A call for new tools became louder. This was the start of the Dutch BPM hype. At first the tools were mainly focused on documenting business processes and organisational charts, whereas publishing was only possible on paper. The 3 features of the tools quickly increased with new ideas like: RACI matrices , generated formbooks and so on. New model techniques and methodologies were introduced quickly. 2.2.3 Methodology / techniques In the beginning the five-column-structure (also known as SIPOC: Supplier, Input, Process, Output and Customer) was leading and widely used. Soon new techniques and methodologies were introduced. Tool vendors quickly reacted on these new developments and integrated them in their tools. Sometimes the methodology followed the technique, sometimes the opposite was true. 3 RACI: Responsible, Accountable, Consulted, Informed. 8
  • 15. | the way we see it Some examples of new features were:  introduction of Activity Based Costing [2] method in the eighties;  adding ISO certification standards (end of 1980's);  integration of risk management modules (begin 1990's);  combination of Work Flow Management and Document Information System (end of 1990's). It is obvious that most of these methodologies were successful in the market, but mostly, only for a while. The comparison with the fashion industry is easy. At one time you're hot, the next moment you're not. A few methods and techniques will always be successful, but is it possible to answer the general question: do methods and techniques make their promises true? 2.2.4 From Tool to Suite The addition of new methods and techniques is not the only development tool vendors made. Better and improved graphical user interfaces, supporting databases or repositories can be mentioned, and of course extensive publication methods like companywide intranet pages and personal webpages. These developments are visible on the BPM Tooling side of the landscape. Examples of such tools are: Aris, BWise or Casewise. But this is not the only shift in the BPM landscape. See figure 1 for the expanding possibilities of BPM software tools. At the other end of the BPM spectrum the execution of designed processes is getting more and more attention. A BPM Tool shifts to a BPM Suite at the moment that documented business processes can be made executable with the tool (or in combination with another tool). Examples of BPM Suites are Cordys and Pegasystems. In theory, in these cases there is an alignment between business and IT. You can find more about business and IT alignment in chapter 2.4. 2.2.5 Added value of tool The acquisition of a new BPM Tool or Suite is not a Friday afternoon decision. Normally a well-considered choice is made, but the managers‟ personal favourite is often the lucky one. But what can be said about the added value of a tool or suite? Is the business case valid or isn't there a business case at all? The added value of a tool is completely dependent in which way it is embedded in an operational way. Sadly it is our experience that the acquisition of a tool is serious business, but the road does not stop there. On the contrary: it is the beginning of a long and compelling path. And it is exactly on this path that you can win or lose the most. Unfortunately little time and resources are available in this stage. Just by investing in time and money, for example in communication and implementation of the new designed way of working, many people should be involved. Otherwise the ROI will be low, and involved people will be dissatisfied. Luckily in more and more projects the significance of the communication and implementing phase is gaining importance. Let's take an example of a transformation from a Current State (Ist) to a Future State (Soll) situation. The 9
  • 16. | the way we see it new way of working (Future State) is documented in a BPM Tool and communication and implementing has been successful. The added value can be expressed in terms of: - a clear sight on the 'End-to-End' processes, in line of the vision - mission of the company; - better alignment between business processes, resulting in a shorter time to market; - clearly defined and published responsibilities. But even after a successful implementation it is hard to determine what the exact amount of added value in Euros is. Is it possible to determine how much clearly defined responsibilities are worth? At the end this is only possible when a clear potential risk has been prevented. Some tools are offering a Return On Investment calculation. For example IDS Scheer (Aris) offers Business Maturity Assessment Services. With this framework the business case of the BPM investment can be well founded. 2.2.6 Business Rules Another positive development is the introduction of business rules management. More and more organisations are asking for a combination of process descriptions, and clearly distinguished business rules. Unfortunately however, we also notice that business rule management and business process management are increasingly being pitched as competing 10
  • 17. | the way we see it options, or one-size-fits-all solutions to business improvement. After all, BPM systems (and the processes itself) are based on rules, and business rule engines can execute actions without a BPM system. In reality, BPM suites and business rule management systems serve fundamentally different and complementary purposes. In many cases, you need to use them together to fully achieve the goals of agility, alignment, compliance and the rest. The trick is striking the proper balance: Which rules are the domain of the BPMS and which are managed by the BRMS? What actions should be taken by the business rule engine, and what should be left to the process engine? Several new tools are emerging in the market and almost all of the established tools are offering a business rule engine. Chapter 2.1 will go deeper in detail concerning this subject. 2.2.7 Many different vendors Although all the leading analyst firms publish on a frequent basis the 'best BPM vendor reports', they do not seem to add very much value to the BPM landscape. The BPM tool /suite market can be characterised as an enormous diversity of tools/vendors, with lots of local players. A good comparison is almost impossible. Just in recent years a globalisation trend is visible. The large vendors are able to concur the global market and their sizes are increasing. Nevertheless lots of vendors have a strong home market. For example Casewise is leading in the UK, Aris widely spread in Europe and in the Netherlands Mavim and BWise are strong competitors. Above all the comparison of tools is similar with the comparison of cars. Only after determination of the main goal of the car (for instance a car can be used for daily work traffic or just for doing the groceries) the best car can be selected. Exactly the same is applicable for BPM comparison. The comparison is only valid when the main goal of the tool is established and this should be fully aligned with the organisation‟s strategy and objectives. So there is no such thing as the best tool or car. 2.2.8 BPMS As stated above the introduction of BPM Suites is a fact. A BPMS combines the functional modules with possibilities to translate the process designs to an executable infrastructure, of course with periodic synchronisations. The introduction can be seen as a major change in the BPM landscape. Just some years ago there was a strict distinction between modelling and execution. Nowadays this can be a vague line. In combination with a Service Oriented Architecture this offers a great opportunity for business and IT. Will there be the long wished business and IT alignment? Technically this is possible, but are organisations willing to transform? 11
  • 18. | the way we see it 2.2.9 What do organisations want? The answer on this question is two folded. At first organisations want to be in front and show the world that they have implemented a 'State of the Art' technology, way in front of competition and with a strong competitive advantage. Examples of these advantages are a short time to market, meet all the compliance regulations or scoring low on bad news. On the other hand organisations are cautious in spending money on BPM (software). Unfortunately there are little examples of a full utilisation of the BPM opportunities. In most cases a progressive management (there is more than short term thinking) is the motive behind a BPM project (read investment), not only in money but also in allocation of resources from start till implementing the project. Also in less economical periods advantages can be obtained, on the contrary: exactly in these periods a stronger position can be achieved. 2.2.10 What do clients need? Organisations nowadays seem to focus too much on a generic approach. 'One size fits all' is not the way. The transition path has to be in line with the professionalism of the employees. In a production plant more effort goes to explanation or training of the new way of working, combined with detailed process instructions, while for a knowledge worker detailed instructions would block his creativity. Lawyers are used to read massive text pages and architects like to look at a diagram. So not only the right tool is important, selecting the suitable methods and techniques is a critical success factor. Perhaps the newly introduced Human Centric Processes principles described in paragraph 2.7 can be helpful for successful implementation a new way of working. 2.2.11 Process-on-the-fly According to TechnoVision 2012 [4] of Capgemini, 'Process-on-the-fly' will be the next major improvement in the business processes management environment. New technologies enable analysts to quickly simulate, describe, model, execute and manage business processes [page 5 of TechnoVision]. This expanding flexibility offers great competitive advantages for early adopters. Perhaps this will be one of the differentiators in a competitive world. Process simulation, or Process Scenario Analysis, will play a dominant role in 'Process-on-the-fly'. Only a validated process can quickly replace the current state situation. Validation by simulation can be fast and reliable. But, several conditions have to be fulfilled: - Getting insight into complex environment/processes (with many parameters). - Process models must be enriched with correct statistical data and the right facts and some assumptions are needed to be made (garbage in is garbage out). The most important effort is to build the model in a simulation environment. After succeeding these conditions, decision making will be easy and profitable. 12
  • 19. | the way we see it 2.2.12 Future What will the future bring? At this moment one of the major trends is the corporation between BPM Tools and BPM Suites. Examples of this combination are: BWise - Cordys and Aris - Pegasystems. In these combinations 'The best of both Worlds' will be combined. Probably this will be the power of the next generation BPM: collaboration or/and complementing between 'old' and 'new'. Not only the vendors will transform but also their clients‟ need a change of mindset (from 'floor workers' to 'boardroom'). So they will be able to shift quicker between the current state and the future state situation. Only then a BPM investment will be profitable. 2.2.13 Summary and conclusion The development of BPM tools or suites can be illustrated on the Capability Maturity Model [5]. In the 1980's beginning in stage 1: the initial stage, followed by level 2: Repeatable in the early 1990's. The Defined stage (level 3) is just before and after the Millennium. On this very moment the BPM tool market is in level 4, the managed stage. The last maturity level (Optimising) will follow, but when and what will this brings? At this moment none of the vendors has a crystal ball as functionality, so ... only the future can tell. Note: the described experiences with the different vendors are based on the personal opinion of the author. Literature [1] Bestuurlijke informatieverzorging Deel 1 Algemene Grondslagen Prof. R.W. Starreveld R.A. [2] Activity Based Costing by Robert Kaplan and Robin Cooper [3] Picture from ‟The State of Business Process Management‟ February 2008, BP Trends [4] Capgemini TechnoVision 2012, Bringing Business Technology to Life, 2008 [5] CMM, Capability Maturity Model, published as Managing the Software Process in 1989. Frank van den Ende is Senior Consultant within the Financial Services Consulting practice of Capgemini. He is responsible for the Special Interest Group BPM Tools. 13
  • 20. | the way we see it By Eric Roovers, Business Development and Senior Consultant, IDS Scheer, The Netherlands. Not so long ago BPM was thought to equate the documentation of business processes for quality management and internal control. Now we see that BPM has become an active design instrument for the business operating model. BPM tools have matured with that trend. To name a few developments of recent years:  The sometimes radical process reengineering of the previous century has been superseded by process optimisation methods such as Lean Management and Six Sigma.  In a time when transparency and compliance are ever more important, business processes form the basis for the identification of risks and the implementation and testing of controls.  Process mining techniques enable a thorough analysis of how business results are achieved, by visually reconstructing the actual process narrative.  New SOA-related technologies make it possible to use the business process as the blueprint for service orchestration. With this, previously unattainable quality and flexibility levels can be achieved.  Finally, business processes are becoming a key element in the development of enterprise architectures, which has become imperative to control the complexity of modern business management. These developments fit in a trend to not only measure business performance by financial standards, but to seek out, in-depth, the opportunities to improve the organisation. With today‟s BPM tools, organisations can establish the impact of changes much better and plan their actions accordingly. With that, BPM tools have acquired a key position in the strategic and tactical management of modern organisations. About IDS Scheer: IDS Scheer is the global leader in independent business process and performance management - software and solutions - and a globally renowned service provider for process driven business transformation and implementation. IDS Scheer experts combine methodology, industry and process management know-how. With its ARIS Software, IDS Scheer is the worldwide market leader in business process analysis and optimisation. ARIS delivers measurable improvements of customers' business performance on a vendor-independent platform. 14
  • 21. | the way we see it ®4 2.3 BeLean , an approach to deliver results that last 2.3.1 Introduction Especially nowadays, in the current economic turmoil, companies are under constant pressure to deliver exceptional customer experiences alongside maximum efficiency. Customers rightly expect everything to be cheaper, faster and better; organisations therefore need to use all the means at their disposal to become more customer focused and at the same time leaner. The methodology named Lean offers to help companies achieve exactly that transformation. Lean optimises workflow and eliminates waste through employee involvement and continuous improvement, always with a focus on the customer‟s definition of value. Although Lean has its origins already in the 50s when Toyota first started the Toyota Production System (TPS), organisations nowadays seem to have more and more interest in proven process improvement methodologies like Lean in order to achieve sustainable results. As budgets become tighter and cost effectiveness can become a competitive advantage for companies, Lean‟s most appealing aspect is the promise of improved efficiency without negative customer impact. Even the most efficient companies still have room to eliminate waste. Indeed, Toyota, founder of modern Lean thinking, accepts that over 70% of its own activity can still be categorised as waste. 2.3.2 Tailoring Lean for success At present, some justified scepticism surrounds Lean. Certain organisations have attempted to transplant a Lean approach from manufacturing to the service sector in a compartmentalised and minimised way, and disappointment has followed, as in the infamous „black tape and active banana‟ stories that hit the UK press in 5 early 2007. In our vision there are three related principles regarding the use of Lean that can help organisations to avoid these pitfalls: 1. Lean must bring about behavioural change. It follows that: 2. Lean must be tackled holistically, focusing on people and organisation as well as processes and that: 3. Deployment must be progressive – it must happen level by level, according to a coherent roadmap. 4 BeLean® is a registered trademark of Capgemini B.V. and describes Capgemini‘s approach to Lean Delivery 5 See for example ―The £7 million guide to a tidy desk‖, The Times, January 5 2007 15
  • 22. | the way we see it Adopting these three principles makes Lean a means to achieving sustainable results – whether financial, operational, cultural or all of these. We call this approach „BeLean®‟. 2.3.3 Achieving behavioural change Past attempts to implement Lean have often paid insufficient attention to the human aspect. Especially for service organisations, the customer experience is determined largely by customers‟ interaction with the staff, so that effectively the people are the process. In our experience, 80% of Lean benefits result from changes to people and only 20% from tools and techniques. It is behavioural change that really makes a BeLean® implementation sustainable. Certain behavioural aspects of Lean are somewhat counterintuitive. In particular, BeLean® assumes that it is the worker who is best placed to improve the process; the manager is a servant of the worker, improving the wider organisation to facilitate what the workers would like to do. Because this idea appears to go against Western-style organisational hierarchies, it is sometimes greeted with scepticism. In order to overcome any such resistance, one should work with people at all levels of the organisation to explain BeLean® thinking and implement the behavioural change it implies. Employees on the front line are given the motivation, tools, and freedom to make sensible improvements to their daily work. At last, they feel ownership and a sense of contribution. Managers need to understand how to stop micro-measuring performance and look instead at the bigger picture. Because they are now aiming to improve the end-to-end process, the managers start to deal with the wider organisational issues that currently prevent the worker from achieving continuous improvement. For example, the team leaders and management of a customer contact centre become less concerned with the number of calls processed by agents and instead rightly focus on the root causes of the call volumes, and on how repeat calls can be reduced. 2.3.4 Tackling Lean holistically To achieve the necessary behavioural changes, it is necessary to consider process, people and organisation together (figure 1). More common Lean approaches focus on applying tools and techniques to processes, to the exclusion of all else. By contrast, the BeLean® approach works across all three areas. Process. The motto here is „do the right work‟: that is, only do what adds value in the eyes of the customer. For example, customers would not want to pay for transporting documents between buildings, or for handing off an application to another department (with the delays that implies); that type of work can often be eliminated first. 16
  • 23. | the way we see it People. „Do the work right‟: that is, ensure staff are fully trained, motivated, and genuinely empowered to make appropriate changes. It is better to identify missing skills and then ensure effective training than to give „must do better‟ pep talks. Organisation. „Manage the right way‟: that is, support the people who operate the process with the right measurements, technology, recognition, and organisational structure. Measurements should help teams to understand their achievements in terms of what the customer needs. For example, in our customer contact centre, does „average call time‟ really help us improve our customers' experience? Surely „number of calls resolved on first contact‟ would be a more effective measure of performance. Sustainable Results via via Behavioural Change Ornage tt Orn g Ornage t Do the work right Ma Do the work right Ma a or k rk ga he ga he r riig s s ga e r People wo htt w niis gh niis riiigh tthe ce n n s ht h rg Do ro atiht way at w a y at a at w a he P Do P on on o on The holistic approach makes for sustainable results because the three strands reinforce each other rather than conflicting, as can happen if process is changed without sufficient attention to people and organisation. The aim is to make every worker think: „I feel fully competent to do my job, I see that my manager supports me, and I have the motivation to make it even better.‟ 2.3.5 Deploying progressively Sustainable results are a consequence of behavioural change, which does not happen overnight. Therefore it is clear that a progressive approach to deployment – taking one level at a time - will build a stronger result. A roadmap is required, and so it is recommended to think about BeLean® in terms of the three levels shown in about figure 2. 17
  • 24. | the way we see it I. Taking control: quick wins to create momentum and build a foundation of basic capability from which to progress. II. Creating excellence: delivering transformational results. III. Sustaining leadership: embedding the Lean culture into the new business. There are several reasons for visualising BeLean® as a pyramid. One is that pyramids are built systematically from the bottom up: starting at the top is certainly not practical. Similarly, with BeLean®, it is best to build the people, process and organisation blocks within a single level before shifting one‟s priorities to blocks in the next level. A common mistake is to keep working on one aspect – typically process – without addressing the related people and organisation issues. Changing the process flow without an equal emphasis on staff buy in, or on metrics to support the new process, is generally disastrous. Like a pyramid, a BeLean® implementation should be built to last. Among other things, this means that even when the top is reached, it is still necessary to keep maintaining the foundations to prevent unseen erosion. All successful BeLean® programmes create a culture of continuous improvement – a legacy that enables the organisation to respond to subsequent changes in market conditions. 18
  • 25. | the way we see it 2.3.6 Implementing Lean Having an approach is one thing, but actually implementing Lean can still be a challenge… A BeLean® implementation is ideally organisation-wide, but can also be undertaken on a smaller scale, for example within a chosen function, and scaled-up thereafter. A BeLean® engagement normally consists of two phases, diagnosis and deployment. The diagnostic phase is valuable because it helps to ensure that BeLean® is implemented in a way that makes sense for the specific organisation. By taking a close look at the organisation and its market first, one can customise the approach to address the most pressing needs of the marketplace, and to help the organisation achieve its strategy. 2.3.7 Summary and conclusion Although some people think of it as new, Lean is a proven approach with its origins at the start of the industrial age. In particular in the service sector however, the results achieved not always were as expected. Successful adaptation requires three related principles: achieving behavioural change, a holistic approach and progressive deployment. In this way sustainable results can be achieved, and delivery of lean productivity improvements as in excess of 20% can become reality. Hans Toebak is Principal Consultant within the Operational Excellence practice of Capgemini Consulting. 19
  • 26. | the way we see it 2.4 BPM as key element in alignment of business and technology 2.4.1 Introduction This book is about trends in BPM – a domain, no misunderstanding there, as highly valued by the authors of this chapter as by the other authors let alone readers of this book – along with countless supporters all over the globe. Still, this chapter will clarify that BPM is one and only one – albeit essential – part constituting a holistic approach to successful alignment of business and technology. Rather than as all-embracing „centre of the universe‟, BPM is positioned as part of a „constellation‟ of collaborating domains creating maximum added value for enterprises, their partners and customers. 2.4.2 Alignment of business and technology is vital Enterprises that effectively align business strategy and objectives with technology solutions achieve competitive advantage. On the one hand alignment enables agile business models permitting fast go-to-market of products and services as well as rapid response to changing market demands thus increasing effectiveness and revenue. On the other hand alignment facilitates better design, development, implementation and maintenance of IT solutions through standardisation, rationalisation and reusability thus allowing for a cost-effective system landscape. 2.4.3 Misalignment of business and technology is common Enterprises engaging in projects classically risk divergence of business modelling and supporting technology solutions thus not achieving business objectives. Business modelling typically concerns strategy, objectives and process flows. Technology solutions characteristically involve package specific customising or even custom development, mostly complemented by separate relevant documentation. In view of disparate tools used, guarding consistency within a project is a formidable challenge in itself. Given multiple business models and numerous technology solutions in subsequent projects and continuous improvement, ever-increasing misalignment is practically inevitable. 2.4.4 BPM facilitates structural realignment of business and technology BPM considers enterprises in terms of cross functional end-to-end business processes, allowing for a homogeneous, methodological integration from functional design to technical execution in underlying application systems. In conjunction with enterprise modelling of strategic objectives and organisational aspects as prescribed by architectural principles, full realignment from strategy to execution can be achieved. 20
  • 27. | the way we see it 2.4.5 Introduction of a holistic approach and role of BPM A holistic approach for (re)alignment of business and technology is based on a close collaboration of three major domains:  business performance improvement (including BPM),  enterprise architecture (including business, information, information systems and technical infrastructure) and  technology development. This combination of concepts in architecture, business analysis, process modelling, implementation and maintenance as well as performance management is required to enable structural and integral alignment and flexibility in business and technology. In turn, this is as enabler for excellent business performance management and thus excellent business results. Vital contribution of BPM is application of process-oriented thinking on all domains enabling business and technology alignment and continuous business performance improvement. Such a holistic approach – supported by proper tools – is ever more becoming reality. For example, by applying process oriented thinking to business performance management, process improvement methods like LEAN Six Sigma are nowadays very often supported by BPM tools that also provide process performance data necessary for continuous improvement. Also, BPM tools establish process- oriented thinking in architecture, enforcing execution of business services by consuming process models in execution platforms. Thus, business and technology are synchronised: both refer to business objectives supported by processes and measured by key performance indicators (KPIs). Another example of emerging cross-domain alignment is business rule management (BRM). BRM aims to define, deploy, execute, monitor and maintain the variety and complexity of decision logic used within an enterprise. These business rules include policies, requirements and conditional statements used to determine tactical actions taking place in real-life business and application systems alike. Extracted and explicit rules contribute to alignment of business and technology terminology. When applied adequately, changes in business rules have little or no effect on process design and execution resulting in flexible business processes. 21
  • 28. | the way we see it A last example is synergy of process-oriented thinking and service oriented architecture (SOA). SOA is a paradigm for organising and utilising distributed capabilities that may be under control of different ownership domains, meaning that business logic is encapsulated in several small and reusable services that can be accessed and combined into processes by internal and external parties via generic interfaces. In a SOA style architecture, process changes only have limited and targeted impact on system implementation and execution reducing time to market and total cost of ownership. Above examples show how business and technology domains become 6 increasingly aligned and information technology becomes business technology : a true enabler of business performance management and continuous improvement by reducing time and effort of adequate responses to dynamic business contexts and increasing opportunities for alternative business models (see figure 2). 2.4.6 Introduction of key domains and role of BPM Business technology is supported by a new generation of tools enhancing business results, flexibility and configurability and linking system functionality directly to strategic objectives. From a BPM perspective the following features are most relevant:  Direct traceability from business objectives and (process) models to technology support; 6 The term ―business technology‖ was originally proposed by Forrester (see ―Business Technology: Do Business Execs Get IT?‖ by Laurie M. Orlov, with Bobby Cameron, Bo Belanger, Forrester, September 13, 2006) and is also principal subject of Capgemini TechnoVision 2012 [0], predominantly aiming to better understand how emerging technologies are linked to business drivers to properly prioritise focused development of required capabilities and timely adoption of new technologies. 22
  • 29. | the way we see it  Manage business tasks across applications: what (objectives, processes and rules) are leading instead of how and where;  Manage by exception: involve business users in automated processes using alerts in case of exceptions (both technical and business);  Integrate/ automate business processes: integrate business applications and automate message flow between systems with an executable process model; through various concepts:  Direct link between business model design and solution by integrating business design tool and business execution tool based on open standards or having both in one comprehensive tool;  Explicit, cross-component BPM layer handles processes where message flow between different business applications is dependent on multiple parallel events like several simultaneous messages, time trigger and business (re)actions;  Universal work lists where users access their process “to-do” lists spanning a range of business activities from administrative to more in-depth processes;  Intelligent routing based on flexible business rules and automated execution of process steps;  BAM delivering KPI information for continuous process improvement and real-time management dashboards for operational and tactical management. Maturity of business technology and approach to alignment of business and technology is dependent on process type involved and are discussed below. Following process types are distinguished:  Management processes: processes that govern operation of an enterprise;  Primary processes: processes that constitute core business and main value creation;  Supporting processes: both administrative and governance processes supporting primary processes. Figure 3 provides a concise overview on business coverage and technology support by process type. 23
  • 30. | the way we see it 2.4.7 Alignment of business and technology for management processes In relation to management processes, technology support focuses mainly on getting insight into business performance and having means to implement continuous improvement and enforce and audit compliancy (“doing the right things”). Due to the rise of balanced score card and process performance management, business performance is not only measured based on financial performance indicators but has been augmented by additional performance data, in particular operational KPIs. Ever-increasing speed and competitiveness of current business environments demands near real-time insight in business performance to timely anticipate new situations. Management dashboards provide such information based on data gathered by business activity monitoring (BAM) without having to pass time- consuming detour via data warehouses. BAM is gradually becoming a standard functionality of BPM tools and industry packages that are being used to support primary processes within an enterprise. Support of management processes is highly dependent on data gathered during execution of primary and supporting processes. In order to get the right information, performance management requirements have to be incorporated in business and technology design of these processes using BPM. 2.4.8 Alignment of business and technology for primary processes Typical business drivers that apply to primary business processes are frequently changing rules and regulations, mergers and acquisitions, continual process and quality improvement. Therefore business and technology support is moving towards process efficiency, agility and enabling continuous business performance improvement. 24
  • 31. | the way we see it For example, to improve process efficiency, methods like LEAN Six Sigma are being applied to remove inefficiencies in process design (“doing the things right”) and execution of new processes is being enforced via BPM tools. A steadily growing market trend is use of Straight Through Processing (STP) to execute processes without any user interaction where applicable. STP is presently supported by almost all BPM vendors. In combination with LEAN Six sigma, STP drastically decreases process duration and execution costs. The automation of primary processes follows a top-down approach that is also supported in both custom development and package based solutions. Making 7 processes agile by introducing BRM and SOA as described earlier is also applicable to primary processes. In custom development, some good examples of approaches enabling a close business and technology alignment based on processes and business rules are Capgemini Model Driven Architecture (MDA, based on OMG), IBM Information Framework and Pegasystems Solution Frameworks. All of them are starting with modelling the to-be situation using open standards and deriving requirements from this new business model. In order to accelerate solution development, reference models are used containing common practices of several industries. Each functionality within these business models is linked to business processes, business rules or business objectives. This approach offers direct traceability from business objectives and business (process) models to technology support and optimal alignment of business and technology in the to-be situation. In package based solutions, process orientation also becomes ever more explicit. Using BPM, enterprises can effectively combine sector know-how documented in reference models for architecture and processes on the one hand and packaged industry solutions and business rules in application suites on the other hand. Starting point is enterprise modelling including process design in conjunction with related architectural principles, strategic objectives, organisational aspects, information objects, application systems including transactions and/ or services and technical infrastructure in third-party tools like IDS Scheer ARIS platform or IBM Telelogic and WebSphere Business Modeler. More limited process design is also possible in embedded modelling environments supporting open standards, like SAP NetWeaver Composition Environment. 7 Despite rising SOA paradigm, hybrid environments involving both service oriented and ‗classical‘ transaction based implementations of application systems will be predominant for many years to come. 25
  • 32. | the way we see it All vendors provide common practice business content that accelerates development and links each application functionality to its corresponding business process component. For custom development and package based solutions alike, following an open standards based transfer to a run-time environment functional process design is enhanced with further technical details such as exception handling to prepare processes for execution. Based on monitoring, processes can finally be optimised, possibly after root cause analysis and simulation, closing the loop of continuous adaptation to consistently meet changing business requirements. From the viewpoint of primary processes, ever-increasing support of process orientation, rules and service oriented architecture within both custom development and packages based solutions enables a top down business improvement approach using BPM providing real process flexibility and a close alignment of business and technology. 2.4.9 Alignment of business and technology for supporting processes Much of current BPM focus is on (mostly top-down) alignment of business and technology in support of particularly primary as well as gradually management processes as described above. Yet there is another, quite similar process orientation emerging from a different, perhaps somewhat unexpected perspective: technology underlying supporting processes, in particular IT governance. All major vendors in latter field are increasingly enabling and 8 promoting business service management and IT process management, aligning 9 ever more closely to widespread standards and best practices . 8 Business Service Management is a comprehensive approach to unifying and standardising IT work. It creates a common, enterprise-wide view of each business service and enables automation of change and compliance across all devices that make up a business service. It connects IT processes, coordinates siloed teams via common workflows and integrates with monitoring and ticketing tools to form a complete, integrated business service management solution best supporting business. 9 Three specific IT governance practices and standards that have become widely adopted across the globe are: ITIL V3—Published by the UK government to provide a best practice framework for IT service management. The chief benefit of ITIL is standardisation of processes and concepts ensuring a shared understanding and offering proven solution models. In turn, this enables additional benefits in the form of cost savings, enhanced quality and greater customer satisfaction. CobiT 4.1—Published by ITGI and positioned as a high-level governance and control framework. Due to its high level and broad coverage and because it is based on many existing practices, CobiT is often referred to as the ‗integrator‘, bringing disparate practices under one umbrella and, just as important, helping to link these various IT practices to business requirements. ISO/IEC 27002:2005—Published by the International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) and derived from the UK government‘s BS 7799, renamed ISO/IEC 17799:2005, to provide a framework of a standard for information security management. 26
  • 33. | the way we see it The growing maturity and consequent adoption of these IT frameworks is being driven by two main factors. One is growing demand for improved quality, reliability and transparency as well as better control over IT activities in response to ever-increasing security, availability, performance, regulatory and contractual requirements. Another is ongoing concern over generally increasing IT (administration and management – not as much hardware) expenditures. Implementation of standards and best practices should be tailored, prioritised, planned and managed to match specific requirements given business context and other methods in use in the enterprise to ensure cost-effective and well-controlled IT delivery. One could even argue that process orientation is more advanced than in technology underlying management and primary processes. There, process logic was historically enclosed in quasi-intelligent data marts and back-end application systems and is only fairly recently being partly abstracted from technology in view of rising service oriented architecture paradigm. Still, resulting management and primary process implementations largely are vendor proprietary, package- based solution vendors‟ approach to hybrid environments is yet ambiguous, and both are bound to specific application system run-time environments. All that glitters is not gold in IT governance either. Vendors have moved bottom- up from backward-looking performance and availability monitoring of single and separate application services and infrastructure components to proactive performance and availability control of multiple and integrated IT services and processes. However, they have developed proprietary instantiations of aforementioned IT frameworks using bespoke workflow and technical process descriptions that at best can be imported one-directionally from a functional process model. On the other hand, more business-oriented tools have moved top-down from modelling and analysis mostly for primary processes to process performance management for various process categories. However, they may have implemented existing IT frameworks concepts for use by business but are still expanding functionalities to provide necessary links into execution that service management vendors have been developing and integrating for years already. More often than not, technology function is still fragmented both organisationally and process-wise as it is based on support of disparate IT capabilities rather than delivery of integrated services and processes. Hence, a clear and consistent definition and implementation of roles and responsibilities is essential in business aspect of IT governance processes. Existing well-regarded IT frameworks may help to define roles and responsibilities for effective IT governance of all process types. BPM offers suitable instruments for successful implementation and management. By adopting such a business focus, IT governance can achieve desired control over complexity, compliance, and costs. 27
  • 34. | the way we see it There is an apparent need to abstract process logic from technology and enable business to drive IT governance processes using BPM as in other process types. Another requirement is that top-down business practices are used in conjunction with bottom-up IT framework implementations using BPM for a proper application of technology in support of IT governance (“best of both worlds”). 2.4.10 Summary and conclusion A holistic process-oriented approach that allows for a homogeneous, methodological integration from strategy to execution and enables structural and comprehensive business and technology alignment –supported by process- oriented tools – is ever more becoming a reality. There is a clear analogy to both business and technology in support of various process types: all require closer alignment to maximise added value for enterprises. However, this chapter found that history, status, and approach in relation to BPM differ per process type and needs realignment in itself to prevent “silos of business and technology alignment”. In brief, BPM is at the pivoting point of further developments – both horizontally (top-down and bottom-up in each process type) and vertically (integration of various process types) – towards better alignment of business and technology. Realigning BPM by broadening scope to different process types, combining business and technology focus and mutually applying key learning and best practices, enterprise maturity level required for true business performance management and continuous improvement can be achieved more efficiently and effectively. To do so properly, combination of concepts in architecture, business analysis, process modelling and implementation and maintenance is required, offering structural and integral alignment and flexibility in business and technology as enabler for business performance excellence. As business and technology domains progressively merge into business technology, time and effort of adequate responses to dynamic business contexts decrease and opportunities for alternative business models increase. This takes us back to where this chapter started: rather than as all-embracing „centre of the universe‟, BPM needs to be positioned as part of a „constellation‟ of collaborating domains creating maximum added value for enterprises, their partners and customers: “Together. Free your energies”! Literature [1] TechnoVision 2012 - Bringing Business Technology to Life, Capgemini , 2008 [2] The Strategy-focused Organisation, Kaplan, R.S. and Norton, D.P., 2001 [3] Aligning CobiT® 4.1, ITIL® V3 and ISO/IEC 27002 for Business Benefit - A Management Briefing, ITGI and OGC, 2008 [4] Worldwide Distributed Performance and Availability Management Software 2007-2011 Forecast Summary and 2006 Vendor Shares, IDC, 2007 28
  • 35. | the way we see it [5] The five automation imperatives: a comprehensive look at Business Service Automation, HP, 2008 [6] [7] [8] several presentations on ARIS Value Engineering, IDS Scheer, 2008 [9] - several blogs on SAP NetWeaver BPM, SAP, 2008 Günther Drabbels is certified architect and Managing Consultant at Capgemini. Gernot Tomsits is Managing Consultant at Capgemini. 29
  • 36. | the way we see it 2.5 BPM as crucial factor for outsourcing IT development 2.5.1 Introduction Outsourcing the development of IT systems has shown a huge growth over the past decade. Large companies, in many cases quoted on local and international stock exchanges, who were formerly developing their own IT systems, have chosen to outsource this discipline. Above all other arguments this choice has mostly been made because of cost savings. The business case for these companies was difficult to be negative as the costs of labour in e.g. India are a fraction of the costs compared to the wages in the western countries. After a significant number of years of experiencing IT being outsourced, it is a known fact that this change within the organisations also has an underestimated downside. This downside is the collaboration between the business parties on one side requesting certain IT support, and IT parties on the other side delivering the systems and changes that have been requested. Unfortunately delivered solutions in many cases are not recognised by the business and thus not to the client‟s satisfaction. In this article, this phenomenon is further elaborated. Solutions to highly improve this negative side of outsourcing IT will be investigated and given. The crucial value of BPM in this matter will be explained as also the trend of capturing high level business requirements in process models and the use of a reliable method for business analysis (BA). In the described situation, it is ironical that in most cases both business and IT parties have done the right thing to demand or deliver what is needed or has been requested. What is lacking in the communications between demand and supply in this environment is for both to have working knowledge of the same language: Business professionals do not speak „tech‟, they are not familiar with UML or use cases. They express their needs in words that describe the way the work needs to be done in the To-Be (Future State) situation. IT specialists then translate this business „language‟ into „tech‟ in a way that complies with the interest of their company. This translation by definition comes with interpretation, which gives room for misunderstandings resulting in a deviant solution compared to the expectation. The addition of business analysis to the development process has reduced many of the difficulties. Main task of the business analyst is to bridge the gap between business and IT by translating the business‟ demand into an understandable and workable package for IT developers. With their knowledge of information analysis, business process management and their expertise on specific subject matters, they form the ideal conversation partner for both business and IT parties. 30
  • 37. | the way we see it Business parties benefit from business analysts as they can provide knowledge on the latest trends and developments in their markets. They understand their business processes and know how to improve them. IT parties also benefit because business analysts speak „tech‟ and are able to understand technological impact and even impossibilities of business requests and demands. On top of that, they are able to translate this into business language. Figure 1 shows the competencies of a business analyst. Although business analysts are very welcome professionals to the set, it has not completely solved the downside of IT outsourcing. So one could say that the problem is not „just‟ speaking different languages, there are also other aspects to it, such as  The relationship between business and IT has become distant;  The relationship has become formal instead of fraternal;  Former IT experts have become business analysts;  The relationship has changed due to cultural differences, which are compelling enough to be described in an article on its own and therefore not further addressed in this article. 2.5.2 Distant relationship When IT was still an in house operation, contacts between business and IT departments were intense and frequent, not to mention informal and pragmatic in order to realise the goals both parties were aiming for, being a team of colleagues. One would walk one floor down to discuss unclear topics or even organise a quick workshop to clarify potential misunderstandings. With IT being moved to, for example India, face to face contacts have been replaced by contacts via telephone or videoconferencing facilities, which take more time and effort to organise and which limit the visibility of non-verbal communications. Although this aspect of communications seems to be surmountable and low on impact, practice proves that the number of misinterpretations is off the charts. Thinking 31
  • 38. | the way we see it about the well known fact that more than 90% of communications is non-verbal, this aspect deserves serious attention. Interesting conclusion from this aspect of the problem is that it indicates that the problem of difficult communications between business and IT is not new at all. Before IT was outsourced the problem was exactly the same, the difference however is that it now has become visible due to the new way of working. Parties nowadays are spread over the world and have lost the informal and pragmatic contacts they used to have, which were very important to keep the process rolling, making the inefficiencies which were already there, unnoticeable. So in order to improve the collaboration between business and IT, improving distant communications is another aspect that deserves particular attention. 2.5.3 Formal Relationship As both parties are no longer within the same company, interests have diversified. Even when both parties are within the same company but within different strategic business units, divisions or other entities, interests are usually in conflict with each other. Where the business “(just) wants things to work the way it supports their business process in the best possible way”, IT aims to reach highest efficiency at the lowest costs, by organising their assets, processes and services conformable to (e.g.) CMMi guidelines. And although CMMi is a very good standard to comply to, the challenge for IT developers is to ensure handovers from their clients (business parties) are smooth, meaning that they need to be able to fully and unambiguously understand the clients request before processing it. In the current situation, IT developers build solutions that meet the specified business requirements as defined by the client and almost nothing more. Although it sounds negative, this is actually correct considering the new relationship. As a result of a change in the process of realising business change, namely the outsourcing of IT development, the internal handover has evolved into a formal purchase order, which has a significantly different value. There is no room anymore for designing 20% of the solution on-the-fly like there was before, when the business kind of expected this from IT, to solve the loose ends that were not described. Today the delivery of a solution that does not comply with the demand, is to be adjusted at the developer‟s cost. This means that every initiative or interpretation from the developer that potentially contributes to a better solution, is a risk for the supplier if it was not formally agreed upon. This explains the developers‟ formal attitude. However, with the previous frequent informal contacts and activities missing, things are determined to go wrong. Hence additional information is needed to realise a common working language, enabling the provision of an unambiguous request to the IT developer. 2.5.4 From IT expert to business analyst In the process of outsourcing IT, many IT professionals lost their jobs. Some went to other companies while others were saved in order to avoid losing the 32
  • 39. | the way we see it knowledge about the systems in use. For the IT professionals who stayed within the companies, in many occasions a place was found within the business analysis department. As business analysis is truly a different profession, this move can only be successful if these IT experts are trained in business analysis skills and more importantly, if these experts are able to adapt to the different mentality which is crucial to their new role and responsibility. Especially the latter is of great influence to the quality of the business analysis performance. The biggest difference between the IT professional and a business analyst is that the former gets an assignment and starts building the solution conforming to the received design. There may of course be some dialogue with the client, but basically IT professionals build to conform to the received design. A good business analyst however, receives a change request from a business owner, starts investigating the real business problem and determines whether the requested solution is the right and useful answer to the request. He does so by analysing and moreover understanding the As-Is situation and comparing the facts gathered from this analysis with the change drivers, client objectives and the change request. Based upon that analysis and agreement on that analysis with the client, he will design a To-Be solution that meets the change driver. A method that enables business analysts to perform their profession in an excellent way is the Structured 10 Expert Method for Business Analysis (SEMBA) , which is shown in Figure 2. This method will be addressed in more detail later in this article. 10 SEMBA is the Business Analysis Method developed by Capgemini 33
  • 40. | the way we see it Quite a difference in approach one might say! So if former IT experts with their knowledge of the existing systems treat business requests using an IT driven approach, a greater risk will arise of requirements being written reasoned from the problem towards the IT solution, instead of reasoning from the desired process. This way of working will not, by definition, express the true needs of the business, but will be aimed at a solution which is known beforehand. Looking at this aspect in combination with the challenges created by the formalisation of the relationship with IT, one could say that it is tempting for a business analyst to write the requirements towards a known solution as it would save a lot of potential misunderstandings in the development process. 2.5.5 Virtual Workshops Summarising the three defined aspects that lead to inefficient collaboration of business and IT, the following list of desired improvements can be made:  improvement of distant communications;  extend the classical information package with additional information, to realise a common working language, enabling the provision of an unambiguous request to the IT developer;  make sure that in the process of business analysis a complete analysis is performed to avoid shortcuts to insufficient solutions. Currently Capgemini is experimenting with virtual workshops. This is a most promising way to improve distant communications. Virtual workshops are workshops where participants are not physically in one room, they can be spread over many locations around the globe. Through the use of web based tools an environment is created in which all participants can communicate through voice and writing. This way a collaborative working is realised leading to a much higher involvement and stronger commitment of distant resources. Besides currently available web-tools which enable conference audio, video and file sharing, much more sophisticated solutions are also being developed. For example SUN [1] has developed an environment in which a virtual office is created, where employees can walk around and interact with others in many ways; one can have both formal and informal meetings. Walking around in the virtual office, you can actually see others standing and talking at the coffee machine, you can build presentations, documents, drawings etc. together by sharing applications or you can demonstrate the results of your offline work, inviting others to provide instant feedback. You can even have a video conference where people in the virtual space are gathered in a conference room looking at a screen displaying people in the actual space. This kind of tooling enables distant IT developers be more immanent as they become actual part of the team in the same office, reinstating the short lines which were there before IT was outsourced and increasing the chances for a “right at the first time” deliverable. It is not only this new way of collaborating that will improve distant collaboration, but also the possibility to have IT development parties involved 34
  • 41. | the way we see it earlier in the process. They will be able to perform the complete business analysis, instead of developing the solution alone based on the received requirements. 2.5.6 Business Processes are leading In case the IT developer is involved earlier in the project, it will be to be involved in writing requirements in a smart and unambiguous way, which is not easy at all. 11 The Integrated Requirements Management Approach (IRMA) aims to standardise the capturing and management of requirements in IT projects. Using this approach will lead to clear and complete requirements and ensures faster start up of the development project against lower costs. Also, the use of IRMA will provide additional information to the IT developer and will improve the requirements management discipline in the project, leading to better solutions. Perfecting requirements management is not enough. In order to reach unambiguousness, the developer needs to understand the arching context, the To- Be situation of which the requirements have been subtracted, in a more concrete and consistent way than described in the average vision document. Changes are based on problem statements, change drivers and client objectives. The arching context for the IT developer is provided by the business analyst by means of interdependent models, such as (a.o.) the business context model, business process model, governance model, information model, data model and high level application landscape design of both the current state and the future state. Parallel to developing these models, the business analyst elicits, documents, organises 12 and tracks changing business requirements in order to create a complete, coherent and consistent package. Naturally during this process of eliciting business requirements the encountered information and system requirements will also be captured. From all mentioned models especially the process model provides the concrete information fundamentally needed to interpret the business requirements the way they are intended by the business, namely the way they support the business process in the best possible way. This is because the process model pre- eminently describes the way of working once the change has been implemented. Consequently, it is the process model that is the common language for business and IT to speak in, in order to understand and to be understood. Therefore, business process modelling is crucial to successful IT development projects. The biggest added value of a business process model in this context is that it provides the business a language to explain what they really want. That is why business processes need to be leading in development projects as they are the 11 IRMA is the requirements management approach developed by Capgemini 12 Requirements Engineering within SEMBA is restricted to business and information requirements. SEMBA does not focus on the system requirements. 35
  • 42. | the way we see it spine of the internal organisation that carries all activities and supportive resources. It goes without saying that it will work only when provided business processes models are uncomplicated and understandable by all involved parties and stakeholders. Simplifying process models can be achieved by using building blocks, which for instance have been defined together with IT developers beforehand. By reducing the number of building blocks or services and their complexity, understandable process models will arise. Subsequently when the building blocks are 100% clear to the IT developers, a correct interpretation of the request is a fact. To secure the connection between the business requirements and the business processes, some companies have decided to capture the high level business requirements within the business process model. This has great advantage as it shows clearly and specifically per activity in the process the high level requirement which the supporting software has to meet. Also it provides for every change, the traceability to why the change needs to be built. Unfortunately the functionality of modelling tools regarding requirements management (RM) is limited and generally insufficient for a software development process. Therefore having the requirement at the operational level within the activity in the RM tooling is still needed. 2.5.7 Reuse instead of re-work The challenge is to keep the connection between the requirements and the business process in the requirements management systems. The worst thing to do is to translate the process model into something the RM systems can work with. This downgrades the process model from a guiding document into a working paper. The model in that scenario that will be guiding the rest of the process from this point on is the capturing of an interpretation of the original process model as defined by the business, adjusted to the functionality of the RM tool. Even though this seems to save a lot of effort in synchronising both systems during the development process, it decreases the accuracy of the description of the requested solution, especially when the process model is forced to be translated once more in case IT development parties again use other systems as part of their efficient CMMi processes. Within the development process the aim should be to reuse existing materials, instead of translating and reworking the received input into new models that may lose crucial information in relation to the original request of the business. Even though synchronising the requirements between the RM tool and the modelling tool takes time, keeping the business process model as a target solution from which all business, information and system requirements are derived, will definitely contribute to a first time right solution at lower cost. 36
  • 43. | the way we see it Enabling the re-use of existing materials will be boosted by integrating business process management and requirements management functionality into one single tool. This will enable companies to govern and control processes and secure that all change requests contribute to better realisation of the company‟s objectives. Change requests becoming a purpose in themselves will then be avoided. Moreover companies can initiate changes in the course of which a thorough impact analysis is possible on all relevant factors including other processes when changes occur in the development process. 2.5.8 SEMBA Listing appropriate methods for business analysis (BA) leads to a handful of methods which claim to be supportive to the business analysis profession. It is remarkable that none of the methods contain a current state analysis combined with a future state design and the making of a migration design in combination with requirements engineering. For this reason SEMBA was developed: the Structured Expert Method for Business Analysis. As shown in Figure 2, the SEMBA method for business analysis covers the complete BA process. With this method experienced business analysts are well equipped to perform a thorough and complete analysis triggered by the client initiative, resulting in an unambiguous Migration Design that is to be delivered to the IT development team. The graphic representation of SEMBA (Figure 2) is a matrix of vertical phases and horizontal streams. Together, these form an orderly representation of almost any BA project. SEMBA is not flat nor is it waterfall. The structure allows batches of activities to be viewed from any desired angle and supports an iterative way of working. Phases help the business analyst to navigate freely through the range of activities applicable at a given point of time. The streams in turn order the range of activities by topic and by analysis and design models; this allows for focus. A standard solution approach will start with the Focus and Direction phase, and ends with a Migration Design. The Focus and Direction phase basically supports the business analyst to prepare the BA engagement: the scope of the solution is agreed upon, if applicable then reference models are 13 chosen, the most suitable roadmap is selected and the approach is defined. The business analyst then comes to an understanding of the As-Is situation for each of the streams, and envisions a To-Be Design. Finally, and this is a key strength of the method, the business analyst builds a Migration Design, which charts the transition that the organisation will have to make from the As-Is Understanding to the To-Be Design. 13 The Roadmap connects SEMBA‘s results to the subsequent solution environment. For instance the SEMBA-RUP roadmap leads to deliverables which are specifically tuned to a RUP development process and therefore enable re-use of materials in the best possible way. 37
  • 44. | the way we see it Compared to an IT driven approach for software development, where requirements are gathered from meetings, workshops, notes and other sources SEMBA not only provides a more structured way of working, it also provides crucial additional information to the development teams in order to send an unambiguous request for change to an IT development party. Featuring five distinct streams, SEMBA covers the entire scope possible for any BA engagement. Business Context This is a collage of the organisation itself, put in the context of the organisation‟s ecosystem. It provides the rationale for the organisational business model and all that flows from this rationale. Business Processes 38
  • 45. | the way we see it This layer is the collection of the business processes that make up the organisation, possibly limited to the agreed solution scope. The Application Landscape and the channels of Information within the organisation all serve to support these business processes. Information Information travels through the organisation by way of IT, but also by way of informal and formal channels that are not part of the IT infrastructure or Application Landscape. The Information stream contains all activities and tasks that pertain to these channels, existing and envisioned. SEMBA is one of the few models currently in BA that pays serious attention to the Information stream of the organisation. Application Landscape The Application Landscape contains all the IT in scope (existing and envisioned), as well as the expressions of this IT to the user in the form of concrete applications. Requirements Engineering Rather than being a regular Analysis and Design-type stream per se, Requirements Engineering features recurrently during each of the phases but as a separate stream, bringing coherence between the Analysis & Design-type phases and the organisation‟s requirements. This fifth stream resurfaces in each of the subsequent phases in the framework, as a continuous inventory of the organisation‟s internal makeup, and a repeated check of the evolving design against that makeup. SEMBA‟s advantages are that it is exhaustive; it features a holographic makeup; it allows for maximum granularity and scalability; it gives unprecedented profile to the Migration Design phase and uses roadmaps to aid the subsequent solution handover. 2.5.9 Summary and conclusion Over the past decade, the outsourcing of IT has shown a huge growth. Although the outsourcing of IT development is still beneficial given the major cost savings, it also has an unpleasant downside which reveals itself in delivery of solutions which are not recognised by the business and thus not to the client‟s satisfaction. This drawback is caused by inefficient collaboration between the business parties and IT parties and can be divided in four aspects apart from a cultural aspect not elaborated in this article. Bottom line is that the collaboration needs profound improvement in efficiency and effectiveness to save the success of outsourcing IT development. Most crucial is to mutually come to working knowledge of a common language. For the business the business process model is the language in which they can express their needs and demands; for IT the business process model provides the information fundamentally needed to interpret the business requirements 39
  • 46. | the way we see it correctly. It is therefore that business process models are crucial to successful IT development projects. They are the common language for business and IT to speak in, in order to understand and to be understood. Building on the process model as common language, capturing requirements in the business process model secures the direct link between both and further improves the cohesion between the business process and requirements. It shows clearly and specifically per activity in the process the high level requirement which the supporting software has to meet. Also it provides for every change, the traceability to why the change needs to be built. Although currently there are not any tools in which sufficient functionality is offered for integration of both business process management and requirements management, both RM and BPM tool suppliers are developing such functionality. From then on all requirements will directly be linked to process models as low level requirements will be traceable to the activity in a process they need to enable. This merger under the auspices of business analysts will bring the collaboration between business and IT parties to perfection. Another contribution to improving the collaboration is to start organising virtual distributed workshops. Virtual workshops will improve the collaborative way of working and significantly increase the involvement and strengthen the commitment of distant resources. Another advantage is that IT development parties can be involved earlier in the process taking care of not only the IT development, but also perform the business analysis. In particular the development of SUN‟s virtual office is a very good example. Finally the use of a thorough method for business analysis is a condition to improve the bridging of business and IT. SEMBA ensures business analysts perform a complete analysis on all aspects of the change request. With specific attention for the involved processes in relation to the Business Context, the Information and the Application Landscape combined with Requirements Engineering, SEMBA covers the complete business analysis process diminishing chances for misunderstandings. Literature [1] Patrick Teters is Managing Consultant at Capgemini. He acts as Expert Group Leader in Business Process Management and is co-author of the SEMBA method. 40
  • 47. | the way we see it 2.6 Process change on (big) wheels Business Activity Monitoring as a drive to change processes. 2.6.1 Introduction Any manager can tell you that monitoring is a necessity to be in control and to be accountable. “Common sense” just isn‟t enough. The complexity of modern processes in practically every industry demands instant monitoring anytime, anyplace, anywhere, anyhow. Measuring practically every (sub) process in an organisation is called Business Activity Monitoring (BAM). The basic idea is easy: give the management (or operations) much more information about the status of the running business processes in almost real-time. The importance of always being “in control” is easy to understand: how about a nuclear power station being controlled on the basis of gut feeling? In fact BAM is not a new concept at all. It has its origin in the beginning of the previous century, the time of the industrial revolution. Since, developments in the monitoring of business processes have been numerous. Especially the „recent‟ ICT developments make real-time monitoring a reality. The advantages are obvious: organisation becomes able to quickly accommodate necessary changes (to speak in buzz-words: they become agile) and businesses can avoid risk and take advantage of opportunities in an ever-changing environment, rather than be restricted by a hard to change IT infrastructure. The next paragraphs describe where BAM comes from, where it is at the current moment and how it can support businesses as a drive to optimise their processes. Where it started: mass production processes Monitoring helps being in control, but also helps in inventing new processes. Henry Ford obviously is a pioneer in using monitoring to change the entire process of manufacturing automobiles. The results of his way of designing, executing and measuring processes still are impressive. The “Fordism”, low cost mass production processes using an assembly line and strict measurement of the process performance was copied by many others. Fordism also stands for high wages for the workers on the assembly line, therefore denying Karl Marx‟s “historical truth” of exploitation of the masses. That the right design of one‟s processes - supported by the outcomes of the monitoring - can lead to a competitive advantage became very clear: Ford‟s mass production processes created a military advantage for the United States which enabled them to win World War II and destroyed almost all Japanese industries. 2.6.2 Second change: Plan, Do, Check, Act A void creates room for new and better ideas. In Japan Dr. William Edwards Deming (1900-1993) introduced statistics for the improvement of industrial quality. His ideas contributed significantly to the high quality of manufacturing processes in Japanese industries. The best illustration of the quantum leap in quality improvement is this quotation from Wikipedia: “Dr. Deming's teachings and philosophy can be seen through the results they produced when they were adopted by the Japanese, as the following example shows: Ford Motor Company was simultaneously manufacturing a car model 41
  • 48. | the way we see it with transmissions made in Japan and the United States. Soon after the car model was on the market, Ford customers were requesting the model with Japanese transmission over the USA-made transmission, and they were willing to wait for the Japanese model. As both transmissions were made to the same specifications, Ford engineers could not understand the customer preference for the model with Japanese transmission. It delivered smoother performance with a lower defect rate. Finally, Ford engineers decided to take apart the two different transmissions. The American-made car parts were all within specified tolerance levels. On the other hand, the Japanese car parts had much closer tolerances than the USA-made parts - i.e. if a part was supposed to be one foot long, plus or minus 1/8 of an inch - then the Japanese parts were within 1/16 of an inch. This made the Japanese cars run more smoothly and customers experienced fewer problems.” Deming‟s PDCA ("Plan-Do-Check-Act") iterative four-step problem-solving process is still widely used in business process improvement programs today. The link to BAM is most obvious in the check step (also known as study step): measure the new process and compare the results against the expected results to ascertain any differences. The fundamental principle of PDCA, is iteration: executing the cycle again will extend the knowledge further. Repeating the PDCA cycle can bring organisations closer to a perfect operation and output. 2.6.3 Third change: Against all odds Finance in the Netherlands used to be the domain of gentlemen serving other gentlemen. In the 1990‟s it became clear that banking processes must be made extremely efficient in order to create higher profits. Segmentation of customers on the basis of their profitability became widespread. Most valuable effect of segmentation is that it is predictable how these customers will act in the (near) future. Monitoring a segment of customers in virtually every activity they do creates valuable knowledge. This knowledge has lead to (semi-) automated processes for loans and credits. Soon, it became clear that fully automated processes create more low risk loans than humans ever could. Unfortunately not every credit process was crystal clear. Managerial greed became stronger than common sense and statistics, thus creating the credit crunch. The credit crunch will create new changes. One of them definitely will be new processes for clear and valid monitoring, any time, any place and in every country. Latest change: BAM changes public inspections and enforcement Last decade‟s industry, logistics and finance have turned into “accurately monitored” institutes: an awful lot of process and performance information is delivered that supports managers to be “in control”. Managers in the non profit sector however still have different ideas about being “in control”. Their responsibilities are simply different than creating profit and shareholder value. Healthcare is the fastest changing not for profit “industry”: efficiency and effectiveness of processes become more important. Inside and outside hospitals and other health centres, work processes are being changed continuously. Even the enforcers are changing the way they work. Writing as many fines as possible used to be the credo. Nowadays these thoughts are changing. Risk-based studies help to create new insights. To quote Dr Deming: “You can expect what you inspect”. Little by little enforcers understand that being a police agent creates fines but being a smart investigator creates compliance and safety. 42
  • 49. | the way we see it There are a lot of examples where BAM supports or even steers the (re)design of processes; a typical Dutch example is the inspection seeking overloaded trucks. 2.6.4 Big wheels cause damage and change enforcement Transport and logistics are very important for the Dutch economy. Many trucks drive from the harbour of Rotterdam to virtually every city in Europe. These trucks do not only bring prosperity, they also cause a lot of damage. If the pressure of one axis is too high the asphalt wears off too fast. As a result roads must be repaired too often. In a crowded country this leads to congestion and many traffic jams. Lately it became clear that overloaded trucks cause a lot of damage to the many bridges in the Netherlands. One of them, the “Hollandse Brug” near Almere is closed for all trucks for over one year. To reach the city of Almere, trucks must drive an extra 60 km (one way…). There are a lot of bridges similar to the “Hollandse brug”, so it is time to change enforcement… How could BAM play a role in this problem? On a number of places the Dutch roads are provided with “Weigh in Motion”, a system that can measure the pressure of axes while the truck is driving by. A complex ICT system gathers the data from the system and leads it to a central data warehouse. In this central data warehouse the data of all Dutch trucks can be observed and company compliance can be calculated. The calculations are being used to sent a letter to this company and warn them that it‟s not compliant. If this company persists in overloading trucks, it can expect a visit from the inspectors. Visiting a company is very time consuming. The monitoring system Weigh in motion helps to define which companies “deserve” a visit, thus making the entire process of the inspectors far more efficient, but also directly providing input for the transporters as well and thus having impact on their core processes as well. Is there more to come? Business Activity Monitoring can change the way we look at processes and the way we work. Mr Henry Ford and Dr Deming demonstrated perfect examples. The finance industry recently showed us that if (credit) processes are not crystal clear, greed becomes more effective than monitoring. The state-of-the-art BAM solutions make it possible for operations managers and upper management to have instant and constant access to critical business performance indicators, which gives them a powerful advantage in today‟s marketplace: BAM‟s output is input for decision making when (re)designing processes Even in the public sector managers are discovering the potentials of BAM. In case of overloaded trucks BAM can help to avoid traffic jams and reducing the cost for maintenance of roads and bridges. To quote Mr. Kees Herschbach, manager of the IVW (The Transport and Water Management Inspectorate): We‟re doing whatever we can to avoid road damage. New processes help us to improve our work. So, next time you‟re in a traffic jam as a result of road works: there are enforcers working and thinking for you! John Waser is Principal Consultant at Capgemini. 43
  • 50. | the way we see it 2.7 Human Centric Processes – the next challenge for BPM 2.7.1 Introduction Our lives are filled with stories. Especially kids understand this concept of a story quite well. Often a (make-believe) story provides the context for activities that they do. Stories help us to understand various concepts:  A story usually has goals and when met, the story ends (or the story is abandoned earlier).  People play certain roles (and kids are not surprised when asked to play multiple roles) and in their roles they interact in various ways and perform activities to develop the story (and reach the goals).  There are rules (and if people don‟t play by the rules kids will react quickly!).  There is power - who controls the roles-assignments and the evolution of the story.  And communication within the story has a specific context, a specific language, where specific terms are used for specific concepts. A context that can be harshly broken by a mother calling the kids to come home, breaking all the rules and communication patterns of the story! When we grow up and start working in companies, strangely enough, nobody talks about stories. When talking about context for activities, we speak of projects, processes, cases, issues. And suddenly stronger and sometimes new demands are put upon us – productivity, deadlines, visibility, accountability, compliance. The Business Process Management (BPM) movement and earlier process-schools have delivered great approaches for structuring and improving certain types of stories that we are involved in when doing business. Concepts such as protocols, procedures and business processes enable us to create repeatable, transferable and improvable stories. But we find that there are types of stories that we can‟t seem to handle well with the concepts and technologies of BPM. Let‟s dive into the next challenge for BPM: Human Centric Processes. 2.7.2 A classification for processes When working with various clients, one can see that their processes can often be classified using two dimensions: 1. Process design-time predictability 2. Collaborative intensity With process design-time predictability, we mean the ability to model a process (all triggers, activities, possible paths and business rules) at design-time (e.g. before process execution commences). For certain processes this ability is quite high – for example the process to borrow a book from a library can be modelled as a finite number of possible events/situations, activities and corresponding paths in the process. Other processes might be less predictable, either because of 44
  • 51. | the way we see it an explosion in complexity in the amount of possible events, timing of events and activities/responses, or because certain events or activities are simply not known yet. With collaborative intensity we mean the number of concurrent collaborating people required to perform activities in the process. With concurrent we mean literal: are people needed at the same time, to perform together an activity for a specific process instance (because they are needed together because of knowledge or decision power that they provide). For certain types of processes this is not needed – think of a production line for a certain widget, where an employee takes a work-in-progress item, performs a specific transformation activity and puts the transformed widget on a stack for the next employee. But think of a process where a complex decision needs to be made, too complex to be handled by one person. If we map out the two dimensions graphically, we can depict various categories of processes. In figure 1 the two dimensions are displayed and used to show segments with typical approaches to implement and control the corresponding type of process. Predict- Collaborative Approach and Description intensity Ability High No people Straight Through Processing (or “STP”)[1] : Straight Through Processing is an approach in which we strive to execute and steer all activities within a process with full automation (or in a factory setting: mechanisation). It‟s a completely “hands-off” delivery. Example: requesting a car insurance policy through the internet, where the full delivery process (profiling, calculations, updates to backend systems and output generation) is fully automated. High 1 person E-Forms and Workflow management [2]: Workflow management is characterized by pushing (or pulling) work through a serial chain of employee/ 45
  • 52. | the way we see it workstations, each focusing on performing a specific transformation. The approach has proven its value in large factories and data/paper-bureaucracies. Example: requesting a loan in a traditional bank, where a front-desk employee registers the request, a loan officer reviews and proposes the loan conditions, a loan manager decides and a back-office employee transfers the loan amount. These types of processes can be supported with E-forms (for simple workflows) and workflow management technology (for more complex flows, regarding possible routes, work assignments and business rules) Medium 1 person Case management [3]: In this approach, which originates from the medical and social security field, a central role is assigned to a “Case manager”. While parts of the process might still be predictable, certain parts are not – and require human intervention. In this approach, the case manager assesses the state of the case, and based on this assessment, decides which activities are currently required. These activities are then assigned to various other workers (including the case manager). Results of finished activities or new signals will result in a reassessment of the case, leading to new activities or termination. Example: processing an insurance claim, in which certain unpredictable events and unknowns will require a claim manager to respond based on the insights at that stage. High Multiple Collaborative BPM or CEBP – Communication Enabled Business Processes [4]: In this approach, the key concepts of workflow are still applied, but the key difference is that certain activities within the process require people to collaborate – together research, plan, discuss, negotiate, solve and/or decide, as part of creating value in the process. This means that in the process, while it is still predictable, at some stage multiple persons need to be brought together and facilitated to collaboratively deliver on a known/defined activity. Example: an employee-hiring process, in which various interviewing people meet to discuss a candidate and decide on hiring or not. Note: “collaborative BPM” is also used to describe BPM tooling that supports people working together in parallel modelling processes. Medium Multiple Human Interaction Management: to Un- predic- Processes of this type cannot be predicted at model/design table time – the amount and possible timing of events/signals, possible shifts in goals and possible activities are too much or to unknown to allow modelling the process before actual execution. This area and the possible approaches (roughly named “Human Interaction Management”) are the focus of the 46
  • 53. | the way we see it remainder of this chapter. A number or remarks:  In certain situations process stakeholders might have implicit biases or political reasons to position “their” process as less predictable, than reality requires (“we are special”). A clear focus on the 80-20 rule, the most frequent events and happy path could help in this case.  Often it will be the case that a process can be placed in more than one area. For instance: a simple order process, that can be handled most of the time through straight through processing, certain products however require workflow and certain exceptions are quite complex and require case management and sometimes even human interaction management. Typically, various fragments of a process may fall in different process areas  A key lesson is that each sector in the diagram requires its own approach and best practices and that these approaches are not optimal for other types of processes. Approaches that are suited for instance for workflow management (detailed design of all activities and business rules of a process in a process model) are not suited for case management (where the amount of possible events and timing would lead to an explosion of complexity in the process model) [5]. 2.7.3 Human Centric Processes In the diagram we roughly identified an area of processes we call “Human Centric Processes” (sometimes also called dynamic BPM, collaborative processes, fluid or ad hoc unstructured processes). Human Centric Processes share the following characteristics: Collaborative Activities are frequently performed by multiple persons working together, in various ways (meetings, phones, emails, chats, concurrent working on documents), consisting of many human interactions (inform, ask/answer, challenge, discuss, negotiate, decide together) Knowledge Activities require various persons with specific knowledge, that intensive needs to be combined to perform the activity successfully Dynamic, adaptive Based on status, signals, knowledge and decisions, the remaining part of the process is frequently refined (leading to new, altered or deleted activities, flows/procedures and possibly even the people involved with their roles/responsibilities) Examples of Human Centric Processes include:  Police or legal investigations  Complex (B2B) sales and negotiations  Market research and strategy setting  Product development  Complex medical cases  Iterative software development 47
  • 54. | the way we see it  Complex exception handling  Mergers and acquisitions 2.7.4 Human Centric Processes – growing role, growing challenges What role do human centric processes play in organisations? How important are they? From an intuitive perspective, one can probably say that these types of processes exist in many organisations and that they have significant impact on the performance of organisations. Many people, if asked, see only a limited amount of their workday in the more “mechanistic” processes, where process flow is known and prescribed (for example submitting expense reports) and see a lot of time being spent in more collaborative, ad hoc processes. However, it is rather difficult to support this perspective with objective data. It is surprising that in this post-industrial society, we measure so little on knowledge intensive work (based on a check with the CBS – the Dutch National Statistics Agency). Fortunately, some research has been done, in this case by McKinsey (2005) [6]. They approached their study into new types of work and processes, by dividing economic activity in three categories. (table 3). Category Description Examples Transformational Extracting raw materials and converting Mining, Production them to finished goods line Transactional Simple interactions and transactions that Clerical and interactions unfold in a generally rule-based manner accounting work and can thus be scripted or automated Tacit interactions More complex interactions requiring a Running workshops, higher level of judgment, involving managing supply ambiguity and drawing on tacit, or chains experiential, knowledge The searching, coordinating and monitoring required exchanging goods and services. Remark: In our perspective McKinsey‟s concept of “Tacit interactions” is very close to what we have defined as “Human Centric Processes”. The key results of their research (based on job-market data in the US – 1998, 2004):  The number of jobs in Transformational activity is dropping. Transactional jobs are growing somewhat, but the tacit interaction jobs are growing the most. 70% of new jobs created in the period 1998 – 2004 were jobs in the field of tacit interactions.  Cost of labour for tacit interaction workers is the highest (55 – 75% higher than for transformational and transactional), and is, as a part of total labour cost, the largest part (47%). 48
  • 55. | the way we see it McKinsey explained these trends as a result of the optimisation and elimination (through mechanisation, automation and off-shoring) of transformational and transactional work, and on the other hand the greater need for collaboration between different companies. Cost of labour is growing due to the fact that tacit interaction roles are often filled with people with skilled and high-educated people, and that companies value these types of roles higher. Peter Drucker predicted these changes, with the rise of the “Knowledge worker”. Based on the growth in importance and cost, McKinsey asks a key question: what can we do to improve the productivity of people working in tacit interactions? Peter Drucker, a well known management guru stated a similar challenge: “The most important, and indeed the truly unique contribution of management in the 20th century was the 50-fold increase in the productivity of the manual worker in manufacturing. The most important contribution management needs to make in the 21st century is similarly to increase the productivity of knowledge work and the knowledge worker.” [7] McKinsey points to a number of paths to better performance:  New thinking in organisational structures that facilitate tacit interactions (such as loosely structured teams, as opposed to the silo‟s and hierarchies that worked great to steer and optimize transformational/transactional work, but that often seem to work against tacit interaction work).  A new look (and investments) on supporting technology. The required technology is very different than the technology used to improve transformational and transactional work. It is McKinsey‟s belief that if properly done, organisations can create sustainable competitive advantage when implementing effective and efficient tacit interactions. 49
  • 56. | the way we see it A number of additional observations:  In addition to these paths, we also believe that the management of tacit interaction work will be different from the other work types. There is growing research in the field of management (for instance based on the complexity approach), that indicates that other types of interventions can lead to better performance in human centric processes.  Today‟s IT solutions are not supporting tacit interactions effectively. On one hand current ERP and bespoke systems are focused on transactions and fairly rigid processes. On the other hand, and as a result, people tend to use general office automation (e-Mail, word processing, spreadsheets) to coordinate and execute human centric processes. These tools help somewhat, but come with a large risk: since these tools lack process support and context, tacit interaction people tend to “drown” in information overload, with full inboxes and many (versions of) documents, tasks lists, etc. [8], [9], [10]. Our conclusion: Human Centric processes are growing in importance. This fact is also recognized in Capgemini‟s TechnoVision that defines (among others) two major trends: from transaction to interaction and process-on-the-fly. And just like the other work types, organisations will have demands on human centric processes and the process participants: output needs to be on time, costs need to be controlled, delivery needs to be efficient and execution needs to be compliant and visible. We have key challenges for this growing field of human centric processes! How do we solve this? 2.7.5 BPM and BPM technology and Human Centric Processes Can BPM and BPM technology solve these challenges? If we look at current BPM thinking, most BPM concepts have their roots in traditional process thinking, dating back from the era of Taylor, Gilbreth and Sloan:  Division of labour, creating roles with specialisation on certain activities (including management as activity) and fitting people in the role.  Work patterns for groups of people based upon a careful design of triggers, activities, sequential flow/paths, business rules and controls – in which each person has a clear, limited role.  Process models and work distribution schemas as ways to intervene, direct and evaluate people‟s behaviour.  A systems perspective in which output, quality and people as process participants can be steered by a control-loop (Plan-Do-Check-Act), using process measurements, norms and motivational instruments (reward/punish). These concepts have provided great value for improving productivity in typical (serial) production environments. But they have also proven to be limited. Key issues with these concepts: - What if certain organisational challenges require effort beyond predictable processes– because there are too many unknown events, ambiguity or too many possible work patterns? 50
  • 57. | the way we see it - What if people need to work in a process and change it “on-the-fly”, based on new insights or new events? - What if certain activities require people to work together, creatively, each delivering unique knowledge? What if before hand, the right people can only be identified when certain information is clear? - What if reality of organisations in essence is too complex, too ad hoc to approach with a process- and systems focus? These types of questions are currently difficult to answer with BPM concepts. BPMN-based process models fall short. KPI‟s and control loops are difficult to define. Terms as “compliance”, “risk management” are difficult to apply. Current BPM technology is also not able to adequately support Human Centric Processes: - Many tools only allow design-time process modelling, which makes it impossible for process-participants to alter the process “on-the-fly” when a specific condition requires this (dynamically adding/changing activities and decisions). - Most tools are using the BPMN (1.1) standard for process notation, which does not have constructs for collaboration (for instance a meeting between multiple “pool” participants). - Most tools focus mainly on System to System (S2S) interactions (Forrester calls this the “Integration Centric” BPM suites) or Human to System interactions (Forrester calls this the “Human Centric” BPM suites – but we question the “Human Centric” term used here). Most tools have no concept for “Person to Person interaction” and lack support for human interactions. Various key people in the BPM industry have realized this (see [11], [12], [13], [14]). We have to conclude that current BPM (as an approach) and BPM technology do not provide sufficient answers to solve the challenges for human centric processes. 2.7.6 New horizons – Human Interaction Management What could support human centric processes, from a conceptual and technological perspective? What could improve productivity? To find answers for this, we believe we need to return to the concept in the introduction of this chapter: stories. We need to acknowledge that in human centric processes stories evolve, in which people collaborate, together determining the story and delivering on the activities in the story. And that Taylorian concepts, “old-school process interventions” and “workflow” do not work! Instead we will need to focus on what happens really when people are working together and interacting with each other. What types of interactions occur? What determines productivity in these interactions? And we will need to study this from a multi-disciplinary perspective – ranging from social-psychology, anthropology to information-processing and IT support [15]. 51
  • 58. | the way we see it A number of persons have identified this need [16], [17] A promising development in this area is that of “Human Interaction Management” (Keith Harrison-Broninski [18]). Human Interaction Management is defined as a set of management principles, patterns and techniques complementary to Business process management. HIM provides process-based support for innovative, adaptive, collaborative human work and allows it to be integrated in a structured way with more routine work processes that are often largely automated. [19]. In summary, Human Interaction Management assets include [12], [18]: - Concepts for people and interactions stories, teams, roles, time, planning. - A different way of modelling processes, that allows for explicit definition of collaborative patterns. - An agent based approach in which process execution is handled through interacting agents (choreography) instead of central process models. - A methodology - Goal Oriented Organisation design. 2.7.7 Future IT Support for Human Centric Processes We described earlier that most human centric processes are coordinated and supported currently by general office automation (email, documents, and spreadsheets). Although this type of IT provides flexibility, it lacks certain features (visibility, audit ability) and poses the dangers of information overload. In addition, current BPM technology does not support these types of processes either – Human Centric Processes cannot be addressed with simple task inboxes/forms metaphor and rigid design-time process models! What would be key features of IT solutions that can support Human Centric Processes (or in other terms – what are the key features of “Human Interaction Management Systems”, or social software with a process twist)? A possible list is presented in table 4 (sources: [16], [17], [20], [22]) A number of IT vendors is working on solutions that support (some of) these features [21]. We also have the impression that more mainstream BPM vendors are researching and developing features in this area as well[22]. 2.7.8 Human Interaction Management –a trend? Based on what we have found so far, can we state that human centric processes and human interaction management (and supporting IT) are trends? There are definitely some positive “trend” signs in The Netherlands: First there was the well attended keynote speech of Keith Harrison-Broninski at a large BPM conference [23]. Secondly the Dutch BPM Forum organized a special session on this subject [24]. Third Capgemini organized a well attended BPM Community of Practice session on Human Interaction Management (December 52
  • 59. | the way we see it 2008). Last we see more and more organisations showing interest in this area (for instance at Capgemini‟s last BPM seminar, October 2008). These signs have resulted in Capgemini Netherlands and the University of Utrecht starting a research program in this area. So Human Interaction Management may not be a trend yet, but our current thinking is that there definitely is a need, although this need is not yet far “on the hype curve”. Our impression is that BPM and supporting BPM technology provide good value for predictable serial processes, but that reality is that there are types of processes that cannot be handled with the current concepts in BPM: Human Centric Processes. As the adoption of BPM and supporting technology grows, we expect that more and more organisations will discover this fact as well and will start looking at additional approaches and technology to support these types of processes. This may pose a risk for adoption of BPM as organisations can become disappointed with today‟s limited support for human centric processes and projects might fail. If Human Interaction Management (HIM) will be the answer is not clear yet. In our opinion, currently HIM lacks scientific foundations (mainly around the behavioural aspects of collaborating knowledge workers and impact on productivity) and still has little proven successes (but HIM is a quite new area, launched in 2005). Process focused A process engine that takes care of assignment of activities to individuals and groups. The ability to freely define, add, alter and remove activities, while also being able to select existing process fragments from best-practice templates of earlier comparable stories. The ability to plan these activities in certain flows, supported by business rules. The ability to include complete automated sets of activities, linked to certain automated services. Ability to assign tasks to story participants with due dates and ability to commit, delegate or reject these responsibilities, linking to calendars (planning) and task lists. Story focused The ability to start a story, join a story, manage all relevant activities and information within the context of a story Information context Allow a story to hold and manage all related information, from repository whatever channel/in whatever form: emails, notes, documents, chats. Note that this area is typically covered by tools as Microsoft SharePoint, but that these tools lack process context features. Social networking Ability to quickly identify people that are needed for a story or an activity in a story, based on certain criteria. Ability to identify people that were / are involved in comparable stories. Ability to inform and invite them to a story. Ability to assign them to certain roles that define authority, responsibility and will drive filtering of information. Ability to access their contact data and profiles. Ability for the story participants to manage the way they will interact (and can be contacted) with the other story participants Personal Presence and story engine – by phone, real life, chat/instant messaging, Management email – and ability to define preferences related to importance/priority of events and activities. Personal and group Ability to view all stories one is involved in, and all commitments. Ability to estimate required effort and planning, 53
  • 60. | the way we see it time management based on due dates. Ability to plan own work. Ability to do this for groups, including synchronisation of agenda‟s and priorities, planning meetings, etc. Context driven Ability to send and receive information through various channels, communication that are linked to the story and certain story contexts such as goals, issues, activities, etc. Ability to receive information and quickly get access to this context information. Integration with Integration with typical information production environments typical tools (Email, Document processor). Ability to find information, based on activity context, role, tags, etc. Location & channel Ability to interact with the story engine through various channels independent (browser, mobile device) Support for human Ability to work together concurrently in a context part of a story interactions in – together defining goals, issues, activities/plans, roles/people or collaborative deliver on a certain activity. workspaces These workspaces should support various human (tacit) interaction- patterns, such as:  - Identify people, get to know each other/profile  - Inform  - Investigate/collect  - Question – answer  - Discuss, share and confront different viewpoints  - Raise as issue/unknown  - Identify required activity or decision  - Constrain  - Negotiate  - Prioritize  - Plan  - Agree, commit  - Decide (authority or democratic/voting)  - Evaluate, identify lessons learned Results of these interactions can easily be stored and tracked and will lead to updates to relevant story participants. Visibility / tracking Ability to quickly view key essence of story and its status. Ability to get alerts based on certain process aspects, such as checkpoints, dates or events such as delays to plan and identification of major issues. Audit log/time line in which all major events are tracked and can be accessed for audit reasons. We expect that multiple approaches for Human Centric Processes will be developed, from a myriad of related areas such as knowledge management, project management, psychology and social sciences as well as information technology developments such as Web2.0, social software, ECM and BPM technology. The focus: how to improve the productivity, manageability and compliance of knowledge workers in dynamic processes and collaboration. In our research we hope to find more answers in this interesting area! Literature [1] See 54
  • 61. | the way we see it [2] See [3] See [4] See [5] Lesson learned from a case management project for a Dutch insurance company [6] “The next revolution in interactions”, McKinsey quarterly, No 4, 2005, Johnson et al. [7] “Management challenges for the 21st century”, Peter Drucker, 2001 [8] Information Overload! - Making a case for Dynamic BPM, Ian Louw, September 16, 2008 overloadmaking-a-case-for-dynamic-bpm/ [9] “Human Process Management”, Jacob Ukkelson, November 10, 2008, higherbpm-business-value [10] “Lost in E-Mail, Tech Firms Face Self-Made Beast”, New York Times, June 14th 2008 [11] “Workflow sucks”, John Pyke, [12] “Human Processes” – Keith Harrison-Broninski, BP Trends, Dec. 2008 [13] “BPM in the Real World: How Person-to-Person Interactions Support Knowledge Workers“, Bill Welty, Align Journal [14] “The Process of Working with People: Person-to-Person Business Process Management”, Howard Smith and Peter Fingar, BP Trends sep 2004 [15] “Human Interaction”, Prof. Juan Quemada, June 23, 2008, [16] “Work 2.0‟, Peter Fingar [17] “Human Process Management”, Jacob Ukkelson, November 10, 2008, higherbpm-business-value [18] Keith Harrison Broninski - [19] See [20] “Democracy – aka Dynamic BPM”,Jim Sinur, akacollaborative-bpm/ [21] A number of vendors working on process technology for human centric processes: - Rolemodeller‟s HumanEdj – - ActionBase - - ResultMaker - - Thingamy - - Handysoft – - Singularity - - SAP(Eventus) - - Interneer - [22] The Power of Collaboration: Collaborative BPM, Whitepaper BEA [23] “BPM meets SOA”, Heliview seminar October 30th 2008 [24] “Human Interaction”, BPM-Forum meeting, October 29th 2008, Roeland Loggen is BPM consultant/trainer at Capgemini. In addition, he is an active blogger on BPM at 55
  • 62. | the way we see it Human Interaction Management: Hype or New Paradigm? By Pascal Ravesteijn from the Utrecht University One of the groups doing research in the domain of Human Interaction Management (HIM) in the Netherlands is the Utrecht University in collaboration with Capgemini and the Utrecht University of Applied Sciences. Pascal Ravesteijn, researcher at the Research Centre for Process Innovation, which is a part of the Utrecht University of Applied Sciences comments: „There is a lot of research being done in Business Process Management, especially in the Netherlands. The Eindhoven University of Technology is world famous for its research on workflow management and process modeling, Cordys is a well known BPMS supplier and YAWL (process modeling language) and Archimate (architecture modeling language) are Dutch initiatives. However the amount of research on human centric business processes is still very limited both in academia as by more commercial organizations. This is remarkable if we look at current events in the western world. For more than 20 years there is a trend of outsourcing manufacturing / development work while at the same time more knowledge intensive jobs are being created. Also the tremendously fast adoption of the Internet has lead to new types of collaboration and services. Organizations are working together in so called business value networks (or virtual organizations) in which partnerships and alliances change a lot quicker if the market demands so. All this means that both organizations and their employees have to be a lot more flexible and agile, this in turn means that modeling initiatives are becoming more complex due to the ever changing environment. For the western world McKinsey estimates that over 70 % of the work is knowledge intensive and can therefore no longer be managed and controlled by standard processes. Based on these developments the Universities in Utrecht have decided to dedicate capacity for research projects‟. To start with it is important to know which initiatives are already being taken in the domain of HIM and related topics. Although Keith Harrison-Broninski hyped the term Human Interaction Management in 2005 with his book „Human Interaction: The Heart and Soul of Business Process Management‟ there have been many related activities dating back to the sixties. The Speech Act Theory (Searle, 1969) is one of the theories that is used to model communication between people in an effort to control that what is being communicated is also actually being done. Other related domains are Human Performance Technology (Pershing et al., 2006), Socio-technical research (De Sitter, 1994), Role Activity Diagrams (Ould, 2005) and the Design & Engineering Methodology for Organizations (Dietz, 1999). Also there is an extensive field of scientific research in the area of collaboration, whether it is between people, organizations or societies from which there are many lessons to be learned. Finally a new and very interesting field of research is that on gaming and more particularly the principles behind gaming. Already large companies like IBM and Microsoft are involved in game research. In relation to human centric business processes and human interaction management research on the ways gaming influences social behaviour, characterization of player populations, gaming principles for active learning and goal oriented behaviour by gaming participants are promising. Online communities in games like World of Warcraft (a massively 56
  • 63. | the way we see it multiplayer online role playing game) mainly consist of smart young people (ages 18 – 35) that are determined to accomplish goals that can only be reached by cooperation with other game participants. If principles that are behind games as these could be incorporated into the work and (IT) support of knowledge workers and organizations then a large increase in performance, flexibility and agility is to be expected! 57
  • 64. | the way we see it 2.8 BPM and training “Stagnant water loses its purity” (Leonardo Da Vinci) 2.8.1 Introduction BPM is a management discipline that requires and enables organisations to manage - plan, change and act - the complete revision cycles of their business processes, from process design to monitoring (measurement) and continuous optimisation (based on Gartner, 2006 [1]). When training people, the focus is on performance improvement of management and employees, in order to increase the performance and intellectual capital of the organisation. At first glance, BPM and the training of employees do not seem to have much in common. But if you look a bit further, you will notice that both BPM and employee training have the same goal. Both are ultimately aimed at performance improvement of the organisation. Because of the effects of ageing of society, organisations are witnessing a run off of knowledge. A means of dealing with this run off is to record the knowledge in BPM products, in which process modelling is an obvious medium. In this manner, BPM products in their own right become a training source for new employees. Training is as old as Roman hills. In „BPM land‟, many BPM related training offerings from consultancy firms, training institutes and tool suppliers can be found. The quality of these training offerings will undoubtedly vary from moderate to extremely good. But what exactly is bad or good? How exactly do you determine and measure the quality of training and who is responsible for doing this? 2.8.1 Market research Market research has shown that a key success factor in the successful implementation of BPM is the presence of a sufficient level of knowledge among employees. An international market study on BPM carried out by AIIM Market Intelligence [2], has shown that 41% of participating organisations experienced troubles due to the lack of knowledge and/or training of internal employees, in the process of implementing BPM. The study “BPM in Nederland 2008” [3] which was recently carried out in cooperation with the Hogeschool Utrecht and Capgemini paints a similar picture. Three quarters of respondents participating in the abovementioned study indicated they use external support in the realisation of BPM activities. 58
  • 65. | the way we see it And in this regard, support by means of BPM training was rated as number one with thirty-eight percent. This fits with the barrier “Insufficient resources with sufficient knowledge”, which a quarter of the respondents indicated to be the primary obstacle in carrying out BPM activities. It should be more than obvious that well trained employees are crucial in the successful implementation of BPM. This immediately prompts the question: How can we successfully train employees in BPM? 2.8.2 The art of training There are many ways to learn. However, not every training goal is the same. The content of a training course is derived from the learning goals, which on their turn can be divided into five learning dimensions: Knowledge  Understand: theories, facts, tips and tricks and background information. Insight  Understand: understanding the context, understanding the necessity and significance of knowledge, understanding mechanisms, connections and logic. Skills  Ability: be able to exhibit desirable behaviour in familiar and new situations; be able to perform demanded physical and mental tasks. 59
  • 66. | the way we see it Attitude  Attitude: the attitude with regards to what has been learned, the attitude with regards to colleagues, clients or new developments. Impact  Effect: The acquired knowledge, skills and attitudes influence the environment and the learning effect is not constrained to the individual. The true impact is achieved when the individual can act from his own unique personality (authenticity). With this classification of five dimensions, the quality of training can be measured by determining in advance, which learning dimensions are relevant and determining the criteria against which objectives and eventually results can be compared. For that purpose, one will have to unequivocally define what the goal of the training is beforehand. One should note however, that descending from the knowledge dimension to the impact dimension, measurement (and especially the determination of the measurement units) becomes ever more difficult. 2.8.3 Measuring training success There are several ways to look at the success of a training course. Figure 2 captures these differing modes. Satisfaction The first way to determine whether training was successful or not, is to measure the satisfaction of the participants. Did the training meet ones expectations? Was the instructor an expert in the particular field? Were the facilities satisfactory? 60
  • 67. | the way we see it This is often measured by means of a questionnaire or evaluation form at the completion of the course. This is the most common method. Drawing a bridge to BPM, one can compare it to the capturing of process descriptions. Are people satisfied with the way in which the processes were captured by the BPM employee? Did the BPM employee have a pleasant way of eliciting information? A manner that says little about the actual quality of the BPM product. Content The second gradation relates to the content. Did the participant understand the content? This is often measured by having participants take an exam. If the participant passes the exam, then one can conclude that he has sufficiently understood the content. A lot of suppliers of BPM training courses employ their own exams, due to a lack of a generally accepted standards, like the standards that are available for service management (ITIL) and project management (PrinceII or IPMA). A new development in this regard is the so-called OMG Certified Expert in Business Process Management (OCEB) certification of the 14 Object Management Group (OMG) [3]. This could possibly develop into the generally accepted standard. If one draws a parallel to the delivery of process descriptions in BPM, then this gradation is where the correctness of the process descriptions is determined. This is usually done by having one or more process experts validate the descriptions. Transfer The third manner involves the Transfer, which can be understood as whether or not people use it in a practical setting. A common problem in the training world: the offered training program just fails to match the practical setting in which the participant operates. Examples are merely vaguely recognisable and processes remain abstract. A better way would be to practice in one‟s own work environment. However, this normally is not workable due to unacceptable risks. So-called learning work labs may be a solution, as they enable free training in a controlled, yet recognisable practical environment, with coaching. New and innovative concepts in which the participants are handed exactly the knowledge, skills and tools that fit their personal project situation and style of learning also pertain. In such instances, the personal learning key map supports the participant in obtaining and applying the competencies in a practical setting, which are needed to e.g. function and work as a BPM employee. 14 OMG™ is an international, open membership, not-for-profit computer industry consortium. The OCEB™ program will consist of five examinations, granting five Certifications. Above the single Fundamental level, the program splits into two tracks - one Business oriented, the other Technically oriented. 61
  • 68. | the way we see it Participants in similar flexible learning routes present their personal practical situations to one another and to experts in the field. In the analogy to BPM, the process description corresponds to the process as it is actually carried out in practice. A technique like process mining deduces the followed processed from event logs and audit trails of systems and databases[5]. Organisations The final gradation is that of the Organisation. In this context, a link is made between the training and the performance of the organisation. For example: has the sales training led to more sales? In other words, does one actually see a measurable improvement in the performance of the organisation? This is ultimately the reason why organisations train employees. If once again a parallel is drawn to BPM, one sees that in BPM methods such as Six Sigma and Lean aim at similar goals. The training of employees can then be seen as a possible solution and possibly a precondition for improving product quality or customer satisfaction. 2.8.4 Summary and conclusion At first glance, BPM and training look like two things which have nothing in common. The opposite however is true. BPM and the training of employees are both ultimately aimed at bringing the organisation to the next – and higher level. Trained employees are a precondition for the successful implementation of BPM. BPM in its own right can be a valuable source from which to provide training. There are several ways in which the success of BPM training courses can be measured. We are witnessing that in the training world, ever more innovative training concepts are being employed, in order to provide a direct and measurable contribution to the performance improvement of the organisation. BPM training courses and BPM implementations are commonly considered to be two separate subjects. BPM and the training of employees in BPM have a strengthening function in reaching the ultimate goal of organisational performance improvement. It is therefore advised to jointly use these two means. Acknowledgement of sources [1] Gartner Research Report, Business Process Management: Preparing for the Process-Managed Organisation, 2005 [2] aiim MarketIQ, Business Process Management, 2008 [3] Hogeschool van Utrecht en Capgemini, Business Process Management in Nederland, 2008 [4] The Object Management Group, OCEB certification, www.omg.orgocebindex.htm [5] Process Mining, [6] Guido de Vrught is Managing Consultant at Capgemini. Currently he is manager of the Technology cluster within Capgemini Academy. 62
  • 69. | the way we see it 3 Point of View 3.1 Introduction This concluding chapter will go into detail with Capgemini‟s point of view on BPM. It starts with the way we see the development of BPM as a management discipline and the BPM maturity of organisations in relation to that development. One could even say that the notion of BPM as management discipline is a trend in itself. It also stresses the prerequisite of having a BPM infrastructure in place in order to be able to realise desired growth in BPM maturity. A further drill down of the BPM discipline leads to the “BPM umbrella”. Our experience is that there are only a few organisations that ask for BPM in itself. Organisations have business issues to be dealt with and there might be one or more BPM related solutions. How BPM and these solutions are related is explained by means of the BPM umbrella. Finally some future developments in the BPM working field are described: what will the future trends look like? 3.2 BPM as management discipline Nowadays there seems to be a general consensus that Business Process Management – as the word “management” implies – is a management discipline rather than a technology or an updated version of BPR (Business Process Redesign) that was hot during the early nineties. Although the term "BPM" is still widely used to mention BPM technologies, researchers like Gartner now use the term as management discipline [1] and in the BPM survey conducted in the Netherlands in 2008 [2] more than half of the respondents supported this definition. In our point of view organisations that implement BPM as a management discipline have attention for the whole life-cycle of business processes: continuously designing processes, monitoring & analysing processes and improving/ optimising processes. All these three components of BPM are necessary to meet the challenges of today‟s world, summarised in three trends that we see dominating the marketplace:  cost-effectiveness: narrowing market windows with shorter opportunities for optimising profits (“In 2007 56% of the respondents indicated that their companies were involved in BPM to save money or improve productivity” [2]);  flexibility: constant change driven by customers and competition in the marketplace, and  transparency: regulations and laws requiring precise execution against cost and schedule. 63
  • 70. | the way we see it Organisations must find ways to better manage their business processes - that is, the ways in which they operate - to deal with these trends. For example, designing processes for agility needed to respond to changing conditions. Monitoring in order to provide information about business operations, enabling business managers to make better and more-timely business decisions. And related to transparency: demonstrate compliance with regulations. Bottom line: by treating BPM as a management discipline, processes become a means to achieve competitive advantages. 3.3 BPM Maturity Although we acknowledge the need to see BPM as a management discipline, in our opinion you cannot separate this from the BPM (or process) maturity level of an organisation. These two aspects seem to be closely interrelated. When investigating the existing literature, there are several BPM maturity models around, mainly based on the CMMi model. Another well known model is Gartner‟s BPM Maturity Model [3] and BPR guru Michael Hammer has his Process and Enterprise Maturity Model [4]. Although the maturity models vary in the number of levels and the complexity of each, in the end all models boil down to the same: with respect to the way organisations deal with BPM there is a growth path, starting at the point where organisations hardly have any notice how their processes work, but are/become aware that there may be some business improvement opportunities that cannot be addressed by conventional approaches. Then organisations become more process aware, up to the level that they have end-to-end, agile business processes in place. By the way, striking result of an international survey [5] is that almost 80 percent of the respondents indicate that their organisation has still not started with BPM or is still in the very early stages... However, somewhere on the maturity path the notice of treating BPM as a management discipline will come along. As one can imagine, it doesn‟t make sense to talk about BPM as management discipline for organisations that are in the very early process maturity stages. So, you cannot reach a certain level of BPM maturity without considering BPM as management discipline as well as the other way around: considering BPM as management discipline indicates that you have reached a certain level of maturity. In other words both developments go hand in hand. In our point of view there are different ways in which organisations can move to - and subsequently move through – the BPM maturity stages. Although reaching the highest levels of maturity must not be an aim in itself, more mature organisations seem to be able to better deal with changing conditions within their ecosystem. The "right" choice – both in the road through, as well as the desired level to reach - will depend on a large number of aspects, amongst which are the company's unique business challenges, the BPM awareness at management level, and the commitment to Business Transformation™. The bottom line is that, without any map, the journey to BPM maturity will be difficult and frustrating. 64
  • 71. | the way we see it 3.4 BPM Infrastructure What we would like to stress for organisations that aim to grow in their BPM maturity is the importance of having a BPM infrastructure in place. High Maturity - Co-ordinated BPM activities 5. Optimised - High BPM Expertise - End-to-end process view - Continuously, proactive - …. 4. Managed 3. Repeatable Low Maturity 2. Defined -Un-coordinated BPM activities - Low BPM skills - (Department) Internally focused -Ad hoc, reactive 1. Initial state - …. Strategy, Achieved Supported by business By processes BPM objectives Impact on Impact on business BPM success process success success In our opinion, having such an infrastructure in place and dealing with BPM as a management discipline are tightly connected: we see the BPM infrastructure as a necessary precondition to reach the higher stages in the maturity model. It makes it possible for an organisation to treat BPM as a management discipline. Starting point for defining the way the BPM infrastructure should look like, always should be the question: “what is it that I want to achieve with BPM?” This in turn should be a consequence of the organisation‟s strategy and objectives. In other words, alignment between strategy and operations. The next question then should be: “who am I doing it for?” Only when these two questions are clearly answered, the next step can be made. Putting the BPM infrastructure in place then has to do with activities like installing a BPM governance, defining and implementing the BPM (meta) processes – e.g. how to deal with changes in required BPM functionality or process contents - , designing and applying BPM standards and conventions, 65
  • 72. | the way we see it selecting a BPM tool, etc. At this stage you should not be dealing with any process-contents at all. As mentioned before there should be a close relationship between an organisation‟s strategy and business objectives and the way they approach BPM. For an organisation where everything is going smoothly - targets are reached without any problems, market shares are constantly increasing, and so on - there will hardly be any reason to be interested in the field of BPM. However, in real life this type of organisations hardly exists and almost any organisation, in time, will be faced with a gap between strategy/ objectives and the actual operational outcomes. In order to solve the issues that cause this gap, BPM solutions can be considered. So again: the organisation has to define what it is that they want to achieve and then look whether BPM solutions may be applicable. As a consequence, our experience is that there are only a few organisations that ask for BPM in itself. An exception might be the request for the implementation of a BPM infrastructure, but overall almost no business manager asks for „two ounces of BPM‟. Instead, he or she has a business issue or requirement that has to be dealt with and there might be one or more BPM related solutions. The BPM professional has the challenge to link solution and issue (with the possible appurtenant benefit that there is a process oriented solution that does not require a million Euros investment in IT solutions). To illustrate this, we use the metaphor of the umbrella. We see BPM as a management discipline, as the all-covering umbrella, under which there is a palette of possible BPM solutions for business issues and requirements. It is the specific business issue or requirement that determines which solution(s) are applicable. As stated before, in the ideal situation this notion is already dealt with when setting up the BPM infrastructure. E.g., when the business wants to make use of process simulation to evaluate alternative future scenarios, this should be a requirement when selecting a supporting BPM tool. This is in order to prevent that a lot of energy is put in modelling processes in tool X and then come to the conclusion that your BPM tool does not support simulation at all. By means of this figure we want to create some clearness in the discussion around the definition of BPM as well. The way BPM manifests itself will often be as one of the BPM solutions in figure 3. When asking BPM professionals about their definition of BPM one will get a great diversity in opinions of what BPM is and is not. Often the answer will be in line with the particular manifestation of BPM for this person. In our opinion though, there is a distinction between BPM as discipline and the BPM solutions. Although the latter one is part of the first, this does not mean that that manifestation is equal to BPM. 66
  • 73. | the way we see it At the highest definition-level we concur with Gartner [6], stating that BPM is a management discipline that requires and enables organisations to manage - plan, change and act - the complete revision cycles of their business processes, from process design to monitoring (measurement) and continuous optimisation. In our opinion this definition implies:  Continuous improvement in terms of (cost) effectiveness, agility and transparency, alignment, and being in control of processes;  A shift to process-centric thinking: processes being treated as distinct assets to be valued, designed and exploited in their own right;  A structured approach for monitoring, managing and iteratively optimizing an organization's operational business processes (the way the business operates);  The implementation of automation suites (BPMS or workflow systems) may play a role as enabler. 3.5 Where is BPM heading to? The list of trends we pay attention to in this publication is by no means exhaustive. We made the selection based on the developments BPM as management discipline we see at our customers, what international research and advisory companies indicate, and results of our Dutch BPM survey. For some „trends‟ you can discuss whether it is already a trend – where in our opinion a trend is something that is already going on – or an expected future development – something one expects to happen, a prediction. The dividing line between these two is sometimes difficult. For example, a trend like Human Interaction Management is disputable: do we already see this happening or do we expect this (eventually being in development at this moment)? Another future development is process 67
  • 74. | the way we see it simulation or process scenario analysis. Is this something new, is this a trend? No, not at all: in the ninety eighties we already used process simulation to support decision making, so nothing new there. On the other hand, nowadays we hardly see companies actually using process simulation on a large scale in order to improve their processes. Nevertheless, we believe that process scenario analysis will become a valuable tool in the near future. In this paragraph we want to highlight some of the future developments that, in our point of view, are the direction the BPM world is moving to. 3.5.1 Human Interaction Management: processes don‟t do work, people do When we look at the current state of BPM, we see that a lot of companies are at the stage that they have documented their processes (often because of compliance regulations) in a certain form of flow charts. For relatively structured processes with a limited number of participants this works out pretty well. In some literature these processes are referred to as task-driven processes. Companies that are somewhat higher in the maturity path are now struggling with the next challenge: what to do with complex, unpredictable processes where we also have a lot of participants (human interaction): human-driven processes? Here the traditional BPM solutions seem to have their limitations: current mainstream techniques and tools for work support, whether categorised as Workflow or as Business Process Management, deal only with "mechanistic" business processes [9]. The need for something more structured than email and less prescriptive than workflow can be understood by considering that in real life, the resource negotiation phase of work is only the start of the person-to-person process. After work is agreed, it has to be performed. This sounds easy, but is not as simple as checking off tasks on a list. Numerous other people – probably from a number of departments - are likely to be involved, and each participant is a potential source for disrupting the process. For example, by failing to meet timescales or the process may be delayed by factors outside of their own control. When performing agreed work by executing processes, one often sees that this process execution in itself requires the creation and execution of new processes among team members, each of which represent additional loops in the end-to-end process. At each stage, those requesting work and those performing work need to agree that work items have been satisfactorily completed. This sign off may also be subject to further interactions and negotiations since the work results may involve compromises. We see Human Interaction Management (HIM) as a likely solution for the “shift from Transaction to Interaction” [10]. HIM not only deals with tasks, but also with those aspects of work visible from inside - information, interaction and innovation. It is the interaction among workers as they process diverse work items, cases and documents that is the focus of attention. Paragraph 2.7 will be addressing details about this subject. 3.5.2 Process-on-the-Fly™ Closely related to the trend of designing for agility (paragraph 2.1), is the Process-on-the-Fly™ concept. “Organisations will need to change their processes in near real-time to quickly reflect and accommodate changes in the business ecosystem.” [10] State of the art (service-oriented) solutions will enable to quickly simulate, describe, model, execute and manage business processes, responding to business-critical events the moment they occur. Especially the 68
  • 75. | the way we see it front office (client facing) functions of organisations will have to deal with this, because there the dynamics of change are the biggest. In our point of view BPM is pre-eminently the working field that can give an answer to this Process-on-the- Fly concept: the future BPM professional has to design flexible processes, to provide organisations with differentiating capabilities to deal with a volatile business context. Comparable with the SaaS (Software as a Service) concept, we see the development to a kind of Process as a Service. One can already see that BPM vendors have picked up this trend as well: „plain‟ business process modelling tools have evolved to „orchestration engines‟ and „choreography platforms‟ that provide ways to construct dynamic processes. Cordys (vendor of next generation BPM solutions) is a good illustration for this: they use the term “on-demand BPM” in their Cordys Process Factory™. This way of process design also requires more need for process management in the means of having process performance indicators in place to measure to what extent the processes perform as expected and possibly require redesign. Continual process improvement methods like Lean (refer to paragraph 2.3), applied to end-to-end business processes thus finally can become a reality. Furthermore, business rules engines enable organisations to isolate their critical business policies and logic from monolithic systems, defining and changing the rules externally, often with a „language‟ that is much closer to business speak. Extracting business process logic and business rules from existing legacy systems is a proven approach to achieve more flexibility and simplified, more manageable core solutions at the same time. Business Rule Management (BRM) by the way is a major trend in its own. The recognition that processes (in their functionality – what they achieve) rarely change, but the rules that „steer‟ the process change constantly result in initiatives to separate both. That the use (and management) of business rules is hot is endorsed by the fact that it is a recurring subject in several of the chapters. 3.5.3 Process scenario analysis A generic definition of business process simulation is "an experimentation with a simplified imitation (on a computer) of a business process as it progresses through time, for the purpose of better understanding and/or improving that business process" [14]. Although simulation tools are around since the eighties, it never really boomed. In more recent history a lot of customers put process simulation on the requirements list for their BPM tooling. In the end however, a lot of processes were modelled, but hardly ever were the processes simulated. To illustrate this: less than 5 percent of the customers that IDS Scheer (vendor of business process and performance management software and solutions) has, have bought the process simulation module of the BPM-Tool ARIS [15]. The reason why process simulation is rarely used seems to be twofold: on the one hand there is the complexity to setup process simulation and the time it takes to collect the often detailed information required for the simulation model. On the other hand process simulation requires a certain level of process maturity that has not been reached by many organisations nowadays. 69
  • 76. | the way we see it A prerequisite for business process simulation is an explicit business process model that requires a lot of information about the process parameters (numbers, cycle times, distribution, etc). In our opinion however, the combination of having real-time process information available (refer to chapter 2.6 Process change on (big) wheels) and state-of-the-art simulation tooling that is able to quickly make scenario analyses, will become of great value in making (strategic) business decisions. The coming years we expect process scenario analysis, to become a more accepted aid for managing change and Business Transformation™. Process scenario analysis will be used in the „traditional‟ way as an aid for quantitative issues. But it cannot only help analyse the current state situation (and identify bottlenecks in inefficient processes), evaluate future state scenarios and perform „what-if ‟ calculations. It also founds management decisions in a way that prevents uncertain investments and without actually interrupting the operations. And in addition to this, all the advantages of process scenario analysis have one very welcome side-effect: the reduction of risk. 3.6 Recapitulation BPM is a living and developing discipline. Companies are more and more aware about the benefits that can be achieved by treating BPM as a management discipline. In our opinion however, organisations cannot make the desired steps in BPM maturity – and thereby frustrating the growth to dealing with BPM as management discipline - without paying attention to the BPM infrastructure. Starting point before putting any efforts in BPM should always be the question “what is it that I want to achieve with BPM?”. Otherwise it will be a long road to nowhere. In this book a number of trends in the BPM working field are described. In addition to these trends we think that there are a couple of future developments that we see as having large potential:  Human Interaction Management as a way of dealing with complex, unpredictable processes where we also have a lot of participants (human interaction);  Process-on-the-Fly™ as concept for designing processes that are able to respond to business-critical events the moment they occur and  Process scenario analysis as a commonly used aid for managing change and Business Transformation™. Literature [1] BPM as a Management Discipline, Gartner Business Process Management Summit, 2006 [2] Business Process Management in the Netherlands – Capgemini & Hogeschool Utrecht, 2008 [3] BPM Maturity Model Identifies Six Phases for Successful BPM Adoption – Gartner, 2007 [4] The Process Audit – Michael Hammer, April 2007 issue of the Harvard BusinessReview [5] Business Process Management, Market-IQ research - AIIM, 2008 [6] Gartner's Position on Business Process Management – Gartner, 2006 70
  • 77. | the way we see it [7] Evaluating an Organization's Business Process Maturity – Paul Harmon, Business Process Trends March 2004. [8] Hype Cycle for Business Process management, 2008 – Gartner, 2008 [9] Human Interactions: The heart And Soul of Business Process Management – Keith Harrison Broninski, 2004 [10] Technovision 2012, Capgemini, 2008 [11] Drive BPM Initiatives To Higher Business Value – Forrester (Connie Moore), 2008 [12] Demand for Business Process Management Suites will accelerate trough 2009 – Forrester (Ken Vollmer, Connie Moore), 2007 [13] The state of Business process Management - Paul Harmon, Celia Wolf, 2008 [14] Simulation: The Practice of Model Development and Use - Stewart Robinson, 2004. [15] An insight in the world of process simulation - Guyon van de Giessen, 2007 [16] Predicts 2008: Business Process management Alters Business and IT Collaboration – Gartner, 2007 Hans Toebak is Principal Consultant within the Operational Excellence practice of Capgemini Consulting. 71
  • 78. About Capgemini and the Collaborative Business Experience Capgemini, one of the world‟s foremost providers of Consulting, Technology and Outsourcing services, has a unique way of working with its clients, called the Collaborative Business Experience. Backed by over three decades of industry and service experience, the Collaborative Business Experience is designed to help our clients achieve better, faster, more sustainable results through seamless access to our network of world-leading technology partners and collaboration-focused methods and tools. Through commitment to mutual success and the achievement of tangible value, we help businesses implement growth strategies, leverage technology and thrive through the power of collaboration. Capgemini employs approximately 68,000 people worldwide and reported 2006 global revenues of 7,7 billion Euros. The Capgemini Group is headquartered in Paris. Colophon Editors: Frank van den Ende and Hans Toebak Capgemini Nederland BV P.O. Box 2575 - 3500 GN Utrecht The Netherlands Telephone: +31 30 689 00 00 Fax: +31 30 689 99 99 E-mail: Copyright © 2009 Capgemini. All rights reserved. 72
  • 79. Capgemini Nederland B.V. Papendorpseweg 100 Postbus 2575 - 3500 GN Utrecht Tel. 030 689 00 00 Fax 030 689 99 99