“Decustomization” Is a Four-Letter Word

Every college or university has an ERP (SIS, HR, Fin) of some sort or another.  Whether it be a commercial product, one that is consortially developed, completely homegrown, or a combination of components, the ERP is essential to the day-to-day operations of the institution as well as its long-term planning efforts.  For decades, institutions have customized their ERP software in a variety of ways and for a multitude of reasons.  These customizations have always been costly, but now most are proving to be significant barriers to progress in the rapidly evolving world of Software as a Service or SaaS.  “Decustomization” of an institution’s ERP software is essential to moving into a SaaS environment.  However, the way we approach it and the terminology we use to describe the process are just as important as the technical details.

Why Customize Software?

Back in the very early days of ERP systems, functionality was limited, while configurability and flexibility were virtually non-existent.  Subsequently, institutions were forced to customize ERP software to complete even basic functions like registration, budgeting, and employee onboarding.  As institutions became more sophisticated users of ERP software, they optimized their ERP software by developing customizations that helped automate processes, better align the software with business practices, or integrate the ERP with a host of other enterprise applications.

What Constitutes a Customization?

Colleges and universities have customized their ERP software in many ways – large and small.

• Custom Tables – Out of the box, most ERP software does not always have a place to store all the data institutions need to get the greatest benefit from this central information system. Adding custom tables allows institutions to collect data from multiple sources that can enhance the capability of the ERP.
• Scripts and Processes – Over the years, institutions have found clever ways to automate functions performed in their ERP software. This could be anything from cleaning up data for compliance to loading or transmitting data to and from other applications to automatically generating reports and alerts.
• Bolt-on Applications – Frequently, institutions have unique needs that are not met, or not met completely or effectively, by baseline ERP functionality. Colleges and universities have developed custom programs (aka bolt-on apps) to extend the functionality of their ERP software.
• Baseline Code Changes – In rare cases, institutions have modified the baseline code of their software to allow it to function differently than originally designed. This has been more common with consortially developed and homegrown applications rather than commercial products.

Can Customizations Be Maintained in a SaaS Environment?

The short answer is “no.”  For several important reasons, a SaaS environment will not support most of the types of customizations described above.  The beauty of a SaaS environment is that it reduces some significant technical overhead (and often cost) for an institution.  Conceptually, things like upgrades (operating systems, databases, or applications) become simple and painless compared to the typical experience of upgrading an on-premise ERP system.  Additionally, elasticity and scalability allow institutions to respond to growth and seasonal business cycles in a way that is extremely difficult in an on-premise environment.  However, these benefits come at a cost – standardization.  While most modern ERP systems have extraordinary levels of configurability, modifications must be made within that configuration framework.  Traditional customizations are not allowed.

Transformation is Both Technical and Cultural

As colleges and universities have set out on the journey to modernize their ERP software, an inevitable first step is a discussion of how they will “decustomize” their software.  In that discussion, an already daunting project finds the level of resistance from key stakeholders amplified dramatically.  Why is that?  Believe it or not, the biggest reason may simply be the term “decustomization.”  This term may mean to some stakeholders that they are losing something that is critically important to their function or even to them personally.  Perhaps a better term to use is “customization transformation.”  This term sends the message to stakeholders that they will still have all the things they have come to rely on, but they may be different.  Explaining how they may be different is an important follow-up step.

How Are Customizations Transformed?

• Take Advantage of Configurability – As modern products have become substantially configurable, that flexibility may eliminate the need for some customizations, particularly those involving terminology, process automation, and data types.
• Revert to Baseline Functionality – Over the decades, commercial ERP software capabilities have increased dramatically. Customizations developed to address capabilities missing from the original version of the software may easily be replaced with delivered functionality.  Reverting to baseline will most certainly reduce overhead cost, improve security, enhance performance, and assure data integrity.
• Reexamine and Reengineer Business Processes – “The way we have always done it” is frequently the justification for a customization. But does any stakeholder remember why things are done the way they have always been?  Probably not.  More importantly, is the way things have always been done the best way to serve the students of today?  Perhaps not.  Reexamining and reengineering antiquated business processes may provide the opportunity to take advantage of configurability and new baseline functionality while also improving service to students, faculty, and staff.
• Redevelop Bolt-on Applications in a SaaS Compliant Manner – Sometimes you really need to do something your ERP software simply will not do. In these rare cases, it may make sense to completely redevelop a bolt-on application in a manner that is compliant with the technical standards of a SaaS platform.  This is likely not a trivial undertaking, but in the long run it is probably more secure and less costly.

Be Sensitive to the Needs (real or perceived) of Stakeholders

However you choose to address your customizations in a ERP modernization or migration project, be aware that term “decustomization” will be a trigger for many stakeholders.  In other words, do not ever use that term!  Select a term like “customization transformation” or a term of your own invention that expresses improvement without loss, focusing on positive results.