What does this guide address - Scope:
Not meant to be all-inclusive but will be modify-able for companies to adapt to their needs (ie. “think about these things ”)
This is post-foundry engagement – addressing how to transfer
Who should use this guide-Audience :
Vertically integrated companies (with internal R&D) that are looking to outsource – looking for partners
Not initially focused on university spinouts
For companies with a working prototype
What are the benefits of this guide:
Increase probability of success within budget
Communication tool- prevent misunderstandings
Useful for planning
Help shorten engagement time (for the transfer?)
Positive business relationships by bringing up issues before they become issues
Leverage best practices developed by having “been there and doing that” – escape typical traps….
Tech Transfer Definition:
What is tech transfer: General Definition – will want to confirm this - consensus
It’s not new research,
It’s transfer of a “known good” idea , technology or design. Either/or:
Selling your idea/design/IP and transferring that externally (design transfer may be a whole different subject)
Commercialization of MEMS requires moving technology from one party to another,
Bringing up a technology at a new location, on new equipment, and/or with new people.
Making it work somewhere or with someone else
Tech transfer is a part of the process of making MEMS work …
Opportunity for Tech transfer exists at every stage of MEMS product development
Core Technology Acquisition
Prototyping (in and out-of-house)
Sale of Technology
Customer (Applications) Support
Define tech transfer for this audience
Take design to manufacturing (with an external partner)
Proven “high yield designs” over prototypes, processes or design concepts.
Utilize MEMS Development Cycle and Foundry schematic as template (A.M. Fitzgerald) – may need to further modified
Keep in mind that yield/cost requirements can vary a lot depending on application and segment. A low volume, high cost product doesn’t need the same level of maturity as a high volume consumer product .
(Need to define success for that product – see below section)
Tech transfer discussion should be discussed for both contexts. It affects approaches, effort and expectations.
What types of tech transfer are we excluding
We are not talking about tech transfer with the goal of transferring a new equipment technology, new materials or new design technology although these may need to happen to achieve the overall goal of product manufacturing tech transfer
ID what we will tackle in the future – future tech transfer expansion opportunities
In Wiki want to collect data from others on their pain points, what do they want to see data on (embed a voting mechanism)
Open source tech transfer AIC – is there a role for AIC in tech transfer – to help co’s engage with another co in tech transfer
OR do we want to have a list of those who are available to help with tech transfer?
What exactly is being transferred - deeper definition
Why and when does something need to be transferred?
What is a “production ready” design? (in other words “Are you ready for tech transfer?”, what does it take to be ready)
Create a checklist (look at Foundry Engagement Guide list as a guide)
Create checklist for each bullet – how critical is it; standard or custom process…
Unit process match
Business model match (understand may be outside of current scope)
2nd Line or 2nd source
6” to 8”
Roles, Team, and Collaboration strategies – Technology Development Protocol Prototype might help here (adapt sections here); as well as Foundry Engagement Guide
Who are you transferring to
What are the different models of interaction/collaboration- examples of models for tech transfer – these are the spectrum (opposite sides of spectrum)
Spec oriented model (ASIC model) (more hands off, not in the fab)
Process oriented, collaboration model (boots on the ground in the fab)
What are you transferring – copy exact; copy end performance, etc.
Are you providing or receiving - process, design, know-how
Collaboration methods- embedded personnel?
Is it an ongoing relationship? Does it need to work for the long term?
Who should be on the team?
Conflict resolution-problem solving
Innovation and collaboration while maintain rights, trade secrets, IP (need IP framework)
Knowledge of process and design mistakes are invaluable.
Leverage staff with hands-on experience
Brains beat documents almost every time.
Don’t ignore the inputs just because you have more experience.
“Boots on the ground” is good (face to face contact and side-by-side working if possible)
Pictures and images (history, mistakes, examples) are critical to success.
The Key is to leverage the incentives, strengths and expertise of the interested parties to maximize success.
Set a clear framework for discussion
Leverage the history (documentation and people)
Make sure to get the sides together as often as needed.
Set a precedent for future collaboration
Don’t partition the process from design, technology from product development.
Make sure that everyone is gaining something from the collaboration.
What is Success? When are we done?
Companies can have the wrong expectations around the end point
Creating clear, quantifiable and measureable milestones to avoid “creep”
Measures for success should be agreed upon up front, but are generally further out than the parties initially assume.
MEMS design and development isn’t done until the design has successfully transferred into production. If you can’t make it at sufficient yield to meet your requirements, it’s not done.
Fab transfer is not done when first samples are completed.
This is only the first main milestone of transfer.
Transition of a design or core technology may be a one time event.
You are done when the process works or the prototypes are replicated for the first time.
In the production context, success may be measured in yield or volume/capacity met.
Can the back-end impact the success of a tech transfer in the foundry? Focus on producing the final product in final format and qualifying that.
A good tech transfer is never “done.”
It is only the first step of the next development activity.
The specifics may depend on the product requirements, but in the end the main measure is whether you can build what you need in sufficient volume and at a cost point to support the market.
Tasks, Schedules, Milestones, Budget issues
Can a generic set of tasks be described (at a high level)
What type of milestones make sense
Expectations and Responsibilities
Lay out clean/clear communication guidelines for tech transfer re. responsibilities of each party (especially important on fab-side); create a checklist
Expectations and priorities of both sides of the transfer need to be aligned
Ongoing process - Need to return to the list of expectations/responsibilities
How can you incentivize all parties to engage for maximum success?
IP management is critical, but overzealous pursuit of IP can be an innovation and collaboration killer.
How do you maximize openness and collaboration while protecting all parties?
Know your partners and understand their motivations.
Set boundaries and partition areas of expertise:
Typically “Design” vs “Process” but this is not always true.
Identify the strengths of the parties and be sure to claim your own.
Come in the door with a clear summary of what you are bringing to the table: Be prepared!
What agreements should be drawn up
Recommendations on how to minimize risk
Is it a “clean” transition? Buying or selling rights
A contractual arrangement that maintains rights? Foundry transfer, licensing, etc
IP issues can be a burden to collaboration but is still a critical thing to maintain.
What is the value of “Joint IP” vs IP partitioning (design vs process)
General feeling is that it’s easiest and best to avoid joint IP.
Need to set expectations up front.
Can’t really expect to transfer “process trade secrets”.
How do you maximize openness and collaboration while protecting all parties?
Set the framework – what’s in scope, out of scope and where you “draw the line”; how do you document and record; notifications between the parties; management of IP filings and ownership
Design Issues (this is not about design transfer)
This Wiki does not address design transfer except as it relates to the fact that design may need to be changed
How do you define the design (a transfer of a design) and to manage the challenges that will come up as you move along
Problems in design discovered during transfer
Problems in fab requiring design changes
A discussion of these issues and how process and design are related
What Documents should be exchanged – a checklist
Document, Document, Document:
Demand drawings, pictures, collections of information
Brains tend to forget details without a good archive of information…
CAD tools and design kits aid in documenting transfer
Case studies of successful/unsuccessful tech transfer:
How can we learn from past experiences in industry and is there a better way?
Describe in this section any best practices
Test Early, do your failure analysis
Detailed, documented description of deliverables
Clear set of quantifiable, measurable, and relevant milestones and method to monitor
Up-front IP ownership and information sharing agreements.
List of documents referred to in this Wiki
M2M Meeting Notes
MEMS Foundry Guide Wiki
Technology Development Protocol
A.M. Fitzgerald website
Dirk Ortloff’s book
Checklist and Key Considerations – relates to list of what we are exchanging in tech transfer (the ultimate high level checklist – the “uber checklist")
Schedule and timeline
Equipment set defined
Success criteria defined