ETO Requirements Capture

Data Management & PLM | 17 September 2012 | Team EACPDS

Share this

The process of capturing, documenting, and agreeing on requirements for product change or development takes on an entirely different scope for companies engaged in Engineered to Order (ETO) businesses. While these requirements are generated internally for Make to Stock (MTS), Assemble to Order (ATO) and Configure to Order (CTO) product lines the ETO business relies on external sources. While everyone is familiar with the formal Request for Quote (RFQ) process, very few engagements will adhere to this. More likely, is a process of starts and stops requiring many man-weeks, months and years. The ability to efficiently; quote, process, develop and ultimately deliver an ETO solution is dependent on the enterprise’s ability to capture just enough information at the project’s inception to describe the product criteria, but not overly constrain the design team. Many a post-mortem analysis has revealed very small or non-existent margins from “specials”. By attending to the requirements at the project’s inception and ensuring that those requirements are of sufficient depth and breadth to quote and create specifications, scope creep can be prevented and margins preserved.

A requirement is a capability which the product or project needs to incorporate. For standard products, these are developed over time by internal teams during the ideation phase of product development.  The design and associated intellectual property are then developed as the project moves from ideation to fulfillment.  While this may describe the development of Intellectual Property (IP) for an ETO business, a different front-end is followed for ETO solution delivery.  As soon as the opportunity is identified by the sales team data (requirements) capture begins.  At an advanced maturity state, this data will be entered into the Customer Relationship Management (CRM) application with the correct associativity and visibility to the downstream (application engineering, procurement, etc) functions.  More often than not the customer contact data and a subset of the original notes will be entered. Another set of data is now stored in notebooks from phone calls and meetings. As more people become involved during the wooing and quoting phase more set of notes are created and NOT captured or associated formally to the opportunity.  Eventually, a quote is generated for the solution and delivered to the potential customer.  It is at this point where the troubles can really begin.  As the quote is iterated the data behind the iterations and the associated cost implications do not have as stringent review as the originals. When the project is finally won the margin has usually been eroded significantly from the original intent even before development starts.  During the quote iterations, technical oversight of the requirements is minimal.  This causes the potential solution being quoted to deviate from a variant of a previous design to the requirement to develop entirely new designs.  The effect is that the time estimates for the original design are now terribly inaccurate and the project won have been underbid.  If aware, most companies will choose to “eat” some of this as development time.  The problem is that most companies are not aware of this and schedule resources around original project estimates instead of the last iteration of the quote.  Now the pressure on the development team is substantial, to meet the new product deliverables at the same time allotted for the original quote.

To combat this, rules and guidelines governing the boundaries for the solution need to be put in place. These guidelines can be as simple as size and complexity constraints or for often quoted, complex designs, configurators can be employed to accurately capture application data.  At the very minimum templates for customer data need to be developed and used to accurately capture the customer’s data. The templates need to be established with clear boundaries so that the correct oversight is employed as the quote is developed.   As important, is maintaining the data as the quote is iterated.  All data needs to be readily available to the enterprise for use during all phases of the project as well as reference material for similar projects.  Associating the original customer data to the quote and any subsequent design files will enable the organization to comprehend the effects changes will have on the overall project.  This data associativity and transparency will help to maintain the intended margin and ensure the project stays on track.

Categories