White paper - Oracle · To use the cooking analogy, ... Computing I white paper l sponsored by Oracle + Estafet 5 ... Process with the lowest number of knock-ons to other processes

>> White paper

Cooking up successful business process management: A tactical approachApril 2012

Preparing the ingredients for a successful BPM project

Sponsored by

Cooking up successful business process management: A tactical approach

2 Computing I white paper l sponsored by Oracle + Estafet

Contents

Executive summary ............................................................................................................................................................. p 3

Introduction .............................................................................................................................................................................................. p 3

Choosing the process ........................................................................................................................................................ p 4

Assembling the ingredients .......................................................................................................................... p 6

Choosing the methodology ............................................................................................................................. p 7

Anticipated impact ................................................................................................................................................................. p 9

Metrics ....................................................................................................................................................................................................................... p 10

Involving stakeholder groups................................................................................................................... p 12

Conclusion ...................................................................................................................................................................................................... p 13

About the sponsor, Oracle................................................................................................................................... p 15

About the sponsor, Estafet .............................................................................................................................. p 16

© This document is property of Incisive Media. Reproduction and distribution of this publication in any form without prior written permission is forbidden.


Computing I white paper l sponsored by Oracle + Estafet 3

Executive summary

Before conducting an intervention as complex as business process management (BPM), and enabling this by purchasing and implementing a BPM Suite (BPMS), it is vitally important that all of the key ingredients are in place. These include choosing a BPM project with high impact and low risk of failure, deciding on metrics and KPIs, selecting a methodology in keeping with the project and the business, and forming multi-disciplinary steering groups and committees of those who will drive the project forward.

Drawing on the responses to a survey conducted by Computing, this report looks at how all these ingredients are brought together in the real world, what the most popular choices are, and why the early stages of a BPM project are the most important.

Introduction

When considering business process management (BPM) there are decisions to be made on both strategic and tactical levels. This paper deals principally with the tactical.

Strategically, the business has to decide whether the BPM approach is right for the organisation in terms of risk and return on investment. An organisation may not be ready for – or have the executive time to devote to – the deep-dive and extensive analysis that this requires. A concise assessment of the organisation’s suitability for BPM is therefore sensible. This would consider whether the organisation’s services are of such a kind that they would benefit from the optimisation and flexibility which a process-centric approach delivers, and whether a shift to a BPM Suite (BPMS) is a suitable and necessary change to its infrastructure. If adopted, an initial BPM project should follow a strategic decision as a proof of concept.

Whatever the motivation for the BPM project, it is essential that it is approached in a way which increases the chances of its success, or the organisation is unlikely to sanction further projects.

This approach can be likened to that of a chef preparing a meal. He has to choose a dish to satisfy his customers’ appetites, assemble the ingredients, choose how to cook them and gauge the reaction of the diners to his meal.

So with BPM projects: the process has to be chosen, a methodology adopted, the elements of the project assembled, metrics agreed, and collaboration between business and IT structured appropriately.



Choosing the process

Clearly one of the most critical decisions to be made in any BPM project is the choice of the business process.

The complexity of the business process and its criticality to the organisation tends to equate directly to risk. Thus choice of process involves a trade-off, especially if the organisation is new to BPM and/or sceptical to the idea of BPM.

To use the cooking analogy, choosing the process is like choosing the dish. A complex dish carries a high risk of failure but will be gastronomically spectacular if accomplished. A simple dish may not carry the kudos of haute cuisine, but if the chef is inexperienced then a mantra of ‘keep it simple’ may be kinder on the palate of those that have to consume it.

The sponsor of the BPM project will want the project to be a success and make a visible improvement to the business. In organisations comfortable with risk-taking among employees, it would be natural to choose a high-profile business process which has maximum impact on the organisation.

If successful, the BPM champion can bask in heroic status. Failure can be chalked up to experience and a less ambitious project chosen next time.

In risk-averse organisations, it would be natural to err on the side of caution and choose a low-profile process which, if successful, can be used as proof of the BPM concept, even if it makes little positive impact on the organisation initially. From this safe foundation, the BPM sponsor can progress to processes of greater impact, gradually building taste for the BPM concept. Failure can be quietly buried.

In reality, the culture in most organisations exists between the two extremes, or fluctuates between them, depending on the perceived success or failure of the most recent project.

Ideally, the BPM sponsor will want to select a process which is low in risk but high in impact, such as a customer support or help desk function; inventory, HR or transport management; or claims eligibility in an insurance firm.

