说实话，第一次听说要搭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的节点，最终抵达审评员的手中。而你需要的，就是找到那些愿意在这张复杂的网上，耐心织补每一个节点的人。
