If its not Structured Chaos, it doesn't need BPM!?

I received an interesting thought from someone who questioned my post on my preferred patterns for implementing business processes. In my post I discussed why I felt that a business process automation or management solution that arrived at effectively a Straight Line of activities was great result, and why I felt that highly complex models were Structured Chaos. The question implied that in wishing to arrive at a nice straight line (or effectively a manual straight through process), potentially I was trying to oversimplify the process. This is certainly a valid consideration.

To me, this type of virtual straight line is a thing of beauty. It represents refinement of the process and removal of waste (a la Six-Sigma). It more importantly represents the real world of business processes that involve people.

To me, the complex business process that attempts to model every possible variable and combination of interaction between people and systems working together is incorrectly trying to force fit a process on top of a system that requires collaboration. If you must use BPM for some of the advantages it offers, model the collaboration through a Single Step or Star.

I'm sure that over time, some of my beautiful straight line processes will become complex, through the addition of plug in requirements, new rules and careful extension. In reality, I also acknowledge this as the success of the original process. It was flexible enough to enable this, to be extensible, without being initially restrictive or brittle and dangerous to touch from the outset.

So I thank the person who chose to give me this thought the opportunity to talk a little more about my design philosophy for processes. I hope to continue with my 'simplistic' approach to business processes, which can be put into production (without any infrastructure at the start of the project) in under 12 weeks, with minimized risk of failure.

In my dim, distant past I was part of the Structure Chaos implementation team, and 9 months in, as now, I never want to go there again. Give me the go-ahead to use an agile, iterative, release early and often approach to BPM, with a nice flexible straight line process, and I'll give you a solution that works on time and to budget, and you can build on in the future.

A post from the Improving It blog

Processes patterns as predictable as Mexico City rain

Mexico City, another wet afternoon

Three months, two business processes, one client with a new system in production. And I'm not talking about some irrelevant back-office processes. The Technolab team have implemented, for the Mexico division of a major international life and medical insurance company, a BPM system for processing new policies, policy renewals and maintenance, from client request through to payment.

In three months, we've taken the blueprints for current state processes from the business analysts and designed, built and deployed a system that should see huge benefits for the company and its employees. And at the end of it, the one prediction I made to myself came true. Business processes fit one of three patterns, and I only like two of them:

1. Straight Line
2. Single Step / Star
   
3. Structured Chaos

When I lead process projects, as I did this one, I tend to guide the client to one of the first two patterns, since they tend to reflect the reality of the way people work and lead to a successful, usable and subsequently easily adopted (by the users) system.

Let me quickly talk through the three process patterns.

1. Straight Line

I love it when a process turns out to fit this pattern. Its exactly what you are trying to achieve when you improve a business process; a process that starts cleanly with a specific outcome in mind, and with minimal deviations that always try to return to the main path as quickly as possible. Why is this good? Because its easy for users to understand, and its clear what the fastest, most efficient set of operations is. A company can build key performance indicators around this, since its easy to measure progress of work through the process.

2. Single Step / Star

How can I call this 'single step' and 'star' in the same breath? This process pattern really revolves around a key single step where the vast majority of processing is done. The steps outside of this often represent exceptions or sub-processes, so much like the Straight Line, they are deviations. And although I say this is single step, the reality is that the work may well cycle around this 'step' many, many times, being delivered to different people and roles on each revolution. But since there is little way to enforce the order of this work (at least with the time or money available to re-engineer the process), while still allowing users to get the job done, the process pretty much becomes an orderly way to track work as it passes between users, with delivery under their control.

3. Structured Chaos

Its when project teams try to force fit a process on top of current operations without effective analysis or change management that I think you see the third pattern. Note I say effective analysis, since there may still be a large amount of time spent on it to produce this result. And there is a chance that is may just work in practice. This is what BPM tools strive to be able to represent, and the temptation is therefore to go with the flexibility they offer. But to me, this process pattern shows a poorly thought out scope for the process. In other words nobody has defined what the process is actually trying to achieve and what type of work it is trying to handle. The more steps and decisions you have to add to manage the necessary requirements of the process, the more likely it is that you have missed one. Often, if a prototype process starts to indicate Structured Chaos, it may be time to rethink, and split the process into several Straight Lines, or possibly one Single Step / Star.

So at the end of three months, what have we arrived at? Well, I'm sure I would not be telling the story in the same way if it was structured chaos. We have deployed a nice clean Straight Line for one process and a nice Single Step / Star for the other. The end result is deceptively simple, and perhaps as much time was spent getting us to this result as actually physically implementing software. Which is great, as the processes will work fast, there is a lot less to go wrong and a lot more flexibility to handle the 20% of cases that don't quite fit strict rules.

