How do business rules relate to business processes? How do business rules support business agility and migration to new business platforms? What does re-use of business rules really mean? This column explains the deep insights offered by the Business Rules Manifesto on these questions. Already read it?
This month’s column is not a debate about decision table theory versus decision model theory. Instead, it focuses on current practices for decision tables and those of The Decision Model. It covers (1) Four Benefits of Decision Tables (2) Decision Tables in Practice (3) The Decision Model in Practice (4) The Science Behind the Transformation Steps and (5) Wrap Up: A Leap in Maturity.
How do business rules fit with requirements? What role should business rules play in business analysis? Do business rules offer something to agile projects? This column, the first in a series of three, explains the deep insights offered by the Business Rules Manifesto on these questions. Already read it? You may be surprised by what you find here!
When we first look at data fields on a business document, they appear complex. However once we analyze and understand them, they become simple. This is one of the purposes for a technique called normalization – to understand data fields and their relationships.
We are frequently asked about connecting and tracing software architecture elements to business processes by integrating BPMN business models and software models in UML (Unified Modeling Language)... Now we will explore how to supplement business architecture with software architecture.
Today many business analysts are creating business-oriented decision models. These decision models contain business logic for operational decisions that operate within business processes. And, it is no surprise that data quality is critical to business-oriented decision models. After all, good decision models operating with bad data are no better than bad decision models operating with good data. The surprise is: not only are decision models a preferred way for managing true business logic but they are remarkably suitable for managing data quality logic!
What comes first, the business analyst or the business analyst experience? If you’ve looked at BA job postings lately, you’d probably say the experience, as most BA jobs require experience. From one perspective, you’d be correct. But from another perspective, you’d be wrong. For if every BA role requires experience, how is it that there are hundreds of thousands of practicing business analysts across the world?
Quite simply, root cause analysis is a technique designed to unearth the real, often unknown reason why a business problem is happening, and then to propose a viable solution to fix it. BABOK explains that root cause analysis “can help identify the underlying cause of failures or difficulties in accomplishing business analysis work”[1] [emphasis added] and further clarifies that it is “used to ensure that the underlying reason for a defect is identified, rather than simply correcting the output (which may be a symptom of a deeper underlying problem).”
Checkpoint Beta is not mandatory. It is, however, extremely helpful for the business analyst. Checkpoint Beta is also an informal meeting, this time with the solution team. It is held prior to committing the solution to the final, formal solution document andobtaining final confirmation from the business community.
With the rapid adoption of The Decision Model, the most frequently asked question is: “How do I convince my organization to try it and eventually adopt it as a standard?” Two related questions from two different perspectives are: Do I have to find a way to introduce The Decision Model from the top down? Can I introduce The Decision Model from the ground up?
As businesses acknowledge the value of business analysis – the result of the absolute necessity to drive business results through projects – they are struggling to figure out three things:
What are the characteristics of their current BA workforce, and how capable does their BA team need to be?
What is needed to build a mature BA Practice?
How are we going to get there?
Of the four articles in the series, this particular article is the most sensitive. If not practiced with caution, trying to influence someone or a situation could have a devastating impact. Therefore, this article comes with a disclaimer: “Stupid is as stupid does.”
The purpose of this article is to provide project managers and business analysts an example of choosing a hybrid solution development life cycle (i.e., combination of agile and waterfall). Much discussion has transpired on the virtues of agile and waterfall approaches.
At some time or another, most companies will likely experience a point in their development when business process management (BPM) will need to be adjusted in order to support growth, mitigate a challenge or respond to market trends. Exploring how multinational corporations such as Apple and Hewlett-Packard have handled such challenges can offer insight for managers looking to apply best practices to the unique situations facing their own organizations.
As we travelled around India we were initially amazed at how the traffic flowed. India is a populous country, of course, and they have an ever-increasing number of vehicles. No matter what time of day it was, the traffic seemed heavy. So, how can their constant flow of traffic work?
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: