The Journey of Moving to a Cloud-Based EHS and ESG System

David Klocek, vice president of services at Sphera, is joined by Nathan Robinson, partner of digital services at ERM, and Priyanka Rajkumar, associate partner for change and transformation at ERM.

The following transcript was edited for style, length and clarity.

David Klocek:

Welcome to the SpheraNOW ESG podcast, a program focused on safety, sustainability and productivity topics. I’m David Klocek, vice president of services at Sphera. I’m joined today by two guests from Europe: Nathan Robinson, partner of digital services at ERM, and Priyanka Rajkumar, associate partner for change and transformation at ERM. Before we get started, would you mind introducing yourselves to our listeners?

Nathan Robinson:

Hi, David. Thanks for the welcome. I’m Nathan Robinson. As you said, I’m a partner in digital services at ERM, the world’s largest sustainability consultancy. I’ve been working in the digital EHS and ESG space for well over 15 years now, helping our clients select solutions, implement them and get them up and running to meet their business objectives.

Priyanka Rajkumar:

Hi, David. It’s great to be here. I’m Priyanka Rajkumar. I’m an associate partner with ERM. I sit within digital advisory in change and transformation. I help clients define their ESG or EHS digital strategy, and then we follow through with system data and people readiness. And I’ve got a background in communications, adult learning and behavioral change. So, I really focus on the people side of change—the people side of assistance implementation.

David Klocek:

Fantastic. Welcome, both! We’ll be discussing the journey of moving to a cloud-based EHS and ESG system, how to build a business case, the key implementation and data considerations and the importance of change management. Having a cloud-based system has become even more important as EHS and ESG data comes under scrutiny from regulators and stakeholders. We’ll touch on the challenges and opportunities through each step of the process.

So, to kick us off here, Nathan, what is unique about this point in time when it comes to firms looking to manage their sustainability, ESG and EHS data? And how did this start and where is the market right now?

Nathan Robinson:

Yeah, that’s a great question, David. If I think back to my entry into this market, the earlier environmental management systems tended to focus on the needs of resource-intensive companies, oil and gas and mining in particular, who needed to track their environmental data primarily to help them with permitting and regulatory compliance. But we then saw there was an increase in carbon accounting systems, particularly when carbon prices were high, and you started to see the onset of some of these carbon trading schemes and carbon caps for organizations. That seemed to be pretty short-lived, though, because unfortunately what happened is the price of carbon decreased and everybody decided it was a lot cheaper just to buy a whole bunch of credits rather than actively manage the carbon that they were emitting.

But what we’ve seen now is the importance of non-financial reporting, which we’ve discussed for years, but now it’s shifted from a nice-to-have to a must-have. So, with regulations like the Corporate Sustainability Reporting Directive (CSRD) and so on, organizations need to have that EHS and ESG data stand up to the same level of scrutiny as their financial or compliance data. So, it needs to be fully traceable and auditable.

We’ve seen this movement for a variety of reasons. There’s a new set of stakeholders who are looking at this information and want to access it, and that includes external stakeholders (public bodies, investment communities and so on), but also you’re seeing internal stakeholders paying a lot more attention to that. So, CFOs are now very much interested in the non-financial aspects of the organization as well as board members and so on.

Also importantly, companies need to stay on top of their regulatory requirements. This is an ever-evolving world. It seems to be every month you look and there’s a new regulation coming out or being talked about, and people need to have systems that can manage that easily and well. Some of this is voluntary. Some of this is committee regulations.

Going back to where we started, what we’re seeing is heavy industry—people who have these solutions going back 10 or 15 years ago—they’re starting now to update and replace some of those legacy systems. Demand has expanded across industries. And what we’re seeing is companies needing to track a variety of this data, both environmental and safety and social information. Ultimately, when it comes to looking at good systems, you’re looking at things that will help you automate your processes and pull your reporting together but in a way that doesn’t dim the lights across your existing team—so, helping support and increase and enhance what’s already going on, but also having data that you can see on a day-to-day and, in some cases, on an hour-to-hour basis so that you can course-correct on the go.

