eprentise manipulates the data in the entire E-Business Suite while maintaining consistent and correct data. For many solutions, it runs one time, changes your data, and then is removed from the E-Business Suite instance. It gives you the ability to make changes to your E-Business Suite that used to be available only through a reimplementation. All changes are propagated throughout your existing E-Business Suite data.

Consider eprentise in situations like these: 

• A merger or acquisition where both parties run E-Business Suite.
• The set-up of E-Business Suite is more than 3-5 years old and doesn’t support the business.
• There are inconsistencies in different parts of the organization.
• The business is supporting several different instances of E-Business Suite.
• Business reorganization, shared service center, and IT consolidation scenarios.
• The database is very large and different subsets of data are needed for testing.
• There is a lot of duplicate data (suppliers, customers, products).
• Divestiture or spin off of part of the business.

This M&A scenario is an example. 

• Company A sells its Division M to a competitor, Company B. Both companies, A and B, run E-Business Suite. Company A runs eprentise Divestiture to split off a copy that contains all of Division M’s business (but none of A’s confidential information). Company A continues to run its main instance, which retains Division M history. It gives the new Division M instance to Company B.
• Company B may choose to run Division M in a stand alone manner until the end of their fiscal year. The instance is functionally complete, consistent, and correct. One optional change would be to run our FlexField software to transform the Division M instance to use the Company B Chart Of Accounts (COA). That would make it easier to consolidate the financial reports between Company B’s main instance and Division M.
• Next, Company B would run eprentise Consolidate to combine the Division M instance into its main instance. They would add all of Division M’s history and open business transactions, setups that define how Division M transactions work, plus other data like Division M’s customers, suppliers, and employees into Company B’s E-Business Suite instance.

FlexField runs one time, changes your data, and then is removed from the E-Business Suite instance. FlexField transforms an existing accounting flexfield’s segment structure, values, code combinations, and CCIDs according to your mappings, and applies the new code combinations and CCIDs. It propagates the change throughout your existing E-Business Suite data, everywhere the accounting flexfield is used. It removes the old code combinations and CCIDs, and aligns the new Chart of Accounts (COA) so that all balances belonging to a single CCID are summarized into a single line.

Your E-Business Suite looks like the new COA has been in use since you first implemented Oracle. The database is functionally and technically consistent and correct.

eprentise software is a family of functional modules used to manipulate the data in Oracle E Business Suite (EBS). It is related to FlexField, another of our products.

With eprentise software you can reorganize, split, divide, or consolidate OEBS instances, and clean up the data within an instance or across multiple instances. 

• Reorganize the business structure within an instance. You can:
  • Move transactions from one set of books, operating unit, or legal entity to another.
  • Move, legal entities between SOBs.
  • Change accounting calendars.
• Divide an Oracle application instance into two or more consistent and correct instances.
• Consolidate two or more application instances to take advantage of a single shared source of business data.
• Consolidate inventories within an instance. You can also change the valuation of inventories.
• Propagate data quality standards throughout one or more instances, including elimination of duplicate master data records.
• Change key flexfield (KFF) segments and values, such as Sales Territories or Asset Categories, and reflect the change in the existing transactional data.

Available options appear in a drop down menu. The eprentise team will work with you after you have determined the desired result to make sure that you understand all decisions.

An eprentise project is like most E-Business Suite projects these days, in that we expect the combined customer and eprentise team to be working from multiple locations across the Internet using web sessions. During key parts of the project, a small number of eprentise team members may work at the customer’s facilities. The eprentise team will provide product usage guidance and product support from offices in Orlando, FL, Atlanta, GA, Ann Arbor, MI, and Bangalore, India.

Your destination (target) E-Business Suite instance looks and functions according to how you have defined the new target. The process is that you will define what result you want to achieve, and eprentise generates the code to achieve the result. All desired history from the source has also been transformed in line with the target that you have defined. The changed E-Business Suite looks like it was set up according to your target definition since the original implementation. In the case of a consolidation, it looks as though you had always operated within a single environment. You may optionally decide to retain a copy of the source environment until your reconciliation and audits are completed. The database is functionally and technically consistent and correct.

As in the question about duration, we need to create a project profile before we know what module licenses and rule templates are called for and thus the direct eprentise costs. With the profile we also work with you to help determine other project-related costs in terms of customer resources or other necessary expenditures. It usually takes a few weeks of discussions and discovery for us to present a proposal.

An eprentise project involves: 

