High patch frequency
Patches are released quarterly or more frequently, which may not allow sufficient time for testing, patch deployment, testing execution, and patch validation prior to implementation in production.
- Defects detected on a company’s patch level may already have been resolved by a future patch release. The vendor cannot fix the issue on a company’s current patch
- Movement to the new patch level requires regression testing to confirm new and existing functionality
- Executing patch testing and implementation requires significant business and IT involvement
- Code freezes can cause organizations to fall even farther behind
The solution’s maturity level is low, and patch releases involve fixes that may affect existing functionality.
- Patch releases may go to market with improvements as well as new defects. In other words, fix one thing but break another
- Business users should conduct and confirm core scenario testing and reporting prior to patch implementation
The scope of testing to confirm both existing and new functionality can be extensive for each patch release.
- Testing and confirmation can raise resource management challenges due to the heavy demands on both business and IT
- Providing coverage for the majority of scenarios and functionality is complex. For companies with customized core RMS solutions, determining the right scope may become even more complicated
Business operation impacts
RMS regression testing requires business involvement to confirm accounting accuracy. Testing should be part of the ongoing business process, and business users must be trained to use new functionality.
- The timing for testing and implementing a patch could affect the timing of financial-close and financial-reporting activities
- Patch implementation should be aligned with patch applications for other IT solutions
- Resources must be allocated to train users on an upgrade’s nuances
- Updating desktop manuals and related process and control documentation is also important prior to upgrade