In the Field with our Experts

New Business Requirements for BI: Part 2

By Fernando Martinez-Campos, Senior Consultant

photo by D'Arcy Norman

In my last post I introduced the concept of top-down requirements gathering. In this post I'll discuss our work with a client where we put it into action.

Our client was an electronics home entertainment manufacturer that partnered with distributors to sell their products through both the Internet and brick and mortar stores. Increasing their sales and market share was a top priority. But they had a problem: too many products were returned for repair multiple times. This company established the reduction of product returns as a core corporate improvement metric.  

Since Product Quality was now a top priority, BI efforts were enlisted to fulfill this goal. I was involved with a team that analyzed the business process and identified analytic needs that could pinpoint where the quality problems occurred: where they manufacturing process defects, material problems, or labor errors?

We identified each phase of the product life cycle: Sourcing, Purchasing, Manufacturing, Distribution, Sales, and Returns. From each of these phases, we analyzed the related data subject areas in detail, looking for some insight as to where defects were surfacing. Since the Returns area was of prime importance, there was a lot of focus on these types of questions:

• What was being returned (product models)?
• Where was it getting inspected and fixed (repair centers)?
• When was it returned and how long it took to fix (time to repair)?
• Who repaired the item (technical personnel, also what repair station)?
• Why did this problem occur (conclusions that can be reached)?

These were the classical Five W’s that can be used in the analysis process. You can use these questions as a starting point of any BI requirements gathering. It addresses BI Analysis from different perspectives:

• The Business Area being analyzed.
• Inputs and outputs of the process flow.
• Time measurements of the steps in the process.
• People and equipment involved in the process.

These different perspectives ensure that the business problem is addressed in a more complete fashion. From analyzing time, process, people and material measurements, the users will be able to better pinpoint the areas where defects are occurring. A flow oriented model is easy to understand since it follows a product through its lifecycle. It also depicts clear handoff points between manufacturing areas, with inputs, durations and outputs for each step.

Taking the top-down approach and subdividing a business processes into phases is one of the classic approaches of BI requirements gathering, but there are many more techniques that we will explore in subsequent posts!

---

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.

When Great Minds Converge...

Dear readers,

Please take note:

We've recently decided that the insightful musings from the experts here at Baseline Consulting would be best served under one umbrella. Rather than our two bi-weekly blogs, In The Industry and In The Field, we've moved all our content into this blog. After all, all of our experts are in the industry, and they're also working in the field. In an effort to make this content accessible to everyone, we've opted to merge the blogs. As a reader, you can expect the same great content, but you only have to look/subscribe/link to one location: Baseline's In The Field with Our Experts.

Updated to add: If you're currently a subscriber, your RSS feed may see some extra activity ("It's alive! It's alive!"), as we merge and update the blogs for easier reading. We apologize for any inconvenience, and we thank you for your patience.

New Business Requirements for BI: Part 1

By Fernando Martinez-Campos, Senior Consultant

 Business intelligence requirements gathering has long been an established process in the BI development lifecycle. However the process is changing. In our client work we’ve seen many approaches to business requirements definition. In my next three blog posts I will discuss one of these clients, and present a top-down case study of defining requirements, starting with the business needs for the Enterprise. Then we will explore other different perspectives of BI requirements gathering.

I have analyzed business requirements in many industries and found it difficult to devise a single, standard recipe of questions that could be applied universally across client situations. The best examples of successful requirements gathering tend to be with companies that have easily understood business processes that can be measured, tracked, and improved using BI. Using the example in these blog posts you can apply some general principles to your specific requirements analysis needs.

Before we start, let me explain the the so-called “top-down” approach to business requirements gathering. Top-down requirements analysis starts by looking at the overall business model. Then we proceed to break down the business model into flows, phases within the flow, and opportunities where BI will help improve the business. Top-down analysis has these benefits:

• It aligns top business priorities with BI projects (and vice versa).
• Executive management gets involved in solving business problems with analytics.
• It provides a high level roadmap of business initiatives and BI projects.

