Join Me For A BI Strategy Workshop In Cambridge, Mass., On October 19, 2010

Boris Evelson

Business intelligence (BI) continues to be front and center on the agendas of businesses of all sizes and in all industries and geographies. Ever-increasing data volumes, complexity of global operations, and demanding regulatory reporting requirements are just some of the reasons. But also, more and more businesses realize that BI is not just a tool but rather a key corporate asset that they can use to survive, compete, and succeed in an otherwise increasingly commoditized global economy.

However, we consistently find that many BI initiatives fail and even more are less than successful. Well, maybe we can help. Even if just a little bit. Come to our interactive one-day BI Strategy Workshop to learn the fundamentals and best practices for building effective and efficient BI platforms and applications. The Workshop will also include hands-on exercises with tangible deliverables that you can take back to your teams to help you jump-start or adjust the course of your BI initiatives.

Why attend? Because hundreds of organizations have already benefited from reading Forrester research and working with Forrester analysts on the topics covered in this Workshop. I plan to present Forrester’s most recent research on:

  • Why are BI initiatives at the top of everyone's agenda, while many of them still fail?
  • What are some of the best practices necessary to achieve successful BI implementations?
  • What are some of the next-generation BI technologies and trends that you can't overlook, such as Agile BI and self-service BI?
  • How do you assess your BI maturity so that you can get a solid starting point on the way to your BI vision and target BI state?
  • How do you assess whether your organization has a solid BI strategy?
Read more

Join Our Data Management Tweet Jam On MDM’s Next Evolution: Tuesday, July 20, 3-4 PM ET

Noel Yuhanna

Many large organizations have finally “seen the light” and are trying to figure out the best way to treat their critical data as the trusted asset it should be. As a result, master data management (MDM) strategies and the enabling architectures, organizational and governance models, methodologies, and technologies that support the delivery of MDM capabilities are…in a word…HOT! But the concept of MDM -- and the homegrown or vendor-enabled technologies that attempt to deliver that elusive “single version of truth,” “golden record,” or “360-degree view” -- has been around for decades in one form or another (e.g., data warehousing, BI, data quality, EII, CRM, ERP, etc. have all at one time or another promised to deliver that single version of truth in one form or another).

The current market view of MDM has matured significantly over the past 5 years, and today many organizations are on their way to successfully delivering multi-domain/multi-form master data solutions across various physical and federated architectural approaches. But the long-term evolution of the MDM concept is far from over. There remains a tremendous gap in what limited business value most MDM efforts deliver today compared to what all MDM and data management evangelists feel MDM is capable of delivering in terms of business optimization, risk mitigation, and competitive differentiation.

What will the next evolution of the MDM concept look like in the next 3, 5, and 10 years? Will the next breakthrough be one that’s focused on technology enablement? How about information architecture? Data governance and stewardship? Alignment with other enterprise IT and business strategies?  

Read more

Software Quality Is More Than Just Lack Of Defects

Mike Gualtieri

My colleague Margo Visitacion and I are finishing up a new report, Seven Pragmatic Practices To Improve Software Quality, that will publish in a few weeks. We realized that not everyone has the same definition of quality. More often than not application development professionals define software quality as just meaning fewer bugs. But software quality means a whole lot more than just fewer bugs.

Forrester defines software quality as:

Software that meets business requirements, provides a satisfying user experience, and has fewer defects.

 

What It Means: Quality Is A Team Sport

Quality must move beyond the purview of just QA professionals and must become an integrated part of the entire software development life cycle (SDLC) to reduce schedule-killing rework when business requirements are misunderstood, improve user satisfaction, and reduce the risks of untested nonfunctional requirements such as security and performance.

Where Do You Draw The Lines Between Business And IT Ownership Of Data And Information?

Boris Evelson

I get many questions on this subject and it often turns into almost a religious debate. Let's throw some structure into it. Here's a decision-to-raw-data stack.

  1. Decisions
  2. Strategy
  3. Policies
  4. Objectives (e.g., clear understanding of what is driving revenue performance)
  5. Goals (e.g., achieve x% income growth)
  6. Calculated metrics (any combination, variation of the standard metrics or KPIs)
  7. KPIs (e.g., profitability, liquidity, shareholders value)
  8. KPMs (e.g., enterprise value, trailing/forward price/earnings)
  9. Metrics (e.g., fee income growth %, non-fee income growth %)
  10. Dimensions (part of MDM, e.g., customers, customer segments, products, time, region)
  11. Pre-calculated attributes (standard, cross-enterprise metrics, KPIs, and KPMs)
  12. Pre-built aggregates (used to speed up reports and queries)
  13. Analytical data (DW, DM)
  14. Operational data (ERP, CRM, financials, HR)

Obviously, it's never a clear-cut, binary decision, but in my humble opinion:

  • 1-6 should emphasize business ownership
  • 10-14 should emphasize IT ownership
  • 7-9 is where it gets murky, and ownership depends on whether metric/KPI/KPM is: 1) standard and fixed, 2) fluid and changes frequently, 3) different by product, line of business, or region.

What did I miss? Thoughts?

Lest We Forget SAP

John R. Rymer

The "smart money" seems to be betting against SAP. I hear all the time about the company's bleak prospects for the future. A client conversation last week reminded me of how strong SAP’s position is, despite its many issues.

This client, a worldwide manufacturer, is investing hundreds of millions of dollars in SAP software for its worldwide supply chain, financial management and reporting, inventory and order management, etc. The new SAP environment will replace hundreds of disparate applications and, ideally, result in far more efficient operations, far better visibility into operations, and far more uniform products around the world. The members of this client’s SAP implementation team have finished SAP implementation marathons before (at other employers). They know the good, the bad, the ugly.