So, if you look at the way a lot of organizations have been managing this, it’s been very much rear-window data management, looking at what has happened and, quite often, only on a quarterly or annual basis. In some cases, you can’t change that. You’ve already kind of exceeded your targets or exceeded your commitments. But by having this data on a regular basis, you can start to see, “Okay, we look like we’re trending a bit higher than we should. Is that okay? Do we need to do something different in our processes or product output to get us back on track?” And ultimately, it’s about reducing risk, making it easier to get insights from your data so you can run the business better and predict what’s going to happen and what the likely trend is going to be.

David Klocek:

Well, that’s great. I mean, that certainly highlights the reasons why systems like this should be put in place and, really, why you want to automate as much as possible through the use of software or other activities like that. There are a handful of different ways of having systems. Some of those are going to be on-premises and some of those are going to be hosted and some are going to be SaaS. So, can you run us through the differences between each one of those offerings?

Nathan Robinson:

Yeah, absolutely. If you go back to the way these systems started years ago, people were all hosting them on premises because, in many cases, that was the only option you had: to install and manage the service yourself. But what we’re seeing now is there’s been a move initially to hosted solutions where the software vendors were providing hosted services either in their own data centers or centers that they were leasing elsewhere. But now there’s a greater move into the cloud.

There are some differences between cloud versus SaaS. With SaaS, or software as a service, you’ve got the advantages of regular updates without needing to run big upgrade projects. So, you’re not worried about the infrastructure, either the hardware or the software. That’s taken care of by the vendor. Typically, SaaS also offers more resiliency. If you’re going to some of the big cloud providers, then there are data centers that offer 99.9999% uptime and all of those good things, which is obviously very important.

Also, there is a difference in the way the solutions are actually implemented or tailored to meet end-user requirements. Rather than these solutions being customized and code being written to adapt the solution to client needs, they’re configured. So, the tools are designed in a way that they can be tailored and tuned to meet the client’s requirements, but it doesn’t impact the way that software works in the background. So, it’s very easy for the client or an implementation partner to make those changes. But those changes, you can be sure, are supported through the upgrades that go on in the background. And depending on what clients are moving from, it can result in a much lower total cost of ownership because, obviously, you don’t have to worry about infrastructure and those kinds of things.

Cloud is slightly different, but for both SaaS and cloud you tend to get better considerations for data residency and security. So, there are options as to where that data can actually sit, which tends to be important for particular kinds of data in particular jurisdictions. You’ve got access to that data in real time—much easier data recovery if there is ever an issue or if you need to do rollbacks and so on. And both SaaS and cloud give you the options to bypass physical and geographical constraints in terms of the data. And again, both of them give you that lower cost around infrastructure and IT needs—you don’t need to worry about having your own IT team supporting the platforms. That’s taken care of for you.

David Klocek:

Excellent. Thank you for that overview, Nathan. So, switching over to Priyanka. We’ve talked about the benefits of these systems, but even if you know the benefits, sometimes it’s hard for an organization to actually ingest those particular changes. So, what are some of the best practices to get those key stakeholders on board?

Priyanka Rajkumar:

So, first things first, I’d say bring change management into the conversation as early as possible, even at the strategy stage. But overall, I’ve got a list of top tips that offer a good start, a strong start.

First off, it’s really important to anchor on purpose and values. And you heard me coming back to purpose quite a lot because there are organizations that do anchor on strategy, and that’s great. But strategy changes over time. Strategy evolves over time, which is why we say anchor on purpose. And the reason we do this is that your purpose, your organizational values, are going to remain consistent over a longer span of time. For example, we want to be a safe organization; we care about the planet; we care about our people. These have a longevity to them.

If we don’t anchor, what happens is there is an implementation and the next change and the next change. And if we haven’t anchored, then that results in change fatigue. And there are so many times where we get called in and say, well, there are so many things going on in the organization, people don’t know where and how, and that’s where we always anchor on purpose.

Then, it’s all about knowing your stakeholders, knowing your audience. We really want to map out—who are they, where do they sit, what are their drivers, what’s changing for them? We want to anticipate in advance how they would respond to the change. We need to ask them for their input so that the change is not done to them, but rather it’s done with them. And we want to meet people where they’re at. Folks are more likely to change, of course, if they feel consulted, if their views are taken into consideration.

