Expand +



Improve Your Response to Opportunities and Challenges Through Business Analytics: An Agile Approach to Implementing Impactful Analytics Solutions

by Brad Surak | SAPinsider

April 1, 2010

Companies across all industries are using analytics to identify and resolve critical business issues. Yet too many analytics projects fail because they’re too broad in scope and don’t deliver on expected results. To keep your project on track, learn the “Four Ds” of determining the right project scope, the value of reference architecture, and other expert advice on wielding analytics for competitive advantage.

Competing on analytics is not a new concept: Companies across all industries are using business intelligence tools to identify a specific business problem, analyze their data to understand the problem’s causes, and then act wisely on those insights to resolve the issue.

But the quality of the information gathered and how that information affects the decision-making process varies dramatically from company to company, or even from problem to problem. Often, the impact of analytics falls far short of expectations. Why? What differentiates analytics from just another reporting or dashboard project? How can you build the necessary competencies within your organization to identify the most effective areas to analyze? And how can you get those analytics into the hands of more decision makers faster?

I’ll explore these questions and suggest an agile approach to leveraging existing investments in software to improve decision making. The goal of this approach is to break down barriers — communication hurdles between business and IT, for example (see sidebar) — that have inhibited the majority of business decision makers from accessing analytics and wielding them for competitive advantage.

Beware of Scope Creep: The “Four Ds”

Too often, an analytics project loses momentum from the start because its scope is too broad. The wider its scope, the more an analytics initiative can seem like a traditional, costly IT project that involves extensively gathering and prioritizing requirements across multiple business domain areas. Facing lengthy design and development phases, business users may lose their initial enthusiasm for the project.

By keeping the scope narrow and delivering results sooner through a more agile and iterative approach, IT can build momentum and maintain engagement with the business. Throughout the project, IT can also make corrections and introduce innovations that help produce a higher-quality result.

Consider a supply chain vice president at a consumer products company who is worried about the financial health of his suppliers. He questions whether they’ll be able to deliver all the necessary materials for his next big order. Developing a comprehensive supply chain analytics project would be too broad and daunting in this case — better would be a targeted, narrow analytics project that just focuses on supplier risk. (Supplier risk is just one example of an analytics use case; see the sidebar for examples from various industries.)

But how do you determine the right scope for your project? Consider applying the “Four D” framework for defining analytics use cases: Detect, Diagnose, Decide, and Direct. This proven SAP model can help you structure the scope of your project into manageable chunks that can be quickly prototyped, socialized, and iterated.

1. Detect

For a decision maker to be able to act on a business challenge, he or she first needs to be alerted to it. To begin an analytics project, collaborate with the business to identify what anomaly or opportunity you need to detect and which metrics, when evaluated together, might signal a possible issue. If you’re analyzing supplier risk, for example, you may want to understand what factors, such as liquidity, cash flow positions, and credit risks, would raise a red flag about a key supplier. Working with the business, you can map out the specific type of information needed to solve a problem. You may identify several different events that you need to detect; each event would become its own use case.

2. Diagnose

Next, carry forward the metrics used to detect an anomaly and define the process for diagnosing the root cause of the anomaly in those metrics. Continuing the supplier risk example, you may dig further into performance reliability or financial viability indicators to assess risk of supplier failure. 

You can generally break the diagnosis phase into two steps: localize and circumstantiate. To localize an anomaly, you drill down into geography — where certain products are sold, for instance — and slice time periods until you understand the anomaly’s boundary conditions and when the problem started. Circumstantiation involves exploring the framework of intermediate metrics, such as financial ratios, to better understand areas for further analysis. For example, once you determine the area of risk exposure for the supplier, you can proceed to further identify causal factors, such as deteriorating ratios due to the loss of a key customer who isn’t paying the supplier on time.

3. Decide

Once you are aware of an anomaly or opportunity and understand what caused it, you can choose the best course of action — such as whether to extend gratuitous payment terms to a supplier to assist with its financial difficulties. This phase focuses on organizing the decision-making process and figuring out the factors that may affect a particular decision. The supply chain VP may want to know the financial impact necessary to keep an at-risk supplier afloat and whether bailing out this supplier would be more cost effective than switching to a competitor.

