<img alt="" src="https://secure.tent0mown.com/160156.png" style="display:none;">
scishield-home-hero_corner-top-right scishield-home-hero_hex-patter-left
scishield-home-hero-2023_2_image1 scishield-home-hero-2023_2_image1

3 Corners EHS Software Systems Cut to Reduce Costs

Posted by Matt Segal on Oct 2, 2019 9:51:36 AM

1909-2 Cut Corners - Header

Here’s a secret most software vendors won’t tell you: Building a powerful, user-friendly EHS software system is expensive and challenging.

It’s not as simple as just “writing code.” It takes thousands of hours of work and a team of engineers, developers, UX and UI designers, and subject matter experts (and the good ones are in high demand).

Not only that, but there’s also the cost of keeping the software up and running properly through testing, maintenance, security, implementation, support, and new feature development.

That all adds up quickly.

Keeping an eye out for red flags

Most companies shy away from that recurring cost, preferring large profit margins over providing the best possible, most sustainable solution.

To help you avoid frustrations down the road, we're showing you three of the most common areas where software vendors cut corners.   

1. IT security

‘Cutting corners’ means doing something the easiest, cheapest, or fastest way, as opposed to taking a more difficult but higher-quality or more sustainable path. In the software world, this frequently translates to skimping on security services and best practices.

It makes sense: rock-solid IT infrastructure and support is expensive, and many of the critical aspects of security are things the average person isn’t aware of and will likely never see in practice (or know to look for).

A vendor might not take the time to review every piece of new code for vulnerabilities, for example, or decide not to perform regular penetration testing. Even a minor weakness can be exploited by cybercriminals, exposing your sensitive data to a breach and public event.

Infrastructure support is another area where vendors might take shortcuts. Again, these are usually things you can’t see — at least, not until a disruption or disaster happens (this is why it’s so critical to ask about these topics early on when looking at a new piece of software).

High availability, resilience, and disaster recovery are all crucial components that form the foundation for a good software solution. With backups, for example, best practices include:

  • Standard local backups: data is kept close at hand for quick recovery
  • Off-site backups: data is sent over a network to servers across the country
  • Secure facility backups: data is put on tape and transported to another physical location
  • Cold site: a location used for backup in the event of a disaster at the main datacenter

Without these elements in place, you may not be able to recover data quickly in the event of a disruption or disaster. It generally doesn’t matter too much... right up until the moment when it matters the most. And at that moment, you’ve either got the data somewhere else, or you’re left without a paddle.

Ask yourself, what would happen to your laboratory and safety operations if you woke up one day and discovered that every piece of your safety information had disappeared in a puff of smoke?

2. Building for instant gratification

Keep a wary eye out for any software provider focused on bells and whistles instead of long-term support and usability. 

Overselling is a common practice among software vendors. In fact, a recent NAEM report found that being oversold on a system that doesn’t perform as advertised is one of the biggest reasons for dissatisfaction among EHS software buyers.

Sometimes, a vendor will encourage customization just to make the sale. The problem with this is that customization requires extensive coding and testing to perform as desired. In some cases, these customization issues can even cause issues during the implementation phase.

Note that this is different from configuration, which is personalization that occurs through administrative screens and modules without changing the underlying code. Think about it like this: Configuration — “Can I have my vending machine sell different snacks?” Customization — “Can my vending machine serve ice cream AND on-demand coffee drinks?”

A similar issue to saying “yes” to customization happens when vendors say “yes” to every feature request that comes along. In both scenarios, developers rush to build features, mistakes get made, and the vendor falls behind on critical ongoing activities like support and updates. In many cases, custom development negatively impacts other areas of your system, and you don’t know until it’s too late. You’re left with a system that’s much more expensive for the vendor to properly maintain, and often doesn’t work as promised.

Other times, vendors cut corners on customer success. After all, it’s expensive to have a dedicated implementation and support team — and it’s something many buyers don’t think about until they’ve signed a contract. Unfortunately, many vendors work hard for the sale but don’t commit the proper resources for what comes next.

The result is that you’ve got an expensive, (hopefully) powerful new system, but no realistic way to use it or have it support your needs (you can learn more about why implementations fail — and how to avoid it — here). The most powerful tool in the world won’t help you much if you don’t know how to use it. 

3. Mobile apps

The hidden costs of creating and managing a mobile app are substantial. When resources go to a mobile app, it’s important to ask “is this being done because there’s a true need, or because the provider wants to check a box?”

To understand why, let's back up a step and focus on an important distinction: mobile apps are different from mobile functionality.

Mobile functionality means that you can access a program from a mobile device through your browser, whereas a mobile app is a program that is downloaded and installed on the device itself.

Building a mobile app is extremely labor intensive. It requires a great deal of development time, attention to the user interface, special coding, and so on. It's a lot like rebuilding the entire original software from scratch. Mobile app security also comes with its own set of considerations, from securing the device itself to protecting data at rest and in transit. As much as we love our phones, boy, are there a lot of vulnerabilities present in them when the data is downloaded to the actual device. Multiply that times (potentially) thousands of users at your organization, and you are taking on a high-risk endeavor.

Unfortunately, some vendors know just how appealing the sound of a mobile app can be. So, they sprint to push out a mobile app and rush it to market without giving it the attention it deserves. Or they try to build a low-cost app which doesn’t actually work as advertised. Sometimes, the app works fine, but critical resources that should be spent on improving and maintaining the main software get pulled away and reallocated.

A poorly built app puts your data at risk. This is such a critical point that we can’t stress it enough.

A poorly built app puts your sensitive data at risk of being targeted, stolen, sold, and distributed by malicious actors.

A recent study conducted by Nielsen found that the average smartphone user has 26 apps installed, and most of them come with privacy and security issues. What’s more, many apps store data on your device — so if your phone gets lost or stolen, your sensitive data goes with it.

If someone now knows the route you take when you’re walking your dog, not the biggest deal.

If someone now knows exactly where you store your pyrophoric chemicals, schedule I substances, and radiation sources, slightly bigger deal.

The problem with vulnerable apps is they often act like dominos. Someone could leverage a vulnerable app to gain access to data that is normally secure, like your bank account, credit card information, healthcare records, and email.

Similarly, a weak EHS mobile app can expose your sensitive laboratory data — and not just to outsiders. According to the Information Security Forum, insiders are responsible for 54% of data breaches. These breaches fall into three categories: malicious, negligent, and accidental. While mobile apps are convenient, poorly built apps are a risk.

Your takeaway

While there are many vendors who operate with a high level of integrity, competition is fierce, and some vendors have been known to cut corners to keep costs low and make the sale. Knowing about these common shortcuts ahead of time will help you ask the right questions and find a reputable vendor you can trust.

Be wary of any vendor who promises short timelines on custom development projects and be sure to ask lots of questions.

And remember that as with most things, unfortunately, if it seems too good to be true — it probably is.

Explore More Posts