Simple is better than complicated
When it comes to commissioning software tools, the KISS metaphor is always best. Keep it simple. While this sounds obvious, I’ve been around long enough to have seen people and teams try to overcomplicate software designs. I think it’s partly because of human nature:
If it’s simple, it can’t possibly handle our use case.
If it’s a simple system, it can’t possibly be worth much.
If it’s simple, then this other more complicated (and more expensive) system has to be better, right?
If we design something simple, how can we justify our jobs and pay scale?
Yet, simple is STILL better, and here are two (simple) reasons why:
Simple structures are understandable by the field crews
The guys collecting field data need to be able to understand the system very easily and quickly. If the learning curve is steep, or if it takes a bunch of actions for the field guys to enter their data into the system, then the software is going to slow things down at the point of data collection. And a slowdown of a single day on a billion dollar construction site matters. Really matters. As in tens of thousands and hundreds of thousands of dollars in added cost to pay the thousands of people on the construction site.
Simple workflows are easier to grasp quickly
When your flow logic in your software tries to do everything for every conceivable and imaginable scenario under the sun, it means it needs to include layers and layers of features and options, some of which will rarely be used. Think here of bloatware, where you end up paying for a massive piece of software but only use 1/10 of it. Not to mention that complex workflows take much longer to learn and understand by everyone, and time is a rare commodity for the field techs that will be using the system to commission the project. Those guys don’t have a lot of time to sit through classes to learn how to enter data into a software system.
An example of a simple commissioning structure
When our software was used to commission Duke Energy’s $3.5 billion IGCC power plant in Edwardsport Indiana, we built the structure to follow a particular one-to-many logic flow. What I mean here is that we separated top-level equipment from lower-level devices into their own tables, and related them to each other. This simplified the structure because it’s easy to understand this. For example, 1 pump might have 1 or 2 motors associated with it. Or one valve might have several instruments associated with it. So when the field tech needs to commission a particular device, he or she can drill down from the equipment down to the individual related device and run their tests on that device, or run tests on the partially completed equipment, or both. Either way, the percent complete calculations roll up from the lower-level device all the way up to the equipment. Validation controls also can be put in place such that equipment cannot be commissioned without first commissioning the individual devices making up that equipment or component.
The main take-away here is that it is much better to 1) separate out the top level equipment, components, and assemblies from the lower-level individual devices that make up that equipment than it is to 2) lump them all together into the same table. Doing it as described in option 1 above allows a field tech to easily understand the flow logic, and it also helps simplify the database schema. So when one of your database admins or app designers quits, you are not left out in the cold trying to understand what the hell that person designed. It is clear.
Simple AND powerful
I’ll finish with this thought. Simple is not the same as weak. When implemented properly, simple database structures are the opposite of weak. They are powerful. Powerful because they make sense to most people (field techs capturing the data stakeholders analyzing the data, and application designers that build and maintain the application), which in turn means less time learning and more time doing. And this matters when you have a huge and expensive crew of highly technical commissioning experts in the field doing what they do best. Don’t slow them down with complex software. Get them to do their jobs and enter their data quickly and efficiently, in any kind of environment…cold, hot, sunny, dark, no internet, dusty, etc. in the field, the software needs to perform one thing well and one thing only, and that is to be able to provide the commissioning tech the proper forms quickly and then get out of the way.