By Sphera’s Editorial Team | October 25, 2016

Companies moving from traditional on-premise, perpetually-licensed EHS software to technology services that are cloud-based, subscription service-based offerings has become a macro trend. When it’s time to look for a new software solution, the temptation is great to use the technical buzz phrases that get tossed around frequently. When that happens, the pros and cons of different delivery models for EHS software can get lost in translation, leading to dissatisfaction and unmet needs.

Terminology like “cloud” or “software as a service (SaaS)” may have very different meanings depending on the professionals who are talking about them. Using those terms without having a clear conversation could be misleading because the company, the potential buyer or the stakeholders don’t end up discussing their underlying requirements. The parties inadvertently talk past one another. Mashing together commercial and technical considerations increases the risk that you won’t get key information for making a decision on how best to meet your financial, functional and technical needs.

It’s important to approach the dialogue with a provider in a way that ensures you’re getting the right information to facilitate a smart business decision. Before bringing up a “cloud-based solution” or whether the offering is “single-tenant” or “multi-tenant,” step back and consider your company’s core financial, technical, and commercial relationship needs. Here are tips on how to make sure you and the software provider get on the same page.

Take a closer look at the delivery model. First, let’s define the terms. Single-tenant product architecture is used exclusively by one company while a multi-tenant product architecture is shared by multiple companies. The end user doesn’t really care as much about the architecture itself as they do about whether the service will work from business process feature function and financial points of view.

Many people think that SaaS is synonymous with a multi-tenant, public, and cloud-based delivery of software services. The reality is more nuanced. Let’s say a business is trying to meet a regulatory compliance objective as quickly as possible. Their leadership starts talking about a SaaS-based offering, thinking it will save time by avoiding IT department involvement. Fewer people, no complex procurement process, speedier and easier purchase, right? But in this scenario, the delivery model decision may be based solely on short-term requirements. Consider all aspects of the program you are supporting such as change management, consulting services, and IT integration. Do not overlook the requirements that you’ll have once you meet your initial business objective.

Focusing on a multi-tenant solution may be a distraction during your discussion. If you’re using a software service for environmental compliance, industrial hygiene, and occupational health or an internal quality program, sharing information across companies on a multi-tenant platform will likely have very limited functional value. One company’s CIO articulated to us recently that they required a multi-tenant SaaS offering. The CIO, who had a technical background, inferred that because the application was getting shared, a multi-tenant SaaS offering would best meet their needs and do so at the lowest price. The CIO sought to drive the cost out of their current program while meeting other requirements. They wanted the ability to control changes in their environment, seamlessly integrate with other systems behind their corporate firewall, and minimize disruptions to their current services. When the discussion finally shifted to focus on the real objectives, we were able to explore a broader set of services and commercial terms to meet them.

Software delivery has a spectrum. On the traditional side, software is installed on-premise on company-owned hardware. At the other end, software is installed in the cloud. There are many shades of gradation. Some aspects of what a company is doing in the EHS domain may be best served on-premise — and others by a private cloud-based model. For example, a company might want to do their environmental compliance on-premise because it requires a high degree of integration with the operational systems for data collection and the management of compliance obligations. At the same time, they may want to run their safety program out of the cloud on a single-tenant basis due to data privacy concerns. Recognize that your needs might be best met by a solution that uses a hybrid delivery model.

Determine the ideal degree of control. The way software is delivered isn’t necessarily driven by technical considerations so much as by the degree of control your company wants over the software you’re using to support your program. Essentially that ranges from high control to low control. The ideal degree level will help determine the best delivery method.

If a company needs the software to exactly match the business process they already have, that would be a high-control requirement. The software must conform to a process that has been defined internally. It may not look similar to anything else on the market due to the organizational factors that drove the definition of the business processes. Consider software upgrades, too. When a company invests heavily in training employees to use the software, they want predictable, scheduled changes to the software that enable them to minimize unexpected disruptions to their workforce.

Perhaps your company is more willing to embrace change within the organization. Let’s say you simply want to use the best practice in the industry, regardless of your current business process. A company that turns control of the business process definition over to the software provider is accepting a potentially lower degree of control over their environment. This can help reduce costs, shorten deployment time, and shorten time to value. The success of many programs often comes down to the ability of successfully manage change. Be aware of your corporate culture, the degree of support you have from senior leadership, and the willingness of the company to invest time and money to facilitate change. Change management costs can far exceed the cost of software services alone.

Once the desired degree of control is made clear, then comes the delivery model. Having a high-control requirement is often the reason why companies buy software and deploy it on-premise, but that is not the only delivery mechanism option. The software could be moved to the cloud and delivered via a private cloud. Conversely, if a low degree of control is needed, highly standardized, cloud-based services may be the right fit.

Compare the full costs of commercial models. Look at software financially and ask whether you are trying to minimize the cost of the service or trying to make the cost of the service predictable. Those are two separate objectives with different outcomes. Figure out whether you’re trying to do one or both, and then you can determine which trade-offs you might contemplate.

Commercial terms can easily be addressed independently from the software service delivery. A prevailing assumption is that the only way to get all-inclusive subscription-based software services would be with software that’s publicly delivered via the cloud. That’s a tremendous over-simplification. Just because your environmental management solution is on premise and your hazard communication solution is in the cloud doesn’t mean it can’t all be governed under common commercial terms. It is possible to procure everything on a subscription basis that has a predictable ongoing cost associated with the technology’s use over time, including upgrades and related services.

Rarely can a software provider do every single thing you require. Functional gaps may have to get addressed another way. If you do have to rely on consulting services on top of the software service you’re procuring, that counts toward the total program cost. Driving down software-related costs while driving up consulting-related costs to compensate for gaps might not actually achieve your financial objective for the program. Having a complete program view is vital to understanding the total cost.

It’s critical for an organization to understand what they’re trying to accomplish, what their financial objectives are, what the objectives for their EHS program are, and how they plan to run their program. When members of the organization do talk with providers, they should aim to have a transparent, nuanced conversation around those objectives. Leave the jargon at the door.