Apotex BO Case Study

© 2008 Wellesley Information Services. All rights reserved.

Case Study: How Apotex Integrated BusinessObjects Solutions into Its Existing SAP NetWeaver BI Landscape for Easier End-User Reporting

Dr. John MayerApotex

2

In This Session ...

• Apotex started down the road of implementing a comprehensive business intelligence strategy in 2002. Since then, there have been successes and many lessons learned, both from a technology and from a process perspective.

• During this session we will explore the Apotex journey and highlight what we now believe to be critical components of building a workable business intelligence infrastructure.

• Part of the technology required to enable this strategy leverages offerings from core SAP applications as well as Business Objects, an SAP Company, and we’ll explore an example of where both technologies are used to provide valuable insight to our business.

3

What We’ll Cover …

• A brief history of reporting at Apotex – successes and challenges• Drivers for reassessing our approach to Business Intelligence• The BI strategy at Apotex – People, Process, and Technology• Example of the application of the BI strategy – Finance

Dashboards• Wrap-up

4

About Apotex

• Apotex was founded in 1974 and is the largest Canadian-owned pharmaceutical company

• Based in Toronto, Canada — exports to over 115 countries worldwide

• Employs > 6,500 people in R&D, Manufacturing, and Distribution worldwide

• Produces > 300 generic pharmaceuticals in > 4,000 dosages and formats

• Worldwide sales > $1 billion per year

History of Reporting at Apotex

• Implemented first SAP ERP system in November, 1999 — FI and processes to support purchasing

• Implemented SAP R/3 4.6C in July 2001• First “Reporting Strategy” in March 2002 outlined the need for

harmonized, consistent reporting across business units and the need for a process strategy and investment in skills – people, process, and technology

• Took a tool-centric approach to reporting/BI – “If we build it, they will come”

5

History of Reporting at Apotex (cont.)

• In the early stages of SAP, focused on queries and ABAP reports in SAP R/3

• Invested in Crystal Enterprise as the backbone for consistent delivery of (flat) reports

• Had a desire to push ad hoc reporting capabilities to end users,but lacked capable tools for a long time

• During rollout of Crystal Enterprise, also started the rollout of SAP BW 3.1

6


• Implemented SAP BW mid-2003 with SAP R/3 SD feeds• Took a very tool-centric approach to developing data marts

and reporting• Implemented with limited success• Lack of adoption due to limited user GUI• Performance issues plagued end-user query generation• Failed to appreciate the complexity of the technology and so

didn’t focus on skills development — led to limited success for support and changes of the data mart

7


• On the end-user reporting front, continued to expand the use of Crystal Enterprise, albeit only for flat reporting

• No consistent reporting approach across projects – no focus on standards, no focus on standards tools (always investigating thelatest and greatest products), no focus on the “big picture”

• By mid-2005, from a comprehensive business intelligence perspective, no further ahead than we were in 2002

8

9




Drivers for a Renewed Business Intelligence Approach

• In mid-2005, started the project to implement dashboards for Finance division

• Started as strictly an SAP BW initiative• Encountered some of the same issues as with SD – performance

issues on query generation, lack of adoption of end-user reporting interface (BEx)

• By mid-2006, however, a couple of things happened:Business Objects purchased Crystal DecisionsOur Crystal Enterprise infrastructure was aging and due for an upgradeProlific system integration was happening on our New Product Development side of the business, which was (is) predominantly non-SAPThere was added awareness of some of the issues we faced

10

Realization of Ongoing Systemic Issues

• There was a divisional, siloed approach to reporting and business intelligence

Lack of oversight and data governanceThere was no control, and in some cases, conflicting definitions as to what certain terms meant – no one was speaking the same language

• There were many data quality and data definition issues:Conflicting definitions of key business terms such as product or launch date, with no single verifiable source of the true informationMany inconsistencies in the data itself (Example: CND vs. CAN)

11

Realization of Ongoing Systemic Issues (cont.)

• Report development was taking too long and often not to user satisfaction

Lesson learned: Report development is a highly iterative process that is not inconsistent with new software development processes

• We were suffering from technology confusionNo control over which technology was facilitating reporting in projects and operationallyResulted in too many tools, no consistent approach, no comprehensive skill development

• Heterogeneous expectations: Some business units wanted reporting tools themselves, some did not

There was a realization that BI maturity was wide and varied across the business functional units

12

13




The BI Strategy at Apotex

• By mid-2006, decided upon a new course of action with a renewed focus on BI as a fundamental business practice and priority

• Developed a comprehensive strategy to drive BI through the organization “top down” through ensuring executive buy-in and “bottom up” by implementing quick BI wins through smaller, more focused data marts

14

The BI Strategy at Apotex – Guiding Principles

• BI needs to be a strategic partnership between all of the Business Units and Information Services (IS) – neither can do it effectively alone or in business “silos”

• Build competency through tools standardization, yielding improved overall support from improved know-how — both in IS and the Business

