Agility by Design - eprentise Blog

The value of an ERP system lies in the promises of better information, consistent systems, and reduced operational costs. With an ERP system, the ability to share data across applications and among different business units translated into more clearly defined business processes. The promise and the value depended on consultants who defined the current state of the business and who had a crystal ball made up of their vast experience to anticipate the future state. Companies counted on their ERP systems to accommodate growth and business changes.

As companies approach 15 to 20 years running the same systems, they are deriving less value from the system that was originally implemented. The number of spreadsheets has multiplied, many are considering a reimplementation, and there are hundreds — if not thousands — of interfaces to systems that perform similar functions, consolidate the data, or translate it so that it is useful to the ever-changing business requirements. The promise of reduced operating costs and consistent systems has resulted in a very high cost of ownership and a loss of business value.

Total Cost of Ownership (TCO) is an attempt to quantify the financial impact of operating an IT product throughout the course of its life cycle. Usually including software, hardware, and training, TCO is a metric that tries to make the true cost of robust systems tangible. More specifically, TCO generally quantifies application-specific hardware and software infrastructure costs required for support, initial implementation costs, ongoing maintenance, and operational costs associated with how the application is deployed. However, focusing only on the hard costs of ownership ignores the significant reduction in TCO that can be obtained by changing operations and business processes. Companies will be able to significantly reduce the cost of ownership of their Oracle E-Business Suite (EBS) by focusing on how the software provides value to the enterprise's operations. Eliminating silos of information, reducing data and process redundancy, and minimizing complexity for management reporting reduces the cost of ownership for the entire enterprise. This article focuses on extending the useful life of an existing EBS environment to accommodate ongoing business changes.

Read more: Tips for Reducing the Total Cost of Ownership of Oracle E-Business Suite

In a previous article, Losing Control: Controls, Risks, Governance, and Stewardship of Enterprise Data, we discussed the ramifications of failing to establish and maintain standards and change control mechanisms around the lifecycles of interrelated data objects. We began by describing a situation in which spreadsheets are used as the foundations of corporate reports and analytics. In such a scenario, the technology being used to store, retrieve, and manipulate the data—Microsoft Excel^®—lacks the ability to validate and enforce data quality. A spreadsheet can’t verify that the formulas behind data extracts and transforms are correct (or that all of the relationships are maintained), and there are no standard procedures for data reconciliation using spreadsheets.

Forget the fact that maintaining 100+ related spreadsheets is a logistical nightmare. It is, but that’s not the real issue. The problem is that spreadsheets aren’t really connected. A formula in one cell that references another cell does not create a relationship between the two cells. This is not nit picking—there is a major difference between a reference and a relationship.

• Reference: A source of information.
• Relationship: A meaningful connection or association between two or more things.

In short, a database relationship goes both ways (and has meaning), making it vastly more important than a cell reference. Put another way, database objects can be connected to other objects without being referenced directly (foreign keys and other database constraints enable this—it is the lifeblood of the relational database as an effective enterprise tool).

A big problem with spreadsheet applications as the major component of most accounting and finance departments is that spreadsheets do not have the capability to enable the establishment of data governance—standards and change control mechanisms—of the sophistication required for running an enterprise. In fact, there is a rift in data quality even before the business user has used Excel to perform a single calculation with the numbers just spit out of the company’s ERP system. Once Excel has the data, with its inability to govern, the data may unsuspectingly change types, formats, or get truncated.

Enough about spreadsheets; Excel is a single tool in a world of technology players. There are new tech products that do embody the capacity of data governance. If you are in a position to evaluate such technology, keep in mind that effective tools must respect the following important caveat:

Once information leaves the database, it no longer embodies the purity and cleanliness that it once did while sitting in the table, with a defined (and standard) data type, minding its own business.

So, how should you keep your data clean? And stepping back, how do new technologies fit in to the enterprise resource planning (ERP) data quality picture?

Perspectives On Data Quality

The role of a data quality process is to make sure that business data – information, mostly digital today, that makes up a picture of a company’s time-sliced existence – is created cleanly and maintains a certain standard of cleanliness throughout its life cycle. But individuals’ viewpoints about the role of data quality technology (what data quality technology wants) are generally split between two opposing perspectives:

