Multiple business units

• Analysis software (used to predict phenomena and performance) is underutilized, for several reasons:

  • Training requirements are onerous for the scope of the task involved

  • Hardware requirements and licensing requirements create extra constraints on learning how to use the software

  • Understanding what questions the software is good at answering creates waste and frustration

  • There is no good software to analyze what the team needs analyzed

  • Fragmentation: multiple pieces of software are required to perform a full analysis and the expertise to connect them doesn’t exist or

  • Balance of simulation versus experiment is over compensated towards experiments which can increase the cost of a decision point.

• Design software (CAD) can be difficult to drive adoption, even if simple to use.

• Research work is most likely to pull on a number of different disciplines to support novel experiments. Items needed include:

  • Custom components

  • Novel detection methods

  • New fixturing components

  • Use of existing manufacturing equipment, components

• Design iterations are challenging at all stages

  • Goldilocks design changes are hard to find. They happen not so slowly that the change will ripple through with potential unintended consequences, and not too fast that everyone assumes the design will change so quickly that they should invest any time into its current state

  • Difficulty creating “forks” of a hardware design to understand how a change will ripple through so marginal designs get frozen. This pushes engineers to “get it right” in the design phase if they can’t afford enough parts for experimentation

• Work is often under documented, for example:

  • specifications are listed but initial design constraints are not populated. In the long term, manufacturing teams know what works, but have a harder time understand how to make improvements (costs, touch time, etc.) that don’t have long-term adverse consequences. This affects how manufacturing teams address process inefficiencies, etc. as they work to reduce costs and improve margins

  • Some organizations hinder sharing of information because they are incentivized to keep certain information “trade secret”, which is painful

  • Repeating mistakes that are well known in larger org, but may be out of technical knowledge base for smaller, disjointed teams

• Duplicate work performed within an org by separate teams resulted in double the labor spend, and increased costs based on fewer common parts

  • Common method of solving: Assigning “specialists” that are responsible for processing all of a certain class of design or experimental work results in the formation of queues that can inhibit total organization efficiency at the expense of subject area efficiency

• New product introduction pain points

  • Manufacturing design work is over accelerated (fixturing, etc) after customer validation of a new product if the customer is facing a finite market window. This results in higher than necessary spend, and is also a problem if engineering teams don’t design to use existing parts or retrofit existing parts.

  • Manufacturing space can be over consumed by new component manufacture

• Manufacturing engineering pain points

  • Manufacturing engineering has to steal design support from product development teams in order to research, development and verify manufacturing improvements.

  • specifications are listed but initial design constraints are not populated. In the long term, manufacturing teams know what works, but have a harder time understand how to make improvements (costs, touch time, etc.) that don’t have long-term adverse consequences. This affects how manufacturing teams address process inefficiencies, etc. as they work to reduce costs and improve margins

Often, you end up with super-technologists who need to keep a running history of lessons learned, who knows what in the company, knows what people are doing at a low level of the organization, etc.