Perhaps the following point about the term decision is already clear to all, but at the risk of stating the obvious, I’ll make it anyway. There’s a major collision of terminology with respect to decision as used by different communities.
In the business analyst community, decision is often used in talking about business analysts’ own work – i.e., what methods to use, go/no-go on change, tool selection, choice of elicitation approach, etc. Its usage also seems to cover the sense of “management decision” – e.g., what course should project work take.
In the larger business community, decision always refers to a determination in business activity – e.g., should this applicant be given a mortgage, what should be charged for shipping an order, etc. This is the focus of decision in the business rules / decision engineering community.
In the context of their own communities both usages are correct. Unfortunately, the collision often results in confusion about the appropriate focus – and about which methods to use – for both audiences.
In situations such as this, the best practice is to define the concept in question for each community. Terms considered to be obvious usually aren’t. It’s not clear to me that this has been done explicitly in the business analyst community.
Another best practice is to qualify the term every time it’s used. So we always say operational business decision when talking about the business context, not just decision. That also distinguishes the concept we mean from other potential sources of confusion – e.g., strategic business decisions and system-level decisions or IT decisions.
I believe what the business analyst community means by decision is strategic project decision or strategic change decision. But I can’t really be sure since as I say the term doesn’t seem to have been defined.
Ron Ross, Principal and Co-Founder of Business Rules Solutions, LLC, is internationally acknowledged as the “father of business rules.” Recognizing early on the importance of independently managed business rules for business operations and architecture, he has pioneered innovative techniques and standards since the mid-1980s. He wrote the industry’s first book on business rules in 1994.
“Instructors were very knowledgeable and could clearly explain concepts and convey importance of strategy and architecture.
It was a more comprehensive, holistic approach to the subject than other training. Emphasis on understanding the business prior to technology considerations was reassuring to business stakeholders.”
Bernard – Government of Canada
“We actively use the BRS business-side techniques and train our business analysts in the approach. The techniques bring clarity between our BAs & customers, plus more robust requirements for our development teams. We’ve seen tremendous value.”
Jeanine Bradley – Railinc
“A great class that explains the importance of business rules in today’s work place.”
Christopher – McKesson
“I found the course interesting and will be helpful.
I like the pragmatic reality you discuss, while a rule tool would be great, recognizing many people will use Word/Excel to capture them helps. We can’t jump from crazy to perfect in one leap!
Use of the polls is also great. Helps see how everyone else is doing (we are not alone), and helps us think about our current state.”
Trevor – Investors Group
“Your work has been one of the foundations of my success in our shared passion for data integration. It has had a huge impact on innumerable people!”