Maybe BPM vendors would relabel Structured Chaos as a beneficial Complex Process. It all comes down to how you market your capabilities and limitations. Still, after 12 years of doing this stuff, I haven't seen a customer happy when you finally deliver them Structured Chaos. I'll stick with my two successful patterns, and leave the 'anti-pattern' to the BPM marketing departments and services teams.

A post from the Improving It blog

The joy and pain of rolling out a new business system

As three months in Mexico City draw to a close, the business process management (BPM) based system we've been building is heading for production. Not wanting to risk jinxing it (so there is a lot of wood touching happening here), I am trying to avoid saying that it may possibly, if the stars align, be on time and to budget. Technolab and the large multinational insurance company that we have been working for should be proud, as even if we do see a last minute hiccup, the teamwork and desire to get the job done has been incredible. So, that's the joy over with. What about the pain?

The pain (at least for me) comes from the uncertainty; the last minute unexpected mishaps; the possibility that the production servers just won't run right; the fear that integration with the system of record is just not the same for production as in dev and test; the fact that I'll have to perfect meditation to try and sleep without my brain going over every last detail (again). Dreaming software is not fun or relaxing. Especially not dreaming it in a foreign language!

But its just an application, right? And its been tested?... Of course.

Its the fact that the system touches the working lives of practically every skilled worker from sales, through underwriting, to policy issuance and accounts receivables. If the system screws up (like throws every item of work into an error state) for some unforeseen and therefore untested reason, there's going to be a lot of people sat on their backsides drinking coffee and waiting. That would not be the ROI that we all hope for. But its not just this project. For me, every system I've deployed (more successes than mishaps, it has to be said) leads to this mix of adrenalin and some other unknown compound (probably caffeine).

So for now, all I can do is keep on using the revolving brain, mentally touching and prodding every last piece of the processes and applications, to satisfy myself that everything is good. Reality is, its been good for a while. We have settled, just in time, into the essential phase of stabilization and risk reduction. So I'm ready for some joy on Friday. Just a little. Seeing the first users successfully login and start working full time, full on, with their new system. If so, you could see a deliriously happy post from me at the end of the week. Please keep your fingers crossed! Mine are, and its making it difficult to type.

A post from the Improving It blog

Download the podcast of this blog post

Testing times: changing perspectives in an agile development cycle

Testing software, in the form of products, custom applications or BPM based process implementations is surprisingly very different. I watched skilled, professional testers provide amazing coverage of a product in my previous life as product manager, with automated tools preventing regression. I've been part of teams building custom business software, then working hard on testing that software so it gets through the final user acceptance without a hitch. Right now I'm working with a client to ensure that the BPM and Case Management solution we built, following an agile methodology, not only meets user requirements, but works without fail. It is this last one that has presented some interesting challenges. How do you transition from an iterative, modified scrum development model, to the formality required to ensure the solution that has evolved just works? This is hard for the analysts and end-users, and surprisingly for the developers as well.

The head of the systems group pointed something out to the team of end-users who have been working with us on the project since day one, and who have now been enrolled as testers. Paraphrased (fortunately, because the Spanish translation would have been bad) he pretty much said,

You've had your chance to say what goes into the solution. Now test what we've been delivered, not what you wish you'd asked for 6 weeks ago. Now is not the time to be suggesting new requirements, or complaining that some things are more difficult to do than you would have hoped. If you can work around a limitation or restriction, you will. Feel free to note potential improvements and we'll rank them for phase two. If the solution does not work, throws an error, or completely blocks work from moving from one activity to the next then your tests have been successful. The aim of this exercise is to come out the far end with a system we can be confident will work in production.

I have a lot of respect for that attitude, especially when it comes from the guy who is paying the bill for the solution that is delivered. Pragmatic, realistic and most likely to lead to a project that is delivered to time and budget, while meeting 90% of the user requirements. It also helped the end-users adjust their perceptions from creative and business minded analysts, to logical and step by step testers. They are testing with real data and documents, which will hopefully uncover any hidden data level issues, but will the test cases cover the 90% of insurance underwriting tasks they have to cover day to day? If you see the work-arounds they have to do today with their paper and 'systems', you'd think it would be hard to fail.

We have one thing on our (the consultants') side, which is the same thing that always represents a risk. The previous paper process effectively had no automated controls, but because of that it meant that you could do whatever was needed to get work done. We've added some controls and rules. In fact over the course of the project we've added, then refined, and finally removed many more. As expected, at the start of the project the appeal of being able to control and restrict a process and its flow was exciting for the users and analysts. They define many things that they realize later on just won't work in practice. The trick to this is helping them understand that this is a step forward from today and flexibility is a positive thing. And fortunately it means that the likelihood of testing failing due to poorly implemented, highly complex rules is much reduced.

So, my beloved user testing team, please beat up our solution this week, with logic, flow and some flair. 'Cos its a damned site easier to fix big problems now than after go live!

A post from the Improving It blog