A Data Management roadmap for a successful BI Analytical Solution
Organizations have a tough task to retain the current business growth, and are examining ways to retain the existing customers, comply with regulations and optimize spend on the operational/capital budgets on strategic plans to achieve the target business growth. To enable a better decision making process, Organizations are opting for business intelligence solutions across the industries.
In large organizations, data volumes and process complexity are growing at a faster pace. Organizations have realized the fact, that Information is a key asset and data collection will be a key factor for competitive advantage and achieve business goals.
The enormous growth of data volumes are adding challenges to the IT teams to optimize the infra-structure and improve the response times. The rising data volumes and complexity have resulted in higher maintenance costs for data retrieval, data integration & data access activities. The expectation of business users to view the critical data down to item level should be available at point-of-decision. These challenges are leading the IT organizations to build BI solutions with advanced analytical capabilities to handle larger data volumes of internal & external data sources.
The key challenge is the data management as understood from the Industry executives, is to integrate the disparate legacy systems & data complexity into BI framework.

Key challenges of BI analytical solutions in the context of a new Software implementation include:

Identifying all the data sources for the BI applications
Growing complexity of data connected to the BI systems due to dynamic conditions impacting business scenarios
Latency of information required for Job performance
Data growth from the connected systems
IT infra-structure and Data integration for new data sources

Decision Technologies is currently engaged in delivering a data management roadmap for a BI project with Internet software provider. The client business had grown over years with acquisitions and this resulted in multiple systems and databases into business solution landscape.
Our Approach to address the Data Management challenges
Initiate workshops/discussions with the business owners to understand the Process and the Data associated with the business scenarios for the BI Solution
Map the processes and the data associated to optimize the data models
Focus on the data quality requirements to make the data ready for business process in the BI Solution
Design a flexible data architecture which supports integration with multiple data sources
Develop a Data governance process to bring agreement within the internal parties on data elements, KPI’s and metrics.

Best practices to implement self-service BI properly
By Wayne W. Eckerson
08/19/10

There’s a lot of talk these days about the importance of self-service business intelligence (BI) but little discussion about the downsides. Unfortunately, I’ve seen self-service BI initiatives go completely awry.
Typically, a small percentage of power users employ the new-fangled tools to create tens of thousands of reports — many of which contain conflicting or inaccurate data — and this makes it harder for casual users to find the right report or trust its contents. Ironically, many turn to IT to create a custom report, which expands the report backlog that self-service BI was supposed to eliminate. In addition, many power users employ the self-service tools to query large data sets that they export to Excel for analysis. These runaway queries erode query performance significantly, making the BI environment even less inviting for casual users.
Despite its allure, self-service BI can cause overall BI usage to plummet, report backlogs to grow, query performance to diminish, and information inconsistency to increase. To avoid such unintended consequences, here are five ways to implement self-service BI properly.

1. Deploy the right type of self-service BI. Power users need ad hoc report creation; casual users need ad hoc report navigation. There is a big difference. Powers users need to create reports from scratch, often accessing data from multiple locations. Casual users, on the other hand, simply want a report or dashboard that contains their top 10 performance metrics and makes it easy to drill down into details, if desired.
Don’t abdicate responsibility for creating standard reports. To ensure that business units exploit the full value of the data warehousing resource, BI teams should take an active role in creating standard reports or dashboards for each group. This requires BI teams to become more engaged with the business, not less, which is usually what happens when an organization deploys self-service BI tools. It is not enough to create the data warehouse; if you want widespread adoption, you need to deliver the end-to-end solution.
3. Create a network of super users. Super users are technically inclined power users in each department who function as extensions to the corporate BI team. Their job is to create ad hoc reports around the edges of the standard reports, suggest enhancements to the standard reports, and work with the BI Competency Center to define standards, select tools, and create a BI roadmap. Super users are the eyes and ears of the corporate BI team within each business group and critical to its success.
4. Liberate and manage power users. Power users can make or break a BI program. To get them on your side, give power users access to the best tools, unlimited access to data, and a sandbox within the data warehouse in which to conduct their ad hoc explorations. To ensure that they don’t proliferate spreadmarts, limit their ability to publish reports back to the server and establish a review board of power users (i.e., their peers) to examine new requests for published reports. This two-pronged approach will empower power users to generate critical insights while minimizing their ability to foment report chaos.
5. Educate executives to use standard, certified reports. For self-service BI to really work, executives need to make a companywide declaration and commitment to use standard, certified reports or dashboards when making decisions. Of course, there will always be exceptions, as when standard reports don’t contain the data needed to address issues required for a decision, but a corporate edict backed up by action makes all the difference.
Following these five steps will help your BI program achieve the Holy Grail of self-service BI.