• Technology enables a data quality process, but doesn’t obviate the need for people (data stewards) to remain actively involved and be held accountable for maintaining the quality of data.
• Technology automates a data quality process, and a well-designed and properly implemented technical solution obviates the need for people to be actively involved after its implementation. [1]

Regardless of perspective, one must admit that time moves forward, new data is continually introduced to the system, and keeping the data clean requires that both the creation and maintenance of information adhere to defined and monitored processes that someone can be held accountable for.

“There is no point in monitoring data quality if no one within the business feels responsible for it.” – Thomas Ravn [2]

The importance of accountability to the data quality process implies that technology alone (or at least the same piece of technology) cannot both enable and automate data quality. In order to do so, it would need to be able to hold itself accountable for the quality of data that comes out of its own processes. The ability to generate an emotional response to potential consequences is at the heart of accountability—this is a problem for technology.

Master Data Management (MDM) is the technology framework for data governance initiatives. MDM addresses data quality, data architecture, and data security. Where data governance defines and standardizes master data definitions, MDM instantiates them into the business processes and propagates data fixes throughout the enterprise. Technology can help data governance initiatives by defining and communicating data policies, business rules, and data definitions by enabling cleansing, sharing, and consolidation of master data, and by tracking and fixing bad data.

Beyond the technology component of data governance, there is a human element to the data quality initiatives of your organization. A primary goal of a data governance strategy is to align the people, processes, and technologies to common objectives. The data governance structure outlines ownership, stewardship, and accountability by defining who has the authority to create, update, or retrieve enterprise data, and by identifying how the data is verified as being complete, consistent, and correct.

The success of an Oracle^® E-Business Suite (EBS) project depends on the both the alignment of the people, processes, and technology, and an effective data governance strategy to manage the shared data assets of an ERP initiative. Within EBS, strong data governance is required to oversee cross-departmental data in a centralized place, to define master data policies, and to fix data issues. Within an ERP system like EBS, the quality of the data makes the system work (or not). Redundant or inconsistent data adversely affects operations, performance, and reporting—not only within EBS, but in the business intelligence systems and in the integration of outside systems.

Figure 1: Dependencies of ERP Project Success on Technology, People, and Process [3]

Every ERP Project is a Data Quality Project

Which ERP projects should be considered data quality projects? All of them. If data governance takes a back seat on every project that is not focused on duplicate resolution or standardization, then by default you are going to create additional duplicate resolution and standardization projects for cleaning up the bad data introduced in all the others.

Not all ERP projects are initiated for the same reasons. The types of projects listed below differ in scope, but the purpose of each of them is to do something with enterprise data. In the case calling for a consolidation, the data from different and disparate systems are burdened with an extra dimension of metadata, namely which system—or source—it came from. Consolidation projects combine a variety of source systems into a single target system; a good consolidation project ensures that the target system embodies complete, consistent, and correct data throughout—it’s really a data quality project. This isn’t an easy thing to do—what, and where, are the fingerprints of multi-instance data?

Well, they’re in the database tables, of course. The complex webs of intra-instance connections—database DNA, so to speak—are comprised of relationships, not mere references, between the data molecules sitting in the tables. The molecules stay an objective course, minding their own business and behaving as they are told. They are great at following rules but lack the ability to create rules on their own, generating a desperate need for data governance at both the one-off project and long-term enterprise levels. As mentioned previously, people—not tools—will always be responsible for creating and administering data governance policies, procedures, and rules that the data and those who interact with it must obey in order to maintain enterprise information of the highest quality.

But a modern marriage of human intelligence and technology sheds light on the role of automation in enterprise data governance, namely:

The pieces of an organization’s data quality initiative that involve repeatable logic, Boolean truth, and measurable current- and future-state values are prime candidates for automation with capable technology.

From an MDM perspective, eprentise^® software embodies this modern marriage. Using its patented methodology (including a deep-discovery Metadata Analysis process, a Knowledge Base of hundreds of thousands of data manipulation rules garnered from experience across all types of EBS instances, and the ability to automatically generate all of the code required for making changes to data), eprentise software automates the project-level data quality and standardization processes across consolidation projects as well as many other types of ERP projects:

