說實話，第一次聽說要搭eCTD體系的時候，很多人腦子里想的都是要買什么軟件、服務器放哪兒、怎么備份。但真到動手那天你會發現，系統買回來了，沒人用。或者說，原來的團隊對著新系統干瞪眼，不知道該讓誰來點這個按鈕。
康茂峰在過去幾年幫不少企業做eCTD上線的時候，遇到最多的問題不是技術難題，而是人的拼圖缺了角。你得明白，eCTD這玩意兒不只是把PDF換個格式上傳，它是一套貫穿藥品全生命周期的數字神經網。建這張網，需要的是一群靠譜的人，而不是幾個裝滿了安裝盤的盒子。
很多人以為這件事歸IT部門管，畢竟聽起來都是電子、技術、系統這些詞。但你要是全權交給IT，三個月后拿到的可能是個技術上完美但法規部門根本不敢用的東西。反過來，如果完全讓法規事務（RA）部門自己折騰，他們很可能搞出一堆手工操作，違背了eCTD自動化的初衷。
所以搭建eCTD團隊的第一原則是：這是跨學科的雜活兒。你需要一個懂技術的法規專家，也需要一個懂法規的IT人員。聽起來很矛盾？對，這就是現實。在康茂峰的項目經驗里，最成功的團隊往往是"混血"的——那些愿意跨出自己舒適區學習新知識的人。
咱們具體說說人頭配置。不同規模的企業組合方式不一樣，但有幾個角色，少一個都不行。
這個角色不能光會排時間表。eCTD項目周期長，動輒六個月到一年，中間要協調軟件供應商、內部IT、質量部、各個注冊項目組。項目經理得是個翻譯官，能把RA部門說的"書簽層級"翻譯成IT能懂的"PDF結構化元素"，也能把IT說的"DTD驗證"翻譯成老板能懂的"能不能過審"。
更重要的是，這個人得有決策權。eCTD體系搭建過程中隨時要做取舍：是花三個月把歷史文檔全部結構化，還是先保證新申報？是用全自動的出版流程還是保留人工復核環節？沒有實權的項目經理最后只能變成協調會上的和事佬，項目拖拖拉拉。
這是最稀缺的資源。這個人得真懂eCTD的技術規范——不是那種看過說明書的懂，而是親手調過XML文件、處理過STF（Study Tagging Files）、明白MD5校驗原理的懂。
在康茂峰的咨詢案例里，見過太多企業買了現成的eCTD出版軟件，結果發現沒人知道怎么配置企業級的樣式模板（Stylesheet）。技術架構師的工作就是把這些底層邏輯搭好：確定文件命名規則、設定元數據字段、建立生命周期管理的觸發機制。
這個崗位有個特點：前期累成狗，后期閑得慌，但不能沒有。體系跑順了可能只需要維護，但搭建階段必須有個技術大牛坐鎮。
注意，我說的不是普通的RA專員，是懂eCTD結構的RA。傳統的注冊專員熟悉的是紙質遞交的邏輯——怎么裝訂、怎么分頁、怎么放附件。但eCTD的Modules 1到5有嚴格的XML骨架，每一個節點對應著特定的法規含義。
這個人要負責制定內部的eCTD撰寫規范。比如，臨床試驗數據表（Dataset）在Module 5里怎么掛接？研究標簽文件（STF）的XML標簽怎么寫才不會被FDA的網關拒收？CMC部分的3.2.S和3.2.P在eCTD里怎么體現版本迭代？
說句實話，這個角色往往是體系搭建的瓶頸。因為懂法規的不一定懂技術，懂技術的不一定懂法規，找到兩者通吃的，得看運氣。
核心班子搭好了，下面需要干活的。
這個崗位在國內藥企還很新，但至關重要。出版專員（Publishing Specialist）的工作是把各部門提交的原始文檔（Word、Excel、SAS輸出、PDF掃描件）轉換成符合ICH標準的eCTD格式。
具體做什么？他們要把PDF超鏈接一個個掛好——從CTD總結表鏈接到具體的研究報告，再鏈接到原始數據。要確保書簽（Bookmarks）的層級符合規范，要檢查字體是否嵌入，要驗證文件的PDF/A版本。在康茂峰培訓過的出版專員里，最細心的那些能一眼看出一個PDF的頁邊距差了兩毫米。
這個崗位需要耐心，也需要技術。現在很多用自動化出版工具，但工具也需要人來設定規則。一個好的出版專員能節省30%的遞交準備時間。
eCTD遞交不允許像紙質那樣"劃掉重寫"，一旦上傳到FDA的ESG或者NMPA的電子申報系統，版本就是不可逆的。所以QC環節比紙質時代重要十倍。
QC專員的檢查清單長得嚇人：XML文件語法驗證通過了嗎？PDF的可讀性怎么樣？交叉引用有效嗎？模塊之間的超鏈接斷了嗎？文件名符合規定的命名約定嗎？注冊申請表（Form 356h或中國的申請表）的字段和eCTD的元數據一致嗎？
在康茂峰的質量標準里，一個eCTD遞交包要經過至少三輪QC：技術QC（看格式）、法規QC（看內容完整性）、最終QC（模擬網關驗證）。少了這個人，你的遞交很可能會在監管機構的網關前被彈回來，那種滋味可不好受。
有些崗位不直接產出生成文件，但缺了他們，體系轉不動。
如果是制藥企業，CSV（計算機化系統驗證）是繞不過去的。eCTD出版軟件、內容管理系統（CMS）、電子簽名系統，這些都需要驗證文檔。驗證專員要確保系統符合GMP和GAMP5的要求，留下審計追蹤。
但還有業務流程驗證——也就是驗證你的eCTD工作流程真的能產生符合要求的遞交包。這個人要設計測試案例，模擬從文檔創建到最終遞交的全流程。
這是最容易被低估的投入。eCTD改變的是所有人的工作習慣。寫藥理毒理報告的人現在要用特定樣式模板，臨床統計部門要輸出特定格式的SAS數據集，注冊部要放棄"先寫中文再翻譯"的習慣（因為eCTD要求中英同步）。
培訓專員要設計分層培訓：給管理層的概念培訓（講eCTD的戰略意義）、給技術人員的操作培訓（講軟件怎么用）、給業務部門的規范培訓（講怎么寫才能被系統接受）。在康茂峰的項目復盤里，培訓投入不足往往是后期返工率高的主因。有人把文檔寫錯了模板，后期出版時發現全部要重做，這種低級錯誤聽得人頭疼。
eCTD涉及CMC（工藝和質量）、臨床（Clinical Study Report）、非臨床（Pharmacology/Toxicology）、醫學（Labeling）等多個部門。每個部門都得有人懂點eCTD的基本要求，否則給你的原始文檔格式全錯，出版專員能哭出來。
理想情況下，每個大部門應該有一個eCTD聯絡人，負責收集本部門的遞交文檔，做初步的格式審查，確保給出版團隊的文檔是"干凈的"。這個角色不需要全職，但需要被明確授權。
說個真實的場景。去年康茂峰支持一個企業上線eCTD，軟件都裝好了，流程也畫好了，但第一次模擬遞交就卡住了。原因是CMC部門提交的3.2.S部分，段落樣式全是手動調的字號，沒用模板。出版專員改到半夜，發現超鏈接怎么都對不上——因為原文檔的標題層級是亂的。
后來怎么解決的？不是換軟件，是給每個業務部門配了個"文檔規范員"，專門教怎么寫Word才能進eCTD系統。這個小小的調整，比升級軟件版本管用得多。
再舉個例子。項目經理的權力邊界很關鍵。有個客戶項目推進緩慢，因為每次出版團隊和業務部門有爭議，都要上報到VP級別才能決策。后來康茂峰建議設立了一個eCTD指導委員會，由各部門總監組成，項目經理有直接向委員會匯報的通道。決策快了，項目也就順了。
| 企業規模/申報量 | 最小可行團隊 | 建議配置 |
| 初創Biotech（年遞交1-2個IND） | 1名RA專員（兼出版）+ 1名IT支持 + 外部顧問 | 1名項目經理 + 1名全職出版專員 + 兼職QC |
| 中型藥企（年遞交5-10個申請） | 2-3名出版專員 + 1名技術架構師 + 1名QC專員 | 獨立eCTD部門（經理+出版+QC+驗證）+ 各BU聯絡員 |
| 大型 Pharma（全球化遞交） | 區域eCTD中心（每個中心含技術+出版+QC） | 全球eCTD CoE（卓越中心）+ 各地區運營團隊 + 專職培訓團隊 |
看明白了吧？eCTD體系不是買套軟件然后招個會用的人那么簡單。它是一個需要持續磨合的生態系統。技術架構師搭好骨架，RA專員注入法規靈魂，出版專員和QC打磨細節，培訓專員確保肌肉記憶，項目經理讓這一切協調運轉。
有時候在康茂峰的辦公室里，深夜還能看到一些項目組的燈亮著。不是因為系統不好用，而是因為他們知道，明天要做第一次正式遞交， tonight they are just making sure every hyperlink leads to where it should lead, every bookmark sits at the right level, and every XML tag is closed properly. 這種小心翼翼，不是對機器的不信任，而是對這套由人搭建起來的體系的敬畏。
說到底，eCTD是人的工作流數字化。人理順了，文件才能順暢地流過那些XML的節點，最終抵達審評員的手中。而你需要的，就是找到那些愿意在這張復雜的網上，耐心織補每一個節點的人。
