I, like I’m sure others, have been told by BPMN modelling vendors that events are a ‘system thing’ and shouldn’t be used to model a business flow. In any large scale process work I have done half the issue is differentiating the correct path through a process, to the exceptions. Whether the goal is removing exceptions for efficiency or showing

Of course BPMN 2.0 has many other advantages for those who wishes to execute process flows directly by a BPMS required attributes have been defined rather than the previous practice where each vendor had different names. In my opinion this can never be achieved, the process complexity needed for IT systems is far greater than business people need to know, or have to think about. This is particularly the case for the executives who we need the buy in from to get meaningful business change! Orchestration is an exception but the line between orchestration and workflow is forever hazy…

From rumours it seems OMG is trying to tie UML closer to BPMN, a move sure to push BPMN forever into the IT department domain and away from business users. But  at least this will hopefully mean the  end of BPEL!

Firstly, what was good; the collaboration features work very well. My colleague was in another city yet we were easily able to watch what was happening in almost real time. Despite being a web based application data entry is pretty straightforward, Lombardi has put a lot of thought into the interface. The automatic layout BPMN tools worked pretty well.

Unfortunately we fairly quickly we started running into issues with the layout. Blueprint only allows automatic layout, there is no way to manually override where it things an object should go on the timeline. It tends to add each item to the next position within each swimlane rather than the next position to the right from the previous item. Great for making spaghetti diagrams that with connections going backwards every time you send a message!

The solution is a little messy but works, if you add the activities you want parallel on the swimlanes to a milestone, the layout makes sure they are all in parallel. Not great, particularly as you are limited to displaying around 9 milestones on a flow. Lombardi will be improving this in a release in the near future.

The tool has the same problem as many other tools, it is impossible to disconnect from an activity and reconnect to a different activity. You have to redo your links, loosing labels. Annoying, but many BPMN tools have this problem.

The next hurdle came with exceptions, I believe in using exception on activities to indicate a business exception, it makes the ‘correct’ path very clear. Blueprint does not support exceptions (or message events) attached to activities, instead you need to model exception flows using decision boxes and message receive events using stand alone icons. Technically still correct but it adds verbiage to your models, many BPMN tools have this issue.

Finally export, this is severely limited. Currently there is PDF and Powerpoint exports, but they are only suitable for smaller documents. The export area needs to be significantly improved, or alternately some form of free view only account concept incorporated to share the models with all stockholders.

I should also mention the fantastic support from Lombardi. Whenever we came across these issues and posted to the support boards, Lombardi responded quickly with a work around or an explanation.

Overall not perfect, but we were able to get the models in very quickly, we liked the interface and we could easily see how it would used rapidly in a workshop environment. If Lombardi keep improving the product, and currently they release a new version every 3 months, it should mature into a very usable application.

Firstly Blueprint differs from other applications in that it is a Software as a Service (SAAS) application, that is, it is an online application rather than an installed programmed. While this makes collaboration extremely straightforward it may make some organisations nervous, having there process flows held not on there own servers. In my experience with any form of BPM project there is a constant need to keep many people in the loop with the latest version, the more the better, online makes this very straightforward. As most workshops involve at least one facilitator, one other person recording information and one or more SME’s from the organisation simple collaboration is vital.

Blueprint does not provide the richness of ARIS’s versions, comments and change requests tracking, but it does provide versions – a good start. Unfortunately Lombardi’s licensing only allows named users (ie. paying users) to view the content, limiting the use as a real time publishing system. The current Powerpoint and Word exports are a little limited.

I should mention Blueprint does support the Business Process Definition Meta-Model (BPDM) XML standard. BPDM was an early push within the Object Management Group (OMG) for a standardised way to transfer BPMN models between products. Unfortunately BPDM seems to have only been implemented by Lombardi, limiting it’s utility! If Lombardi was to implement the Workflow Management Coalitions (WfMC) XPDL standard, transfer and publishing would be simple, as Lombardi are a strong advocate within OMG for BPDM this is unlikely.

Probably the biggest feature of Blueprint that I have not seen in any other product is the ability to switch between a process listing view, process flows and full documentation. This works extremely well, the DMAIC style shown below is perfect for use in a workshop setting.

One happy with the text description the next step is to define actual BPMN process steps, the tool can happily swap back and forward between these modes.

Finally there is a very effective documentation mode, which lists issues you have identified in creating the processes.

These multiple modes is a very clever idea and make the tool very effective to use.

The biggest feature gap in the Blueprint product is around the artefacts used within the process flows. There is limited ability to reuse artefacts that have been identified elsewhere in other processes. For example, an output of one process could easily be an input to another. When you are specifying an input, output, data item etc. it will list existing text items and allows you to select from the list. An option is available to export these artefacts in excel pivot tables for analysis, there is only limited identification from the original process and there is no way to identify what ‘type’ of information it is, vital for SOA analysis. If this is contrasted to ARIS which has superb reuse of artefacts, the ability to show the same artefacts in different contexts (for example. process versus system interface), and rich reporting it is clearly lacking.

Overall the tool is definitely worth looking at for consulting engagements, I have yet to see any other product with such clean integration between initial workshop information gathering, detailed process and supporting documentation. The visual editor needs work, but Lombardi are actively developing it and it is certain to get better over time, it already beats Visio by far.

The work will however it seems will carry on as two separate organisations; the International Process and Performance Institute and Steve Tower’s group the BPGroup.