The third thing is all about behavior change. So, now that you know your stakeholders, you know your audience, how can we help them towards this behavior change? It all starts with, first off, we build the capability so that they’ve got the new knowledge. They’ve got the new skills. They know what they’re doing on go-live day. They know exactly where to go and what to do. Then, it’s about making the space so that they’ve got the opportunity to put that behavior into practice—all the good things that they’ve learned, we want space for that behavior to actually take place and occur. And finally, it’s about motivating them through this positive feedback loop. We get line managers and supervisors involved, and you’ve got to give them that positive reinforcement that they’re on the right track. And that’s how we cement behaviors.

And then the fourth aspect is about measurement. We cannot reiterate how important measurement is. We set in place your short-, your mid-, your long-term benefits, and we want to measure them. And we want to define things such as your leading indicators (how many people turned up at the training?) and your lagging indicators (what did they do with it?). We want to set baselines, and we also want to make sure that we pivot the program based on what we’re hearing, based on feedback. Do we need to go a few steps back? Do we need to reiterate? Do we need some leadership endorsement? So, we need to constantly have our ear to the ground and pivot.

Also, another thing I’d say is, you know, when we define these short-term and mid-term benefits, and when we achieve them, there are so many change programs that say, “Have faith! We’ll get there in the end.” But when we have short- and mid-term benefits, and we achieve them, your target audience has already experienced those short-term benefits, and that helps drive the adoption. It drives the engagement. So, in short, what I’d say is you anchor on your purpose and values, know your stakeholders and audience, drive behavior change and measure with a vengeance.

David Klocek:

That’s a great proactive approach to organizational change and absorbing it. So, that’s fantastic. As part of that, can you give a brief overview of the journey to make an informed buying decision? I mean, obviously, you have a great plan for making the change once you’ve made that decision, but what does it take to make the decision to move forward?

Priyanka Rajkumar:

Definitely. We often have this conversation with our clients, and the conversation is: Should we be making this, because we know best what our needs are? We know the users; we know how we’re using the data. Should we make this ourselves, or should we buy a system off the shelf? And it’s a really important discussion to have. It’s going to be unique for each organization, depending on where they’re at, because as Nathan has already shared earlier, this market has advanced so rapidly over the past few years, and there are so many options on the table.

However, there are some aspects to bear in mind while you make the decision, especially if you’re tending toward a “make” decision. There’s a lot of legislation coming up, especially in the ESG space. There’s the CSRD, EU Taxonomy, ISSB, SEC and others on both sides, but all of those globally. So, are you as an organization able to keep up with all these legislative changes and be on top of what’s required by them—the data, the KPIs, etc.? It’s all well and good to make a system, but you need to maintain it, and you need to keep it up and running. Do you have the focus, the momentum behind not just the building walls but the maintaining of the system? What happens if there’s a leadership change or team changes and other things? How do we make sure that you’ve captured the knowledge and you can still continue to have the system that you had thought of in the beginning—the objective of the system is met?

So, those are just a few on my end, David.

David Klocek:

Well, excellent, thank you. And I totally agree. You know, most companies, to be honest, they’re in the business of doing whatever their business is, not necessarily making software. And so, a lot of times making sure that people understand it is totally cool to build something, but it’s a whole other level of work to maintain the systems. And that is one area that we do see in most of our customers where they may have tried to build something. It’s just really difficult organizationally for customers who are not IT-based customers to maintain a system because it’s a lot of non-key, non-core work. Once an organization decides—let’s say they do decide to move to a cloud-based system—where should the implementation journey begin?

Priyanka Rajkumar:

We want to start with the end in mind. What do we want to achieve? How do we want to get there? How do we get access to the right information, whether it’s high-quality, transparent data toward reporting or compliance? And then from there, we work our way backward. So, once we know the outcome, it’s all about getting a digital strategy in place—defining your data architecture. What’s the data journey from source systems through your data lake, or you could have multiple data lakes, and then applying your workflow and analytics and reporting it through a system such as Sphera. Nathan?

