Customizations made during implementation are not impacted by core application upgrades

Description

Incorporating customizations in Corporate Performance Management (CPM) software is often a necessary step during implementation to fit the unique needs of an organization. However, these customizations can potentially be affected, or worse, deleted during core application upgrades. This requirement mandates that customizations made during implementation are not impacted by these upgrades.

Example Use Case

Scenario: A mid-sized manufacturing company implemented a CPM system. They were very aggressive with their customizations, such as additional reporting modules, altered workflows, and tailored functionalities, and custom code.

Solution: The vendor is able to isolate customizations made during the setup process from their core product thanks to their product architecture. This enables upgrades to be incorporated quickly, and in many cases improves upon or makes obsolete complex customizations.

Considerations

This requirement applies not only to customizations, but also to custom packages that are deployed during implementation. For example, some vendors offer industry-focused implementation starting points for customers. These are loaded or pre-configured when your instance is activated. If those industry models are upgraded in the future, do you get those upgrades? Not always. Sometimes they are considered a customization and are not truly a product, despite what the licensing may say.

Customization capabilities vary by vendor. Some offer simple drag and drop, low code setups that can be done rapidly. Those are highly upgradeable. On the top of the market, we see products that allow code to be written against the application and custom database calls. Those are longer implementations and can be more difficult to upgrade.

As a general rule of thumb, the longer the implementation takes, the less reliable the upgrade process will be.

Questions to Ask a Vendor

• Persistence of Customizations: Will some customizations always last after an upgrade, while other types might be affected? Describe those situations.
• Risk Assessment and Mitigation: What risk assessment do you perform to assess the potential impact of an upgrade on the customizations? Do your customers participate in this?
• Post-Upgrade Testing: What are our responsibilities for testing after an upgrade? What specifically should we test?