These dynamics can be seen playing out in the responses to Computing’s survey of 100 senior IT professionals at large organisations (Fig. 1).



Fig. 1 : “How do you prioritise each BPM project?”

Most critical process 33%Highest impact process if the BPM project goes well 28%Most broken process 12%Current project planned to be run traditionally which we thought could now use BPM 10%Lowest risk process if the BPM project goes wrong 8%Process with the lowest number of knock-ons to other processes 7%Other 2%

One-third (33%) have opted for the most critical process, suggesting a make-or-break attitude to BPM, a requirement to fix the business quickly, or significant BPM maturity. Twenty-eight percent have gone for the process that will have the highest impact if the project goes well. Eight percent have chosen the opposite tack and selected the process with the lowest impact if the project goes badly.

Twelve percent have opted for the most broken process, and seven percent have chosen a process with the least number of knock-ons – possibly a wise decision given that process inter-dependence is one of the fundamental issues business process change programmes wrestle with.

A tenth have BPM-ised a project which was already under way using other methods.

The principles guiding the prioritisation of BPM projects by an organisation are likely to change over time as its experience of BPM increases. Choosing low-risk processes with the lowest number of knock-ons, or adapting already-running projects to use BPM, are thus more likely to occur in organisations which are just starting the transition to BPM. Process-oriented Organisations with significant experience of BPM can aim for enterprise-wide critical and high-impact processes with reduced risk and the expectation of a greater ROI.

The Process Excellence Network’s study Business Process Excellence: Trends & Success Factors 2012, discovered that over 50 percent of process improvement programmes have been running for 4 years or longer, while fewer than 15 percent have been running for less than a year, and just under 10 percent were still to be launched. Similarly, 46 percent had programmes were enterprise wide, while only 10 percent were running small scale pilots.

While the results are not limited to BPM programmes, this does highlight the importance of intelligently matching your selected process to your organisational maturity.



Assembling the ingredients

Before you start cooking, it is wise to assemble all the ingredients, lest something burn while you are rummaging in the fridge for crème fresh. And so it is with a BPM project: there are a number of items which need to be in place before the project can commence.

Among those surveyed, the largest proportion of the survey respondents (60%) are at the planning stage, with the remainder either in the midst of a project or evaluating and optimising the project.

For those 60 percent at the beginning of the project, it is interesting to see which ingredients they have already assembled. A team with the skills to execute the project is clearly a prerequisite and unsurprisingly the majority of respondents (55%) have this in place (Fig. 2).

Fig. 2 : “As part of planning for the BPM project(s), have you set up any of the following?”

* Respondents could select more than one answer.

A team with the required skills to execute the project 55%

A steering committee with representatives of IT and the business, or similar body 51%

Project-specific roadmap with key milestones 45%

Strategic roadmap with high-level business goals 45%

A firm budget for the project 39%

Progress review schedule with relevant business representatives 38%

A review of the impact the project will have on your current architecture 36%

Centre of excellence, or similar function 18%

Contingency funds for overruns 17%

None 14%

Other 1%

0 10 20 30 40 500 10 20 30 40 50 60



Selecting a process for a BPM project should be a decision made between IT and the business, including the process owners and higher strategic management. Maintaining dialogue between the IT department and the business is also essential throughout the course of the project. Again more than half of the respondents (51%) have got as far as establishing a steering committee with representatives from IT and line of business; 38 percent have established the schedule by which this group will meet.

A slightly smaller proportion (45%) of respondents have established the strategic or project-specific milestones for the project.

A firm budget for the project has been set by 39 percent, but only 17 percent have provided a contingency fund for project overruns.

Other ‘ingredients’ which respondents have assembled include: a review of the impact the project will have on the organisation’s current architecture (36%); and establishing a BPM centre of excellence, or similar function (18%).

Fourteen percent have yet to assemble any of the ingredients, perhaps because they are at the very early planning stages of their BPM project.

However, the fact that only just over half of respondents have a team with the required skills in place (with figures reducing for other key ingredients), highlights the need for increased organisational awareness of these ingredients in the early stages of BPM adoption.

That this constitutes a real risk of failure is borne out by the Process Excellence Network study referred to earlier. This showed that process improvement programmes which are at an early stage report the highest failure rates. Those of under a year’s maturity continue to be the most unsuccessful (nearly 35 percent, with only five percent of these being highly successful). This remains high (just under 30 percent unsuccessful) for those of two to three years’ maturity.

Choosing the methodology

