Thursday, October 29, 2009

Agile approach to BPM / BPE / BPR

Continuing on the Business Process theme I want to think about what an Agile approach to BPM/BPR would be.

For me there are two scenarios: Business Process Management for new processes and the “re-engineering” version which looks improve existing processes.

In the first case the answer is: start small.
Don’t just look to develop a small piece of software;; look at the business you want to enter, look at the product or service you plan to offer. Find small pieces which can exist in their own right. Maybe you can start by offering it in a small geographic area. Maybe you can limit your offering to start off. Maybe you can shave off some of the frills to the offering.

Find the smallest possible product or service that you could enter the smallest possible market with. Build just enough (if any) technology to support that and enter the market. Then set about expanding your offering and you sales. As you do add the bare minimum of technology to do it.

Yes, its incremental growth. Yes, it is bootstrapping yourself to organic growth. That doesn’t look good on a business plan, doesn’t look good when you are GE and you need big new markets and big new products to make any difference to your balance sheet. Sorry about that.

It does mean the risk is less. It does mean you could fund a start-up to do it. It does mean you could make a lot of experiments to see which markets are attractive.

So it does mean you need to change the way you enter new businesses.

Second case: you have some existing processes at the moment.

Here you want to set in place a process of improvement. Not a big bank, sweep everything away but a million small changes that build to big change. Involve the people who are doing the work. Find out what they think would improve matters.

Perhaps you want to leave the IT to one side entirely to get get started with. See what changes and improvements you can make without any IT change. When you’ve made them use IT to cement the changes.

Again it doesn’t have the big bang mega-bucks appeal of the big project but its far more likely to lead to long term success. This is how you create and sustain a continuous improvement culture and a learning organization.

The traditional “Business process” mindset seems to view the business as a gaint state machine. It is the SAP teams job to help the people in that organization move through the states and transitions of that machine. This approach assumes “the big brains know best.” Which is exactly what has been discredited in the software development world but there is still an illusion that this can happen on the business side. Thats why we need an Agile approach to business processes even more than we need it in software development.

I keep thinking of Naked Objects. It seems to the Naked Objects approach could be a great approach to bootstrap a an Agile BPM programme.

1 comment:

  1. Hi Allan,

    As you know we've been using Naked Objects in Ireland for the last five years plus, and it has substantially changed working practices around pension benefit processing, child benefit, and another dozen or so benefits.

    Right now we are extending the scope of the system for unemployment benefits. Currently there is a very laborious manual process for tracking casual workers, that is, those who are claiming unemployment benefit but who do the occasional work. There are some complex rules to do with whether such a claimant is entitled to work or not, all of which must be calculated by hand on sheets. It is laborious work and whenever there is an error, costs yet more money for the government to put right.

    So the project is to automate this area, effectively moving this part of the business process within the computer. As always we are developing this iteratively, and using Wink demos ( to demonstrate the system both to the domain experts and to allow them to demonstrate what's being developed to a wider audience.

    Picking up on what you've said about small changes leading to larger changes, once the eligibility rules are automated then we can turn signing on into a kiosk system. We've been doing a few technical spikes with signature capture systems, and other ways of establishing "provenance" are also being explored.

    If anyone here is interested in learning more about Naked Objects for either Java or .NET, they might want to check out my blog at (Java) or the main .NET website at (.NET)



Note: only a member of this blog may post a comment.