In this manufacturer, SAP is sticky for four reasons.

Read more

Best practices for using spreadsheets as BI tools

Boris Evelson

By Boris Evelson

We all know that the war of fighting the proliferation of spreadsheets (as BI or as any other applications) in enterprises has been fought and lost. Gone are the days when BI and performance management vendors web sites had “let us come in and help you get rid of your spreadsheets” message in big bold letters on front pages. In my personal experience – implementing hundreds of BI platforms and solutions – the more BI apps you deliver, the more spreadsheets you end up with. Rolling out a BI application often just means an easier way for someone to access and export data to a spreadsheet. Even though some of the in memory analytics tools are beginning to chip away at the main reasons why spreadsheets in BI are so ubiquitous  (self service BI with no modeling or analysis constraints, and little to no reliance on IT), the spreadsheets for BI are here to stay for a long, long, long time.

With that in mind, let me offer a few best practices for controlling and managing (not getting rid of !) spreadsheets as a BI tool:

  1. Create a spreadsheet governance policy. Make it flexible – if it’s not, people will fight it. Here are a few examples of such policies:
    • - Spreadsheets can be used for reporting and analysis that support processes that do not go beyond individuals or small work groups vs. cross functional, cross enterprise processes  
    • - Spreadsheets can be used for reporting and analysis that are not part of mission critical processes
Read more

Oracle OBIEE 11g Launch: "We are back!"

Boris Evelson

Whoever said BI market is commoditizing, consolidating and getting very mature? Nothing can be farther from the truth. On the buy side, Forrester still sees tons of less-than-successful BI environments, applications and implementations as demonstrated by Forrester's recent BI Maturity survey. On the vendor/sell side, Forrester also sees a flurry of activity from the startups, small vendors and large, leading BI vendors constantly leapfrogging each other with every major and minor release.

In terms of the amount of BI activity that Forrester sees from our clients (from inquiries, advisories and consulting) there’s no question that SAP BusinessObjects and IBM Cognos continue to dominate client interest. Over the past couple of years Microsoft has typically taken the third place, SAS  fourth place and Oracle the distant fifth. But ever since Siebel and Hyperion acquisitions, the landscape has been changing, and we now often see Oracle jumping into third place, sometimes leapfrogging even Microsoft in the levels of monthly interest from Forrester clients.

Read more

Your Future Needs A Type 4 Technology Strategy

Randy Heffner

As I discuss with clients the developing notions of Forrester's Business Capability Architecture (see blog post #1 and blog post #2), I have found it important to distinguish between different levels of scope for technology strategy. The primary distinctions have to do with (a) the degree to which a strategy (and the architecture it promulgates) aims to account for future change and (b) the breadth of business and technology scenarios addressed by the strategy.

Thus, I define a four-part technology strategy taxonomy along a two-dimensional continuum with (a) and (b) as axes (IOW, the four parts are archetypes that will occur in varying degrees of purity), to wit:

  • Type 1: project strategy for successful solution delivery. With Type 1 strategy, the goal is simply to achieve successful project delivery. It is beyond the strategy’s scope to consider anything not necessary to deliver a solution that operates according to immediate business requirements. Future changes to the business and future changes in technology are not considered by the strategy (unless explicitly documented in the requirements). The classic case for a Type 1 strategy is when an organization definitively knows that the business scenario addressed by the solution is short-lived and will not encounter significant business or technology change during the solution’s lifetime (history argues that this is a risky assumption, yet sometimes it is valid).
Read more

Database Migrations Are Finally Becoming Simpler

Noel Yuhanna

Lately I have been getting quite a few inquiries on database migrations asking me about migration approaches, best practices, and tooling. Some of the reasons why companies are looking at migrations are because of staffing issues, scalability and security concerns, and cost-saving strategies. Migrations have always been complex, time consuming, and expensive, because each DBMS has proprietary data structures, data types, and SQL extensions. Once you choose a DBMS, you get locked into its platform, often creating a challenge when looking to migrate. Some companies told me that it took them more than a year to migrate some large and complex applications, which is not surprising. Although, tools and services have helped with migrations in the past, they have not been comprehensive and automated, which would make the process simple. Like an IT manager in the retail sector recently told me, “We did not want to spend a million dollars on tools and services just to save a million dollars on our database platform; it just didn’t make sense.”

Read more

Planes, Pains, and Multichannel Engagement

Stephen Powers

Recently on a cross-country flight, I was just waking up when the flight attendant asked me what I wanted for lunch. She was a little annoyed because I kept her waiting while I  looked  through the magazine for food choices, and gummed up the whole works. And who could blame her for being annoyed? She had a whole bunch of people to get serve. I made a hasty selection and mistakenly picked the healthy snack box (organic pumpkinflas granola and apple slices instead of pepperoni and a chocolate chip cookie).

About an hour later, I had some serious hunger pains and would have killed for one of those old-school gummy chicken casserole airline dinners.

What would have solved this? A proper online engagement architecture, naturally. I usually print my boarding passes out ahead of time. So why doesn’t an airline print out the food choices under the boarding pass, or distribute via mobile devices as people increasingly use them for check-in? The airlines could provide other information, too, like how full the flight is, and whether NBC in the Sky will show something good like “The Office” or something not-so-good like “The Marriage Ref”.

So, what’s the problem? Content management and delivery systems aren’t unified.  There are all kinds of opportunities to present rich, consistent, engaging multichannel experiences by integrating technologies such as content management, customer relationship management, document output management, email campaign management, and others. But these are still siloed, due to legacy issues as well as market dynamics (there is no unified solution on the market).

Read more