Normally when doing process analysis it is extremely difficult not to get bogged down in the detail, this is reflected in the tools and reporting systems. Hercules-X seems to be a good way of removing that level of clutter, the tools can still be used at the detailed process level but that’s where they are kept.

Things such as KPI’s, success measures, action lists are kept at a text based summary where it is much easier to discuss them, it is definitely worth investigating this as a tool to help discussions in workshops. Workflows do not work at all in workshops, they are the perfect way to switch off everyone’s attention while they disappear into following the details, plans for the weekend, their next cup of coffee etc.

The tool pays attention to action phrases rather than process detail forcing people to think in a similar way to the key action points. This is similar to main actions in an Aris flow (for example) , without getting stuck in all the other details that process flows throw at you. I would like a way to specify ‘key’ inputs / outputs though, without them it can be difficult to isolate the ‘right level’ of process decomposition to pay attention to. I guess you would use something similar to SIPOC diagrams as a separate exercise to work that out.

Probably the biggest change to what I usually do is to have two facilitators bouncing off each other; I usually try to get the participants heavily interacting but no one can listen my voice for a few hours and stay focussed ! We always have two people present anyway; one to watch body language and to take notes. Changing role very often worked very well. For BPM consultancy this would be easy to roll in, different processes from different people.

Another great trick was prioritising a SWOT by sticky notes, then everyone voting. You gained a focus on priorities while still capturing the variety; in the past I’ve populated the key points onto a SWOT but you loose the other ideas that way. People walking around to put the sticky notes helps keep people interested without the artificial ‘party games’ most facilitators resort to!

Any activities I’ve ever done with sticky notes work well; in the past I’ve been in workshops that build processes using the notes; the only problem is translating them to a BPM tool takes a LONG time. Working with the two facilitators, driving ARIS live translating what is happening with the sticky pads is probably a good solution; it would avoid people looking a screen of a live model being ‘built’, I find one of best ways to loose your audience!

The techniques sounded like a perfect solution for many places with no effort, organic, no genetic modifications, 2-3 times the rice yield… generally I don’t believe in silver bullets so I started reading more….

SRI is a set of techniques combined, it uses organic fertilisers, hand pulling out weeds, moving plants into more optimal areas as they are growing, keeping soil moist but not flooded, and even better it does not use genetically modified seeds – seeds do not have to purchased each year from bio-tech companies and arguably the produce may be healthier.

Many of the techniques are very labour intensive making it unsuitable for large commercial operations; many places in the world, particularly those having problems producing enough rice for food and country loan repayments, produce crops as small family farms. It does seem to produce 2-3 times the yield as traditional techniques, As water gets harder and harder to come by, and damns getting more frequent this situation will only get worse. It cannot work for highland areas, presumably as keeping the soil moist would be difficult, this would limit it in Northern Thailand and parts of China but leaves plenty of land.
A quick google found not everyone agrees; there are very strong groups (John Sheehy) pushing genetic modifications of crops to make them more efficient as the only answer. Probably is a reasonable answer for large scale agriculture with higher profit margins for buying seed every year.

The frustrating part about anything in development, you almost never get a clear, simple, answer. But it is good to read about something which seems to be really positive, involves very little money, and could produce real results in only a year or two!

Ikisan’s has a really easy to read summary
Oxfam’s SRI summary.

This project is like many others, developers have been doing one thing, huge amounts more have been promised, analysts doing another, management thinking something else, most of them seem quite competent, so what has gone wrong?

There are hundreds, if not thousands, of attempts to work this out so I may as well throw my ideas into the mix.

The biggest most obvious reason is over promise by the technical group. No one in the IT management area really gave them a strong direction either – so they chose to develop an outdated perl solution. The Analyst has been superb and has documented most business processes in a good level of detail. Development will now not be that hard.

So how to avoid the same traps the original developers fell into in future projects…..

• Don’t go for in house developers. Developing is just too hard to do without a decent core of people around to bounce ideas of, check each others code etc. In the past I have never been a fan of outsourcing, but I have turned fully around now.. but only for part of the team.

• Do have an analyst embedded with the client. The knowledge that can be gained by sitting with an organisation for a few months cannot be matched, no matter how skilled the interviewer. Once change management for implementation begins, they will be invaluable.

• Make sure the communication channels are there right from the beginning. Everyone should know the expectations. This does not mean a Prince project kick off or landscape document which will be ignored by everyone as soon as they are signed off, but a really easy way for everyone involved to see it, in detail, as often as they want.

• Documents should all be built in a living environment, sure there is a need for sign off at times, but a signed-off document, is a dead one and is meaningless the second it has been approved. If you try to repurpose your documentation content from one group to another, as often as possible, by default you become more aware of what each other is actually doing; or at least what questions to ask.

• A big one, make sure the project manager (or program manager) doesn’t just report what people want to hear. So many try to hide problems from the stakeholders, funders, senior managers, other project members , everyone!

• Overall it has to be a non-blame environment, get the communication happening in any form possible. Tools like Wikis and Blogs can assist with this, particularly if a common taxonomy for tagging has been established so that it is easy to view information applicable. Of course, if there is any form of blame comes down from these forums, openness will disapear. Establishing the rules before opening access, and keeping them brief, should help.

I have been working in Business Process related issues for far too many years and am seeing lots of patterns and gaps, enough they are worth writing down.

In the spirit of helping this field grow this field is my own small contribution with these ideas!