If you spend enough time inside an oil and gas operation, you'll eventually encounter a spreadsheet or locally built app that has become essential to someone's job.
Often, you'll see a maintenance team use a spreadsheet to combine information from two enterprise systems or an engineer maintain a local dashboard because the enterprise application doesn't present the information in a useful way.
Understandably, these tools tend to attract scrutiny. They may sit outside normal IT governance or break when an underlying system changes. But before trying to eliminate a locally built tool, it’s critical for leaders to understand why someone built it in the first place.
In many cases, the answer points directly to a functional requirement an existing application wasn't meeting.
Follow the Work Behind the Tool
During a recent application mapping engagement with a major refiner, one of the biggest surprises we found was the number of workarounds taking place in applications like Excel, Power BI, and Power Apps. Despite a robust enterprise technology environment, employees still relied on additional tools or spreadsheets because information in enterprise systems was either incomplete or needed to be reconciled before it could support the work.
A spreadsheet like this may pull equipment information from one source and maintenance information from another. It may also apply rules developed through years of operational experience or flag exceptions that require additional attention. By the time the spreadsheet becomes part of daily work, it can contain a working version of the team's requirements.
That's why we described these tools during our recent webinar as manual “crosswalks.” Each employee-created solution can provide evidence of a gap between what sanctioned systems currently offer and what the work requires.
Look Inside the Workaround
I recommend starting by walking through the work with the people closest to the tools. Identify where the information originates and what the employee does to make that information usable. Pay particular attention to calculations, business rules, exceptions, and handoffs.
A workbook that looks relatively simple from the outside might be answering questions such as:
- Which information from two systems refers to the same asset?
- Which source should take precedence when records conflict?
- Which exceptions require someone to intervene?
- What information has to be available before the next step can occur?
Document the people involved as well. A locally built solution maintained by one experienced employee creates a different risk profile than an IT governed tool with clear ownership and support.
The objective is to understand the logic and dependency well enough that the organization can preserve the requirement even if the system landscape eventually changes.
Get the Real Answer From Users
How these conversations are framed has a major effect on what you learn.
During the refiner engagement I mentioned earlier, we found that presenting the exercise as an audit or rationalization effort resulted in employees providing the “official” version of how work happens. When the conversation was reframed as an effort to understand their work, people were more willing to explain the tools they used and what they had built themselves.
There's some amount of human psychology to keep in mind. Someone who has spent years optimizing a workbook that helps a team get through the day may reasonably become defensive if the first conversation centers on compliance or retirement. We've found that starting the conversation with the work process itself makes these conversations much smoother, especially when employees do have understandable attachments to their own systems.
During those conversations, we walk through a task from beginning to end. We ask where employees leave the system of record, where they have to look somewhere else, and what they do when the information they need isn't available. We intentionally want to find the points where someone has to reconcile information.
Those moments often tell you more about functional fit than asking whether employees are satisfied with a particular application.
Decide What Should Happen Next
Understanding why a shadow tool exists doesn't mean it should automatically remain in place. Some tools create legitimate risk, particularly when a business-critical solution sits outside IT support and can be affected by technology changes without IT realizing it.
Once the underlying requirement is understood, the organization can make a more informed decision about how to support it. The existing enterprise application may be able to meet the need through configuration or better training. Another sanctioned platform may be a better fit, or part of the manual process may be a candidate for automation. In some cases, the locally developed solution will remain the most practical option, but ownership, documentation, support, and governance need to reflect its importance to the business.
Start With the Tools the Business Can't Work Without
An organization with hundreds of spreadsheets and locally developed apps can't investigate each one with the same level of effort. Start with the workspace, function or tools people consider truly essential.
I recommend focusing on solutions that combine information from multiple enterprise systems or depend heavily on one person's knowledge. A tool used across several roles or functions deserves attention, too.
From there, document the requirement behind each tool and decide where that requirement should live going forward. Over time, that creates something more useful than another inventory of shadow applications. Now, operations and IT can get a clearer sense of where the current technology environment is falling short.
For a deeper look at how these shadow tools fit into the broader application landscape, watch our webinar, Navigating AI Readiness: The Strategic Value of Application Mapping. We explore how understanding the tools people actually use can inform application decisions and AI automation.
/1.%20Visuals/Website/Icons/x-twitter.svg){kind=icon}