研发项目管理系统，买成熟的还是自己搭

买了软件用着用着发现和自己的管法对不上，系统里填一遍、线下走一遍，半年后报表没人信。本文给出标准能买、独有要搭、要复制优先搭三个判断，重点在混用时的数据边界：项目号只能有一个源头，节点上的必须留存项决定了要建几张表单。

买回来的软件为什么会用成两套账

研发项目从预研、立项、计划到交付物、评审、结项，节点多、周期长。

成熟软件带的是行业通用做法。你公司的评审谁参加、里程碑怎么算完成、交付物要不要归档签字，软件里的那套不一定对得上。

对不上以后，一线会选最省事的路：系统里按软件的规则填一遍，线下再按公司的真实管法走一遍。半年后系统里的进度和实际差得越来越远，领导看报表不敢信，还是开会问。

要不要用低代码搭，问题不在软件好坏，在你的流程能不能被这个软件装进去。

三个判断

情形	建议	理由
流程标准、行业通用	买成熟软件更省事	方法论别人已经做过，自己搭反而缺经验
流程是自己独有的，还经常调整	在低代码平台上搭	改配置当天生效，不用等厂商排期
要和现有系统深度打通，还要在集团里复制	搭的优势更明显	应用和接口在同一套平台上调整，复制时改的是配置

流程走向：

• 你的研发流程 → 流程是否行业通用
• 流程是否行业通用 →（通用）是否需要与现有系统深度打通
• 流程是否行业通用 →（独有且经常调整）平台搭
• 是否需要与现有系统深度打通 →（否）买成熟软件
• 是否需要与现有系统深度打通 →（是）是否要在集团内复制
• 是否要在集团内复制 →（三家以内）买 + 接口补齐
• 是否要在集团内复制 →（多且各家有差异）平台搭
• 平台搭 → 模板统一 + 差异做附加项

第二个判断最容易被高估。很多团队认为自己的流程很特殊，把审批链画出来发现八成的节点和通用软件一致。真特殊的地方通常在节点之间的跳转条件上，比如评审不通过要回到哪个节点、要不要重新排期。

第三个判断要看集团规模。三家子公司和三十家子公司不是一回事，要复制就得考虑每家改什么、集团统一什么，这件事在低代码平台上做，模板和差异能分开管。

买和搭混着用怎么划界

更多企业是混着来的。划界我建议守两条。

软件管研发过程本身，任务、交付物、评审记录这些标准动作留在软件里，别把它拆散。搭出来的应用管软件管不到的两头：前一头的预研立项申请、后一头的结项费用归集与成果归档，加上中间的例外流程，比如临时插项、跨部门借人。

两边的数据靠接口对齐，项目号必须只有一个源头。项目号在两套系统里各生成一遍，是所有对不上账的起点。

CREATE TABLE rd_project (
  project_no     VARCHAR(32) PRIMARY KEY,  -- 唯一源头，另一侧只读引用
  source_system  VARCHAR(16) NOT NULL,     -- RD_TOOL / PLATFORM，登记在哪边生成
  project_name   VARCHAR(128) NOT NULL,
  phase          VARCHAR(16) NOT NULL,     -- PRE_STUDY / APPROVAL / EXEC / REVIEW / CLOSE
  budget_amount  DECIMAL(18,2),
  owner_user     VARCHAR(64) NOT NULL,
  company_scope  VARCHAR(64)               -- 复制到其他单位时的归属
);

CREATE TABLE rd_milestone (
  project_no  VARCHAR(32) NOT NULL,
  node_code   VARCHAR(16) NOT NULL,
  plan_end    DATE,
  real_end    DATE,
  gate_status VARCHAR(16) NOT NULL,        -- OPEN / PASSED / REJECTED
  back_to     VARCHAR(16),                 -- 评审不通过回到哪个节点
  PRIMARY KEY (project_no, node_code)
);

CREATE TABLE rd_review_issue (
  issue_id    BIGINT PRIMARY KEY,
  project_no  VARCHAR(32) NOT NULL,
  node_code   VARCHAR(16) NOT NULL,
  closed_at   DATETIME                      -- 未关闭就推进下一阶段，报表要能查出来
);

back_to 和 gate_status 两列值得单独说。跳转条件是通用软件最常缺的东西，也是自研应用最有价值的一段。rd_review_issue.closed_at 为空但项目已进下一阶段，就是"问题还开着就往下走"的证据。

不管买还是搭，节点上要留下的东西

阶段	谁发起	系统里必须留下	常见断点
预研	研发人员	可行性结论	结论只在会上说过
立项	项目经理	预算、里程碑、评审意见	预算和计划分开在两套表里
计划与执行	项目组	任务、交付物、变更记录	变更不走审批
阶段评审	技术或质量委员会	问题清单和关闭情况	问题还开着就进下一阶段
结项	项目经理	成果归档、费用归集	交付物没齐也结了

这张表决定了软件的配置工作量，也决定了搭的应用要建几张表单。买软件的人经常跳过这一步，直接看厂商演示，演示里一切顺，落到自己那张立项单上就发现字段没有。

一家医药集团的实验室项目管理

一家医药集团的研发型实验室项目管理就是在 Dolphin Code 低代码平台上搭的。总部先用起来，再做成应用模板，复制到集团里的其他单位，各家按自己的审批链调整。

这里值得抄的是顺序。先在总部把流程跑通，把哪些字段必填、哪些节点会卡人摸清，再谈复制。一上来就按集团统建，各家需求先吵三个月，模板还没定就已经过时。

复制的落地形态是模板加附加项：模板定义必填字段与主流程，各单位只允许追加字段和调整审批人，不允许改必填项。放开改必填的后果是集团报表在两年后彻底没法汇总。

动手之前先验证两件事

选成熟软件，让对方按你真实的立项单做一次录入，看必填字段和跳转条件能不能改。选搭的路，请厂商用你的一个真实项目现场配一条流程，看从字段到审批链要多久能跑起来。

上线检查清单

• 项目号的生成方唯一，另一侧字段只读，接口不做双向创建
• 评审不通过的返回节点与是否重新排期已配置，并做过一次实例验证
• 阶段评审未关闭的问题会阻止进入下一阶段，或有显式豁免记录
• 模板与各单位附加项分开管理，必填项不允许在单位层修改
• 变更记录走审批，交付物未齐时结项动作不可执行
• 用去年结项的三个项目做差集：实际走过的节点与立项时定的节点差在哪
• 用真实立项单在目标软件里录一次，字段缺口列成清单

关于得帆智能

得帆智能成立于 2014 年，目前拥有 2100+ 家大型企业客户和 2400+ 个落地项目。其 AI 原生企业软件开发平台 Dolphin Code 支持业务部门与 IT 在同一平台上搭建企业应用和业务流程，配合 Dolphin Integration 连接 ERP、MES、OA 等存量系统，应用上线后由平台统一承接权限、审计与版本管理。

说明：本文由得帆智能整理发布，文中提到的 Dolphin Code 等产品为本公司产品。内容根据项目实施经验整理，仅作行业交流，不构成采购建议；文中表结构为示意。