
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.
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?
Firstly, instead of focusing on the standards; the following are what I feel are mandatory for business acceptance of a business modelling tool:
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?
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.
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).
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:
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???
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
10 | |
7 | |
7 | |
7 | |
6 | |
5 | |
5 | |
4 | |
4 | |
4 |