Boiled, fried, roasted, baked, grilled or poached? The nature of the dish will help determine the technique required to cook it. But with some foods, several options are available for the same raw ingredients.

Similarly, choice of methodology will have a fundamental impact on any BPM project. Agile, with its iterative method of gathering requirements in an interactive environment, lends itself to BPM projects in large organisations where the requirements of multiple stakeholders need to be taken into account and the stakeholders kept abreast of ongoing development. Indeed, Agile is favoured by the respondents to Computing’s survey – 43 percent have decided to adopt an Agile approach for their BPM project (Fig. 3).



Fig. 3 : “Have you chosen/did you choose a methodology for the BPM project(s)?”

A much smaller proportion – 12 percent – have chosen to use a Waterfall approach. This approach is well-established and offers mature frameworks but is often regarded as too rigid for modern software development, with an increased risk of failure.

A significant proportion – 38 percent – have yet to decide on a delivery methodology, perhaps reflecting that they are at an early stage in the project.

Among the seven percent who have chosen ‘other’ methodologies, respondents mention Lean, Prince2, Processwise and methodologies specific to their organisation.

For organisations that are new to BPM, the very act of undertaking a BPM project may require a re-think of the methodology used for software development. In fact, fairly equal proportions of respondents say they have changed their previously adopted methodology for BPM as those which say they have not (31 and 28 percent, respectively). The largest proportion (41%) have not chosen a methodology yet, reflecting the fact that they are in the early stages of their project.

For those who have chosen a methodology, their choice has numerous drivers: for example, almost half (46%) have continued with a methodology previously used by their IT department, while 13 percent have used a methodology used for previous BPM projects; 29 percent have used a methodology for which the department had skills to hand. If the last meal you cooked was bacon rashers and your cooks are skilled with the grill pan, grilling will look like the most viable option for your next dish.

Other drivers include: the methodology which is deemed most suitable to the BPM project (33%); an integration partner who drives the methodology (12%); or using software which specifies the adoption of one methodology (also 12%).

Yes, Agile (43%)

Yes, other (7%)

No (38%)

Yes, Waterfall (12%)



As already mentioned, BPM projects do lend themselves to an Agile approach. This is because BPM, supported by an effective BPMS, significantly reduces the traditional barriers between design, development and improvement in a solution lifecycle. Processes can be designed, optimised, implemented and tested in smaller cycles.

BPM projects thus blur and challenge the distinctions between delivery and improvement methodologies and there is consequently a risk of confusing or conflating these when speaking of ‘methodology’ in a general sense. Solution optimisation is no longer something that happens after solution development, but constitutes a key part of effective BPM projects, facilitated by a common modelling language understood by both the business and developers as well as the simulation opportunities delivered by a BPMS.

It is important, therefore, to ensure that everyone is clear about what is meant by ‘methodology.’ Agile and Waterfall are not the same species of methodology as Lean, SixSigma, the Balanced Scorecard etc., and it is important not to conflate them while drawing on the best they have to offer.

BPM’s methodological challenge to existing delivery and improvement approaches thus highlights the importance of defining new ways of working to obtain the maximum benefit from process automation. Doing effective BPM implies change.

Anticipated impact

Whether low-risk or high, showing a positive impact on the business is vital for BPM projects. In our current cost-constrained economic climate, saving money or increasing productivity is most likely to be interpreted positively. Hence efficiency or cost reduction and productivity gains are the anticipated impacts of a BPM project most frequently chosen by respondents (64 and 63 percent, respectively – see Fig. 4).

Improving customer service levels (49%), streamlining internal processes (47%) and improving service delivery (46%) also score highly.

These results are broadly in line with the 2012 results reported by the Process Excellence Network where the “emphasis on demonstrating value for money is reflected in the overall goals of process improvement programs for 2012 – nearly 70 percent of respondents indicated that either increasing efficiency or reducing cost was a primary, secondary or tertiary driver for their process improvement program. However, improving customer satisfaction was the biggest primary driver for process improvement with nearly 40 percent of respondents citing it as the key goal”.

The fact that only 27 percent of respondents identified the maximisation of IT assets as an anticipated impact is interesting. It could indicate both a lack of understanding of how technology can facilitate effective BPM, as well as an important strategic gap in ensuring an alignment between business and technological transformation on BPM projects.



Fig. 4 : “What impact do you anticipate the BPM project(s) having?”


Metrics

The most experienced cooks can judge by eye the quantity of ingredients required for a dish. But with each new recipe, it is important to measure accurately.