The decision-making processs incorporates other information — the amount and type of finished products that will be affected by a disruption in supply due to the failure of that supplier, for example — that supports how to mitigate risk and decide on the best course of action. Often by asking what-if questions, IT and a business user can model the consequences of a possible decision to determine the best combination of desired outcomes and manageable side effects.

4. Direct

After you identify the best course of action and communicate it to all relevant stakeholders, you’ll need to regularly follow up to ensure that the plan is carried out. To that end, the analytic facilitates the issuance of directives needed to execute the decision by, for example, aggregating status updates on the action plan (either automatically generated from the ERP system or manually entered). The executive who issued the directive can then view the progress and feed that information back into the analytic to determine if the decision is actually resolving the detected problem. In the supplier risk example, this may include monitoring progress on a decision to source a new supplier so the supply chain VP can see how that process is progressing and what the potential delay may be for his operations and customers. 

Of course, software alone cannot fully manage most complex directives — human judgment and input is needed — but linking to the enterprise applications that manage business processes helps ensure decision execution.

Business challenges continually change, so you need to be able to rapidly adapt your analytics in order to solve current, top-of-mind problems.

Improve Quality and Control Development Costs: The Value of Reference Architecture

Beyond the business efficiency benefits, knowing how to scope an analytics project using the Four D framework offers advantages on the technology side as well. By clearly understanding the form that most analytics applications take, you can architect your enterprise software investments to optimize the development and execution of those use cases.

I recommend having an analytics reference architecture that provides a view of your system, including its major technology components, the relationships between them, and the externally visible properties of those components (see Figure 1). This base structure is not designed for any specific analytic; rather, it serves as a starting point for any analytics application and can be layered upon and adjusted to meet the particular needs of a company’s use case.

Figure 1 Reference architecture for business analytic solutions

A reference architecture aligned with a set of common use cases enables you to make major design decisions just once and leverage them across multiple analytics initiatives. This flexibility reduces the time and cost needed to design and develop a new analytic because your development team will need to only address novel aspects of the design. When an issue arises with a design, the team can correct it at the reference architecture level and propagate the change to all affected analytics. The reference architecture then becomes the source of quality and productivity for analytics development, as well as a means to align the business purpose of the solution with the implementation technology.

Designing software around how business users make decisions can lead to faster resolution of pressing questions.

React Rapidly: Adopt a Squad-Based Execution Model

Not surprisingly, how you staff an analytics project has as much impact on the result as the other areas I’ve discussed. Think of analytics initiatives as special operations focused on addressing top-of-mind business problems. Develop a rapid reaction mentality, and when an opportunity or challenge arises, assemble a small cross-functional squad and task them with the mission of working with the business to define the use cases and deliver the end result.

Ideally, your squad would include: 

  1. A business domain expert who understands the business challenge at hand and is committed to addressing it within the Four D framework1
  2. A visualization expert who takes the identified use cases and translates them into storyboards and then into the final user interface
  3. A data architect who understands the data available for analysis and can design the necessary analytic data models and source system integrations

The individuals in these three core roles should work as co-leaders of the squad, complementing each other based on the practical constraints and requirements from their respective areas.

Depending on what business problem must be solved, this core squad should be augmented with specialists, such as activity-based costing experts or predictive analytic algorithm experts. The key to this squad-based model is to keep your team nimble — you can enable different roles to lead at different times, depending on the phase of the project.

An Agile Approach Delivers Results

Through a combination of the Four D framework, an aligned reference architecture, and a squad-based execution model, a business analytic solution consisting of two-to-three use cases can go from concept to launch in under 90 calendar days at a predictable cost (see sidebar). This capability to react rapidly to pressing business issues can be integrated into your organization’s operating model to enable a more effective use of your business intelligence assets to drive measurable business impact. 

Brad Surak ( is the Chief Operating Officer for Business Analytic Solutions at SAP. He drives an execution model that enables agility and efficiency across the strategy, solution management, development, and go-to-market functions of the business. With more than 15 years of experience spanning the software and systems integration industries, Brad brings a unique perspective to innovation within a large company.

1 The specific titles of individuals who fall into the “business domain expert” category will vary by organization. For example, you may refer to a business domain expert as a business analyst at your company. [back]

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!