In the Field with our Experts

What’s Your (MDM) Type?

By Bill O'Kane, Senior Consultant

 

photo by Dan4th

As part of an interview recently given by Evan Levy, he was asked to explain the various flavors of MDM implementation. The three generally accepted categories are persistent (all master attributes stored and maintained exclusively in the data hub for access by client systems), registry (sets of master attributes stored and maintained in client systems are registered, or “pointed to” by the data hub), and hybrid (also sometimes referred to as co-existent, where a copy of some or all of the client systems’ master attributes are stored and maintained both in the data hub and the client systems). While each MDM implementation is inherently different due to the uniqueness of each business and operating environment, these categories sufficiently encompass the vast majority.

I’ve come to realize that all of the projects I’ve been involved in have been of a single type: they began life as persistent-style hubs (and in fact, were justified this way in terms of a business case), and later became hybrid, as the costs associated with ancillary tasks (such as remediating all of the legacy batch processes to access the data hub) came to light during detailed source system integration planning and analysis.

I often discovered a heavy reliance on vendor-driven operational systems, which many times limited the ability to remediate certain technical processes. However, in spite of the fact that it became necessary to retreat from the completely persistent view from a tactical perspective, I believe that all of these projects remained successful because the persistent-style vision was kept on as a strategic guiding principle. In other words, the project teams were held accountable for creating data architectures that would support a persistent-style implementation, even if the source systems were allowed to keep their copies of the master data for a while longer. In fact, on some occasions, the project team was even asked to submit project plans for these future remediation tasks for use as time and budget might permit.

Although I’m less familiar with pure registry-style implementations, the idea of implementing something like this without a more persistent-style strategic vision to guide the proceedings makes me a bit uneasy. For example, questions I’ve heard come up more than once in regard to registry style: How is this different from the Virtual Data Warehouse concept we tried and failed to implement fifteen years ago?, or Won’t we just be creating another data silo? I have to confess, I don’t have a great response to these. Moreover, one of the things that originally drew me to MDM is that its nature (when persistent or hybrid) forces organizations to at last come to grips with the sins of their pasts in regard to data architecture, data governance, and metadata. 

---

Bill O'Kane has twenty years of experience in the design, development, and implementation of large-scale Master Data Management (MDM) systems and Data Warehouses, with an emphasis on Customer Data Integration (CDI). His experience includes both the development of internal systems and the integration of vendor-based solutions in complex environments. Bill has achieved success in diverse corporate environments including Fortune 100 financial services and health management companies, mutually held insurance companies, and privately held software vendors.

Facilitating BI Requirements Workshops

By Fernando Martinez-Campos

 
photo by faster panda kill kill

In this post we will explore ideas for facilitating BI requirements workshops with a group of users. The main goal of requirements discovery workshops is to identify initial BI requirements with key business stakeholders. These sessions start with open ended questions which evolve into detailed requirements. As a facilitator your responsibility is to keep the process on track so business value is derived from the discussions.

The earliest preparatory steps require that you identify the audience participants, create an agenda that will spark interest and schedule the meetings. You will also need to appoint a scribe, who will record the proceedings and capture the output (the facilitator can rarely do both jobs well). I find it useful to also have an initial set of prepared examples that show the progression of an idea into actual requirements. By showing these examples early during the first meeting, you will show stakeholders what the desired outcome of requirements gathering looks like.

Some common steps  in a BI requirements discovery session are:

• Brainstorming ideas – This is the open ended part of the discussion
• Categorizing ideas into business function – This step organizes ideas into groups
• Associating business functions - The groups are related together
• Defining business questions – Initial business questions are chained with follow on questions
• Refining detail requirements - This step translates the questions into detailed requirements
• Prioritizing requirements – Ranks the requirements in order of importance

Let’s use these steps with an example of how these facilitated meetings were conducted at our electronics manufacturer client. The main objective was improving the repair process using BI analytics. The initial session had about eight stakeholders in attendance.

Several categories were developed that had business requirements:  products returned, centers where repairs took place, tests performed, and repair actions. We developed the categories into associated business functions: for example, the Test category had related tests to test results which were associated to the Repair category with repair actions. We continued chaining more questions if the repair action yielded defect trends. By looking at how these business processes were linked, we could track the progress of the workflows in the repair process.

We published the requirements of these workflow activities along with the required data that was needed. On the next session we reviewed, adjusted and agreed on the requirements. Then it was time to prioritize which requirements needed to be implemented and created a roadmap of BI projects.

The BI requirements workshop reaped the following benefits:

• Established solid alignment between the business stakeholders and BI developers
• Documented requirements of the repair process and its analytics
• Reached early stakeholder consensus of the requirements
• Provided visibility on the agreed priorities to set the right expectations
• Provided a forum to communicate feedback and potential risks