With BPM projects, inputs and outputs need to be measured. Process performance monitoring should involve performance and workload metrics, gathered for process, activity and participant, and assessed against business-oriented key performance indicators. Ideally these would be presented on a dashboard for easy assimilation.

This is important not only in order to measure current performance, but to assess whether the BPM project has been successful or not. When defining expected benefits and KPIs it is therefore important to also set improvement targets. Measurement should drive improvement and serve the organisation’s business goals, rather than being undertaken for its own sake. KPIs which do not deliver value are either redundant or may constitute a drain on resources.

Efficiency/cost-reduction 64%

Productivity gain 63%

Improve customer service levels 49%

Internal processes 47%

Service delivery 46%

Compliance 28%

Maximise IT assets 27%

Knowledge/decision-support 22%

Introduction of web/multi-channel applications 20%

Supply chain changes 12%

0 10 20 30 40 50 60 70 800 10 20 30 40 50 60 70 80



Respondents choose to track a variety of metrics (Fig. 5), the most popular being delivery timeframe (59%). User acceptance milestones (44%) score even more highly among respondents than delivery to budget (39%).

Fig. 5 : “What are the agreed metrics?”


Other popular metrics include higher customer satisfaction levels (37%); lower cost (35%), shorter time to complete the process (30%) and improved knowledge management (32%).

Hard-edged metrics, such as increased sales (15%) and decreased head-count (14%) are less popular. Twelve percent have yet to set metrics, indicating that they may be at the very early stages of their project.

Delivery timeframe 59%

User acceptance milestones 44%

Delivery budget 39%

Higher customer satisfaction levels 37%

Lower cost to complete new process 35%

Improved knowledge management 32%

Shorter time to complete new process 30%

Functional prototype 26%

Increased sales 15%

Decreased headcount 14%

None yet 12%

Other 1%

0 10 20 30 40 50 600 10 20 30 40 50 60



Involving stakeholder groups

IT departments are sometimes accused of operating in a vacuum, developing systems with little regard for business aims. Like cooks preparing dishes which customers have not ordered, their restaurant is unlikely to stay in business long.

In BPM projects, it is vital to involve stakeholders at the beginning of the project and throughout development. In some organisations the stakeholder group may be littlemore than a line of business manager and a handful of users. But the chances are that in a large company, the stakeholders may include business managers at higher levels than the process owner. Other stakeholders might include enterprise, data, process and security architects; business process analysts; process developers; services, software and user interface developers; a quality assurance team; and operations teams, as well as end users.

In complex structures, BPM champions would do well to establish stakeholder groups appropriate to the organisational roles of different stakeholders and their varying relationships to the BPM project (as sponsors, managers, or ‘do-ers’). It is important to establish an open dialogue with all these stakeholders from the outset of the BPM project, and to keep that dialogue alive throughout development and during performance testing.

This is where an Agile approach often proves its worth for BPM projects. It enables not only effective and regular reporting to sponsoring stakeholders, but allows appropriate managers and do-ers from relevant parts of the organisation to participate in defining, reviewing and testing the evolving solution.

As we have seen, the respondents to Computing’s survey prove themselves to be a fair way down this road already (see Fig. 2 on p. 6). Thirty-eight percent have gone as far as to establish a review schedule with the steering group.

The effectiveness of these review meetings is difficult to assess without further investigation, but a reasonable measure of whether stakeholders are taken seriously is the frequency with which they meet (Fig. 6).

Fig. 6 : “How often do you plan to demonstrate progress in the BPM project(s) to business sponsors?”

More often than weekly 3%Weekly 15%Somewhere between weekly and monthly 57%Less frequently than monthly 15%They’ll see it when it’s finished 7%Other 3%



Among those who have planned this far, the largest proportion of respondents (57%) have scheduled meetings at a frequency of more than weekly but at least monthly. Fifteen percent are meeting weekly, while the same proportion do so less frequently than monthly.

Meeting that infrequently means the project could be way off course before the stakeholders have a chance to correct the error in direction. On the other hand, over-reporting is both time-consuming and can severely hamper the effectiveness of the delivery team.

Although only representing a small proportion, the seven percent of projects where the business will review the BPM project only once it’s finished, face a significant risk of delivering a solution that does not meet stakeholder expectations, and with no chance of correcting direction.

Conclusion

