How we do business: some lessons learned

We have been building machines for a long time, and seen automation vendors make some of the same mistakes over and over again.  We’ve attempted to capture some lessons learned for both the vendor and the customer below:

Pre-Sale

Nobody will be happy if the automation provider buys the job

Everyone has had the experience of working with an automation vendor who has under-bid a project.  Component substitutions, parts purchased from E-bay, change orders for the smallest deviation, minimal debug and a slipping schedule are common reactions when a project manager is trying to trim costs on a mispriced project.  The automation vendor never fully recovers the shortfall, the schedule slips and the customer receives a poorly running machine.

 

Working with the customer is not a zero-sum game.  If one side loses, both sides fail

You can (and should) write a tight specification.  The automation vendor can fill their proposal with caveats, qualifications and exceptions.  At the end of the day, the customer can’t force the vendor to build a quality machine on schedule.  The vendor will never extract payment from a customer if the machine does not work.  Both parties must be clear in their expectations pre-sale, and must protect their interests during the project.  However, the working relationship they establish will be a major factor in the success of the project.

 

Help the customer to anticipate.  Will volumes change?  How will parts vary as tools age or new vendors are used?  What QC checks are possible in the future? 

Purchasing custom machinery is an expensive, difficult process.  Your automation vendor should be able to support you by anticipating common changes to your requirements.  It may be that machine throughput could be boosted over the minimum requirements with little or no expense.  Empty stations could be provided for a future inspection process.  New part styles may have to be run.  An experienced automation vendor can anticipate issues and “future proof” the machine at little or no additional expense.

 

Jobs that fail badly are usually the result of poor scope definition or poor understanding of the scope

If there is an inspection, can the inspection criteria be fully defined?  Are all process parameters mutually understood?  For example, the customer may expect a press monitor to provide force/distance curves while the vendor expects to press to a hard stop.  Has the product design been completed, and if not does the vendor understand what areas of the product are frozen?

 

 

Project Management

The customer is not the enemy, is not an obstacle, and is not trying to make your life difficult

This seems obvious, but it often gets lost in the struggle to reach milestones in a timely manner.  If the customer makes a change, it is not because they think your job is too easy.  The end goal is always to build the machine they need.

 

Get a jump on the project. 

It is very easy to lose several weeks “spinning up” a project.  Starting aggressively and getting engineers kicked off the first week will save weeks of schedule that will be desperately needed at the end of the project.  As a customer, you can help by ensuring that sample parts, part models and part drawings are in the project manager’s possession prior to project start.

 

No surprises

If the project manager is doing their job, problems will not be true surprises to the customer.  Tell them what may go wrong, what you are doing to minimize the chances of it occurring.  Nothing that occurs during debug and run-off should surprise the customer.

 

Report bad news early

Things will never get better on their own.  Problems will never resolve themselves.  You will never make up schedule in debug.  It is human nature to avoid difficult conversations.  Have them anyway.

 

There are two customers, the company and the project team

We always remember that an individual went to bat for us, and that our success or failure will reflect on them.  A successful project for the buyer’s company should be good for the team members, but we will always remember that our job is to support our counterparts on the customer team.  We seek working relationships that will last for years.

 

 

Engineering Phase

Get early customer input. 

The automation provider will never know the product as well as the customer.  Learn from the customer’s history.  Do an on-site visit whenever you can.  A day spent on site will save many days of design.  Listen to the managers, but also the operators and maintenance people.  If you address their concerns they may become allies.

 

Simplificate

It is a good idea if it solves the problem at hand, and eliminates several others in addition.  If it solves the problem at hand, but complicates some other aspect you are probably not on the right track.  The classic example is a clever idea that gradually forces you to make more and more changes to other parts of the system.

 

The biggest influencer of project success is mechanical design

We participated in a review of the ten year history of projects at Mark’s last company.  These projects represented more than 100 million dollars of custom automation.  The single biggest contributor to ensuring a project was a success was the lead engineer.  A strong engineer can salvage a weak concept, and can support weak project management.

 

The controls engineers have the toughest job

The controls team is the last to touch the machine.  They are responsible for actually making the machine work, so their task is to not only complete their own work but to address all of the issues that were not fully solved during the design phase.  Make their job easier by considering purge, fault condition recover and calibration modes during mechanical design.

 

Review HMI design early

Tt easier and less disruptive to incorporate the customer’s preferences before the system is fully programmed.  More importantly, this discussion with the customer will naturally lead both the vendor and the customer to a fuller understanding of the machine’s functionality.  It is not uncommon for major “what ifs” to be uncovered in this review.

 

 

Build Phase

A network of trusted vendors is critical

Good vendors can bail you out (but don’t make a habit of counting on them).   A knowledgeable rep can advise on serviceability and reliability factors that an automation vendor will have little visibility to.

 

Inspect parts upon receipt, not after fitment problems

The typical job has enough components that, even if the probability of any individual part being bad is very low, chances are something will come up.  Find out before it becomes critical path.

 

Start building as the parts come in, don’t wait for a full station before starting

Build what you can, when you can.  Finding fitment problems, missing components or other early debug phase issues early in the build phase helps indemnify the project from late phase delays.

 

Don’t leave an assembly step unfinished

Placing bolts without fully torqueing them is worse than not placing the bolts in the first place.  Stick to the task until you reach an easily detected stopping point.

 

 

Debug and Completion

Prototype early and often.

Build test components in the design phase.  Get customer buy-in.  A small expenditure of engineering time may save weeks of time in debug.

 

Involve the customer in the debug effort. 

They understand their product, and what the critical parameters are.  Getting buy-in and a sense of ownership from the team who will be responsible for supporting the machine after delivery is critical to the long term success of the project.

 

Never underestimate debug time, or try and cut it short

There is no savings, in labor or schedule, to trimming debug.  Anyone can get a machine run at 60-70% OEE.  It takes machine cycles to get the machine “over the hump” and running well.  Better that those cycle occur on the automation vendor’s floor instead of when the customer is trying to ship product.

 

If the controls engineer tells you something is done, check if their laptop is plugged into the machine…

If it is done and debugged, why do they need the laptop at the machine?

 

Unless required by external factors, solve everything before delivery

Papering over issues, or shipping a machine that is not running smoothly is asking for trouble.  It takes at least twice as long to solve issues on the customer’s floor.  Sometimes this is necessary, due to customer milestones, but everyone involved should be aware of the affects.

Advertisements