• Consolidation
  • Mergers & Acquisitions
  • Shared Service Center
  • Departmental Instances
• Reorganization
  • Changes to EBS configurations
• Upgrade
  • De-supporting of current install
  • Take advantage of new features (E-Business Suite R12)
• Migration
  • What’s the difference between migration and consolidation?
• ERP Extensions
  • Supply chain planning
  • Vendor relationship management

Within Oracle EBS, eprentise has taken the first step in broadening the scope of MDM to include all of the attributes of enterprise data – metadata, seed data, reference and configuration data, data structures, and even consistency among different E-Business Suite instances – driving toward the concept of a single, global source of truth that is complete, consistent, and correct. eprentise puts the power in the hands of the business, employing its collection of pre-defined business rules to formulate optimized intra- and inter-instance connections—the new DNA—from which it derives the automated mappings and sequences required to effect the desired changes. eprentise is not an extract, translate, and load tool—data changes happen inside EBS, which is exactly what we want in order to keep the data pure and clean (sitting in the table, minding its own business).

Technology such as eprentise software can play a pivotal role in automating large portions of repeatable data quality requirements that adhere to governance policies—delivering them repeatedly for quality maintenance purposes or as an integrated byproduct of other ERP projects like consolidations and reorganizations. While eprentise does have a software product specific to cleansing and standardizing data (see eprentise Data Quality), the same metadata engine, duplicate resolution, and standardization functions are built into all other eprentise products, enabling you to tackle the E-Business Suite projects you’ve budgeted for and increase the focus on complete, consistent, and correct data simultaneously.

Unlike Excel, eprentise does not prohibit data governance—it promotes it. Whether you need a data quality product to use on an ongoing basis to align enterprise data to changing corporate governance policies or you need to make a specific change (such as a functional currency change, a calendar change, or any of the other changes mentioned below), eprentise software is the tool to use if you need quality data—automatically.

eprentise knows quality data. Our software products for Oracle E-Business Suite include:

• Instance Consolidation
• Currency Change
• Reorganization
  • Calendar Change
  • Merge or Split Sets of Books (Ledgers in R12)
  • Merge or Split Business Groups
  • Merge or Split Operating Units
  • Merge, Split, or Move Inventory Orgs
  • Merge, Split, or Move Legal Entities
• Divestiture
• Data Quality
• Data Archive and Subset

For other eprentise articles focusing on E-Business Suite topics, please see our blog.

1. Harris, Jim. What Data Quality Technology Wants, OCDQ Blog. Thursday, January 13, 2011. http://www.ocdqblog.com/home/what-data-quality-technology-wants.html

2. Moseley, Marty. Measuring What Matters, Mastering Data Management. May 20, 2010. http://masteringdatamanagement.com/index.php/2010/05/20/measuring-what-matters/

3. Keifer, Steve. ERP Projects and B2B E-Commerce, Hardlines Technology Forum. April 19, 2010. http://www.slideshare.net/gxsinc/erp-projects-create-b2b-ecommerce-opportunities

As a mission critical system, considerable time and attention should be devoted to maintaining, improving, and optimizing your Oracle E-Business Suite (EBS) system. While most tasks are relatively routine in nature, sometimes—either due to organizational changes, the need to upgrade, or due to changes in management and regulatory reporting requirements—a change is needed in your EBS system that requires the initiation of a more complex project.

Even with the best of intentions, planning, and hard work, complex EBS projects can fail for a variety of reasons. Whether you’re planning for an R12 upgrade or reimplementation, completing a post-M&A consolidation, implementing OBIEE or Hyperion, or simplifying your EBS footprint (or more), reviewing and recognizing common Oracle project management failures and their respective best solutions can ensure that your projects succeed in 2012 and beyond.

Here are eleven specific and common reasons why Oracle projects fail, including advice on how to prevent them in advance.

Read more: 11 Reasons Oracle E-Business Suite Projects Fail (And How to Fix Them)