• Managing the project.
• Defining requirements.
• Making business decisions to define the target environment.
• Obtaining consensus for changes.
• Revision and adjustment of reports and interfaces to the organization’s other systems (custom, legacy, third party software, or external) to support the changes made within the E-Business Suite.
• Running eprentise software.
• Testing to make sure that the results meet the requirements.
• Planning for cutover to production.
• Cutover to production. 

Within any project, executing and analyzing Metadata Analysis usually takes between two to three weeks. For some projects, you may need to execute Metadata Analysis multiple times to account for the changes to the database that will occur by executing some of the rules. Most rules can be executed in days.

We suggest that our customers plan from one to six months for most projects, depending on the complexity. Consolidations are usually complex and will usually take between six months and a year. We welcome the chance to talk with you about the type of project you are contemplating. After a few discussions we will create a project profile which will include the estimates of the schedule, costs, and required resources. There is more to the project than simply running the eprentise software.

Consider the following observations about what is not complete, consistent, or correct. 

• If there are multiple E-Business Suite database instances, no instance provides the complete business data. There are often inconsistencies among instances. The inconsistencies lead business users to conclude the data is incorrect and can’t be trusted. They often have external spreadsheets to fix the data and reconcile the differences among the instances.
• When there are multiple EBS instances, you usually find data is passed between them via interfaces, to synchronize data and couple business processes together.
• Some approaches to consolidating multiple instances leave out the transaction history, so the business users are left with “sunset” instances that contain all the history up to the point of consolidation. They may need to access these sunset instances to look up prior events and transactions. Thus the single consolidated instance is not complete.
• Even when there is only a single instance, there may be different charts of accounts, or different business rules employed by different parts of the organization. If the business users employ external reconciling spreadsheets because of these differences, the instance is not complete, consistent, or correct. 

This is what complete, consistent, and correct does mean. 

• Complete – All business data, including all history, is in one place, the database of record. There are no sunset instances. There are no spreadsheets for reconciliation or corrections. There are no interfaces or data flows between EBS instances.
• Consistent – Since the data is in one place, if it is used multiple times in the instance, it means the same thing everywhere. There is no “translation” to go from one instance to another or from one organization to another. If you are creating a report, consolidating financials, or developing a data warehouse query, you are comparing apples to apples. Standards are in place for abbreviations, naming conventions, and business processes such as payment terms, credit limits, and account numbers.
• Correct – Users rely on the accuracy of the information. There are clear data governance structures in place, as well as standards and processes to create, retrieve, update, and delete data. It is possible to audit the data and prove it is correct according to all the business rules.

The key to eprentise is the Metadata Analysis process. Metadata Analysis discovers and documents the internals and architecture of your E-Business Suite environment. The discovery process includes looking at all the relationships in the database, applying recognition patterns to classify the data into different categories, and then matching what it finds with the data built into eprentise’s knowledge base about the E-Business Suite. After Metadata Analysis “learns” about your environment, it creates rules that direct eprentise software in the methods and sequences for making changes to the database. eprentise then verifies that the rules it created are valid. It does that by checking each rule against every row of data. Once a rule is verified as not compromising the data integrity, it is added to eprentise’s rule repository. Business users identify the changes they would like to make to the E-Business Suite by defining a “target”. The structure of the target determines the code that eprentise generates to execute the rule.

In most situations we suggest that customers change their COA in 11i and go into production prior to the upgrade. Alternatively, the COA change can be the first step in the upgrade project, or the last.

We will evaluate with you the comparative level of effort and elapsed time to use eprentise for a consolidation, split, or reorganization compared to your R12 upgrade. In most situations, we suggest these paths: 

• Consolidate 11i instances, then upgrade the single consolidated instance.
• Upgrade to R12, then split the instance into two R12 instances. However in some situations an M&A transaction may force a timetable where the split must be done first, and then later the two parties each have to upgrade.
• When eprentise will be used to reorganize and transform the data in a single instance, the sequence depends on whether the reorganization or the upgrade provides the most value to the business. Most eprentise reorganizations will be smaller in scope than an upgrade, easier to test, and quicker to get into production.
  • If one provides significantly more value, then do that first, put it into production, and do the other later. If there’s a new functional module in R12 that you need, that might be an argument to upgrade before reorganization. In most cases a reorganization will be much less effort and take less time than an R12 upgrade.
  • If you have the resources and the timing works, it’s feasible to do both in a single production release. During development you still do one after the other in sequence, but perhaps you can have just one testing cycle.

We look at the expected work effort and elapsed time to complete the two alternatives. The first option has one consolidation and one upgrade project. The second option has two upgrade projects and then a consolidation project, so it is likely to require more work. Using eprentise to consolidate 11i instances or R12 instances is about the same level of effort. It would also take longer if the two upgrades are done one after another instead of in parallel.

