Who's the boss of BPM?

Who should take responsibility for a business process management (BPM) initiative - management or IT? An ostensibly simple question with a complex answer.

Business units are largely concerned with operational efficiencies, according to Steve Keys, SVP Asia Pacific and Japan, Middle East, North Africa and Turkey, Software AG, but the big IT trends of mobile, social, cloud and big data are presenting challenges and opportunities. They want to reduce costs and deliver on customer expectations, and business process management (BPM) can help improve agility, customer experience, and differentiation.

But BPM can be overkill for a few simple workflows, said Sean Hooper, APAC enterprise architect at Oracle, suggesting that it comes into its own where multiple people and systems are involved, especially when a process crosses boundaries between organisational units such as departments. BPM can help by enabling more efficient handovers between the people involved, even where some of the steps are outsourced, he said.

Stephen Schwalger, business development manager at Pantha Corp noted that, while BPM is good for repeatable processes, organisations should beware of trying to apply it to complex situations requiring judgement.

BPM: not just technology

BPM is not just about workflow, and not just a technology, said Russell Gordon, practice director - business process, UXC Eclipse: “technology is just an enabler”. An organisation needs to align processes with its strategic vision, and then define and design processes from end to end.

For a BPM project, IT should be technology agnostic at the outset, focusing instead on the business objectives before deciding what technology is appropriate. The order is “people, process, technology”, he said.

Peter Jarman, architectural lead ANZ, Infosys, emphasised that any necessary re-engineering, alignment, and organisational restructuring should occur early in a project before IT gets involved.

IT or business driven?

While there are some circumstances in which IT can usefully take a leadership role in BPM, the consensus seems to be that it is generally best if business managers are at the helm with IT management providing support and influence.

Keys said a BPM project at New Zealand-based dairy company Fonterra was driven by the IT department knowing what could be achieved. One of the situations the project addressed was logistics delays. For instance, if a ship scheduled to transport a batch of fresh products was going to arrive in New Zealand three days late, that could mean the product would be too old when it reaches its destination, so that batch would be redirected to the domestic market. Automating that process meant integrating all of Fonterra’s and its logistics providers’ systems to allow the right decisions to be made.

Dan Ternes, regional CTO at Software AG, said people on the business side of an organisation often don’t know what’s feasible, so IT has a role in showing what’s possible. “But in this day and age, initiatives come from business people. It’s their budget, their problems.”

So the challenge for IT is moving from a ‘control’ to a ‘support’ mentality, suggested Schwalger. If a BPM is driven by IT, the organisation’s internal structures aren’t usually right for that to be successful and so an ‘enabler’ perspective is required instead.

IT-driven approaches aimed at providing a platform for the business can be great from an infrastructure perspective, but aren’t necessarily grounded in the actual business problems, said Russell Ives, business process outsourcing lead, Accenture Australia. For example, a business unit may have cobbled together a workflow that’s difficult and therefore expensive to unpick into the new platform, so the alternative is to redesign the workflow.

An increased emphasis on solving issues within a business unit results in more tactical solutions, he warned. While this may yield good outcomes from the point of view of someone working within the unit or that of a customer - for example, fewer hand offs within a process usually mean greater efficiency - from an enterprise perspective the results can be sub-optimal.

Another problem with projects driven by an individual department is a lack of visibility of related processes elsewhere in the organisation, said Ternes. This can result in a hospital kitchen delivering a meal for a patient who has been taken for an X-ray, for instance. He describes such situations as being “blinded by white space”.

One way of avoiding these situations is to adopt a structured approach so that processes receiving attention from a business unit are mapped onto the organisational value chain, said Jarman. That reduces the risk that an improvement in one unit will have a greater negative effect elsewhere, and it will also help select the projects that deliver the best ROI to the organisation.

It is up to the business to take this organisation-wide view, he said. IT can be an influencer, “but honestly, they should not be the driver”, though he concedes there are rare situations where IT management does understand the business better than their line-of-business colleagues.

Gordon’s view - based on UXC’s experience of which projects are most successful - is that business systems managers have a central role in checking that proposed department-level purchases fit the organisation’s overall plan, and they may have to tell departments to hold off for a few months as another project in train elsewhere will provide required functionality. They need to be able to ask the right questions about objectives and other related activities, talk to IT to see how it fits into the strategy, and then prioritise the various projects.

