Why businesses should prioritize configuration over customization when evaluating EHS software.
Organizations evaluating EHS management software applications are often in search of the ‘ideal’ solution; a powerful, cloud application that does everything they need it to do, in a simple and straightforward manner, and at the lowest price possible. That’s the dream. Unfortunately, many firms find that ideal often hard to come by.
In those cases, where an organization finds a solution that’s close to what they are looking for, they might ask the vendor “what changes can be made to the solution to bring it closer in line to what we need?” That question invariably raises a long-running debate: Should we configure or customize? So, what’s the best approach?
In this blog, we’ll explore:
- The differences between customizing versus configuring software
- The pitfalls that accompany a custom-code EHS software approach
- Why vendors might promote the value of custom-code EHS software
- Why a no-code, configuration-based approach is preferred
What’s the difference between configuration & customization in EHS software?
The terms ‘configuration’ and ‘customization’ are often used interchangeably, they refer to two distinct approaches to reach a desired end goal.
Configuration refers to tailoring, adjusting, or adapting an application’s settings, preferences and/or out-of-the-box functionality to best suit the buyer’s specific needs and use cases. Any software will need to be configured to meet each buyer’s unique requirements. Such requirements might include workflows, dashboards, business rules, views, layouts, etc. Therefore, most software applications are designed to offer a certain degree of front-end configurability, allowing client system administrators to alter their configuration, to reflect changing business needs.
By contrast, Customization refers to the act of altering the existing base code, or writing new code into the software to enable it to meet specific customer demands. Customization allows vendors to meet the specific needs of a customer that their platform’s out-of-the-box capabilities do not address. However, while customization offers businesses the ability to create new functionality for these needs and use cases, this approach is not without its risks.
The Challenges That Accompany a Custom-Code Approach in EHS Software
Obviously, most businesses prefer a product that is customized to their specific needs, preferences, requirements and interests. Who wouldn’t? But, when dealing with software, customizations can create tradeoffs and risks that must be examined thoroughly before heading down that path. Let’s look at a few.
Complexity
Since customization involves changes to the application’s code base, specialty skills and expertise in programming is required. And the lack of expertise required to make those changes is often the first major hurdle faced when organizations look to customize software. As different applications are built on different code bases (e.g., Java, C#, Python, etc.), customers might need access to developers with specific knowledge of the code base in that application. Granted, if the vendor is responsible for writing the code, that issue isn’t as fraught with danger as it would be if the customer is making those changes themselves. But even when a vendor supports customization, their developers need to stay apprised of the specific changes made to the code, which can introduce risk whenever something changes in the application overall.
Time
Customization is much more time-intensive than configuration. Beyond understanding what new functionality is needed, new code must go through extensive quality assurance and regression testing to ensure that it will not only work (e.g., solve the problem for which it was built), but that it will also not break existing code elsewhere in the application. That specialized development can significantly increase software deployment time, slowing down a business’ ability to get their users onto the platform, and limiting the productivity gains sought through digital transformation. By comparison, software that delivers front-end configurability is tailored more easily to the company’s needs, helping to speed up implementation, and creating a faster time to value.
Cost
As customization requires the vendor to pull product development resources from their other roadmap commitments, most customization projects are an additional expense for organizations looking to deploy software to address their business needs. Therefore, avoiding customization by investing in software applications with extensive of out-of-the-box functionality for multiple EHS & Sustainability use cases leaves more money to invest in solutions for other initiatives, or to support more widespread and effective user adoption.
Flexibility
One of the biggest constraints to customization is its impact on flexibility. Custom code locks the organization into that change. Building onto that new functionality requires new code. Undoing prior customizations requires new code. And if you’ve purchased a SaaS application, that custom code will constrain your ability to access new software versions, updates and enhanced features. In those situations, any custom code must be ‘wound down’ to enable the release to occur, after which the code needs to be ‘wound back up’ again and checked to ensure that a) the platform upgrade did not adversely affect the custom code, and b) that the custom code will not compromise any new features released in the latest upgrade. Simply put, such customizations make upgrading much more difficult, time consuming, and expensive.
Sustainability & Support
Vendors of SaaS applications thoroughly test and validate their functionality before release, and actively support those out-of-the-box features and configuration options through continual monitoring, testing, troubleshooting (e.g., bug fixes) and new releases. For organizations that have introduced custom-code, there’s always a risk that the vendor will not support those customizations, especially if the customer created them themselves. If something goes wrong, you might be on your own. Worst yet, if the vendor can help, they might charge you for it, meaning your spending your finite budget to fix custom-code, instead of using it to expand your use of the application.
So, if customization is so fraught with risk, why do some vendors offer it?
In most cases, options to add custom-code to a SaaS application is often a tactic used by vendors to offset their lack of out-of-the-box functionality required to satisfy specific use cases or workflow needs. You might here; “If we don’t have something, don’t worry – we can build it for you!” Be wary of that claim. Adding custom code to your SaaS solution might be pitched as a simple, everyday activity. In reality, however, it could drastically hinder your ability to realize the immediate value for your investment, and may also significantly increase your total cost of software ownership.
In some cases, customization might even be a ploy by the vendor to enable them to finance product development on the back of the customer. For vendors that do not have extensive domain experience, customization projects often give them access to the customer’s functional experts. In that respect, these experts help the developers understand the use cases, needs, workflow and data elements required. And once the custom code is created, it’s possible that the vendor can then take that code and create a new out-of-the-box functionality to sell to other clients. Unbeknownst to them, the customer may have financially backstopped the vendors new product.
Why a No-code, Configuration-based Approach is Best for EHS Software
To avoid the traps of customization, it’s best to partner with a vendor who understands your business, industry, and specific functional domains supported by their software. Vendors who employ a team of experts in your industry and/or field understand the challenges your business faces. Therefore, they are often already working on the solutions you’ll need to address critical business issues and use cases. Furthermore, these vendors usually have more out-of-the-box functionality to service key market needs, and do not rely on custom code to fill the gaps in their offering.
So, if you’re looking for an EHS Management Software solution, what things should you keep in mind?
1. Prioritize multitenancy
Multitenancy refers to a software architecture in which a single instance of software runs on a server and serves multiple tenants (customers). Therefore, when selecting a true SaaS software application, prioritize solutions built on a no-code multitenant architecture. This approach means that all customers are on the same – and most current – version of the platform at all times.
Multitenancy drastically improves the flexibility and speed of software upgrades. Unlike a single-tenant application where each environment must be upgraded individually, multitenant systems are able to “push” software upgrades out to all customers at the same time. This significantly increases speed and lowers the difficult time and cost to upgrade. The visibility in knowing exactly when new features will be available helps to improve decision-making and internal change management.
2. Choose no-code, configuration driven options
Avoid the traps of customization by selecting a no-code, configuration-focused software application. These platforms are built with a data configuration layer sitting atop a standard code base. In these systems, no changes to the base code are allowed. By adopting a no-code, configuration-focused approach, vendors can easily tailor the platform to meet customer business requirements without having to deal with changes to base code, which can introduce risk, impact service availability, break existing functions or create constraints to accessing new features or upgrades. Moreover, when it’s time for upgrades, customers won’t need to worry about ‘winding down’ customizations and ‘winding them back up again’, drastically improving upgrade speed and reducing the risk of data errors that can disrupt operations.
3. Select vendors that are committed to user empowerment
At Cority, our goal is to keep customers on the most current version of our platform, and then to ‘give them the keys to the kingdom;’ empowering them with tools to help them configure their environment as they want. Without a focus on user empowerment, organizations are at risk of being beholden to their vendor’s Professional Services and Support teams to make even the simplest of configuration changes, which can really drive costs up. When considering EHS management software, ensure you’re considering how the vendor is setting you up to be self-reliant. It’s great to know that they’ll be there if you need them, but sustainability means giving you the tools to manage the system on your own.
4. Prioritize applications with an extensive out-of-the-box features
A way to avoid unwittingly financing a vendor’s product development is prioritizing platforms that offer a wide breadth of functionality to support both current needs, and to help address future problems. EHS management software that supports multiple EHS & Sustainability domains in a single application, with a consistent user experience, irrespective of the user entry point, will ensure the most flexibility in your software investment. Therefore, while vendors with extensive teams of internal experts are a first good sign, dig deeper to understand how the vendors connects experts with customers to create a partnership approach to innovation.
Final Thoughts
Selecting the right EHS management software for your business is difficult. And while vendors might position customization to address shortcomings in their offering, it’s important to evaluate the risks associated with custom-code.
No-code configuration is a more flexible, efficient, and cost-effective way to build a solution best suited to your business’ needs. It will help ensure that your software investment continues to pay dividends for your business long into the future.