Nathan Robinson:

I’m building on your point about starting with the end in mind. I think for me it’s very important that a client has got a very clear view on what they want to get out of this system, from reported information—who are the stakeholders who need to see that information, and how do they want to consume it? Do they need reports? Do they need dashboards? Does it need to go into some other platform?

But also, what are the business processes that need to be supported? So, how do you want your users to engage in the system? If you think about, for example, an incident management solution, you’ve got multiple stakeholders that will need to interact with that solution at different points in the journey. So, we think about who those people are and the best way of getting them to get engaged in that, and that can then help inform how we work to configure a solution so it meets each of those different stakeholders’ needs and is easily accessible to them.

I think once you’ve got that core understanding of what the system needs to do, then you can start looking at how. And that includes looking at what data already exists. So, are there other systems that will need to be integrated with this tool, or are there systems that potentially get replaced and retired as a result of the new tool? Quite often what we see is that companies are coming into these projects where they’ve got fragmented or broken system architectures—there’s lots of data existing in lots of different pockets, but none of it is holistic. And this is a really good opportunity to have a course correction and do a reconciliation of that. It doesn’t need to mean starting over, but it’s looking to see how you can leverage and get more value from some of your existing systems by bringing data into the new system. But equally, it’s looking for opportunities to retire and get rid of systems that are maybe a bit long in the tooth or no longer fit for purpose.

And you can look at a way of avoiding double handling of data as well, because quite often what we see is data will exist in multiple places and people have to look at it, and there is no single version of the truth. I think once you get to that understanding of how you want the system to work and who’s going to work on it, then we can start to look at how you build that single source of truth, which is so important—that people know that when they go to the new system, the data they see is accurate, reliable, robust and, very importantly, traceable and auditable. Because, particularly for some of these data points—I’m thinking specifically about the ESG-type data—they need to stand up to third-party verification. So, the more you can build in validation in the tool, then an auditor can go in and actually see, “Okay, you reported a number here,” and they can then work back through the tool to understand what transformations took place and where it came from originally, put a tick against it and say, “Yes, that number is an accurate and verifiable number.”

David Klocek:

That’s a great point. Data integrity [is important], or at least understanding data integrity and the sources and the data that is not only captured in the system but reported from a system (if there are calculations or manipulations that are made) is correct. And I do think that in the past, there were some companies that have definitely been concerned about closed-box or non-visible data. You look at it as—if you don’t build the system yourself, you’re trusting that somebody else has done it appropriately. But beyond that, some sites also don’t necessarily trust the data that gets into the system or what’s done with it, or if their data is actually clean and correct from its original source systems. How can they get around these particular challenges?

Nathan Robinson:

That’s a really important question, so I’ll build on some of the prior points. It’s really important when you implement a tool like this, and particularly if you’re importing legacy or historic data, that you’ve gone through a process of cleansing that data—that you’re not just importing the old garbage. You’re cleaning your house as you go, and then as you’re building the new tools, as new data goes in on a business-as-usual basis, there are validation rules built in there that ensure that people are employing the correct data, or you’ve got automated processes in place to do that.

What we absolutely want to avoid is designing or building a system that then automatically requires people to start building their own new shadow systems. That’s the old way of doing things. We need to make sure that that doesn’t happen, and there shouldn’t be a need for doing that going forward. But importantly, to be able to do that, we need to start to be able to visualize, and for the clients to visualize, that the whole value chain of the data in the organization—as to where it comes from and where it needs to go—can take a while to do, but it’s a super important investment in a project like this. It’s something that shouldn’t be underestimated, but it’s an investment you make early in a project to avoid lots of costly rework or rehashing of data later down the line.

