Tag Archives: engineering

VinceSebald
Soapbox

Automation – Planning is Everything

By Vince Sebald
No Comments
VinceSebald

Automation of processes can provide great benefits including improved quality, improved throughput, more consistency, more available production data, notifications of significant events and reduced costs. However, automation can also be expensive, overwhelm your workforce, cause future integration problems and magnify issues that you are currently experiencing. After all, if a machine can do work 100 times faster than a human, it can also produce problems 100 times faster than a human. Whether it is a benefit or a scourge depends largely on the implementation process.

There are thousands of possible technology solutions for just about any production problem. The trick to getting results that will work for your company is to use good engineering practices starting from the beginning. Good engineering practices are documented in various publications including ISPE Baseline Guides, but there are common threads among all such guides. What will the system be used for and what problem is it intended to solve?

The key is implementing a system that is fit for your intended use. As obvious as it sounds, this is often the most overlooked challenge of the process. In the grand scheme of things, it is a MUCH better proposition to spend more time planning and have a smooth operation than implement a system quickly and fight it because it isn’t a good fit for the intended use. The industry is littered with systems that were prematurely implemented and complicate rather than simplify operations. Planning is cheap, but fixing is expensive.

The most important step to getting an automated system that will work for you is also the first:

Defining “what” you need the system to do: User Requirements

Automation Runaway
Once automation is in place, it can be a boon to production, but don’t let your systems get ahead of your planning! It can be difficult to catch up.

With decades of experience in the automation industry, I have seen systems in many industries and applications and it is universally true that the definition of requirements is key to the success of the automation adventure. To clarify, the user requirements are intended to define “what” the system is required to do, rather than “how” it will do it. This means that persons that may not be familiar with the automation technologies can still be (and usually are) among the most important contributors to the user requirements document. Often, the people most familiar with the task that you wish to automate can contribute the most to the User Requirements document.

Some of the components of a User Requirements document typically include:

  • Purpose: What will the system be used for and what problem is it intended to solve?
  • Users: Who will be the users of the system and what is their relevant experience?
  • Integration: Is the system required to integrate into any existing or anticipated systems?
  • Regulatory Requirements: Is the system required to meet any regulatory requirements?
  • Functions: What is the system required to do? This may include operating ranges, operator interface information, records generation and storage, security, etc.
  • Performance: How many units per hour are required to process?  What percent non-conforming product is acceptable?
  • Environment: What environment is the system required to operate in? Indoor, outdoor, flammable, etc.
  • Documentation: What documentation is required with the system to support ongoing maintenance, calibration, etc.?
  • Warranties/Support: Will you perform work in-house, or will the manufacturer support the system?

The level of detail in the User Requirements should be scaled to the intended use. More critical operations may require more detailed and formal User Requirements. At a minimum, the User Requirements could be a punch list of items, but a detailed User Requirements may fill binders. The important thing is that you have one, and that the stakeholders in the operation have been involved in its production and approval.Once completed, the User Requirements can be a very good document to have for prospective providers of solutions to focus their attention on what is important to you, the customer.

Equally important to the process is the idea of not over-constraining the potential solutions by including “how” the system will meet the requirements within the User Requirements. If it is required to use specific technologies for integration with other existing systems, it is appropriate to include that information in the User Requirements. However, if use of a particular technology (e.g. “wireless”) is not required, the inclusion may unnecessarily eliminate viable design options for systems that may address the requirements.

Once completed, the User Requirements can be a very good document to have for prospective providers of solutions to focus their attention on what is important to you, the customer. This helps to ensure that they focus their efforts in the areas that match your needs and they don’t waste resources (which translate to your costs) in areas that don’t have tangible benefits to you, the customer. It also gives you a great tool to “value engineer”, meaning that you can consider cutting design options that do not support the User Requirements, which can reduce project costs and timelines, keeping things lean and on track.

Further steps in the project are built around the User Requirements including system specifications provided by vendors, testing documentation and the overall turnover package. An appropriately scaled User Requirements document is a low cost, easy way to ensure that your automated system will serve you well for years to come. Alternatively, the lack of a User Requirements document is an all-too-common indicator that there may be challenges ahead including scope creep, missed deadlines and unacceptable long term performance.


Feel free to reach Vince at vjs@sebaldconsulting.com with any questions you might have.

Soapbox

Human Error? No Problem

By Dr. Ginette M. Collazo
No Comments

If you are in the business of growing cannabis, you should be aware of the common reasons for production losses, how to address root causes and how to prevent future occurrences in a sustainable way. Human error is the number one root cause identified in investigations for defects in the cultivation business. Sadly, little is known about the nature of these errors, mainly because our quest for the truth ends where it should begin, once we know it was a human error or is “someone’s fault.”

Yes, human error usually explains the reason for the occurrence, but the reason for that error remains unexplained and consequently the corrective and preventive actions fail to address the underlying conditions for that failure. This, in turn, translates into ineffective action plans that result in creating non-value added activities, wasting resources and money as well as product.

Human error can occur when workers are in direct contact with the plant

So after investigating thousands of human error events and establishing systems to improve human reliability in manufacturing facilities, it became even clearer to me, the need to have good, human-engineered standard operating procedures (SOPs).

In the cannabis growing process, there are different types of mistakes that, when analyzed, all can be addressed in the same manner. For example, some common errors that we see are either overwatering or nutrient burn, which can occur when the plant is overfed. The same is true in the opposite scenario; underfeeding or under watering lead to problems as well. If your process is not automated, the reason for these failures was most likely human error. Now, why did the person make that mistake? Was there a procedure in place? Was the employee trained? Is there a specific process with steps, sub-steps, quantities and measures? Were tools available to be able to do the task correctly? There is so much that can be done about these questions if we had clear, well-written and simple, but specific instructions. The benefits greatly outweigh the effort required.

Also, besides providing step-by-step instructions to avoid commission errors (to perform incorrectly as opposed to omit some step), there are other types of errors that can be avoided with SOPs.

Decision making like detecting nutrient deficiencies can lead to human error.

Decision-making is another reason why we sometimes get different results than the ones expected. If during your process there are critical, knowledge-based decisions, workers need to be able to get all the information to detect as well as correct situations. Some decisions are, for example, when (detection) and how (steps) should I remove bud rot? Is there a critical step in the process (caution) to avoid other plants from becoming affected? Any information on the what, how, when, where and why reduces the likelihood of a decision error, later described as obvious.

When we face manufacturing challenges like nutrient deficiency in a particular stage, mold, fungus, gnats or even pollination of females, we want to do whatever we can to prevent it from happening again. So consider that from avoiding to detecting errors, procedures are a critical factor when improving human performance.

Here are some guidelines when writing procedures to prevent human error.

  1. Use them. Enforce the use of procedures at all times. As humans, we overestimate our abilities and tend to see procedures as an affront to our skills.
  2. Make sure it is a helpful procedure and users are involved in the process. People that participate in writing rules are more likely to follow them.
  3. Make sure they are available for their use.
  4. All critical activities should have a procedure.
  5. The procedure needs to be clear, have a good format, clear graphics, appropriate level of detail and specific presentation of limits.
  6. Make sure that facts, sequence and other requirements are correct and all possible conditions are considered e.g. “what if analysis”.

Human error won’t be eradicated unless we are able to really identify what is causing humans to err. If eliminating or “fixing” the actual individual eliminates or potentially reduces the probabilities of making that mistake again, then addressing the employee would be effective. But if there is a chance that the next in line will be able to make the same mistakes, consider evaluating human factors and not the human. Take a closer look and your process, system and ultimately your procedures.