Efficiently managing customer specifications

[geesamand]

My company builds rotating machinery and frequently handles customer specifications. Unfortunately, many specs are not optimized for our type of equipment so we expend energy dealing with exceptions and clarifications.

Internally this means we must:
- Identify all of the real world "requirements" that result from the spec
- Interpreting the spec language consistently across orders, and across customers
- Distilling the spec into a list of exceptions/clarifications for the customer
- Apply our products in a savvy way to meet the intent of the spec with maximum value
- After winning the order, distilling the spec again (more detailed requirements) suitable for internal use

Right now we rely on knowledge, spreadsheets, PDFs with comments, and printed copies with comments. There is no consistency and only our most senior staff have a chance of winning the order with reasonable agreed requirements.

Have any of you worked with a system (software or process) that helps here? Is there a software solution that streamlines all of this?

 

[JohnRBaker]

While not providing a solution, this does describe what many of us have had to deal with when it comes to responding to a customer 'spec':

John R. Baker, P.E. (ret)
EX-Product 'Evangelist'
Irvine, CA
Siemens PLM:
UG/NX Museum:

The secret of life is not finding someone to live with
It's finding someone you can't live without

 

[3DDave]

"Interpreting the spec language consistently across orders, and across customers"

Why is this a requirement? If different customers mean different things with various requirements, the interpretation cannot be consistent across customers.

Seems like you want to fire your senior staff and replace them with what's known as an expert system. These were proposed in the 1980s and failed to catch on. I guess part of the problem was that senior people don't care to spend a few years coughing up everything they know in order to be suddenly shoved out the door when their expertise no longer has value. The bigger problem is that understanding what the customer wants from what the customer says is still not reducible to a set of rules.

The bigger question is why are you taking orders for equipment that is outside your capability? Perhaps a better process would be to train the sales staff about the abilities your company does have so customers order what the company actually can make.

 

[IRstuff]

Conversely, it could be the case that the seniors are winging it half the time, anyway, and this is an attempt to buckle them down a bit.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert!

https://www.youtube.com/watch?v=BKorP55Aqvg

faq731-376 forum1529 Entire Forum list

http://www.eng-tips.com/forumlist.cfm

 

[CWB1]

Why is this a requirement? If different customers mean different things with various requirements, the interpretation cannot be consistent across customers.

As with engineering standards, most companies have a list of orderable specs/options for a given product requirement. When the customer orders you simply check the appropriate boxes to tailor the product to them.

geesamand, there are many product definition/requirements software packages out there. I've used several but admittedly on a Monday morning the only that comes to mind is PTC Integrity.

 

[geesamand]

Interesting responses so far...I suppose I must explain our situation better

I don't believe our situation w.r.t. customer specs is widespread in industry. We make a specific type of machinery and many customers (or worse, their appointed engineering companies) don't have a specification that applies to our machinery. Our transactions are big enough to be capital expenses and managed by a 3rd party engineering company, but not big enough to be handled by people with knowledge, experience, or caring. The specs vary enough from one transaction to another that we can't build a standard product around meeting most specs. They're basically bad specifications, and the amount of effort that goes into enforcing the spec vastly exceeds the effort that goes into building a smarter spec. The end user's corporate engineering departments have been scaled way back and engineering companies are filling the void. It seems to me the engineering companies are making their money by pound of paper, yet the quality and effectiveness of the product is largely unmoved by this heavy lifting. The engineering companies fight to keep us from cutting down unnecessary paperwork or working directly with end users and having conversations that help us see through the words in the spec and gain proper insight into the actual needs and conditions.

Our approach is:
- We review specs in detail at the time of quote. The alignment of the spec and our products is a factor in whether we quote at all. We frequently take exception to the entire specification and provide clear detail in our quote as to the functional design. We have no interest in cutting corners that matter in the end. If anything we work with weak specs that will fall short of the end users' expectations.
- We don't have enough senior staff (people who rely on tribal knowledge) to move all specs in their entirety through them. We have a few senior staff who consult and help answer questions and review the proposals before we send them out, but we let mid-level staff do the heavy lifting with the spec documents.
- We take exceptions, make clarifications, etc. clear in our quotation and are careful to ensure we don't accept a purchase order that ignores the technical agreement that's been worked out. (It's rare to see a spec revised; it's usually handled as a lift of exceptions and clarifications)
- In many cases, we fight through an unhelpful engineering company and poor spec because we want to connect with the end user and get installed equipment on site. Only then can we generate rapport or history with the end user that allows us to sell direct.
- We know our competitors are fighting the specs because we see them supplying closer to their standard products than we do.

Determining how to handle constantly changing spec content and building the list of clarifications and exceptions anew for each transaction is a slow, tedious process. I want software or process that helps us collect these comments, report the comments separately(perhaps as a spreadsheet), and ensure we are fulfilling every contractual requirement and ensure that the engineering company, our sales staff, and our engineering team all know what to do. I want it to help the spec reader to home in on important areas and inform the reader of our preferred company position on various topics. I want the spec reader to know how we've handled similar requirements on past relevant transactions. This goes well beyond the basic commenting functionality found in PDF software.

David

 

[Sparweb]

The specs vary enough from one transaction to another that we can't build a standard product around meeting most specs...

Maybe not a standard product, but could you come up with a shopping list of features and characteristics? Is it possible to hand your prospective customers a blank spec sheet/form that they can fill in, preferably by selecting from lists of dimensions/components/materials that match your tools and processes?
At least, when they want something that is not on the form, you can inform them that it is possible but costs more, and inform production that more special tools need to be made.

STF

 

[geesamand]

That is extremely effective with end users who trust we know what we’re talking about as a supplier and industry expert and when they are willing to pitch in a tiny bit to help get the best equipment for their money.

The engineering companies who write specs on the other hand consider it their solemn duty to make everyone else conform to them above all else. Their business model assumes every buy is a complete custom designed system at import-grade commodity prices and in-stock lead times. They have never accepted our data sheets (must use theirs) so by extension I doubt they would ever spend a minute filling one out. That kind of efficiency is not in their DNA.

David

 

[CWB1]

I've worked in that world. IMHO you need a simple requirements software tool as mentioned above.
Your sales folks also need to be abundantly clear on a few things with everyone involved during early project discussions. 1. Writing requirements is a group exercise between your engineering staff and theirs. 2. An end-customer rep needs to be involved in all discussions. 3. Price discussions only goes through the end-customer, not a third-party engineering firm. Its very tempting to bend over for anyone waving a check however this increases cost and headaches later on in the project, if a customer insists those be ignored they should pay accordingly.

 

[Sparweb]

Understood. Sounds like what you're really looking for is a way to pull down the engineer's pants right in front of the end-user, but without making the engineer embarrassed about it. If the end user is not interested in participating in the good specification process that CWB1 recommends, then the only way I can think of to do that is to lay all your cards out on the table for the public to see. For example, create a web page which lists product examples, with specifications AND the end user's price if the design was optimized your way. Then let those engineers spec something that costs 3x as much and wait for the end users to phone you.

STF

 

[truckandbus]

My past company approached this two ways

1) work with trade organization to come up with a standard specification with common options. The standard did not necessarily reflect our version of the product but if a customer chose to use it, we already knew where we deviated from it and had our deviation requests cataloged and ready to go

2) established a technical spec review department that maintained a record of previous bid packages and accepted/denied deviations. When a new bid hit the street it wasn't hard to see if it was brand new or recycled content. we had to make sure our BoM structure supported easy filing and retrieval of deviations and supporting documentation. It was managed through excel spreadsheets and Adobe Pro fro collaboration