The full article can be read at
http://tdwi.org/Articles/2010/08/19/experts-self-service-nirvana.aspx

Key Data challenges in a ERP Implementation
Ensure business participation in the Data migration (Data preparation, Collection and validation)
Align Business process with Data
Selection of right technology for Data conversions and migration
Continued Data Integration
Number of Data sources for the critical business objects

Decision Technologies have recently worked on two projects in Semiconductor and Electronic manufacturing services (EMS) industries on data migrations to help implementing the business transformation projects.
The Semiconductor client had migrated from SAP 4.7, Oracle into ECC 6.0.
The EMS client had migrated from multiple Legacy systems into SAP SRM, SAP MDM, ECC & SAP BI.
Key learning from the SAP ERP Implementations at our clients
Data assessment at the beginning of the Project to optimize the SAP Configuration settings, avoid duplicate & redundant entries, estimate the data quality effort requirements
Determine the SAP Enterprise settings early ( Company Codes, Plants, Sales Org, Distribution channel, Purchase Org, GL Accounts, Bank Master, Controlling data, Hierarchies and others) which will drive all the data migration activities i.e. Master data and Transactional data.
Design & Develop an appropriate Data conversion architecture to effectively control the time and cost for the opted technology
Do not build excessive business logic in the SAP data upload programs. Have a good ETL tool to implement all the data transformations before transferring the data to SAP
Involve the Business super users and process owners early in the Data migration workflow to validate the data
Determine the multi-language support requirements at the beginning of solution design

Our Approach to address the Data challenges
Begin a Data audit in the early stages of Project to identify the critical fields required to support the business
Map the Business objects( Field mapping) to the new SAP system and identify gaps for design& development
Build a implementation plan to align the data activities with the SAP Configuration activities
Focus on the data quality requirements to make the data ready for business process
Design a flexible technical architecture which supports multiple iterations of data testing for the full data volumes
Automate the High volume Data activities to avoid delays with manual operations
Develop a workflow process to have a clear delegation of responsibilities to validate and address the data quality issues during the data migration.

The major factors contributing to this situation are:

1. Implementing the Legacy business processes in the new system, not validating the best practices given by the Software vendor.
2. No training planned for core business teams in advance of the solution design phase to understand the standard functionality offered by the software vendor
3. Data Quality assessment and ERP Software mandates for Data Quality
Strict governance on change management
4. No communication within Project teams on the cross-functional dependencies
5. Failure to test the data and impact across multiple stake holders in the enterprise
6. Focus on the process testing with sample data and not simulating the real-time data scenarios

Challenges for different business groups

Product data/Customer data/Vendor data is a corporate asset across the enterprise and the executive stake holders are represented from Engineering, Operations, Marketing, Sales, Procurement, Finance and Information systems. Each of these functions or stake holder focus on his requirements and not validating the inter-dependencies within them

The challenges may be better addressed if a right implementation partner is selected, who have domain experience and as well as IT experience to ease many of the commonly encountered issues. The Implementation partner can help address the business re-engineering of the processes to suit the best practices and also help analyzing and closing the identified gaps.

For example, an Engineer can help optimize the PRODUCT based on marketing team surveys with the customers. Operations team may design an economical packaging to minimize the transportation overheads and based on customer requirements.