Top-down means considering a general business problem at the highest level of the enterprise, the “top”, and subdivide the analysis into more detail. This process ensures that the highest business priorities are addressed first. Then subsequent efforts refine those priorities into implementable projects. Top-down works best when there is a high-profile business initiative and a sense of urgency with executive management. This provides the impetus to fund projects that analyze these problems and implement BI solutions.

The top-down approach is not the only way of gathering requirements —we’ll discuss others in future blog posts.   

---

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.

IT and Business Alignment Begins with Listening

By Robert Stone, Managing Consultant

A lot has been written about the topic of IT –business alignment. We see it in action at our clients all the time. Baseline even offers a course on the topic.  I’ve made certain observations about it in my client work over the years that I’d like to share in this blog post.

We find that business intelligence projects are often the optimum way for companies to achieve tighter IT-business alignment. That’s because IT - business alignment will succeed only if you’re solving a business problem.  IT should not show up at a meeting with business users and recite a laundry list of everything they can do.  They should also avoid discussions of technology or existing reports. Instead, they should ask the business what their problems are.  Stakeholders actually enjoy describing what is preventing them from achieving their strategic goals or, at an individual level, what is preventing them from being more productive in their daily work.  IT should listen to the concerns of the business stakeholders and then determine how they can help in an effective manner.   Successful projects will become more frequent because IT already knows the business problems in detail before the project ever begins.

photo by Orange_Beard

Alignment is really all about building a relationship of trust.  If you constantly help business find reasonable and effective solutions then they will trust you.  Trust is also doing what you say—much easier with a set of articulated business requirements in place—and this requires good data management and business intelligence capabilities.

Alignment is not about pitching the business on a new project, the latest BI tool, or the latest methodology. It’s about establishing rules of engagement that can only be followed after earning the stakeholders’ trust.

---

Robert Stone has been with Baseline Consulting over 9 years and is a Managing Consultant responsible for leading and managing large and small projects.  He has over 25 years of IT experience with a diverse knowledge and skill base, and he's focused his skills on using technology to empower business users in many industries.

7 Ways to Cover Your Asset

By Rob Paller, Consultant

If you have attended a conference on data warehousing, business intelligence, data management, or data governance recently you ultimately have heard the saying, “Treat your data as a corporate asset”, countless times. Treating your data as a corporate asset means investing in data comparable to other corporate assets in terms of resources and technology. It also means that you understand the cost of poor quality, inaccurate, or missing data.

We have belabored the point that you should invest time and money into data integration technologies to assist you in mastering your master data elements. This is after you have invested the time, people and money to establish sound data governance policies. Nor does it discount the investment in the BI tools that can translate your data into information that can be used, understood and profitable.

What cannot be overstated is to the need to protect what is arguably your most important corporate asset from not only natural disasters and hardware failures but from both accidental deletion and intentional sabotage.  At the end of 2008, JournalSpace, an online company in business since 2002, was forced offline permanently because their entire database was overwritten as the result of a malicious act. What made the situation fatal was their reliance on the hardware redundancy of RAID alone to protect their database. In other words, they did not archive their data.

photo by wonderferret

Are you doing everything possible to cover your corporate asset?  Here are several questions to help you determine your own disaster readiness:

• Are you logging all queries submitted to your databases and archiving these logs daily?
• Have you established a disaster recovery process for your database systems?
• Have you performed periodic disaster recovery drills to make sure you are able to bring the affected system(s) back online?
• Are your archives maintained in separate location from your database systems?
• When an employee with administrator privileges leaves the company do you not only remove their user accounts but change the admin passwords on the systems administered by the employee?
• Do you maintain an audit log of users with the ability to purge production data and failed logon attempts for these users or admin users?
• Do you maintain a separation of duties and/or environments for testing ETL processes?

Are you able to sleep well tonight knowing how well your asset is covered? If not, follow the seven steps above and you’ll rest easy.

---

Rob Paller is an expert at business analytics and database administration. Since joining Baseline, Rob has been responsible for developing a case analysis system to streamline the oversight of food assistance benefits, implementing a common citizen data model, and assisting in the rollout of a new public assistance data model integrating data from over 10 years of legacy with a new benefit eligibility determination system.