Requirements for a successful automation project. 5

[MSCHWALM]

Success of an automation project is defined in many ways. Two major definitions exist:



1) Machine XYZ completes all its logic functions and physical movements. The movements were defined by a combination of the automation engineer and process manager.



2) Machine XYZ produces product to specification. Often this specification is on the overall product which can be affected by both the incoming and subsequent processes. For example a failure by this definition may include a project where the machine moves exactly as specified but due to an incoming product the outgoing product fails to meet specification.



Which do you consider correct and why?



What would you like to see from an automation company? How should the initial project be approached? Should the automation company include development time to better understand the customers process? How would you like to see an automation company handle pricing and delivery when an automation project is often a development project where the path to solution is often not well understood beforehand?



Thanks in advance for your input.........MSCHWALM

 

[ELECTRICKEN]

I don't think it's a question which is right.<br>
The customers I work for look at it this way.<br>
OK lets say &quot;A&quot; is process into XYZ &quot;B&quot; is process out.<br>
The bottom line is A+XYZ+B=PROFIT &quot;The Real Boss&quot;<br>
Many designers are given 100% to 150% flow rates to design<br>
machine XYZ.<br>
Define where you fit in the equation &quot;Scope of work&quot;.<br>
You need this very well defined with the customer.<br>
In the real world an average process line runs 86% to 95% annual product depending how good the automation is. XYZ is most likely oversized for A or B or both. My feeling on the matter is you need a clear understanding of A&B to automate<br>
XYZ to a customers satisfaction.<br>
Bid yourself enough hours at a flat rate to set a &quot;scope of work&quot; Meet with your customer and set a direction of work.

 

[rush]

The ideal form of a consulting project is a partnership. If you are the service provider your pay should be based on the profit generated. This only works if your &quot;client&quot; is willing to provide the needed resources. In theory, this applies to an external consultant as well as the &quot;internal&quot; ones. This ideal is hard to achieve. However, that is no reason not to work toward the ideal. The closer you are to the ideal, the better the result for everyone.<br>
<br>
With this in mind, if an automation project produces junk because the input is bad and not because the automation failed the result is still junk. The operation was a success, but the patient died! It is hard to call a project a success if the bottom line is a loss.

 

[rth]

We are designers and manufacturers of automated test and assembly equipment. The first requirement for a successful project is for the customer fully to understand his product and his need. A simple requirement but rarely met. Providers of automation systems work across a broad range of technology and in diverse industries. They therefore generally have a broader and more up to date knowledge of applicable technology than customers. A successful outcome can only be achieved through cooperation. It is simply not possible to quote a price to complete an automation project on the basis of a customer specification. An automation supplier needs to be involved from the earliest possible stages, preferably at product conception. There is resistance to this as it implies that the supplier of the automated manufacturing equipment is chosen early and that the customer is then tied to that supplier. The solution we find works best is to proceed intitially with small contracts for design and/or feasibility studies. This means that the supplier is paid for his input and the customer gets real information, drawings etc. of a standard not possible to provide in response to a tentative enquiry. Both customer and supplier learn as the designs are developed and the customer benefits by being part of the process which selects the optimum, and therefore most cost effective, solution. The safeguard for customers lies in the ability to suspend the relationship with the supplier at the end of any of the predefined stages and to take the information, for which they have paid, to the open market for competitive quotation. It is the knowledge that the customer has this ability that keeps the supplier focussed on the task in hand.<br>
<br>
On a slightly different but related subject I would like to make an observation. When consideraing a product which has to be assembled designers automatically envisage one part in each hand. Hands are difficult to replicate. If component designers thought more in terms of the ability of simple machine mechansisms then the whole process of automated assembly would be very much easier to achieve, more reliable and more economic.

 

[VSTOLcost]

rth,<br>&nbsp;&nbsp;In regard to your last observation:<br>I learned what I know about tooling design from old-guard machine shop guys.&nbsp;&nbsp;That will teach you to consider what the tools can do, what they can't, and maybe more importantly - what the shop machines can do.&nbsp;&nbsp;One more reason young engineers should co-op.

 

[vinod]

these are
1.study of the process
2.ergonomic aspects
3.budget available
4.technological environment in the organisation asking for automation
5.Manpower who is going to support the project.
6.Type of idiot moves expected.
7.disaster considerations in case of failure of any automated sub system.
8.reliability requiremrents of the process being automated.
power available at the site the project is being implemented.
9.educational and social environment around the project site and of the manpower likely to handle the project

vinod
vksingh_15@yahoo.com

 

[ghostdog]

Some very intelligent posts.No pint in repeating some of te stuff. My thoughts.
I find that its easy to over complicate stuff. Mostly the customer wants the end result and doesnt really need the painful bit in the middle. Get the solution and work backwards. Dont invent solutions for solutions to solutions to problems. Sort out the basis for your project. Always consider the manual process too , how can we use it ? what should we learn from it. On line help apart from this site is poor. Check out

http://www.roboknowlege.com.

Its a bit specialized but if post the question and check out the site content you might provoke a response.
regards