By Fernando Martinez-Campos, Senior Consultant
photo by アラン
In my prior blog post I described how the project team decomposed an electronic manufacturer’s business flows into “phases” where the flow started and ended.
Our team used subject matter experts who helped us prepare a series of interview questions. We had challenges in defining the inputs, outputs, and exceptions in each phase. And we worked hard defining the different user types who were responsible for each phase. In addition, we had to enlist management support to arrive at the interviewee list, inform them of their need to participate, and conduct the interviews using the manufacturing flow.
Notice that up until now we have been analyzing the business flows, not the BI requirements themselves. The team wanted to understand what really drives the business, not simply jump to conclusions as to the appropriate analytical reports. The team also had “domain knowledge” of this industry, so we were able to apply lessons learned from other companies we’d had worked in prior projects.
But for companies that aren’t as process-centric, there are other means of defining BI requirements. For instance:
- Management by Objectives – Involves interviewing senior executives and determining their objectives will give you insight into the current priorities and tasks for the business for each area.
- Functional Business Model – Instead of the business flow model we discussed, with this technique we categorize the business functions: Financial, Manufacturing, HR, Marketing, etc. Then each function is decomposed into more detail to determine its business goals. This is a structural approach since these areas are depicted as organizations and not as flows.
- External Constraints – You can also identify regulations, laws, partners, vendors and competitive drivers that impact the business model. These can be measured with analytics to ensure business processes do not deviate from these constraints.
The Top-Down approach worked well for our manufacturer client since the executives themselves were driving this process. Once BI reporting was implemented, senior managers were able to understand the underlying reasons why so many product returns were occurring:
- Repair Centers – There were repair centers that were not following established test and inspection processes.
- Flawed Engineered Designs – Overheating of mother boards were occurring on specific product models that were experiencing the highest number of failures.
- Manufacturing Defects – Tracing back products returned to the specific manufacturing facility yielded a gold mine of data that pinpointed the failed components and originating suppliers.
The Five W analysis highlighted the locations and components that caused the greatest number of errors. Quality processes were then instituted to continuously improve the weakest links and feedback loops remained in place to measure the trends of ongoing product returns.
So there’s an example of top-down requirements delivering real business value. In future blogs we will discuss other starting points, other than the top, to gather BI requirements.
Fernando Martinez-Campos is a senior consultant with Baseline Consulting and expert in data architecture, data interchange standards, legacy coexistence strategies, and reference architectures templates for infrastructure, applications and databases.
Comments