Carol Francum, SearchOracle.com resident 11i guru and CIO for Ashford Systems Group, shares her 12 critical practices...
for implementing your Oracle Applications. For more information, ask Carol a question in her Ask the Experts area.
1. Establish a project team
When establishing a project team, incorporate management support. Executive sponsorship and membership in the project team can ease the political process, circumvent attempts to delay processes or help change requirements and scope. Team members should include knowledgeable business users from all affected departments, if possible, as well as technical personnel. Consider additional training in the new applications for the business users who will be active on the team. Commit to communication through all levels. Establish mechanisms for encouraging communication and cross-functional cooperation.
2. Infrastructure assessment
Count the number of users, sites and applications to be deployed at each site. When working with multiple sites, each site may have different technical architectures. Document the planned technical infrastructure. Sites not presently using Oracle Applications will need installation plans. While many of the same activities occur in installations and migrations, the installation plan at a new site requires additional preparation, planning, coordination and training. Be aware that data conversion efforts are often under estimated. Data conversion will be discussed later in this document.
Review your technical infrastructure. Oracle 11i requires about 12 GB, and some DBAs recommend a starting size of at least 40 GB. Check Oracle's list of certified platforms. If you plan on using a non-certified platform, you will need to plan additional time for testing at each phase of the migration.
Decide whether a single or multi-node implementation is best at each site. Many implementers prefer a three-node architecture at a minimum:
- The client tier may have multiple client platforms, Macs, PCs, etc. -- even PDAs or cell phones may be client devices.
- The application tier includes the 9i Application Server, and may have an additional node serve as reports server.
- The database tier includes the server(s) on which the database resides.
Use the number of users, applications and sites to develop the capacity plan. The capacity plan develops and documents database sizing, performance and throughput requirements based on these basic assumptions. The capacity plan also identifies how expected growth of the database or the enterprise over time affects the technical underpinnings. For example, a site which manufactures large numbers of components that it sells in large volumes will require different sizing than a company that sells few, but very expensive items. The two companies are likely to have very different numbers of transactions occurring at any given time. Other companies may need to track maintenance records for all of their parts, and all of their items sold for the life of the product. Keeping extended histories adds additional complexity to the database requirements.
3. Database version
Oracle version 11.5.9 (the latest version of the Oracle E-Business Suite available) requires Oracle9i. Upgrading the database is a straightforward task, although it will require review of any existing customizations for compatibility. You may want to establish a standalone 9i database for testing applications customizations as a separate phase, prior to starting the migration. Sometimes custom code uses non-standard techniques that may not work in subsequent versions. You may want to consider Oracle10G in your long-term plans.
4. Development Suite versions
Consider what version of Oracle development tools were used to create any customizations. Upgrading to Internet Development Suite 9i is recommended. Use the standalone 9i database platform to test the forms and reports upgrade before starting the actual migration tasks.
5. Document customizations
Types of customizations include changes to standard application forms and reports, custom PL/SQL procedures or SQL code that supports the business. One example is using the custom.pll to modify forms. Evaluate whether the customization will be needed after the migration. Processes that the customization was built to support may have been incorporated into the new version of the applications. It is possible that the standard functionality of the new version will be sufficient for your purposes. Alternatively, you may consider implementing the standard functionality, and add the customized process in a later phase of the implementation.
6. Evaluate existing processes
This is an excellent opportunity to streamline or standardize your business processes in a given area. Existing processes are evaluated in combination with management's business strategy and vision for the migration or implementation. The company's vision to support online customers or suppliers in certain ways, to make processes more efficient or to centralize operations in a cost-effective manner will affect the implementation. For successful change, be sure to control the expectations of both management and the users.
In one company planning a migration, customer service personnel regularly requested pricing exceptions or waivers for customers. The waiver process was implemented using a manual-intensive process. A series of meetings were held to determine how pricing could be standardized, and to evaluate whether items were priced appropriately. Review of pricing requirements provided input to additional steps for Oracle Advanced Pricing setup, and the migration was accomplished without customization or the need for a waiver process. The users were pleased because the new process did not require additional steps and approvals. Financial analysis subsequently showed that the pricing of goods was more accurate and consistent, profits increased.
Planning involves significant interaction with the actual users of the application. Observing the user, asking questions like, "If you could improve the process, what would you do?" and collecting feedback are extremely important. Resist the urge to jump to conclusions about how a process should be accomplished. The users understand the culture and activities of the business and how changes will be accepted. Cultivate users carefully. Avoid promising technical solutions or customizations. Your primary task at this point is to identify where the new functionality will meet existing needs, and document where the new functionality does not meet the users needs. This is part of the "map and gap" process.
7. Document 'to-be' process flows
The to-be processes provide requirements which will be used to determine any setup changes needed, and to help plan testing and training scenarios for the new system. These are also part of the map-and-gap process. Where a to-be process is not met by new functionality, either work-arounds or customizations may need to be developed. Tools for diagramming process flows can be as simple as any block-diagramming program or may use methods like RUP (rational unified process). The objective is to enhance understanding of the process between users, business analysts and technical implementers. The to-be process flow must be timely.
Implementing prior to agreement between groups may cause significant re-work. Where there is conflict between business areas, it may be necessary to appeal to a committee with oversight responsibility. A recommended practice is to create a project team of cross-functional users and managers empowered to make decisions.
Sometimes, the user may need to be shown how the new functionality operates before being convinced that the standard functionality will suffice. Using a balanced scorecard to evaluate functional solutions may be used to identify optimal solutions. Users respond well to changes when they see that all options have been considered, along with the cost issues.
8. Identify external interfaces
External interfaces include legacy systems that continue to be used, but provide data on an interim or ongoing process. While Oracle provides extensive capability to accept and process data from external sources, the existing interfaces must be thoroughly documented. For each interface, identify the following:
- Data sources and permissions needed to access the data. How often does the data change? Will regular updates be required? Will the owner of the data be responsible for cleansing the initial data, or will the project be responsible? Does the data needed reside in multiple sources, and require coordination between data owners? If data is transacted in high volume or regularly, creating interface tables and writing programs may be cost effective. Oracle9i has new functions for data retrieval from external sources, and enhanced merge functionality that may help the conversion effort. Caution: Be aware that conversion scripts from previous migrations may not work due to data or database table changes.
- Map the data formats from the source to the new format. Identify the new data repository.
- Identify data protocols required. When dealing with EDI or other formats, the requirements may change between versions.
Where custom tables are developed in support of the data interchange, consider potential impact on the capacity plan.
9. Establish and publish an implementation plan
The implementation plan that looks great on paper, and has all the technical contingencies considered, may be changed by seemingly innocuous business events. Review the intended plan with executive sponsorship before publishing. Plan for changes when it is published with the users. When implementing throughout multiple sites, consider the impact of continuous travel on the implementation team.
10. Multiple phases for additional developments
While your implementation plan will include phases for strategy and analysis, requirement definition, development, prototype or pilot installation, testing, delivery and maintenance, you may want to add additional phases for sets of improvements or customizations. This allows you to migrate or upgrade to a standard functionality, and to use standard testing scripts available from Oracle, as well as the opportunity to benchmark processes. At the conclusion of each additional development phase, you may want to re-evaluate progress in comparison to the original benchmarks. Understand that over time, benchmark values will change as the database grows.
The value of testing business processes, data conversions, interfaces and reports should be stressed to the project team, users and managers. When evaluating processes, consider how the uninformed or untrained user is likely to try to use the system. When implementing interfaces, assume that the data input may not be cleansed or in the expected format. When considering where the project timeline can be reduced, do not cut the test phase. The assumption, "Our developers are highly trained and check their code very well. We don't need to test it." is an invitation to disaster.
When planning your migration or implementation, plan to train each user. Using a conference room pilot (CRP) is a common measure for training and testing. As functions are implemented, the users are encouraged to test the system to see that it complies with their needs. This familiarizes them with the new look and feel, and provides an assurance that the application performs as required.
Training plans range from simple to elaborate, and may use a big-bang training approach, a train the trainer approach, online training using Oracle Tutor, or a combination of methods. Training provided too early is ineffective; training dependant on power users passing on knowledge may be less effective as time elapses and those power users are no longer available. One organization created laminated cheat-sheets for involved processes. Another encouraged power users to provide brown-bag sessions at regular intervals. Many organizations find that employing outside consultants to do refresher-training sessions at yearly intervals effective.