On the other hand, early on as you are designing the process, when you have only a concept of what you want, simulation allows you to see what might happen and do a lot of “what if” runs. On top of that you may need a whole load of simulation data to feed into your process, so you could attach to a component that simulates that data and provides it to the process as though it were an application or another system.

One of my interests is solving the question, “how do I switch this on and off?” Shame there’s nothing like it…

Thanks to you both the whole simulation concept is growing on me, beyond it being a checkbox on a vendor’s sales sheet. Bob, its good to hear feedback from a real life person that simulation has been useful in practice.

I still need to think through the use of simulation on existing processes, but this is how I interpret what Andrew has suggested:

The use of analysis tools can help reveal bottlenecks on the live process. I’m guessing that simulation then provides the ability to feed this information back into the process to work out how to change it, without changing the live process until you are comfortable with the changes.

The thing that has been nagging at me through this discussion is this: does analysis and simulation of well-defined or existing processes lead to you changing the process; or does it really help identify that legacy systems, applications, UIs, or users at that point in the process are not performing well, highlighting inadequacies peripheral to the process itself?

My guess is that simulation does not lead you to changing your process (since a well-defined process is designed to perform a series of tasks in an order that is fixed due to that being the natural order of events). Simulation in combination with analysis helps you identify other issues, and ensure that you are actually focusing your efforts on the right place.

Did that help? Not sure…

Cheers
 -Phil

To re-enforce the notion of user involvement, I had an interesting conversation with a colleague this morning. She was telling me about a BPM project that used simulation. It was used to good effect with the client, who was very impressed and it helped sort out a whole range of issues. We both think that simulation is a much under-utilized technique.

As to a UI, yes it will work in production, but it’s not finished yet! But that is only one side of the story. I think simulation and testing overlap quite significantly. Simulations in the early stages are mainly to prototype a number of potential solutions and expose them to the users. The processes will not go very deeply into the enterprise system at this stage in the lifecycle. Further along the lifecycle, processes reach more deeply. They also need to control access to confidential information and the like, so testing is done with the real system, but the process only produces test data. It would help if the process engine and BPMS would support this approach.

Having the facility to exercise and stress a process (or group of processes) until a breaking point is reached is very useful in planning capacities. It also helps point out where any weak points or bottlenecks are so that these can be addressed.

Note: I did not say that bottlenecks would be eliminated, they can only be moved — once you clear one you’ll find another constraint somewhere else. It also allows “what if” changes to be exercised to see if unexpected side effects occur.

Yes, you could do this without simulation and no, it is not a substitute for thought and planning — I would argue however that it is a useful tool to help.

Interesting thought. I would have to seak outside opinion to judge where simulation ends and testing begins. You must have a good idea, right? To be honest I have never used simulation on a real project. More just evaluated some of the tools out there for OEM’ing into a vendor’s product set, to check another box.

My feeling was that on real projects where I was trying to rapidly introduce an automated process, simulation was seen as an extra level of resources drain. After all, many organizations see a great response from a business analyst just standing in front of a whiteboard and walking through a newly-proposed process, with users criticizing from the wings. Who needs technology to achieve a higher level of interactivity than that?

By the way, releasing new processes rapidly is an important side point. For more discussion on the importance of releasing a new process in under 90 days, see Sandy Kemsley’s Column 2 blog (and my comments). It may be a discussion you could weigh in on!

Back to the point. The same projects that I talked about with the low-tech whiteboard approach probably could have benefited greatly from simulation during the design phase, as it would really have shown users what works and decisions they would retain, and what would have fallen out of their hands. But for the processes I’m talking about, using simulation for workload balancing and optimization was unnecessary, and therefore probably would not have intruded into the ‘testing’ space.

Either way, I do want that UI prototyping tool, as long as the output can be used in production. Users don’t like the idea of changing visual things like UIs that they have become comfortable with. If you know a tool, I want one (or 10).

Thanks for the discussion (it’s been good enough for me to reference more than once on my blog).

-Phil

A great insight. I was just contemplating the same thing this morning. The simulation that is being suggested here is closer to testing than “traditional” testing is. So my question is, where does the simulation finish and where does testing begin? Couple that with a rapid prototyping tool for the user interface and the ease of refining processes, and you have the ideal environment for most (or perhaps all?) of the life cycle.