We need to consider all the different types of data that go into this system. Some of it is your operational data, the data that’s generated as a part of your business operations. But also, a lot of these systems need master data, and there’s referential data in there. So, master data includes your organizational hierarchy, which is a really important factor, because how you set that hierarchy up can dictate how you then slice and dice the data going forward. What we see is quite a lot of clients want to be able to slice and dice data in multiple different ways. It might be on a geographic basis; it might be on a business unit basis; it might be on a particular product line basis. So, we need to make sure that that’s considered early and the system’s built and designed in a way to do that. Quite often you see reference data in there. So, emissions factors, libraries and those kinds of things—making sure that they’re built in and considered and can be updated on a regular basis as the system progresses and so on. Simple things like units of measure; we all know that people weigh things, the same thing that they call different things, different units in different geographies. So, we need to have a way of making sure that people in the U.S. can enter things in units of measure that are familiar in the U.S., and people in Europe can use the metric system and so on and have the system actually able to do those conversions and have a standard unit of measure in the background.

And then the final thing is having validation rules in there so that, as data goes into the system, the system is checking and knows, “Okay, for this particular field, I expect to see a number between X and Y.” And if the end user puts in a number out of that balance, it either says, “No, that looks wrong,” or at least challenges it and says, “Okay, you’ve gone over a tolerance there. You need to put a justification in there.” So, you’re still starting to build up that audit trail as to why numbers have been put in there and so on.

David Klocek:

Okay, well, thanks. And so, to this point, we’ve talked about the need for the systems, the different kinds of systems, the change control going in and during the roll-up to an implementation and then even the implementation side of things and making sure that the data is good. So, that’s great. We’ve gone from the point of basically implementing the actual software, but that doesn’t necessarily mean that it’s sticky or used that much. Priyanka, how do they do that? How does a company move from the requirements, basically, to the results—getting the most out of the system?

Priyanka Rajkumar:

Definitely. So, you’re absolutely right, David, because there are situations where a cloud-based EHS or ESG system has been implemented, but it’s not delivering the expected results. Some questions we need to ask ourselves in such situations are:

Are we focused on the solution itself rather than the benefits? Was it all “go, go, go” for the go-live, but then, “Well, what are we doing with the data?” Is it high quality? Does it have integrity, etc.? So, what are we focused on—the system or the benefits?

Have we identified underlying processes that must evolve first? It could be that you need a scalable process, something that’s modular, something that’s going to be more fit for purpose for the future and that needed changing. So, have we identified those underlying processes that should have evolved?

And then the most important: Have we identified the people who must adopt these new ways of working?

So, here’s the thing: Buying and implementing an enterprise cloud-based EHS system, of course, is a strategic investment decision. It’s taken by business leaders. But ultimately, the system itself is going to be used by employees, our colleagues up and down the organization. And we need to bring them along. We need to meet them where they’re at, as we discussed earlier. So, it’s things such as people readiness. Do they have an ESG capability built? Do they know why we’re doing it? What’s the rationale? There’s the training; there’s the communication; there are the campaigns. How do you support their transition with change ambassadors or change champions or sustainability folks who can be at the point of need during the transition? And then—we keep talking about this—but how do you preempt resistance and at least respond to it? So, that’s people readiness.

Then you’ve got things such as your process readiness. I think we’ve discussed the scalable process, etc. It’s also about your data readiness—so, things such as your data integrity, data quality and data ownership. What’s the lifecycle of the data or how are we going to use this? And then, also, it’s about getting the right organizational structure and the governance—how are we measuring this? How do we know that this works in practice? How do we make those difficult decisions?

So, those are just some levers that we would pull in order to move from requirements to results.

David Klocek:

Well, thank you. So, are those any different than what a company should be doing for ensuring long-term success following an implementation?

Priyanka Rajkumar:

Definitely. So, just to go over it, when you go live as well as when you’re into business as usual, we definitely need things such as leadership endorsement. We need leaders to have bought in to this. We need good change communications and campaigns. We need the planning, the preparation and the training. We need to track the benefits, etc. But there are some principles that I’d like to share with you, David. There are ideas, right? We’re creative. Everyone comes up with new ideas. And how do you provide folks out there listening to this with some handrails around—how do we make sure that we’re making the right change in people-focused decisions?

