- 10 November, 2003 11:55
Ideally, companies should be able to quickly automate their business processes while also being nimble enough to optimise those processes over time. In practice, companies often find themselves bound to the business rules hard-wired into their enterprise applications.
When the Defence Housing Authority (DHA) began examining issues around its business-IT alignment and change management framework late last year as a prelude to re-engineering part of its business, it found some of those issues irresolvable. Or rather, they were irresolvable until it adopted a business process methodology known as ARIS (Architecture of Integrated Information Systems), which gave it a way to articulate organisation processes, infrastructure, data and outcomes and the linkages between them.
According to DHA quality assurance consultant Alistair Brooke, using ARIS was like "turning a lot of light bulbs on" in the minds of regional managers. Being able to make visible some highly complex processes helped grab the attention of senior and business managers whose traditional focus was performance and the bottom line, and shifted their thoughts towards an entirely new mind-set.
"I think really the critical thing is that visibility, because visibility creates awareness," Brooke says. "People are simple, they like things being simple, and unfortunately most of our business processes aren't. Even where we do acknowledge there is some degree of complexity, people will always have a simplistic view until you actually can see a process in its entirety. And I think that was the thing that really turned a lot of light bulbs on."
Needing to put a microscope to its relocation process as a prelude to some significant changes, the DHA found that communicating those processes, not only across different business lines and people but also geographically, was a vital first step both to achieving the needed changes and to getting all managers and employees to adopt a process mind-set, Brooke says. And in the evolution to business process management (BPM), that is precisely the name of the game, according to Queensland University of Technology associate professor Michael Rosemann, who is also director of the Centre for IT Innovation.
Rosemann, who recommends ARIS, says having made real progress on implementing integrated applications, Australian organisations must now strive to ensure business process management becomes as much a part of the mind-set of every manager as cost management or leadership. He says the huge upsurge of interest in BPM over the past 12 months in Australia shows many organisations now understand the potential it provides for significant organisational performance improvement. And that potential is very real. For instance, after just three weeks raising the DHA's awareness of business processes, Rosemann's team had helped it identify more than $2 million in savings.
"The message is you can significantly improve the performance of your organisation," Rosemann says. "Thinking in processes should be something every manager executes on a daily basis. Most companies are a long, long way from that, but we see a kind of momentum. It seems like after GST, Y2K and ERP implementations the focus is shifting from reactive IT problem management to proactive business IT alignment (Where do business and IT come together? and Where does it actually make an impact?).
"So instead of thinking: 'Let's approach e-procurement', [it's now:] 'Let's look into how we do procurement in the first place and let's improve that process.' Then later on down the track it's: 'Let's talk about some kind of e-procurement.' "
Business process modelling is a core activity within business process life cycle management processes. And BPM is increasingly where business meets IT, Rosemann says. "When it comes to an IT implementation, there are well-defined pathways and methodologies," he says. "BPM, however, is where business meets IT. As part of BPM you can ask yourself: 'Should I automate this? Should I outsource? Should we change accountability/responsibilities?' So you need a mind-set that can combine workflow management and balanced scorecard, ERP and activity-based costing."
Rosemann says although this is a very new and much more holistic way of thinking for most CIOs, such thinking must eventually extend across the entire organisational hierarchy.
Rosemann began thinking about business process re-engineering (BPR) while involved in preparations for an SAP implementation in Germany in 1993. Heavily influenced by Michael Hammer's work on BPR, the team began by doing quite a lot of business process modelling, but became distracted once it got its hands on SAP. The trouble was, Rosemann says, like most organisations this one found the early awareness of BPR could not be followed up until it had "cleared up its IT landscape".
"From 1993 to 1996 we saw a lot of SAP implementations in Europe where initially we looked into processes and realised later it was all too complex to do BPM and ERP implementations at the same time," he says.
At the time most implementing companies were still based on functional silos and were hesitant to institute collaboration between those functional areas. Not until they had achieved effective integration of their major applications were they in a position to start thinking about business process, redesigning their company around business processes, and designing and selecting IT solutions based on business process-related criteria.
Australia has lagged behind Europe in this area, but Rosemann says the situation is changing fast. Perhaps 20 to 25 major Australasian companies, including Australia Post, BP, the Commonwealth Bank, Woodside, Health Insurance Commission, Centrelink, Ford Credit and Television New Zealand have implemented ARIS over the past two years. Others are striving towards BPM using other tools and frameworks.
Business process modelling is a core activity within business process life cycle management. Rosemann, whose postgraduate students also have been helping many Australian companies to examine their business processes and come up with ideas for improvement, says business process models provide a bridge between IT and business as organisations seek ways of aligning future IT opportunities to business expectations.
"We literally take postgraduate students to many companies here in Brisbane and have a look at various business processes. After a few weeks we always come up with significant improvement ideas," he says. "But companies traditionally still very much believe in their functional silos, and hesitate to collaborate between these functional areas. The idea of business process modelling is to increase the awareness, the appreciation for the idea of business process management."
Rosemann says although Australian organisations have done some process modelling, their efforts have typically been fragmented and patchy. "Wherever we go we find process models or related tools but there is often no overall enterprisewide approach," he says. "As part of a continuously increasing BPM maturity it will be the next challenge to roll out the BPM idea in an integrated and standardised way within and beyond the enterprise."
He says in Europe this new emphasis on process has seen many CIOs take on the new title of chief process officer (CPO), in recognition of the need for the technology head to support the business processes. It is something Australian organisations might do well to emulate and would be a recognition that CIOs must understand that it is possible to improve processes, but that IT is not always the only vehicle to achieve this.
Those wanting proof should look to what is happening in Asia and Europe where there is a far higher level of business process management maturity. Rosemann says in those regions many organisations have replaced the concept of doing requirements specification as a prelude to developing software (a software-centred modelling approach) with a business modelling approach where business and IT aspects are both modelled. Although there is no guarantee such an approach will always reap a benefit, if an organisation has never looked across its functions, that exercise is almost certain to pay off.
"We like to say it's like finding a room that has been closed to you thus far, and now you open the door and there is definitely something of interest for you. If you look across functions, you definitely find potential for improvements," he says.
Rosemann's postgraduate students try to help organisations adopt a more holistic approach to process thinking. Rosemann says their experience demonstrates the clear benefit that can come from adopting a more comprehensive picture of organisational processes. And that means not just examining the organisation's IT-related interfaces, but also its organisational interfaces: such as where person A does not know what person B is doing, or where application A holds certain data and application B holds the same data unnecessarily.
"Our aim is to increase the awareness for the importance of business processes, help organisations to understand their business processes, and then together with them ask what can be improved. Some ideas are purely HR organisational ideas, and some of them include the reconfiguration of an ERP, or the development of new applications."
Relying on Intuition
When it comes to successful BPM efforts, Rosemann says it is important that the BPM framework be adapted to the organisational culture, rather than trying to distort the culture to fit the framework. To achieve this, the organisation must remain in the driver's seat, must adopt an intuitive approach and must ensure that involvement of employees extends from the operational level right through to the CIO.
He says there is substantial value in aligning your Balanced Scorecards with those business processes. There is a tendency when it comes to process modelling, he believes, to develop endless process descriptions. Many companies use their process models as a kind of wallpaper, leaving the CIO to wonder whether there are any real benefits to be gained from the exercise. But when business process analysts develop models and comprehensively analyse their processes, CIOs want to know how that work will support their business objectives. Will the process be faster? Will it be cheaper? Are there areas where the organisation will become more customer oriented?
Using Balanced Scorecards makes it easier to describe cause and effect relationships and determine how one objective is likely to impact on another. Graphically demonstrating the relationships between Balanced Scorecards and process models lets the CIO see the big picture and better communicate objectives and strategies, and makes it easier to navigate between business processes. It gives the CIO a very concrete way of thinking about achieving that alignment, Rosemann says.
"The CIO doesn't want to see 200 process models. The CIO wants to have a 10,000 feet picture: So okay, here are your core and enabling processes, here's the linkage to my Balanced Scorecard, but if you want, I can take you the whole way down to the detailed business process description."
Rosemann says the early phase of the BPM work - where project teams analyse the current processes, shape their ideas and specify requirements - is the most significant phase of the business process life cycle, and has the most influence on costs. "This is where I shape my future business," he says.
Yet he says too many organisations willing to spend huge amounts at the end of the exercise stint at the beginning. Many companies seriously underestimate the number of processes they have. When they try modelling their processes in Visio or PowerPoint they find themselves pushing the software to its limits, until the tool itself becomes a limitation on their work. "Go to the top 50 companies in Australia and 49 of them are in that situation," he says. "We really see this learning curve."
Using a more mature BPM tool helps overcome those limitations and also helps organisations as they go through the learning curve.
It is also important for organisations to adopt a life cycle approach to BPM, Rosemann says. Too many companies adopt a one-year time frame, and expect that buying new software will fix all their problems.
"So many companies thought SAP stood for 'Solution to All Problems'," he says. "So you talk about their shortcomings and they will tell you: 'In one year we've got this new piece of software coming and everything will be better.' This is a clear over-estimation of IT capabilities. We like to say: 'Well, talk about what happens in two months. What happens without a service level agreement, without a Web-based solution? What can I do in the short term?'
"At the same time we like to leave them with a three-year out picture - like at the Health Insurance Commission in Canberra, we did some work and designed a process model for the year 2005, where we say: 'Okay, have some kind of a carrot, what are you aiming for?' "
Once and Future Benchmarking
The message is that BPM should never be done as a one-off process. Instead, the organisation should have a process that describes what it would like to achieve in future years and should employ both a current and ongoing benchmark for its BPM-related activities. The term "business process maturity management" describes such an ongoing effort, which aims for increased competence and capability in the management of business processes.
So follow-up is vital.
"Our experience is that it is one thing to go to a company, do some modelling, get stakeholders excited and involved, and come up with ideas of what can be improved. We might leave the organisation with an idea for how they save $2 million, then come back a year later and find nothing has changed," Rosemann says. "And I think this is what you also see very often: You've got people who are creative, who come up with the ideas, but actually changing the organisation, doing something, executing ideas, implementing ideas is a completely different story of course.
"So you've got great ideas, but then you've got culture barriers, you underestimated certain issues. So we really see this as three main steps: awareness, design and implementation. First is to get the buy-in, get the awareness: 'Why should I be interested in BPM?' The second step is to understand the processes and what can be improved, and this is literally still in a modelling tool or a piece of paper. And the third step is the actual implementation of the redesigned business processes. And of course this presents a complete new challenge."
All BPM activities should be conducted with an eye to the future, Rosemann says. Five or six European organisations are already heavily into process performance measurement, or business activity monitoring. The idea is that once the organisation has implemented its BPM process, and has a workflow, document management system and ERP, it is quite cost effective to extract data so that the CPO can gain information about the speed, cost and quality of processes. But most Australian organisations should see this as something to aspire to, not something to achieve in their early BPM activities.
"I think for most Australian organisations this goal is far down the track, because it really requires that you have got a more integrated, process-oriented IT infrastructure that can extract data. But I think this is something that will come and will then satisfy the information needs for the new CPOs," Rosemann says. "And I think it is good for the organisation to be aware that this capability will exist as an opportunity at the start of the exercise."
True Process Automation
At the DHA the framework is helping with efforts to align business models with IT development models. Brookes says the theory is that if they can create the right interfaces, changing just part of a process will lead to the automatic creation of an application development template.
"That will require a lot of resource, and a lot of detail, so we're not saying we'll be able to magically do it, but that's the peg in the ground. [If we can achieve it] that's pure alignment, because then you're automating that development part of it. Now there's a lot more to it, and that's taking a very simplistic view, but even if we get part of the way there, we're going to dramatically speed up that application development process," Brookes says.
"That whole process of IT change that many businesses go through, which is fairly costly, fairly time consuming, we can speed that up, and that's going to bring a lot of bonuses just by doing that."
In the meantime he says the DHA has learned that getting a handle on process is a process of discovery in itself.
"Most find that a lot of processes within an organisation are really implicit within that organisation," Brookes says. "We have a legacy systems architecture. Whenever they were installed there were probably good intentions, and it was all fairly well documented. But as time goes on, policies change, procedures change, and then those policies and procedures become ingrained within an organisation, and you then sort of don't have that visibility. You lose it, and you start doing things because that's the way it was always done.
When you really discover where all those processes are - and ask the question: 'Why are we doing that?' - you really can come up them with a set of processes that you know are essential, and you've really got justification for them," he says.
"You have a lot of quick wins just by that process of discovery and looking at where you have kinks in your processes," Brookes says.
Business Process Modelling Is Gaining Speed
SIDEBAR: Analyst View | By Carl Zetie, Forrester
The most important question to ask in selecting a business process modelling (BPM) tool is: What will you do after modelling?
In the past, BPM was often unfairly tagged as an abstract or esoteric discipline conducted by business analysts in pursuit of some higher goal: In the 1980s, for example, it was "quality improvement"; in the 1990s, "business process re-engineering". Today, BPM has a far more widespread role to play in many more enterprises. Increasingly, organisations are adopting business process modelling as a precursor to some other activity, such as business process integration. Pragmatically, BPM is now more widely understood as a means to an end, essentially as a higher-level model of some other activity, and that end goal will be critical in selecting the right tool.
The purest (and most traditional) use of a BPM tool is still by people who are "true" business analysts, sometimes with little or no IT knowledge. They build models of both the "as is" business flow and the "to be" business flow, largely or entirely free of implementation details in the IT sense (and at the highest level, even the assumption that a process is necessarily automated). The modeller works with line-of-business managers and others who understand the operation of the business to develop models not only of processes but also of assets, organisations, roles and hierarchies. The models are usually enriched with information about associated costs (both in time and money) to identify the value of potential improvements. Sometimes, the lowest level model that this person creates resembles the highest-level models of a traditional systems analyst, but not always. The purposes and objectives of this kind of modelling include identifying potential organisational efficiencies and modelling and testing potent ial cost savings.
The second use of BP models is as a precursor to some other, often IT-related, activity, to gain a better understanding of the true business requirements before embarking on implementation. One common objective of BPM in this sense is building higher-level models before embarking on design models; for example, in Unified Modelling Language (UML) use cases and essential class models. These users are really doing what used to be called systems analysis; many of the better tools for this purpose are direct descendants of former CASE tools.
Most recently, BP models have gained attention as a means to visualise application integration such as EAI and BPI. It is essential to understand integration flows at a business level before trying to automate them. BP models are often a more business-centric way to do so than the lower-level, more implementation-centric models often incorporated in the EAI tools, which are often more focused on the physical rather than the conceptual integration.
There is also growing interest in the promise of "automatically" transforming from BP models to application integration models and thence to implementation, and a number of proposed standards are emerging to support this aim. However, organisations should be very wary of any promise of totally automated transformations. Database administrators apply essential physical optimisations to the design before implementing the data model created by an analyst, and the same is true of business processes. Both the business analyst and the system designer have an essential role to play, but at least they increasingly have a common language.
Carl Zetie is a vice president and analyst in Forrester's Application Development & Infrastructure research group (US)