First, the typical problems that we hear about is TAG data’s all over the place. The TAG data is on spreadsheets that are on file servers. It’s on people’s desktops. It’s on flash drives. It’s just hard to centralize everything because it’s all over the place. The main problem that derails a coherent tag management strategy is that different groups are working on TAGs and TAG data, so the data ends up fragmented, living wherever it pleases.

The other typical problem we hear about all the time is that people are using spreadsheets. At the end of the day a TAG list is just a TAG number with a bunch of data associated with it, but when you use spreadsheets you encounter some of the inherent problems that always exist when teams use spreadsheets for project management. These problems are revision control, data quality, and duplicate copies, and rectifying duplicate copies, and so forth.

If the TAG data is fractured like this, engineering may produce multiple designs for a piece of equipment which wastes money. Or commercial groups may purchase too many, too few, or incorrectly spec’d things. Finally, the completions team won’t have the whole story – they won’t know the specifics about what they are testing which could lead to inoperability, shutdowns, or major delays.

Another problem that we hear about all the time is that there’s no rules or workflows. So once stuff does get changed, and this spills over into the revision history, you’re not sure why. Sometimes numbering doesn’t make sense, or different groups use different numbering sequences and formats, and it’s hard to get all of those things to work together.

The final big problem that we hear about all the time, just so ubiquitous, is that your TAG lists, they don’t connect with document management and they don’t connect with procurement, completions, or commissioning. This is a huge problem because all of these disciplines either rely on the engineering data in your TAG data base to do their basic job functions or they use tag data to complement their work.

The best solution for managing your TAG data is one that centralizes global TAG data for a project (or even an organization) in a single application. Further, the ideal system enforces and automates a workflow for numbering and naming. This system maintains accountability and visibility by tracking who makes changes to tags and what changes they made. The ideal system natively integrates with procurement, document management tools, and completions & commissioning.

The main objective is centralizing all TAGs in a single application

When users from across the world can log in to a tool and contribute to the TAG lists and equipment data from anywhere, there’s really no barrier to collaboration other than having an Internet connection. The main benefit is everyone is on the same page. There is one list that everybody woks from – no more decentralized spreadsheets. Further, if you have central repository so all of your project TAG lists are in one app you can drive some really awesome inter-project collaboration. For example, if you have a repeat project, you can duplicate the TAG list and pull over metadata and so forth. This is a huge time saver both in terms of administration and data entry, but engineering hours as well.

The second thing was an Optimized Workflow.

Rogue TAG numbering is bad. It confuses engineers, buyers, and throws a wrench into completion processes. More than standardizing TAG numbering you should look to smart numbering. If the system will build the TAG numbers based on the properties of the TAG, there ends up being a 100% confusion free and 100% duplicate free system that makes sense for all teams using the tag lists. For example, if ‘system’ is a level your TAG number, the system that’s logged against the TAG should populate that level of your TAG number. In the same way, a good system can translate a tag into the client’s number so you can produce more meaningful reports.

The third thing is Accountability and Visibility.

Engineering projects need a system that ensures a clean TAG register. The ideal system will clearly show who edited which TAG information, when they did it, and so forth. Then there’s revision history. Similarly, someone changes critical TAG data, there needs to be a reason so if somebody who looks at that tag later, they can be like, “Why did this particular piece of information change?” Just click over the “history” tab and you can see right there that I’m the person that changed it, and that I’ve entered a reason for why I’ve changed it. It’s just another level of control that projects in the 21st century should have.