BTW — I could probably live with ‘BIRP’ ;o)

Can you share the URL to an article on the subject?

You hit the nail on the head. Too many decent systems have failed because of the lack of user buy-in. Maybe that is because IT chose to ignore the business, choosing instead to just rework a current system in a new technology, or maybe because the executive sponsor was ‘weak’.

As you say, getting the system in front of the users early and often really works — so maybe simulation is a great tool to aid this, long before a real workflow executable process could be shown.

This allows the two key tasks (integration and process design) to happen consecutively, i.e. one group (the business) can model and simulate the process at a business level, while the technical group validates the integration and legacy issues within the real workflow environment.

At the end the tech guys have a job of pulling the process into the real workflow environment, and refining it to fit the legacy system constraints previously discovered. Then the business process designed and simulated by the business people still holds. Whether a round-trip simulation is still required at this point is probably debatable, as there should now be a usable test system to start validating with users.

In summary, maybe simulation can reduce the overall project time, while allowing essential legacy integration tasks to happen early (reducing risk in the long run), and enhancing user buy-in through early involvement.

Sounds like we have a great new methodology here: BIRP for BPM (BIRP being Bob, Ismael, Ryan and Phil)!

Yep — it looks like an interesting discussion you are hosting over there! I was going to stay out of it — but I couldn’t resist (just wait…)!

Thanks again for the interesting discussions. My blog is going to be full of links to you soon! Now I’m going to have to be really smart to get the reverse to happen!

Cheers

-Phil

Thank you! Thank you! Thank you!

We’re finally getting down to the kind of discussions I’m trying to get here. Real users talking about real project, without any marketing bullshitake.

Yes, integration matters!

Yes, integration is what will make or break a BPM project!

Yes, simulation is secondary in most instances.

If the Dutch Government could deploy a process with 250,000 steps without simulation, I doubt that very many projects actually need simulation. Simulation is great for eye-candy sales presentations, but very few users actually need it. And if they do, they need it in a way that handles both flow and data, which very few process simulators support today. Actually, does any process simulator support both today? Anyone?

I wish that my good friend Phil Gilbert would hear this kind of user feedback more often. In that respect, the discussion thread that we have had here would have benefited from user input like yours.

BPM users of the world, please express yourself! This forum is yours!

As ever there are many words of wisdom in your post. Here are my thoughts based on some front-line experience in different organizations.

Over the last 10 years I have worked with a variety of mainstream workflow and BPM tools — plus some product-specific ones that were still reasonably strong. Having simulation out of the box would have made a few of the projects easier, but for others it is unlikely it would have made us aware of some of the rat-holes we were going down early on.

Several years on from a painful project I have realized that simulation is NOT needed for many processes (i.e. less than 30 human interaction steps). Since the issue we had in many cases was not the logic or sequence of the process, but in fact the backend system integrations (and the UI).

In reality we should have worked backwards, proving integration point first against a dummy process, ensuring that we could get at and alter the data in the backend legacy systems and understanding the impact this would have. This would have avoided the need for many of the simulation requirements, since when it came to the real process we could run a test instance of the real workflow engine. More importantly it would have demonstrated up-front that the legacy system internally controlled large portions of the process, which if we were not careful we would only duplicate (possibly incorrectly) within the BPMS.

So I would propose this methodology when legacy systems are involved:

- Prototype the integration first
- Test with an abstract process
- Ensure that the legacy systems can handle the proposed integration
- Identify constraints based on internal processes enforced by legacy systems
- Refine the process given these limitations
- Finally start testing the process with some real-world and simulated data

I know that this seems like a brutal approach for some projects, so I’m interested in your thoughts based on your experience!

We’re seeing eye-to-eye on this one.

As a business process owner I am in total agreement, as for me, simulation and optimization are the two ultimate goals of a BPM tool. In many industries the market conditions can change rapidly and dramatically, so simulation, sensitivity analyses, and “what-if” scenarios would help further the understanding of the process and enable it to adapt, be more robust and flexible, to effectively cope with change.

-Ryan