This team of managers should comprise a cross-section of IT and business people, he said. While they should report directly to the CIO they need to work independently of IT as their task is about aligning IT and business strategies - “an independent team sitting on the side” that’s involved in any project involving IT - and that requires support from managers in the various departments.

Dealing with the pace of change

A recurring issue in IT is that the traditional six-month or longer development cycle is no longer accepted by business units, leading to the adoption of agile practices, or in some cases, business units turning to SaaS rather than software operated in house.

The existence of “pockets of automation” and the lack of a “joined-up strategy” are usually signs that the organisation is dissatisfied with the IT department’s agility, said McCormack. But when individual business units acquire technology, they get short-term relief but it typically doesn’t deliver on the longer-term promise, he suggested.

When business units are under cost/efficiency pressure they need rapid deployment and rapid return, said Ives, and if IT can’t deliver, they will go it alone. IT needs to combine a strategic platform with quick delivery, so he suggests the creation of ‘tactical response teams’ to provide rapid rollout of BPM to the various units.

Jarman points out that a BPM project specification does not need to be 100% complete before implementation begins. Indeed, that may be wasteful as some sub-processes such as exception-handling routines may disappear under the new system.

Business requires rapid change, and IT leadership needs to transform the department to an advanced services unit, otherwise business units will look outside the organisation, potentially duplicating the effort, warned Schwalger. This is happening, and happening quickly in some large organisations (driven in part by cloud services) so IT needs to adapt.

An example of such services is Concur’s offering for managing travel and expense processes, which can be set up in hours even by a CFO - including integration with finance systems - said Marten Jaggers, managing director, Concur. But he said there is still a role for IT departments because of the benefits of connecting with other systems, such as CRM (eg, to access customer information, and to record spending on visiting the customer), time and billing, human resources and project management. This can be a big productivity gain for IT, Jaggers suggested, and an even bigger one for the business unit concerned.

Another way of speeding-up implementation is through vendor-supplied predefined best-practice processes. Oracle, for example, provides ‘accelerators’ for specific sectors such as finance, government and utilities, as well as for common functions such as service requests, procurement, and password reset, and its partners, including Capgemini, also offer catalogues of pre-built processes. In both cases the processes can be customised if necessary, saving time compared with starting from scratch. “This is a step in the right direction,” suggested Hooper.

Keys notes that some processes may be implemented in existing applications, but it’s better to have them in a separate layer, with the necessary integrations with the various applications.

That said, the BPM capability provided by the incumbent enterprise software vendor may be the way to go. Hooper gave the example of Yarra Valley Water, which broadly adopted Oracle technology while still using certain applications (eg, asset management) from other vendors. Using Oracle BPM to process infrastructure requests from urban developers was much cheaper and “certainly much more lightweight than a commercial [BPM] application”, he said.

But Gordon said organisations that implement ERP and then use the ‘best practice’ processes supplied by the vendor, without determining their unique requirements, may miss out on addressing those unique requirements. It is better to do strong analysis upfront, defining requirements and design processes to suit, and only then worrying about the technology. Excellent results have been achieved where process was the key driver, he said.

The agile approach allows quicker wins, and avoids the problem of delivering after the business requirements have changed, he said, suggesting organisations focus on one process or a few processes at a time, get them right, then move on to the next small set.

Tools help bridge the divide

One way to bridge the IT/business divide is to use models that are understandable and useful to both sides.

While a BPM project often “creates a lot of tension” between the business units involved and IT, Luke McCormack, vice president APAC, Pegasystems, said his company uses a model-driven architecture that allows the definition of rules, service levels, user interfaces and other aspects in a way that can be driven by business users. Then Pegasystems’ product generates the code that implements the model. IT is not disenfranchised, he said, as it still works with the business users, handles integrations with other systems, and other aspects that require a technical slant.

A situation where a business unit provides IT with a specification and doesn’t see the result until it is ready for acceptance testing is not good, said Jarman, who advocates a more collaborative relationship between IT and business.

Business process model and notation (BPMN) can play a part, he suggested. BPMN can become embedded in the business side, and then IT can take care of the implementation - especially the integration with other systems - according to the specifications produced by the business unit. Then, over time, IT ends up with a catalogue of services that the business uses for BPM projects.

Image credit: ©iStockphoto.com/violetkaipa