Oracle Implementation projects at large organizations typically tend to span over a long period of time and quite often into years. Wide scope of requirements, complexity of design, elaborate testing efforts and smooth cutover planning, all mandate substantial investment of time. This may lead to substantial time getting elapsed between start of the project and the go-live of implementation.
During the implementation, the
project teams start with a given version of oracle code and design the solution based on that version. In large implementations, substantial number customizations are built for the customer specific requirements. During
project implementation duration itself, oracle may come out with new Rollup patches for the modules that are being implemented. As applying the Rollup patches may significantly impact the already built customizations and since they require significant analysis and regression testing, these new Rollup patches are not applied to Oracle instance used during the implementation, unless it is a must to resolve a project specific issue, Thus, more often than not, the oracle version that gets implemented at go live is the same that was started with at the time of design.
Further, after the go live, the projects teams and client business teams are focused on making the production environment stable. The thrust is on making sure that all the built components and solution work as has been expected as per the designed solution. So it takes some more time to make sure the production environment is stable and running smoothly and during this time the new Rollup patches are not taken up for application. Further, successful implementations are very close in being able to provide to the customers almost all the functionalities that they sought from the implementation. With requirements being met, the client organization’s IT and support team’s next goal is to ensure continuity of systems to the business and operations. Due to this, the latest Rollup patches do not get applied to the production environments even further down the line.
Also, since the oracle implementation are large initiatives for the client organizations, they tend to be sticky in the sense that customers tend to harness the implemented oracle system for a good number of years before planning for any major change unless it is required by a new initiative. And, in some situations, the cost of large implementations leads to client management ramping down teams and focus on maintaining the system rather than bring any further changes that may impact the existing system. This tendency further causes delays in taking up the Rollup patches for application.
Thus multiple years would have passed on since the start of the Oracle implementation without the newer Rollup patches being applied to the system. As a result of all this, the oracle version in production would have become woefully out of sync with the latest versions from Oracle. In case of some rapidly evolving oracle modules (e.g. WMS), this gap becomes even more pronounced.
This can be a very drastic situation for production environments that are at the core of running large
scale business operations. What further increases the gravity of the situation is the fact that this criticality may not be borne out to
system managers until the production system runs into a major issue with Oracle standard code. When a major production issue occurs and it needs to be resolved in the oracle code, then to be able to fix the issue Oracle support expects the client systems to be close to the latest system versions vis-à-vis the program files pertaining to the issue. Often times the issue may not be replicable within oracle support instances due to version differences. Then oracle development and support further necessitate that the production system version be the latest. Moreover, it may not be possible for oracle to fix the issue in isolation as changing just few of the files may have impacts that are widespread in the system.
So, it might lead to a situation that there is not an existing oracle patch to resolve the issue and
Oracle is not able to provide a one off customer specific patch. Even if it is possible, Oracle may take some time in building a one off patch and testing it. If the issue is so critical that it is stopping the operations, this time lag may lead to huge losses to business. This can cause a scenario wherein the latest rollup patch needs to be applied urgently. As this would require significant regression testing, it will significantly delay the resolution time of the issue. Also, applying the rollups within a short timeframe may not leave enough time for proper planning and rigorous testing of the patch.
Therefore, it is highly imperative for system managers to ensure that the Oracle versions in production are timely updated with latest rollup patches. The application of rollup patches should be taken up in earnest and due importance should be paid to this activity. This will help in planning properly for the application of these patches and performing rigorous end to end testing of the same. Further, this will ensure that the system is capable of handling any eventuality if it arises. The resolution turn around time for any critical issue will be short and business and operations will be affected to a lesser extent in case of issues.
Also, with the system being on the latest versions, any new initiatives and new solution that need to be brought in to the oracle system can be taken up quickly as and when they come up and implementing these solutions will not require an extra effort of bringing the systems in sync with the latest version. Overall, it makes a lot of business sense to continually asses and evaluate the new Rollup patches provided by oracle for application in the production systems and ensure the sustainability of the system.
Since it is a principles based accounting standard, their may be lack of uniformity in disclosures by companies leading to increased complexity for investor. Investors must adjust themselves to such fluctuations