The first BPM project an organisation undertakes can be critical. Given that there may not be either the time or willingness in the organisation to engage in the broader process improvement and enterprise-wide value-chain analysis that often accompanies BPM, means that an initial project often has to demonstrate value with limited resourcing, with the validity of BPM as an approach hanging on the outcome.

A successful proof of concept will effectively demonstrate the benefits of BPM, empowered by the adoption of a BPM suite: the deployment of a common language by which the business can understand and define its processes; a means of more closely aligning business needs with their enabling technologies; flexibility with regards to process change and agility in responding to changing business requirements; live and up-to-date performance data, enabling effective performance management and appropriately targeted process improvement.

That means IT leaders should be prepared to run a BPM project as a proof of concept which show demonstrable benefits within a tight timeframe in order to achieve continuing business buy-in.

These constraints highlight the necessity of carefully selecting the right process, approach and resources to deliver as a proof of concept.

Choosing the process for a BPM project should thus be a collaborative effort between business and IT to ensure that business needs are met by the capabilities which can be realised within the defined time-frame and with the appropriate available resources.

An appropriate team needs to be assembled, a design/development methodology adopted, and the metrics by which the success of the project will be judged need to be agreed.



Throughout the project there needs to be a constant dialogue between the process delivery team and identified stakeholders to ensure the solution is fit for purpose and that expectations are managed and aligned throughout changing circumstances and priorities.

By following the right recipe, IT can thus ensure that BPM is a dish that the business will want to order more often.

In collaboration with our sister brand Computing, IThound.com offers an unrivalled survey-based report creation service. Employing the expertise of senior journalists in their respective fields, IThound.com creates co-branded professional reports, white papers and videos quickly and with the minimum of fuss, representing an efficient and cost-effective way of reaching your core audience. IThound.com hosts thousands of reports, web seminars and videos from hundreds of vendors and analysts. For more information about our surveys, content creation, video facilities and white paper hosting services call +44 20 7316 9529 or email [email protected].

mailto:info%40IThound.com?subject=

http://www.ithound.com



About the sponsor, Oracle

With more than 370,000 customers – including 100 of the Fortune 100, and representing a variety of industries in more than 145 countries around the globe –Oracle provides the world’s most complete, open and integrated business software and hardware systems.

Oracle has always developed technologies that customers use to manage information, streamline business processes and reduce the costs and complexity of managing their IT infrastructures.

Oracle’s solutions in business process management provide best of breed solutions to managing workflow, process integration, process analysis, process optimisation and control. Now achieving top rankings in analyst reports, Oracle BPM delivers support for process excellence but equally critically is fully integrated with all Oracle’s other software, specifically its business enterprise applications and high performance middleware.

A BPM solution built on Oracle provides its customers with a more complete, open and integrated BPM solution.

In addition to offering complete systems to its customers, Oracle builds leading hardware and software system components using technologies based on open standards – giving customers a choice. Customers can choose the complete system or have the option to procure and integrate leading software and hardware components from Oracle to meet their specific needs.

For more information:Visit: www.oracle.comPhone: +44 (0)8705 332200Email: [email protected]

http://www.oracle.com

mailto:uksales_ie%40oracle.com?subject=



About the sponsor, Estafet

Estafet provides companies with Business Solutions by using its expertise in Information Technology. We work with some of the best known companies in the UK to help them transform the way they do business and reduce costs through IT.

We have specific vertical business knowledge, products and solutions. We have a passion for technology and an open flexible approach to business.

Estafet work with companies to transform the way they operate. We help the organisation focus on their Business Processes rather than on IT applications. We implement those BPM solutions using Oracle Fusion BPM 11G and 10G products.

Estafet has BPM Specialised status within Oracle.

We work with customers to define the strategic and tactical work streams required to maximise value from a BPM approach. We create a BPM roadmap that shows the agreed vision and the steps needed to achieve it. We help select, plan and deliver an initial process for automation. We start simply, and gradually build up the complexity of rules, functionality and user interfaces using an iterative approach. Collaboration ensures this feeds into the customer’s BPM journey and organisational learning. We also enable the broader organisational change required for businesses to successfully adopt BPM through consultancy, transformation delivery and the development of appropriate BPM frameworks.

We believe quality and transparency go hand-in-hand, and our approach provides regular integration, testing, reporting and demonstration of success.

For more information:Visit: www.estafet.comPhone: +44 20 8614 7070

http://www.estafet.com

Documents

White paper - Oracle · To use the cooking analogy, ... Computing I white paper l sponsored by Oracle + Estafet 5 ... Process with the lowest number of knock-ons to other processes