Blackberry’s are the Enterprise preferred mobile email and calendar client which are usually forced onto employees; but iPhone and Android devices are the preferred mobile email and calendar client for employees that are forcing these clients into the Enterprises. The funny thing is that until the iPhone was introduced; Blackberry’s were the best option out there because we didn’t know better.
Within business process modelling (from a detailed requirements and process design perspective), I believe the best option for business users is to use BPMN. But the question is: Are we just waiting for the iPhone of Business Process Modelling to come along.
Inspiration for this Blog
A colleague of mine attended Business Analyst World (@ba_world) in Melbourne recently and some presentations from other companies really resonated with her.
In short, the companies were doing business process modelling leveraging a product that didn’t implement BPMN or any other generic standard for that matter but talked to the business users in a specific business modelling language that they could understand. Oddly enough, the product being leveraged was a product I had seen before, but it had a major drawback for me and that was that it didn’t implement an open standard. Why do I consider this such as big issue? In short, vendor lock-in; and this is an issue because if you invest in Business Process Modelling of your business; then it is a huge investment that should be maintained indefinitely.
Anyway, this got me to thinking…When it comes to lower level process diagrams, EPC seems to work well, but just seems to be too restrictive and forced to me; BPMN appears to be trying to reach nirvana too quickly with a language for both business process modelling and business process management style Workflow; and finally, businesses and business analysts seem to still love swim lanes in Visio.
So is the future of requirements elicitation near and just not understood well enough by everyone yet, or is it just not being thought about yet?
The Makings of a Good Modelling Tool (An alternate set of requirements)
Firstly, instead of focusing on the standards; the following are what I feel are mandatory for business acceptance of a business modelling tool:
- Usability – Ability to model in front of business users (otherwise we need to work off a whiteboard; then copy into the tool later) – FYI – Mobile Device integration (like iPads) could be an interesting use-case in the future here too…
- Documentation/Training Tool – Process models need to be made available to the whole organisation and easily accessible via a web interface with intuitive usability – preferably integrated with the business applications.
- Displayed in a pretty, well laid out and not boring way – Process modelling isn’t everyone’s cup of tea; hence it can’t be dull to look at as that will lose your audience quickly (just a fact of life).
- Collaboration Platform – Ability for anyone in the business to question existing processes or recommend changes via the web interface used for Documentation/Training.
- Ability to view as-is and to-be changes efficiently – If you’re tool is entrenched in the organisation, change naturally happens; and your tool needs to easily support this.
- Ability to view models similar to the way we document use case definitions – Just like showing a business user 10 pages of documented requirements; showing end to end processes with all variations, exceptions and interactions is just not going to work in getting effective understanding and sign-off from the business. I believe by just focusing on standard flows, alternate flows, and exception flows similar to old-school use-case documentation; really would allow you to focus the business users and not overwhelm them in workshops.
So About the Standards…
I’m not an expert in Business Process Modelling and I’m also not trying to suggest that I’ve researched this topic extensively, but I know what will work with business users when I see it (and I haven’t yet). I currently lean mostly towards BPMN style swim lanes or EPC; but I’m not sold on these either.
Side note: I see BPMN as something very powerful in the execution world with tools like SAP’s BPM combined with the inbuilt business view as a great way for the business to monitor and measure their semi-automated processes; but this blog is focussed on business requirements using business process modelling.
Basically, the purpose of BPMN is to support business and technical stakeholders; hence as a design tool; we’ve probably got it right there. However, when it comes to requirements and the importance of getting requirements right; let’s drop the technical and focus on the business.
Do we need another standard? Most likely in my opinion. The problem is how to write this standard? We obviously want some link into the BPMN space but this will have to be fairly loosely coupled in my opinion (though a level of reverse engineering in the future would be heading towards nirvana again). Who is best to write this standard? Software companies? Probably not though in this day and age there’s little other choice.
In short, it would be good to see if this is a real need still so I’m interested in your opinion or knowledge here?
The Business Analyst Role – The most important ingredient regardless of Standards
This is slightly off-topic but I thought was important to add in this context:
Regardless of tools, standards or methodologies; one key skill I strongly believe is the secret to successful projects is good business analyst skills.
There’s a real art to getting the requirements out of the business without just documenting what they know back to front already. Often the business will just tell you what they do today, and skim over details that are obvious to them which can hurt implementation projects when you only find out when it’s not built in final UAT.
Just as important: because business users are so entrenched in the current processes; sometimes they don’t even realise why they do things a certain way. Typically there are significant efficiencies to be gained if challenged appropriately and while modelling helps significantly; the BA’s key in identifying this.
For traditional waterfall projects; Business Analysis is extremely critical as obviously signing off of requirements early means little ongoing involvement between business and the testing cycle. Within Agile methodologies; developers usually pick up this role; and although maybe not as good as a dedicated business analyst, the shorter iterations and direct business engagement helps significantly as developers are unlikely to misinterpret the requirements; and even if they do; it’s picked up quickly.
In short, a good Business Analyst will ensure that regardless of your approach or tooling; they’ll capture and convey the requirements appropriately.
I have a dream…
that one day all business users, IT folk and software companies will model their processes in a consistent way in order to design their systems appropriately. It will be a common language that is not only intuitive and well understood but integrated through to system design and back. I just don’t think that day is today and hence for today, we’re reliant on Agile methodologies or great Business Analysts (or preferably both together).
Edit: What’s wrong with BPMN for Requirements Elicitation
I realised after I posted this that I missed thisfundamental section to my blog. To at least give some background to why I think it misses the mark I’ll make the following observations:
- Unlike EPC, BPMN is less structured and open to different approaches based on your background. Maybe a clear standard on implementing BPMN from a requirements perspective may fix this.
- Some of my requests for the tool could address many of the other problems I have with BPMN such as being able to view the processes in isolated ways to not overwhelm the business.
- BPMN is quite clearly a type of programming language and hence forces this style of thinking onto the business.
- It’s not abstract as it usually becomes an execution language. I believe in UML that you split up logical models verses design models, and that is really powerful for communication. Sometimes logical and physical can be quite different.
- It doesn’t have many obvious business interactions icons.
I have to admit, I haven’t reviewed ARIS recently to see what they have done in this space as we currently use Enterprise Architect for our early modelling needs but the tool really shouldn’t matter that much should it???