There are other considerations. 

• Upgrading to R12 is largely related to keeping up technically with Oracle's releases. The business reasons for an upgrade are usually related to needing the new accounting methods and new module functionality not present in 11i. R12 introduces Ledgers, Ledger Sets, and Subledger Accounting Methods. Setting up and staffing shared service centers is easier.
• Most companies delay the upgrade, since it's a lot of work without a lot of business benefit, and they want to wait until R12 is stable. Also, many of the advantages of R12 are meaningful only if you have a single instance.
• Users test the consolidation transformation on a familiar release. By using eprentise before upgrading, you are able to isolate the impact of consolidation changes without introducing the complexity of a new release, new functionality in new modules or new features in existing modules, and different business processes.
• Consolidating to a single instance has business benefits regardless of the release you're on. We believe (a) a company can estimate the business benefits with a small amount of financial analysis, and (b) the benefits will be significantly more than the combined technical and business benefit of an R12 upgrade on multiple instances.
• In summary, even though R12 is more stable than a year ago, we still suggest consolidate then upgrade as the sequence of choice.

eprentise and FlexField have no impact on normal E-Business Suite operations, patches, or upgrades.

A DBA installs eprentise software and supervises the technical operations. The primary eprentise user is a senior business system analyst who runs the software.

A DBA with system privileges makes a clone of the database and installs eprentise software. No special skills or new techniques are needed. The install can be completed in about a half day. The DBA may also create eprentise users and projects so that the correct privileges are assigned. A DBA may also be required to monitor performance, and adjust tablespaces or rollback segments as the data is manipulated. After running Metadata Analysis and analyzing the results, it usually takes a few days from start to finish for each transformation run.

Since the customer runs the E-Business Suite in production, they understand what needs to be changed and they have the skill to design the target. We usually review and comment informally on the customer’s design during their planning and decision making. The eprentise role is to guide the customer on how to use eprentise software operations (which operations, which sequence, etc.) to complete the transformation.

All projects will include custom training according to the customer and project requirements. The customer team, which may include third party consultants, is expected to have adequate knowledge and skills related to E-Business Suite. The training is about how to run the individual eprentise operations such as: create project, administer project, analyze metadata, analyze configuration, use rule templates, create rule, and execute rule. The eprentise team is available to help your team run your eprentise project and to help you go into production. Product usage training and transformation support is included in your eprentise license support fee.

The eprentise software contains its own framework for project administration and use of eprentise. It connects to and works with multiple E-Business Suite instances through a web browser. As with many E-Business Suite projects, you will set up clone instances of your production environment and these will be the test environments. You may also set up a target environment and temporary work areas. We will work with you during project planning on the specifics.

Yes. eprentise follows the BR100 Oracle Validated Configuration guidelines, a part of the Oracle Application Implementation Method (AIM) for E-Business Suite, for comparison reports. Central to most of the methodologies is a comparison of the current “as is” situation and the desired “to be” or target environment. After defining the target environment, eprentise software is what you use to change the E-Business Suite data from the “as is” state to the “to be” state. A project manager will have no difficulty integrating eprentise software into a standard methodology.

The eprentise solution is software. However, the eprentise team will be needed to help the customer use the software, at least during the initial runs. The eprentise team’s role is product usage guidance and product technical support, based on over 20 years’ experience with the E-Business Suite and having developed eprentise software. eprentise software includes the fundamental functions of metadata discovery, comparison, and analysis, plus data copy, filter, change, and merge. The eprentise team understands how to interpret the metadata analysis and instance comparison reports, and then, based on the analysis results, plans which of the software operations the customer needs to execute.

Business and technical people who have seen brief eprentise demonstrations have told us the user interface is clear, uncluttered, and easily understood. You will not need specialist IT resources or consultants to run the software or to write extensions.

The eprentise team works with your team to determine the best approach to get the desired results.

eprentise software products are mature with zero errors in production.  We will be glad to provide references if you are interested in a particular product.

FlexField is now the industry standard for changing charts of accounts, having been used in hundreds of successful runs.

You cannot use eprentise to consolidate an 11i and an R12 instance. In this situation, we suggest you upgrade the 11i instance to R12, without full testing and production cutover, and then consolidate the two R12 instances. We will work with you to see if there are reasonable upgrade shortcuts.

The eprentise architecture is built on a multi-tiered, distributed computing model. The architecture comprises: 

