So in previous conversations I had rambled on about Continuous Process Improvement (CPI), as well as the Product Design Cycle. These two items seem to be at odds with each other. CPI is about process, repetition and systematic adjustment of that process to improve efficiency. Product Design is about creativity, innovation and commercializing concepts into salable products. Sounds like oil and water, how do they mix?
Simply put, a mixed model should be employed.
Engineers and designers tend to object rather strongly when presented with timelines, deadlines, or requests to schedule their work output. This is partially rightfully so since you can’t schedule creativity, but not entirely true because the design cycle is far more then creative work. Good designers and teams understand that process is not meant to constrain their creativity, rather provide more time for it by streamlining repetitive tasks.
Product Design and development is often thought of as a sexy cycle of conceptualism, creativity, fabrication and product testing. While these are true steps in the process and are the kinds of steps that keep engineers excited about their work, the reality is that 40-50% or more of the design cycle is mechanical admin type tasks. These tasks can include product documentation, drafting, blueprints, supplier qualification, fabrication support, purchase orders, Bill of Material (BOM) creation and maintenance, and Engineering Change Orders (ECO’s) to release product into the operational world. Legacy product support is also on the task list for engineers and design teams, evaluating product performance reports and issuing corrective actions. What this really means is that engineers and product designers only spend a part of their time doing what they want to do, and a good part of the day doing admin work.
This is where CPI can step in, structure, document and measure the steps needed for team members to do repetitive tasks in order to reduce their cycle. This is at least a three-fold benefit to the organization. Engineers reduce the time they spend on admin to allow them more time to do the fun stuff. The organization can also benefit by realizing a reduction in overall design time. (This is always a balance with increasing engineers’ development time) The third benefit is the standardization of work output for supporting teams. BOM’s are standardized, ECO’s are standardized, drawings are standardized for quicker processing downstream.
Candidates for CPI? Start small, Requests for Purchase (RFP’s), these are requests from engineers that trigger purchasing to place orders for stock or prototype parts. There is little variation in the steps needed, ie a part number, desired vendor, vendor quote, quantity needed, time needed and approval for purchase. The flow is very standard and simple to map out with standard forms, standard routing and approval triggers to initiate the PO from purchasing. Sounds elementary, but without a process each engineer is on their own to place PO’s their own way. In my organization we have roughly 55 Mechanical and Electrical engineers located in 5 offices on 3 different continents, all filtering their RFP’s through a central procurement group. Before a standardized practice, this was a disaster of mis-information, missed approvals and mis-routings. After process we were able to reduce delivery time to the engineer, increase part accuracy and reduce the effort (and staffing) requirement on the procurement group. As an added benefit, when errors are found on the finance side of the house with department or task coding, we have defined mechanical steps we can retrace to root-cause the issue for future prevention.
There are other steps in the Design Cycle that are great candidates for CPI, but that’s good for another day. Thanks for reading, I hope you found this helpful, feel free leave a comment on what you think could be standardize.