The Integrated view of the Product and good governance will enable the business to address the challenges mentioned. Any delay in addressing the critical issues will diffuse the business drivers and impact the ROI

Systems covered in this blog:
SAP ERP system: ECC 4.7, ECC 6.0
Oracle ERP system: Oracle ebiz platform
SAP CRM system:
Oracle’s CRM system: Siebel on premise, Siebel on demand (maintained and hosted by Oracle)
In today’s competitive global marketplace, Enterprise Resource Planning system (ERP system) and Customer Relationship Management systems (CRM system) vendors are offering attractive incentives to companies moving from competitor ERP systems and CRM systems to theirs. Faced with the challenge of re-licensing and re-implementation from a old version of a CRM system or ERP system to the latest versions, a significant number of companies show interest to move to a competitors ERP system or CRM system to obtain better deals on licensing fees and incentives.

SAP and Oracle are the two major software giants in the Enterprise Resource Planning systems (ERP System) and Customer Relationship Management system (CRM System) solutions with a combine market share of over 50%.

The three areas that should be considered before making this decision are;
Business processes and functionality mapping – How well are the business processes understood and how these processes map to ERP system or the CRM System.
Frequency of change: How frequently does the business processes change that in turn require config changes require customizations to the ERP system or CRM system? For example, Siebel CRM system can be configured and extended as required while changes to Siebel on Demand CRM system (maintained and hosted by Oracle) may take up to a year if ever.
Data Migration: this article will discuss the data migration issues & challenges facing a company considering a move from one ERP system to another. For example from SAP’s ECC system to Oracle E-Business application suite (Oracle’s ERP system).

Data migration key challenges include:

• Identifying and analyzing source data for the ERP system or CRM system
• Accessing heterogeneous data sources for migration to the new ERP system or CRM system
• Addressing and maintaining enterprise data quality required for the new System
• Converting and transforming data for import into the new erp system or CRM system
• Supporting an iterative and ongoing data migration life cycle

Data Migration Technical Challenges
Nomenclature and data structures
SAP uses the Business Partner for its ERP system while Oracle’s eBis suite calls it the Party model. While the concept is the same, the data structures for the same objects are very very different between SAP and Oracle. This is just one object scenario with challenges to data migration approach and architecture.
Point being that every ERP system and CRM system platform has a unique nomenclature and accompanying data structure for each data Object. To complicate this even further the data structure usually changes from version to version. This requires a strong understanding of the business and the ERP system or CRM system data model to architect the right solution.

Underlying database
Data migration between SAP and Oracle is complicated in how the underlying database is used buy each ERP system (or CRM system) For the most part SAP utilizes the database as simple storage and does not leverage primary key and foreign key join relationships at the database layer. (The join logic is stored in the application layer) A prime example would be how SAP converts numbers to text; the customer number is 16 characters long and can have leading zeros.
Oracle ERP system on the other hand, mainly due to its roots as a database company, utilizes the efficiencies of the primary key and foreign key relationships at the database platform.

Decision Technologies recently completed data migration, for a semiconductor client, from six legacy ERP systems to Oracle and SAP ERP systems with a two-way integration between both Oracle ERP system and SAP’s ERP system. The semiconductor client is utilizing the Oracle E-Business suite for manufacturing functions and SAP ECC 6.0 erp system for financial accounting.

Decision Technologies key suggestions –
The business functions might have changed drastically from the last implementation, do not solution the system with the configuration existing on the current ERP system.
Perform data assessment at the beginning of the project to estimate the number of critical objects, structural differences, data quality, amount of customization existing in the current ERP system to exactly scope the Data migration efforts.
Validate the business requirements and compare it to the best practices from the new Enterprise Software vendor to avoid costly customization
Create a Change Management program to train and enable understanding of changes for user base. This will facilitate adoption
Communicate early and often to all impacted teams to garner collaboration and help architecting a user-friendly solution
Design & develop an appropriate data conversion architecture to effectively address the requirements of all systems in the Landscape
Determine the multi-language support requirements at the beginning of solution design