• A client tier that supplies the user interface
• An application tier responsible for servicing requests and providing responses to the client tier
• A database tier, which hosts and manages the eprentise schema

 

Client tier

The client interface is provided as HTML pages which can be accessed via a URL on a standard web browser. Users log into the application through a Login link provided on the eprentise Index page. You can use a standard web browser (e.g., Internet Explorer 6.0+ or Mozilla Firefox 2.0+) on any type of networked work station.

Application tier

The application tier provides for client side validation and manages the communication between the client tier and the database tier. The Application tier also hosts the eprentise reports engine. The current version of the eprentise software is supported on any Linux or UNIX platform that is also capable of supporting Oracle database versions 9i and above. Apache Tomcat server provides the technology component services and acts as the web server, processing the client requests by way of Web Listener and Java Servlet Engine (JSP).

Database tier

The eprentise database schema houses the eprentise knowledge repository and the core rules engine. The eprentise schema is created with its own dedicated data, index, temporary table space, and all the database objects required to operate when you install the software.

Both application and database tiers may reside on the same physical server that hosts your Oracle E-Business Suite test or production instances. It must at least reside on a server that has a DBlink connection to these instances.

 

Yes. eprentise and FlexField can be used for these E-Business Suite releases: 10.7, 11.x, 11i, and R12 (all current versions).

eprentise runs on the same platforms as the Oracle E-Business Suite. eprentise is browser-based. You will run the install script on the same server as the E-Business Suite, and then use any browser to access the software.

Your project management and users will develop a test plan to look at the “As is” state, the changes made, and the E-Business Suite instance after using eprentise. Our customers go through the usual change management testing processes, usually an abbreviated version. The testing will focus on account balances, individual transaction records, representative business flows, workflows, reports, interfaces, and customizations.

When your change management people become familiar with how eprentise works and what the business users will “ask” it to do, then they should be able to determine how to set up change requests and approvals, and monitor or verify completed changes. All changes made by eprentise are thoroughly documented. If eprentise creates a journal entry, the new journal entry includes the original journal and a description of why the journal was created. The metadata analysis and configuration analysis provide an accurate “before” picture of the environment. They create reports all the way through the transformation process that show which data was selected for change and what changes were made.

eprentise software works within the E-Business Suite and the standard, out-of-the-box functionality. There is an optional customization metadata analysis to document database objects that are not part of the E-Business Suite. eprentise does not change any source code, packages, or SQL code in an E-Business Suite environment. That means that any interfaces to third party systems, enhancements, non-standard reports, and bolt-on software are outside the scope of what eprentise will address in your transformation project. You will need to determine if these are impacted by the eprentise transformation of the EBS, and adjust or fit them to the new EBS environment.

The business users need to make decisions about what the target environment looks like, criteria about what makes a duplicate, which standards eprentise should enforce, and any “rules” like revenue recognition rules, allocation formulas, security rules, or workflows.

Once the eprentise software knows what the target is, then it generates the code to change the source to the target. It does not know the business or best practices for an industry.

The customer needs to know how to set up and implement E-Business Suite to get the desired result. That includes knowledge of how organization units or sets of books work, what is a roll-up group, how to define a flexfield, how to allocate costs, how to move an asset to a new category, or how to drill down to sub ledger detail.

The testing process is similar to the testing that you would do for any other change to your E-Business Suite. In most cases, you start with a development or configuration phase, possibly with a data conversion phase, followed by the actual E-Business Suite testing. The EBS testing is known as the System Integration Test, Conference Room Pilot, or User Acceptance Test. With eprentise you first configure then run the transformation, which is like a data conversion. You will test the results of the transformation. Then you run tests in EBS against the transformed EBS database. Since eprentise is rules-based software, you quickly can change the transformation if you don’t like the results.

The following diagram is an overview of testing an eprentise transformation and the subsequent E-Business Suite testing.

(click image for a larger view)

This is an overview of the process steps. 

