Last year, I wrote an article that talked about key issues that IT need to consider when deploying enterprise class business applications. This year for OpenWorld, I decided to follow up the article with a breakout session to discuss the topic. There is a saying that “three minds are better than one”, so I recruited Keith Peters and Deep Ram, who had close to 30 years of combined experience working with application customers, to help put together the presentation. I am going to cover what we discussed at the session starting with this blog entry.

To frame the discussion, we decided to organize our material around application lifecycle phases, and based our discussion loosely around Oracle Unified Method, Oracle's implementation methodology for both application and technology products. Oracle Unified Method, as the name implies, is a unified implementation methodology that combined the best practices of the older Oracle Application Implementation Method as well as the methodologies from many acquired companies. The result is a very comprehensive set off best practices that should lead to implementation and operational successes if the methodology is applied properly.

At the earliest phase of an application project, known as the inception phase, there are two sets of activities that need to be done to set the foundation for achieving success later on in production. The first is to control the scope of customizations. Customization is often seen as a controversial topic, and some application vendors even go as far as telling customers to avoid customizations altogether. In our view, some customizations can be justified. One ways that different organizations compete with each other is through process innovation, and process innovation often require application customizations in order to support the processes.

However, bugs and performance problems may also get introduced into customizations alongside new capabilities. Before packaged applications are released to customers, they usually undergo extensive functional and load tests to ensure the proper functioning, stability, performance and scalability of the products. However, once customizations are introduced into these applications, these test results effectively become invalidated, as the actual application is not the same as the version that the vendor tested. In other words, there are potential costs and risks associated with customizations, so they should be made very selectively.

How to be selective?

We have observed the following practices at some of the best run application implementation projects by our customers.

1. Spend time to really understand the full capabilities of the applications. The whole point of buying a packaged application is to take advantage of the business practices that are baked into the product and leverage the economy of scale of sharing their development costs with other customers. To make intelligent decisions on what to customize, it is important to know what is already in the box.
2. Analyze the current business processes and adjust them as necessary to fit the application. Customizations are usually done to support specific business process activities. If the out-of-box application does not work the exact way that maps to various business tasks, perhaps it would be easier to change the way that people use the application. Furthermore, simply converting existing inefficient business processes to run in an application usually is not the best way to improve effectiveness.
3. Make whoever requested for customizations justify the needs. Evaluate the requests against potential costs and risks for approval and prioritization. This process should both be quantitative and qualitative. For example, justify benefits in terms of task step reduction, or even potential incremental revenue affected. For costs, have rough estimates on implementation and testing times. A scoring system, with clearly defined criteria, could also be very useful.

The most important thing is that these activities need to be carried out by the organization's own staff as much as possible, as it can be problematic to rely solely on the advice of outside consultants. While the best consultants would provide sound advice, there are also some bad apples that would encourage customers to over customize because they stand to profit from it.

By controlling the scope of customizations, not only would you make your application implementation more manageable, but you would also increase the chance that your application will run smoothly in production.