As the BI stakeholders gained confidence in the combined effort, follow on sessions became easier. In fact, follow on BI requirements sessions  managed themselves!

---

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.

Defining Data Requirements

By Fernando Martinez Campos, Senior Consultant

photo by clayirving

In my last blog post I described a way to define BI metrics through business user interview techniques. Now it’s   time to start investigating what data is needed to answer the business questions. This post discusses data requirements, a subset of business requirements gathering.

A fundamental step in defining data requirements is to build a logical data model (LDM) which reflects the natural way data relates to the business. Aside from interviewing users and building an LDM, another input involves analyzing the sources of this data: operational applications and departmental databases.

Data requirements should be a precursor to data source analysis and profiling. A mistake many analysts make is to assume that the source is good enough to run BI Analytics. Once they load the source, much to their chagrin they find “data surprises” that will make the analysis unreliable. So it is extremely wise to being data source analysis by interviewing the SMEs and ask these fundamental questions:

• Does the data contain duplicates?
• Is there occasional missing data in some of the fields?
• Is there a better source for this data?
• Is the data content recorded accurately and reflect the business event?
• Are the business rules defined when adding or changing the data?
• Is there a data owner responsible for fixing it?

I am always surprised how much users know about errors in their data. They are invaluable in pinpointing where the errors are in the sources. Your initial efforts in the data quality investigation will uncover these “data hot spots” from them. When you start profiling the data to obtain more accurate results on exactly where all the problems exist, you’ll have a great headstart With the data profiling results you will be prepared to proactively handle any unexpected problems with the data before you load the data.

Besides creating the LDM, you will also need to create a Business Requirements Document (BRD) that will have a data requirements section. These are the activities needed to build this section:

• Define the data with a precise meaning and content, in other words, the metadata
• Determine how often the data needs to be loaded
• Determine the cutoff time for the data
• Analyze audit and compliance considerations
• Define the performance requirements and response times in retrieving the data
• Determine if the data has special security and privacy needs
• Define the length of history needed for the data

Creating a BRD streamlines the design phase with these benefits. You can uncover early security, audit and performance considerations that will need to be done in the physical implementation. And data profiling helps you proactively minimize any data quality problems during the load process. Finally, creating an LDMprovides the foundation for the physical data model (PDM) which becomes the de-facto data structure for the tables on your data warehouse.

---

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.

BI Requirements: Defining Business Metrics

By Fernando Martinez Campos, Senior Consultant

photo by Aussiegall

When you are embarking on any analysis project, a good investigative technique is to use a variety of structured questions. When interviewing business users, you want to uncover not only how they use information, but what specific information they need, and what they will do with it.

Let’s use this approach with an example: we are going to measure an electronics retailer’s Repair Center activities . These are some of the questions I asked to analyze how the repair process is tracked:

• Trends - Are the defects after repair Increasing or decreasing? For example, is a certain defect trend getting worse or better? 

• Associate - How do you associate defect trends to other trends? Are the defects related to certain manufacturing plant trends? Or are the trends related to specific repair centers?

• Exceptions – What are the exception trends? What is the defect threshold number for a batch of products? What do they do after this threshold is reached?

• Chain - Once you have the results, what is the next business question? If the errors can be traced to a repair center, the next question may be: can we pinpoint the employees that make the most errors, do they need better training? Or is there a flaw in the repair process? The chain of questions and results will give you insights into the business process.

• Other Data - What additional data will you need to improve the process? This involves getting additional sources to enhance the results. If errors can be traced to a supplier, will the manufacturing Lot Number help in pinpointing a batch of defective materials?

As you can see, as the interview progresses, there are more and more business questions being uncovered. You will need to determine how long to pursue follow-on questions. For example, once you have determined that the Michigan Manufacturing Plant has the most defects, is it because they source materials from a specific vendor?  You may follow vendor data until you decide that the scope has expanded beyond your initial analysis goals.  That will indicate that is time to conclude that line of questioning.

When the user gives you a measure, it must be quantifiable and defined in a precise way. The specific measure should move towards achieving an organizational metric and have an actionable target goal. The objective can have lower and upper limits so you can spot variances. As these quantitative measures are analyzed for their directionality (getting better or worse), they should lead to actionable decisions.

Once measures are implemented, you must look at them over time so the business process can be improved. After changes are applied to a process, did the measure results in the direction you expected? Or where other variables causing the problem?

What benefits were realized by using the measures approach? In the case of the Electronics Manufacturer, defining these measures provided standard and concrete ways to track the business. The measures were objective and had universal agreement by all users. They now had a common mechanism to understand what was happening in the business.

Once you are finished defining the key metrics, you are now ready to investigate where you will get the data for them. That will be the  subject of my next post.

---

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.

New Business Requirements for BI: Part 3

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.