Configuration vs. Customization… What’s the Difference?

If you know anything about Enterprise Systems Renewal (ESR), you know we’re changing business processes and replacing the collection of aging systems we use to run the university.

The changes will be deeper still. They’ll go to the heart of how IT and the rest of the university work together. A key example is the difference between customization and configuration — a distinction with a very big difference.

Here’s Why It Matters

For the past several decades, UC San Diego has been using the customization model, which goes something like this: a business owner thinks about what he or she wants a system to do, then asks IT to build that functionality into the system. A programmer writes a custom program to satisfy the request. This might take days, weeks or months, and the process happens again and again. We’ve used this approach until now because it was the only way to provide new functionality to meet evolving needs.

Let’s face it: these customizations – many of them resulting from your hard work and ingenuity – have kept the systems afloat and kept the university running.

What’s not obvious is that customizations sometimes affect each other. A customization one business owner asked for might require a change to a customization written for someone else, which in turn leads to a change someplace else that causes the program written for the first business owner to fail. What's also not obvious is that these customizations or custom programs require lots of people to maintain and support. Such an approach is costly, time consuming and, in most cases, unsustainable.

So What Is Configuration?

Enter ESR and the configuration model. While we’re in the process of choosing a new financial system, we want something great that will meet our needs right out of the box. As part of the selection process, we’re taking current use cases into account and requiring prospective vendors to prove how they can address those needs.

As the new financial system is set up it will be configured to further meet our specifications. Configuration includes things like data entry screens or workflow setups that align with our campus terminology and operational requirements. Then, properly trained and supported system users in IT may make additional configuration changes with tools, templates, practices and workflows available in the new system.

The benefit to configuration vs. customization is that our new system will be supported and continually updated by the vendor to meet changing compliance requirements and incorporate new features over time. This will keep our system fresh, and the lack of customizations will make it possible to adopt future updates and make it easier to train new employees and current staff.

What About Future Customizations?

Customizations may still be possible, but will be less frequent. If we need to go into the source code to make mission-critical customizations, we’ll absolutely do it. However, customizations will be reserved for truly unique needs that otherwise can’t be met through a configuration or process change. All customization requests will result in higher cost of ownership and must go through a rigorous approval process, including a required funding justification.

Getting You What You Need

Getting you the information you need to do your job is the top priority. Most of that will be accomplished through the solution’s built-in features and specific configuration changes. Odds are what you’ll need will be available through a configuration and customization won’t be necessary.

We recognize this will be a change – both in how you access information through the new system and in how you get help. A big change also represents a big opportunity – to streamline workflows, move into the future and give you more time to do your best work.