I was teaching a business analysis course recently and noted that few students had used a Fishbone Diagram along with the Five Whys for root cause analysis. This motivated me to write an article on root cause analysis using the combo method along with a short example.
Corporate mergers and acquisitions (M&A) continue as a critical means for enterprises to meet strategic objectives such as growing market share or acquiring new capabilities. However, rate of successful outcomes has not grown at the same pace as the number or M&As themselves. In this post, Dr. Coghill argues the case for using enterprise architecture to provide increased visibility and clarity around M&A objectives to support improved outcomes.
Business rules cover a very broad space. Across the entire space, however, you can be sure about one central idea – business logic should not be buried in procedural programming languages. Call it rule independence. Why is rule independence important to you? Because rules entangled in procedural code won’t ever be agile. Rules change all the time – and in a digital world the pace of change is always accelerating. How you can stay on top of it is the central question in business agility.
Most of us are well aware of the problem of organizational silos and non-integrated applications and channels. The question is how can we plan to eliminate them? The notion of a value chain is to take a 10,000-foot view of the business based on how value is created incrementally toward final delivery of products to end-customers. In other words, a value chain model looks holistically at the value-adding capabilities of an organization end-to-end, irrespective of organization lines of responsibility or existing functional activities.
Chaos! Stress! Everyday mess! Isn’t this an everyday situation for a business analyst? If not, either you’ve job satisfaction or you’re not being introduced to the real world of business analysis.
A person might possess great skills, however, (s)he might not be able to utilize skills without the right mix of tools and environment. A toolbox enables a person to implement the skills in the most efficient way. Possessing necessary tools is just the one part of it. Another is the knowledge to utilize the right tools at the right time to cater the solution and ensure timely committed delivery.
What are these tools? How do we map the usage of tools to the given circumstance? How can we efficiently utilize the tool? Does it depend on the solution or the approach?
This is the last article in this current “Deep Dive Models in Agile” series and covers Decision Models, which include both Decision Trees and Decision Tables. Decision Models include two RML System models (Decision Trees and Decision Tables) that detail the system logic that either controls user functions or decides what actions a system will take in various circumstances.
The primary subject of this article is process, a word that is generally both indefinite and nuanced when applied to systems development. In this article we describe how process as a concept becomes both simpler and more definitive when it is integrated with decisioning. The combination of process and decisioning extends the ‘decision centric’ development concepts that we have evolved over the last 15 years. These concepts combine into a proven, practical, and robust methodology that leverages decisioning and agile techniques to fundamentally simplify commercial software development.
The PBD starts with examining the end-product data elements and associated business rules. The BA team then uses this information to redesign a process that produces the end-product. Special note about the team. The lead BA should remind the team members that this is a redesign effort. This is a real challenge especially for the team members who are knowledgeable with the existing process. It may be best to recruit team members with a “fresh pair of eyes.” Note that there is no doubt that the BA team will consider automation in the redesign. In this effort, the BA team should keep in mind a quote attributed to Bill Gates [3] on BPM.
“The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency. [7]
In my experience, all benefits come from redesigning or improving existing processes, not by applying automation through software. Software only facilitates the process improvement.
A combination of process modeling (BPMN) and decision modeling (DMN) simplifies business processes by eliminating and replacing entire sections of the model with a decision model—the decision logic of the process model is precisely captured by decision modeling a separate yet linked model.
This article is the last in a trilogy of articles that map the evolution of a proven, practical, and robust methodology that applies decisioning techniques to fundamentally remake commercial software architecture and development.
brought to you by enabling practitioners & organizations to achieve their goals using: