Estimating final price

[automan]

Is there anybody here who is involved with estimating final price for an automation system in a tender (and not necessarilly just in a tender).
I work in a group named "Sales & Proposal" and we have our own way in calculating final price and ofcourse preparing technical proposal.I think, sharing different experiences, would be very interesting and useful.

 

[jstolaruk]

Actualy, the non-disclosure agreement I signed with my employer (and the non-compete agreement with previous ones) disallows me from doing that.

I've used company spreadsheets that are really complex involving the different burden rates/scalars depending on the skill level of the company services and I've used them where they were a straight percentage markup.

And then there is finally the SWAG method based on experience. "yea, it should be worth about this". Thats what you use to check your spreadsheet output

 

[automan]

Let me explain what we do:
We complethly design.We generate hardware list ,software list , hardware manpower, software manpower.The lists includes all the details for example hardware list contains PLC components and accessories (cabinet..wireshoe...operator desks...)
Cause the time duration for this activities is restricted we work overloaded.I want to know whether other companies do the same?

 

[jstolaruk]

Let me explain what we do:
We complethly design.We generate hardware list ,software list , hardware manpower, software manpower.The lists includes all the details for example hardware list contains PLC components and accessories (cabinet..wireshoe...operator desks...)
Cause the time duration for this activities is restricted we work overloaded.I want to know whether other companies do the same?

I may have misread what you were asking for. I was thinking about a quote for a customer.

 

[rstech]

I typically go through the design steps when quoting a job. I pick out all the automation components and assign man-hours to the build, programming, installation, debug, and documentation. Typically the man-hours are based on the number of I/O points, size of the equipment, etc. Programming man-hours often go by features of the system such as recipe management, detailed production data, data collection, etc. as well as I/O points. I've heard of others quoting based on the number of rungs in a program.

I also always have a miscellaneous column because typically the initial concept differs somewhat from the final product and I try to avoid hitting up my customer for "extras" unless they make a major change.

Now, most of the jobs I work on are relatively small, single-cell, stand-alone machines for example. I couldn't imagine using this method for an entire line or large-scale machines. I would think it would be too time consuming and costly. That's when you need some kind of estimation process to use instead of actual I/O counts.

 

[automan]

I may have misread what you were asking for. I was thinking about a quote for a customer.

No jstolaruk, you've not misunderestood. I was explaining, we do detail design in a short period of time and then we can calculate final price to quote for a customer. Rob is right, in large scale projects this is a heavy job.

 

[Unregistered]

I typically go through the design steps when quoting a job. I pick out all the automation components and assign man-hours to the build, programming, installation, debug, and documentation. Typically the man-hours are based on the number of I/O points, size of the equipment, etc. Programming man-hours often go by features of the system such as recipe management, detailed production data, data collection, etc. as well as I/O points. I've heard of others quoting based on the number of rungs in a program.

I also always have a miscellaneous column because typically the initial concept differs somewhat from the final product and I try to avoid hitting up my customer for "extras" unless they make a major change.

In addition I always have a challenge in my mind between different soloutions.
SIEMENS, ABB, OMRON , VIPA, KEYENCE , AD...
and from another point of view the selection should be made between PLC BASED or PC BASED soloutions like BECKHOFF or SIEMENS WINAC.

 

[chakorules]

I have a sample quote that I have shared. You can download it here:

http://forum.mrplc.com/index.php?act=Downloads&CODE=02&id=187

I also have a quoting file you can download:

It's located in this post here. Called "quoter.zip"

See if that helps you any.

 

[jstolaruk]

I have a sample quote that I have shared. You can download it here:

http://forum.mrplc.com/index.php?act=Downloads&CODE=02&id=187

I also have a quoting file you can download:

It's located in this post here. Called "quoter.zip"

See if that helps you any.

Chris, very nice thorough quote.

A couple of years ago I was a partner in a controls engineering firm and apparently we got into a situation (I don't recall the exact details) where the company got stuck having to pay sales tax on some services or equipment we sold. It should have been exempt (industrial processing) but there after we added the following line to our terms: "The Above prices do not include any sales taxes and, if applicable, would be the responsibility of the purchaser."

 

[rsdoran]

The problem I ran into in the past was you had to have separate licenses etc to sell electronics, computers and industrial equipment. The electronics (plcs and many devices fell into this) and computers ( and/or components) were taxed.

The paperwork almost drove me insane, I now offer nothing but labor/services.

 

[jstolaruk]

The problem I ran into in the past was you had to have separate licenses etc to sell electronics, computers and industrial equipment. The electronics (plcs and many devices fell into this) and computers ( and/or components) were taxed.

rsdoran, your description is the first I've ever heard of that. Licenses? That firm I was a partner in hit gross sales of $12M, was auditted once by the IRS, and that never came up. And I've never seen it in any other companies either. Just curious, I guess, as to your circumstances.