First off, a principle would be: Is this purpose driven? Are you inspiring your people through purpose? Is this empathetic? Are we thinking about the change from the people that are impacted and their perspective? Are we building transparency? Are we building that trust through transparency and communication? Are we participatory? So, are we inviting participation and co-creation along the way? And is it iterative? We learn as we go. This iterative principle is so fundamental because, with change, we think we’ve got to get it right the first time around. But we’ve got to factor in that we want to be empathetic and participatory, and we want to really bring people along, and that’s why it’s got to be iterative as well, where we get our folks involved.

These are just some principles. So, even if you’ve come up with all the most fantastic ideas, you can apply these lenses to them and say, well, does it fulfill these criteria? And then, you’re well on your way.

David Klocek:

Fantastic. Thank you for those highlights and those excellent points. Can you both share some final takeaways or action items that our audience should focus on?

Nathan Robinson:

For me, the important thing is thinking about where you want to be—planning for the destination, looking at what the business processes are that you want people to be supported and guided for with the software, thinking about the data that needs to be in the system for you to be able to get information and insights about the performance and to be able to act on that information and those insights to improve the situation, be it safety, performance improvement, environmental performance improvement and so on.

But it’s also thinking about the longer-term needs. So, quite often you see people coming into a project with a very defined scope, but what else might this system need to do for you in the future that you’re not necessarily ready to implement today, but making sure you’ve at least considered that so that you factor that into any design decisions you make. I would say the other key point to me is making sure that you have documented some of those business processes. Don’t go into a technical design without knowing what it is that you want to get built, because quite often we find that we go into design sessions with clients, and the client assures us that they’ve got internal alignment and everybody is agreed on what the process is. And you get in there, and very quickly it’s quite apparent that there is no internal alignment. You’ve got 20 different views as to how a business process should work, which we can absolutely support clients with, but we need to know that that’s the kind of support the client wants. So, that’s the key thing—making sure you’ve got that internal stakeholder alignment and that you’ve identified all of the internal stakeholders. Sometimes you can get a situation where you’re in a room with people and they make some very good decisions, and then two days later somebody else appears out of the woodwork and throws a landmine in and undoes all of that good work.

I would say the final thing for me is to think about how much you can resource and manage internally and where you need help, either from extra hands and bodies on a project, but also where you can benefit from external support and assistance with best practices and guidance. This might be the first time you as an organization have implemented a tool like that, but there are lots of others in the industry, including people on this podcast, who’ve done this multiple times for lots of different industries. That can be hugely beneficial, that you can learn from their experience and learn from best practices across multiple industries to help implement a solution that not only works for you but also is built on lessons learned from other industries. And you can also be gently challenged during the project as well. You get an external perspective on how things can work and where they can benefit you.

David Klocek:

Well, that’s great. Priyanka?

Priyanka Rajkumar:

So, from my perspective, I’d say it’s got to be purpose-driven. It’s not just about anchoring and combating the change fatigue, but it’s about strategic business decisions that are driven by solid data. And how does that further your purpose? How do you make business decisions based on solid data, and how are they purpose-driven? And it’s just about building that employee engagement, closing that “say, do” gap. We’re a safety organization, but what is our data quality, or are there integrity issues, etc.? So, it’s really important to track it all through being purpose-driven.

And then the second thing would be people first, because, ultimately, it’s humans who are using the system. There are great systems, and they work, but we need to bring people along to really say: How do you make the most of these systems, and what is the art of the possible once you’ve implemented a cloud-based ESG or EHS system? Those would be my two: purpose-driven and people first.

Nathan Robinson:

That people-first thing is so important. For me, these projects are not IT projects. It’s not about a piece of software. It’s about how a piece of software supports people doing their jobs and, ultimately, helping the clients have safer, more sustainable operations. And that’s all about people.

Priyanka Rajkumar:

That’s right.

David Klocek:

Totally agree. You know, a lot of us tend to look at these as being IT-based, like the system will solve everything, but it takes everybody’s input, and it takes our ongoing efforts to make a system truly successful within any organization.

Priyanka and Nathan, thank you very much for joining this particular podcast here for SpheraNOW ESG. I definitely appreciate all your insights and all the time that you’ve given.

Priyanka Rajkumar:

Thank you for having us.

Nathan Robinson:

Yeah, I really appreciate the time today, David. Thank you.