LAS VEGAS -- With a competing business intelligence product already in place, pockets of resistance in the sales...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
force and a wealth of spreadsheets, the team launching Oracle Business Intelligence Enterprise Edition (OBIEE) for analytics at McKesson had its hands full.
Speaking at Collaborate, the Oracle users groups show being held here this week, Tony Isele, senior business analyst with the medical supplies, distribution and technology company, offered some advice on overcoming that resistance and successfully deploying OBIEE.
When McKesson first launched its OBIEE program, it was running Siebel Sales 7.5 on Windows on Oracle with SQL Server serving as a data warehouse. It wanted to enhance the reporting and analytics within the CRM system. Complicating the project, the company already had BusinessObjects in place.
"It was well established and expanding very fast with high adoption," Isele said. "We knew if we were going to be successful, we had to do something different."
My sales staff is starving and you've got rice and you don't want to give it to them because it's dirty. Give them the dirty rice.
McKesson division president upon seeing an OBIEE prototype
The group at McKesson running the BusinessObjects program is separate from Isele's, but they maintain a friendly relationship, he said.
"Even though they were our competition, they were also our peers," he said. "We didn't want to cannibalize the good work they had done. We wanted to compete with them but compete with them in a nice way."
That meant focusing on OBIEE's strengths versus BusinessObjects, which was running a large number of very complex reports that extended across a wide swath of the business. However, they ran off a copy of the transactional database and were static, Isele said.
The business users for the OBIEE project included senior executives, sales managers and client executives, who are effectively the front line sales managers and regional analysts that support the sales staff.
With BusinessObjects, it was typically the regional analysts who were accessing the system and running reports, often at the request of the managers. To get OBIEE adopted, Isele knew they had to appeal to everyone, and OBIEE's advantage was in its close integration with Siebel.
"I can't tell you how important this is in OBIEE," he said. "In Siebel, where the user is, it really does drive adoption. BusinessObjects sat in a separate application. People would go to OBIEE to get an answer instead of going to BusinessObjects."
Hurdles for the OBIEE implementation
The project faced other hurdles as well. There were myriad spreadsheets in use throughout the company, and Isele said there was pressure to retire them. That was not something his team wanted to undertake, however, preferring the carrot approach to the stick, convincing users of the benefits of OBIEE within Siebel. Ultimately, people who brought their static, Excel spreadsheets to their manager were convinced into abandoning them on their own when their managers kept asking why they were still using them for certain tasks.
Also, senior executives were calling for their own dashboard that extended across the business.
"It was a complex job," Isele said. "They had to bring in data without common keys or a common data model. It really didn't fly."
Senior executives were also ideal sponsors for the project, however, and since he couldn't deliver the dashboard, Isele needed another way to get them on board.
The solution -- one he recommends for anyone undertaking an OBIEE implementation -- was to build an OBIEE prototype. That was where they would find their target users and sponsors.
A prototype proves its value
Prototypes can add expense and demand more time and resources of a project, but they’re well worth it, Isele said.
McKesson built a sandbox and put six-month-old data into it to demonstrate some of the system's capabilities. The prototype took about a week to build. It was not perfect. The data was old, it would crash on occasion and some fields had no data, but it helped ensure the success of the project.
Isele and his team brought the prototype into a one-hour meeting with sales managers and senior executives. Some of those people were openly questioning whether the company needed another business intelligence tool. But once they started slicing and dicing the data, no one wanted to leave, even given the shortcomings of the prototype.
"It showed them things they didn't know and in some cases things they suspected but couldn't prove," Isele said. "We had sales managers cancelling other meetings, and we stayed two and a half hours showing them old data."
Several sales managers demanded access to the prototype itself. Isele and his team nearly became victims of their own preparation.
"We had a division president asking us to roll it out in a week," Isele said. "He said, 'My sales staff is starving and you've got rice and you don't want to give it to them because it's dirty. Give them the dirty rice.'"
Isele found the project sponsors in senior executives and the regional analysts.
Rolling out OBIEE functionality in waves
The first implementation was rolling out OBIEE to 850 Siebel Sales users. It focused on some basic needs: analysis of the sales funnel, activity opportunities, closed wins, and win/loss reporting.
"We tried to focus as much out-of-the-box functionality to get it up and running fast," Isele said. "Probably 70% of it was out of the box. Our strategy was to get out fast and extend it over time."
Reports were populated directly to the user's Siebel home page and were focused on user workflow and sales processes.
To ensure adoption, users had to trust the data. The OBIEE project included exception reporting to help users understand where data might be wrong and where they could go to clean up their bad data.
"We called them data exception reports because no one likes the word compliance," Isele said.
The next release focused on a new and separate group of users: the product specialists. At McKesson, these are sales reps who support a few specific projects and are brought in to help with those products on a deal. They wanted access to just their data, not the entire opportunity or sales data.
To solve that problem, McKesson looked outside of OBIEE and had client executives assign the product specialists to a sales team.
"A specialist would own a quote," Isele said. "We created an attribute on the revenue line item for product specialist and had specialists tag themselves on opportunities where they were on that deal."
The product specialists were then on board.
Finally, Isele and his team populated reports on the Sales portal, an internal portal shared throughout sales, putting reports from their dashboards directly on the page when they log in. They also made sure OBIEE got the credit.
"It's very important the users know where the data is coming from," Isele said.
Each report is tagged at the bottom with "Source: Sales Analytics."
In addition, McKesson set up its OBIEE implementation to run through the SQL Server data warehouse. That meant feeding data into an extract, transform and load (ETL) tool from Informatica.
"You need to communicate when the ETL runs," Isele said. "One thing we did to help with that is at the bottom of every page is a little report that gives users when the ETL run time is. That tells them what the oldest data in the data warehouse is."
OBIEE can tap nearly any data source, Isele said, including Excel, transactional databases or a data warehouse.
"On the transactional side, you're highly normalized for efficient updates," he said. "On the data warehouse, you're highly normalized for efficient reporting. Use ETL to bring data into the data warehouse and it will be extremely fast. The problem with this is it's not real time. Our ETL runs on a nightly basis."
More OBIEE implementation advice
Isele also recommends that organizations implementing OBIEE bring in outside expertise to get them started. Also, don't focus on cosmetic changes. Business users will come asking for cosmetic changes, but it’s getting the data right that should be the focus.
A key, as with nearly any IT project, is to bring IT and the business side together.
"That means IT going to the business side -- they won't come to you," Isele said. "Get engaged with business users and what data they need. Get something out quick and evolve it."