技術移轉到量產：研發交得出去，工廠接得下來

春武里工業區一家做塑膠射出的台商工廠，新品量產已經進到第三週，良率還是卡在七成上下。老闆把現場主管找來問，主管攤手：模具沒問題、料號也照著開的單買，就是不知道為什麼進料溫度只要差個兩三度，成品邊緣就會出現一圈細微的縮水。

原本負責這支模的研發工程師，兩個月前家裡有事回台灣了。老闆打開他留下的資料夾，裡面只有最後定案的圖檔、一份規格書，還有幾張手機拍的試模照片。至於當初試過哪些溫度、哪一種料比配過又被放棄、為什麼最後選了現在這個參數——一個字都沒有。現場只能從頭再試一次，兩個月前那個人踩過的坑，整個團隊再踩一次。

換一個場景。曼谷一家做食品進口的貿易商，開發部門花了三個月談進一支日本進口的調味醬料，簽完約很開心，在群組裡丟了一句「新品下週到貨，大家衝業績」。業務馬上開始跑客戶，跟餐飲客戶說「常溫保存，效期兩年」。等到第一批貨進了客戶的中央廚房，客戶才發現包裝上寫的是開封後必須冷藏、而且原廠標示要另外做泰文標籤才能上架。客戶退貨，業務被罵，開發部門一臉無辜：「這些資料我當初都有拿到啊。」

一個是工廠，一個是貿易商，看起來是兩回事，其實是同一個病：東西已經開發完成了，但相關的知識只留在開發那個人的腦袋裡，沒有被正式交出去。這就是研發循環的最後一段——技術移轉。

為什麼這一段最常斷

研發循環走到這裡，前面該過的關都過了：老闆問過「這個做得出來嗎」、市場情資收過、Roadmap 排過、設計開發卡過關、BOM 整建過、測試驗證也通過了。前面六講講的都是「怎麼把東西做出來」，這一講講的是完全不同的另一件事——怎麼把東西交出去。

而這兩件事的能力，其實不是同一種。一個工程師能把產品做出來，不代表他能把做的過程講清楚給別人聽；一個開發人員能談進一支好貨，不代表他知道業務跟客服需要知道什麼。技術移轉之所以最常斷，就是因為公司通常只驗收前者，從來不驗收後者。

在內控循環的職責分工上，技術移轉這個環節的負責單位是生技（生產技術）加上研發兩個單位，權責寫得很明確：一是「研發日誌與 KM（知識管理）整建」，二是「技術、功能、賣點訓練」。

為什麼要兩個單位一起？因為交接是雙向的動作。研發是交的人，生技是接的人。如果整個過程只有交的人在動——他整理了一份資料、寄了一封信、開了一場會——那不叫交接，那叫「他自己做了一份文件」。接的人有沒有真的接住，是完全另一件事。

管理學上對這件事有個講法。日本學者野中郁次郎提出「內隱知識」（Tacit Knowledge）的概念，指的是那些存在於人的手感、經驗與判斷裡，沒有被寫下來、甚至當事人自己都說不太清楚的知識。相對的是「外顯知識」（Explicit Knowledge），也就是已經被文件化、任何人拿到都能理解的部分。

技術移轉的本質，就是把內隱知識盡可能轉成外顯知識。而中小企業最大的風險在於：一支產品常常從頭到尾只有一個人負責，公司的知識資產有很大一塊，其實是掛在幾個人的腦袋上的。

老闆通常不覺得這是風險，因為「他人還在啊」。但風險從來不只是離職。請長假、被更急的專案調走、生病、甚至只是隔了一年自己也忘了——都會讓同一條線卡住。差別只是離職一次卡到底，其他狀況卡個兩三週而已。

對買賣業與進口貿易業來說，研發循環在你們那邊叫開發循環，技術移轉的內容不是工藝參數，而是「這支貨的規格、賣點、以及不能對客戶承諾的限制」，必須正式交到業務、客服與倉儲手上。開發部門確認的東西，只有開發部門知道，前線就一定會出事——像前面那個調味醬料的例子，資料明明都在，只是沒有交出去。

怎麼做：把腦袋裡的東西交出去

1. 研發日誌是寫給下一個人看的，不是寫給自己看的

這是最關鍵、也最容易被誤解的一點。多數研發人員其實都有做紀錄的習慣，但那是「自己的筆記」——寫給自己看的東西可以只記結論、可以用只有自己懂的縮寫、可以跳過已經內化的判斷。

交接用的研發日誌完全不同。它的讀者是一個「不在現場、沒有參與過、可能是一年後才接手」的人。所以有一條原則要記住：失敗的紀錄，比成功的紀錄值錢。

成功的做法遲早會被找到，因為它就寫在最後的規格書跟圖面上。但「試過什麼、為什麼不行」如果沒有人寫，下一個接手的人一定會把那條路再走一次。前面那家射出廠賠掉的兩個月，賠的就是這個。