• Use the right tool for the right purpose with the right user• Adopt the concept “Better BI = Better Bottom Line”

15

BI Strategy at Apotex — Technology Recommendations

• Standardize on the right BI software vendor and tools• Align the existing BI and other reporting implementations with

standard BI tools where possible• Create a flexible, scalable, and robust technical architecture that

can quickly adapt to business needs while controlling costs• Separation of the back-end data source technology from the

technology driving the presentation layer to the end userPresentation needed to be consistent to the end user, regardless of back-end system; i.e., had to work across many technologies (SAP, Oracle, SQL Server databases, DB2, etc.)

16

BI Strategy at Apotex — Technology Recommendations (cont.)

SAP - BW

RDBMS

MS Access

Departmental Systems

Staging Area

Harmonization and Consolidate

Data Mart

Data Mart

Data Mart

Presentation Layer

Dash Boards

Reports

ReportsUniverse

OLAP Cube

17

BI Strategy at Apotex — Technology Recommendations (cont.)• Using the SAP BW FI initiative as the guinea pig, investigated

whether BusinessObjects™ XI Rel. 2 could be the end user unifying presentation technology

• Tested the suite of available applications against both the SAP BW FI cubes and non-SAP applications

• Found it to be easy to integrate and most of all, an enhancementto the end-user experience

• In particular, found the BusinessObjects Web Intelligence®

software technology to be robust and able to facilitate the end-user ad hoc reporting capability that we had been missing for so long

18

BI Strategy at Apotex — People Recommendations

• Ensure the right people and organizational structure to support the BI strategy

Assign a BI Process Owner to ensure accountabilityDevelop in-house skills for BI Functional ConsultingImplement more rigorous Data Architecture for Design and Development oversightDevelop in-house Application Development and Data Warehouse Development skills

• Establish relationships with the right technology consulting partners to assist with the BI implementations as we grow our internal skills

19

BI Strategy at Apotex — People Recommendations (cont.)

• Clearly separated what IS is responsible for and what the Business is responsible for:

IS best suited to handle core design of data warehouses, data marts, universes, and their development

Can oversee design consistency and identify cross-functional points of integrationCan leverage external partnerships where necessary and can monitor vendors for performance

Business is best suited for developing ad hoc reports and queries — analytical reporting, e.g.

• Initiated an overall corporate directive that each business unitmust identify and train BI power users as part of project rollouts

20

BI Strategy at Apotex — Process Recommendations

• Focused on new, enterprise approach to data mart development and reporting

• Invested time and resources to map out a data dictionary to be used across all new initiatives – defines consistent definition of certain data, ownership of that data, required stewardship, and rules for its use

• Continues to be refined and the dictionary grows with time – have implemented a Corporate Data Governance group

21

BI Strategy at Apotex — Process Recommendations (cont.)

• Harmonized our data mart design principles across both SAP and non-SAP systems

In the past, tended to treat SAP as its own technology, with itsown set of design principles and implementationWe now harmonize on our approach to gathering requirements and architecting solutions

• Tended to treat the implementation of data marts/BI as part of projects separate from the operational support of those applications

22


• Implemented three working groups in Information Services:Strategic, Tactical, and OperationalFocused on communication between all relevant parties that facilitate the BI strategy – make everyone feel as though they play a contributing part

• Strategic Working GroupComprised of BI Process Owner, Data Architects, Designers, and Consulting ManagersDiscuss, define, and refine overall BI strategy, business drivers, and prioritiesHelps define the pace of BI implementation based upon the needs of the business, maturity of the business units, where existing tactical deployments lay

23


• Tactical Working GroupComprised of Data Architect, Consulting Managers in charge of Projects, Operational Support ManagersCommunicate the status of specific project initiativesDefine training gaps and approach for project go-lives to ensure operational supportBalance tight resource pool across project work while taking support work (changes, incidents) into consideration

24


• Operational Working GroupComprised of a Reporting Manager, Operational Support Managers, Designers and Technical DevelopersHelps communicate and manage operational reports incidents and changesVets changes against the timelines for project deployments and alignment with overall BI strategy

25

Continuing BI Challenges

• Wanting too much too soonThis needs to be thought of as a multi-year endeavourBest practice – The “rolling snowball” approach

Start small, build awareness, build competency (both IS and Business), focus priorities, establish quick winsAvoid the avalanche

• Limited resources available to manage operational changes and incidents, and to perform general maintenance

• Time lag from when individuals were initially trained to when they actually started using that training

26

Continuing BI Challenges (cont.)

• Difficult to manage and enforce standards against physical database changes and implementations

• Limited understanding of dependencies and impacts as it relates to BI initiatives, across multiple data sources

• Lack of clear business ownership/stewardship of information • Data inconsistencies

Heterogeneous master data across business functions continues to be a barrier to system and BI integration

27

BI Recommendations

• Hire and/or train internal staff and engage them on projects to ensure learning and knowledge transfer

• Align project management methodology to support various BI and Data Management tasks and deliverables