1. Freeze and save the initial state E-Business Suite test instance.
2. Create a baseline set of E-Business Suite trial balance and other reports you will use later to verify the results of the transformation. Usually we recommend the trial balance reports from each module, and then other reports that you would use when you close a period. Depending on what you want to change, you might generate some other more detailed listing reports within each module.
3. Run eprentise Metadata Analysis.
4. Create a test clone of the initial state test instance.
5. Run eprentise and use the different eprentise rule templates to define the transformation.
6. Run eprentise and execute the transformation rules against the test clone.
7. Run the same set of EBS trial balance and other reports against the transformed EBS database. Metadata Analysis also provides comparison reports on the initial state test instance and the transformed E-Business Suite environment.
8. Compare and reconcile the initial state baseline reports and the transformation reports.
9. This completes the transformation testing phase, and you will either cycle through adjustments to the transformation and retesting, or initiate the EBS functionality testing.
10. Start a Conference Room Pilot to give the users an opportunity to complete process cycles (order-to cash, procure-to-pay, etc.) with the changed data. If the results are not what you expect, then you will create a new rule and start the testing process again.
11. After the eprentise Transformation and EBS CRP testing are complete, test the interfaces and third-party systems with the changed database as part of your integration testing process.
12. Finally, when everything has been updated, then the users will conduct the UAT with the fully integrated changed data.

There is no official Oracle policy about eprentise software. A high level executive in applications development at Oracle is aware that customers in the real world do carry out data mapping and migration projects and have a need for software to assist them. Oracle Sales has an internal knowledge repository and they have listed eprentise as a recommended solution for these situations. One prospective eprentise customer told us that while discussing his need to change the COA at a customer briefing at Oracle headquarters in Redwood Shores, an Oracle representative told him about eprentise.

No. We requested certification but Oracle declined, primarily because our software is not integration software and does not run once the transformation is complete. There is no organization within Oracle that has a mission to see whether a Partner ISV data conversion, migration, and mapping product leaves the database correct and consistent. eprentise is not software that runs on an ongoing basis within or in conjunction with the E-Business Suite, so there is nothing to certify.

We know of one situation that occurred in a test environment. When a FlexField customer created their new COA, they numbered the segments as 10,20,30, and so on, instead of 1,2,3…. Some E-Business Suite reports were not working properly. The customer created a new accounting flexfield numbered as 10, 20, and 30 the same way, recreated the problem, and Oracle pointed them toward a Metalink entry that said that the segment numbers could not have any gaps and that a 10,20,30 numbering schema would not work for many reports. When the customer renumbered their segments as 1,2,3…, everything worked properly. Again, the problem was in a test environment, and it was not created by FlexField.

There have been other instances where errors occurred because a user did not properly apply a patch, because set up wasn't completed, or due to the existence of bugs in E-Business Suite.  These are all errors that can and should be avoided, and and they are almost always discovered and resolved during one of multiple test runs.

None of our customers has ever reported a problem that was created by eprentise. Most of the problems that our customers encounter are only noticed within the eprentise project because of the discoveries during Metadata Analysis or because of their extensive testing after executing eprentise transformations.

Oracle will continue to support all standard E-Business modules, even after changing the data using eprentise or FlexField software. Our software does not violate the Oracle Support Agreement. Oracle does not support any third party software. If there is a problem that is caused by our software, we will support it at any time, and we will help you work with Oracle Support if you have a problem that is not related to our software.

If you think that the problem is related to a change made by eprentise or FlexField software, please contact us. We will help you isolate and define the problem, and work with you on your Oracle service request. When you contact Oracle, they may require you to recreate the problem and you may need to do that in an environment or with data that has not been transformed by eprentise. This is the normal problem solving process with any ISV software component or CEMLI (customization, extension, modification, localization, integration). Note though that while CEMLIs are active software, eprentise is a one-time transformation program and there is no active software or processing logic added to your E-Business Suite instance.

Yes, it is recommended that you do not modify the data using SQL or SQL*PLUS because you risk destroying the integrity of your data. This is a recommendation only, and doesn’t affect any support agreements. The reason for this recommendation, as stated in the Oracle documentation, is that:

Oracle Applications tables are interrelated, any change you make using an Oracle Applications form can update many tables at once. But when you modify Oracle Applications data using anything other than Oracle Applications, you may change a row in one table without making corresponding changes in related tables. If your tables get out of synchronization with each other, you risk retrieving erroneous information and you risk unpredictable results throughout Oracle Applications.

The eprentise development team thoroughly understands the relationships in E-Business Suite and has designed and implemented a variety of checks to make sure that the eprentise software does not compromise the integrity of the database as it transforms the data. We designed eprentise and FlexField software specifically so companies could make changes to their E-Business Suite that were previously not possible without a reimplementation.

The E-Business Suite doesn’t have any setup forms or programs to change the underlying configuration of a number of key elements once E-Business Suite has been implemented and put into production. eprentise software provides additional capabilities not in Oracle’s product. There are many independent software products that extend or augment what the E-Business Suite does. Customer IT departments and independent consulting firms also enhance the Oracle-provided functionality. Oracle does provide guidelines for doing so, and eprentise follows the guidelines.