The decision of whether to apply a patch on your ERP system isn’t an easy one. Sure, it’s not as harrowing as a complete ERP upgrade to a whole new Oracle E-Business Suite version – but there’s always the possibility that something will go wrong in your system, either due to a conflict between your customizations and the new code, or some other factor.
Many organizations tend to fall into one of two categories when it comes to applying Oracle EBS patches: Proactive or Reactive.
The Proactive Approach:
Organizations that wish to be on top of the latest patches released by Oracle constantly embrace new functionalities, stay compliant with regulations, or follow the Critical Patch Updates (CPU) distributed every quarter. Such patch implementations are usually initiated as part of the IT maintenance strategy.
Oracle helps these companies stay current by recommending the required patches according to the relevant Oracle EBS Version:
The Reactive Approach:
These organizations take the conservative approach and apply patches only if needed. They will handle issues that occur in the EBS system on a case by case basis, usually initiated upon the business user’s request.
The most cautious companies will even avoid installing patches altogether, and apply data fixes instead.
What Are You Compromising On?
Whether you’re proactive or reactive, your approach probably revolves around some sort of compromise. Every fix or patch introduces a risk. The question is: how do you approach this risk?
The chart below illustrates the compromise most organizations are forced to make.
When it comes to E-Business Suite patches, your compromise is somewhere between high-risk/low-cost or low-risk/high-cost. In the high-risk/low-cost cases, you deploy the patch after conducting only business-critical testing. In the low-risk/high-cost cases, you test everything. That’s a big pain, it carries a high price tag, and can be quite disruptive to your business operations. In truth, most organizations fall somewhere in between these two extremes, hence the compromise.
So you need to patch and you need to test for impact, but how do you find the right balance? Between IT and the business, you need to figure out who needs to test and what exactly they need to test. Will someone be going through all the patches’ readme notes trying to identify what the impact might be, on standard as well as custom functionality? That takes time and inevitably leads to “guesswork”. Can you trust that you are really focusing your testing on the impacted areas? Are your testers (IT and business) testing too much? Too little? Are they testing the right things?
Clearly, there’s a lot of questions and concerns that need solutions! No wonder some organizations would prefer to take a reactive approach and opt to apply patches only if absolutely necessary.
But I don’t think that this is the answer. The best solution is to employ a deterministic approach to reduce your testing workload and risk as much as possible, which can be done with automated impact analysis solutions. Because, in the end, you shouldn’t pass on patches only to save time and money. They are released to fix problems, improve performance, add features and adhere to compliance regulations. Stop compromising and take control.
Find out more about automated impact analysis solutions >> Sign Up for a Free Trial.
Are you proactive or reactive when it comes to patches? How do you deal with the risks involved? Please share your strategies in the comments box below.