• Engage BI and Data Management functional experts in reviewing project plans and assess approaches earlier, start evaluation stage

• Ensure projects are prioritized to make proper usage of limited BI and Data Management resources

• Avoid going live with multiple projects that include BI deliverables, phase out implementations

28

29




Finance Dashboards – Drivers

• Business driver for Finance (FI) dashboardsLooking for a consolidated view of our business, with the ability to drill down to more detailDriven by looking at views from different perspectives: Product, customer, or region

• Design DriversWanted the dashboard experience to facilitate guided analysis — with little effort business users could drill into more detail to get answers to information summarized at a higher levelDashboards need to be user friendly and responsive, and the infrastructure had to allow for power-users to develop ad hoc reportsAllow individual users to store and run their own custom reports

30

Finance Dashboards – Technology Overview

• Example of the marriage between SAP NetWeaver® BI and BusinessObjects technology at Apotex

Back-end data mart originally developed on top of SAP BW 3.1 – utilized the SAP infrastructure to pull from data sources (ETL), stage data, and build InfoProvidersHave since upgraded the back-end systems from SAP BW 3.1 to SAP NetWeaver® BI 7.0Utilized BusinessObjects XI Rel. 2 for front-end dashboard presentationThe BusinessObjects front end was originally developed on top of SAP BW 3.1, but no issues were encountered as a result of the upgrade to SAP NetWeaver BI

31

Finance Dashboards – BusinessObjects Architecture

32

FI Dashboards – Data Sources

• Master Data: from SAP R/3 and I-many Inc. CARS® Contract Management solution

• Transactional Data from:SAP R/3:

COPA Operating ConcernsProfit Center ActualsProfit Center BudgetsProduct Costing

CARS:Contract Sales Items

Flat Files:Projected Sales Budget by Material

33

Finance Dashboards — Back-End Design

• Data extraction from SAP R/3, CARS, and flat files• ETL: Source to Staging Layers

Staging Layer consists of Operational Data Stores (ODSs) and Cubes

• ETL: Staging Layers to Reporting InfoProvidersBase Reporting Cubes

Physically partitioned by business divisions and Fiscal YearSummary Cubes

Customer and ProductDaily Sales Cube

• Aggregates are also created for each InfoProviderAggregate structure is driven by dashboard components

• MultiProviders on top of InfoProviders above34

FI Dashboards — Front-End Design

• SAP NetWeaver BI Queries on MultiProviders are created to support the dashboards

Be sure to flag “released for OLAP” (ensures accessibility from the BusinessObjects Dashboard Manager front end)

• BusinessObjects Universes are created on top of SAP NetWeaver BI queries:

BusinessObjects Web Intelligence reports are built on top of the Universes to support the dashboard application

• Xcelsius® models are built with the BusinessObjects Web Intelligence reports using the Live Office Connector

• Xcelsius models are displayed using the Dashboard Manager as container

35

FI Dashboards — Overall Architecture

36

Finance Dashboards — Guided Analysis

37

Finance Dashboards — Guided Analysis (cont.)

38

Business user is presented with view of KPIs for a particular region of interest


39

Based upon information displayed, user can investigate each KPI from a Customer, Product, or Region perspective


40

Detail reports pull parameters from the previous dashboard and give the ability to tailor the report

Finance Dashboards — Challenges

• Business users wanted to use the same set of dashboards to display both summary and detailed information

• Summary information needed to be summarized “on-demand”from detailed information

Drove the design to include aggregate and summary cubes to alleviate performance issues

• Difficulty finding qualifies consultants versed in the integration of the SAP and Business Objects toolsets

• Time allocated to data cleanup and validation was vastly underestimated, even for feeds from SAP R/3

• There were gaps in the knowledge of the back-end data —business rules not always well understood for processes that occurred manually or were ad hoc

41

42




Resources

• Benard Boar, The Art of Strategic Planning for Information Technology (Second Edition, John Wiley & Sons, 2001, ISBN# 0471376558).

Good high-level overview of the strategic importance of business intelligence

• Ralph Kimball, The Data Warehouse Lifecycle Toolkit (Wiley Publishing, 1998, ISBN# 0471255475).

Description of a practical approach to building an enterprise data warehouse

43

44

7 Key Points to Take Home

• Business Intelligence is a long-term endeavor that will continually evolve and adapt to current business needs

• Avoid approaching BI strictly from a technology perspective —focus on process and people as well

• Start with an enterprise view of BI, but start small with quick wins to build competency and organizational buy-in

• Concentrate on one set of technology and mandate its use across all operational, tactical, or strategic initiatives

• Focus efforts on data management — the need to have harmonized data definitions and master sources of the truth

• Communicate, communicate, communicate — involve everyone in the process

• Invest in the skills required to support the BI process

45

Your Turn!

How to contact me:John Mayer

[email protected]

46

DisclaimerSAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver®, Duet™, PartnerEdge, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor controlled by SAP.

Apotex BO Case Study

Documents

Transcript of Apotex BO Case Study