Domain Expertise and Attention to Detail

March 10, 2016
Featured image for “Domain Expertise and Attention to Detail”

Domain Expertise and Attention to Detail

INTRODUCTION

This post intends to deal with the actual work as well as the emotions that go into a project that is set up for success.  Up front preparation and attention to detail are keys to that success yet that exercise requires great discipline to complete.  Having a Control System Integrator (CSI) that has domain expertise is a great asset in working through the details for your application.

DOMAIN EXPERTISE

Just exactly what is “Domain Expertise”?  By our definition we mean someone who has had prior, in-depth experience doing the same sort of thing that the project at hand entails.

As a customer you might think:

  • “Why are there so many questions?”
  • “If they have all this domain expertise then why do I have to answer so many questions?”

The thing is – without domain expertise you don’t really know what questions to even ask let alone recognize reasonable answers.  Having an experienced CSI quiz you about your company’s habits as it relates to the project will uncover more detail than you would at first think.

THE INTEGRATOR’S JOB

We feel that it is the CSI’s function to understand not only the technology being applied, but also the nature of how you operate your business which is sometimes called the ‘activity model’.  You have a business model that works for you and your employees.  You and your employees will be able to function more efficiently if this new system is built around how you run your business rather than simply delivering some ‘default pull-and-release’ standard solution that will cause you to reinvent how you function to operate your business.  The so called ‘default standard’ will require less up front work by you, but the enduring effect of having a system not tailored to your people will drain more effort and money over the life of the system than one that has considered and accommodated the activity model of your people as they produce your product.

Hardware / Software Considerations

In relation to the ‘technology’ statement in the above paragraph, it is the CSI’s job to know the following with regard to the proposed hardware and/or software:

  • Is it at or toward the end of its life cycle?  How long will it continue to be supported?
  • Is it so new that it is not truly mature enough to provide a solid solution at this time?
  • Does it have the capability to deliver the solution with the desired or appropriate features to accommodate your needs?
  • Is it rated for the environment in which it is intended to operate?  (temperature, humidity, voltage condition, …)
  • Is it compatible with the rest of your plant (spare parts, maintenance tools/experience, networks and communication protocols, legacy devices, …..)

You may have a number of older legacy devices that still use RS-232 for communication.  The newer processors may not accommodate RS-232 (Ethernet/IP is the current prevailing protocol).  So then the question exists about whether to upgrade all the plant’s legacy devices or find a processor that can still accommodate this older RS-232 protocol.  These are all good things to know up front!

You may have a need for data collection.  Perhaps you have some regulatory reporting requirements or perhaps you have a mission to track things like OEE (Overall Equipment Effectiveness) or perhaps you intend to move into the Food Safety Modernization Act and track ingredient genealogy or perhaps use production data to do vendor evaluation or ……….

You may have no need for plant floor to top floor connectivity and therefore absolutely no need to buy a product that supports multiple network protocols.

Up Front Project Tasks

Many of these things may seem small and inconsequential and you wonder why your time is being wasted discussing them. But minutia can have lasting long term consequences. Some examples of detail challenges are given below:

Tag Naming Conventions

How many characters are in an ingredient’s Short Name?  If we say that the default is 8 — well then 8 surely must be good.  “Let’s go with 8 – next question?”  If we take a little more time to ponder the question and how it applies to your plant we could see that “Brown Sugar” would be too long for 8 Characters.  So it could be abbreviated to “BwnSugar”.  “Yeah 8 will work.  Let’s move on.”  However, let’s consider what might be involved if we need to also identify the vendor or the grind or GMO/Non GMO?  Eight (8) characters won’t be long enough.  Someone says, “Well then let’s use 50 Characters.  Fifty (50) characters will surely be enough for any product.”   Question Answered – Next.  But 50 Characters consumes a lot more memory and will be very difficult to display on a graphics screen and still get a reasonable amount of information on a screen.   So something between 8 and 50 is really the best answer.

It is not the CSI’s job or place to tell you what the right answer is, but to provide enough information and guidance so that the right answer can be arrived at collectively.  And this right answer is almost always a compromise – but it needs to be an informed and properly vetted compromise.

Obviously this example may seem to be a bit dramatic, but over the years there have been discussions that were very similar to the one just hypothesized.  Not every detail needs to consume this amount of time or energy, but each detail or family of details needs to be considered.

Device Naming Conventions

Now that the P&ID’s are completed and all the stakeholders are in agreement that the plan will work, you and your team want to move on to the next task at hand.  However, here is this CSI (who has domain expertise) wanting Device ID’s and Descriptions defined.  While it might be easy to say that this is a task that can happen later and by others who don’t have such high demands on their time, it might well be worth the extra time to deal with this at the beginning of the project.

The Device ID’s and Descriptions will be with the plant forever. So if it is really a Condensate Pump or a Reflux Pump, but it is mislabeled as a Product Pump – that name will be causing confusion among the operators and support staff for the life of the plant possibly resulting in lost time, delays and/or lost product or employee injury.  Admittedly it is less of a problem for the workers that have been in that plant area for the long term, but for the new personnel looking for XV-123 Reflux Recirc Valve (because that is what it is commonly referred to), but in every piece of documentation it is referred to as FV-5123 the lost time and confusion can be significant.

A good Device Description will convey functionality of the device such as; YV123 Discharge Hopper Valve.  Such a description is more descriptive and helpful than; YV123 Butterfly Valve.  The latter description (YV123 Butterfly Valve) identifies what you are trying to find when you are wandering around the plant hunting for it, but it doesn’t say where you should be looking.  Especially if you have 15 butterfly valves on that line, but only one discharge hopper.

It is important that you (the plant/customer) control the Device IDs and Descriptions so you don’t have the same ID or Description used multiple times in the same plant/enterprise for similar reasons.

SUMMARY

Yes, it is important to have a CSI that has domain expertise, because that will lead to a more successful implementation of your project, but don’t assume that just because the CSI has domain expertise that he/she can read your mind or the mind of your employees.  It still takes a diligent effort to do a proper job of collecting and defining details at the beginning of the project to have the best outcome.

Marvin Coker
Senior Project Engineer

BIO

The author has a BS in Mechanical Engineering from Kansas State University and well over 30 years in the control and automation business.  Of those 30+ years, 22 years have been with Bachelor Controls.


Share: