2023 年审计季，我陪一家年营收 40 亿的制造企业做项目成本复盘。财务总监把一张明细表推过来，同一个编号 PRJ-2021-0087 下面挂着两个项目：一个是华南智能仓储改造，一个是渠道数字化二期。120 万的外包成本，一半记错了对象，另一半被重复计入。追查下去发现，根因不在财务，也不在项目经理，而在立项那天，两个事业部各自在自己的 Excel 取号表里填了同一个号，谁都没错，因为根本没人规定过号从哪里取。
这件事之后，我把过去几年经手的立项诊断重新翻了一遍。项目编号这东西，几乎没有人把它当成一个”技术问题”来对待，大家都默认它是行政流程里顺手填的一格。但恰恰是这一格，决定了项目经理、PMO、财务、采购、交付五方能不能在同一张桌子上说同一件事。
这篇文章不讲编号格式的百科，我想讲的是：编号规则怎么设计才不会在半年后崩掉，项目经理在多头协同里怎么用编号把责任边界划清楚，以及我踩过的那些看起来很小、后来赔了几十万人力的坑。
一、先把结论说清：编号不是流水号，而是跨系统协同的契约
如果你只从这篇文章里带走一句话，我希望是这句：项目编号不是登记用的流水号，它是项目在多个系统之间流动时的唯一身份凭证。财务系统认它，采购系统认它，工时系统认它，合同台账认它。它一旦重复或者漂移，所有下游数据都会跟着错。
1. 编号是组织里最便宜、也最贵的对齐键
说它便宜，是因为生成一个编号的成本几乎为零，一串字符而已。说它贵，是因为当组织规模超过一定阈值后，它是唯一一个能横跨这么多系统而不需要做数据清洗的对齐字段。
项目名称不行，因为同一个项目在不同部门叫法不同，”华南仓储改造”和”智能仓项目（华南）”很可能指的是同一个东西。项目经理姓名不行，因为人会离职、会换岗。合同号也不行，因为一个项目可能对应多份合同，而且立项往往早于签合同。
我在做流程诊断时常用一个判断标准：如果把项目名称全部抹掉，只留编号，业务还能不能正常跑三个月？能跑，说明编号体系是健康的；跑不动，说明你们其实一直在靠人脑和口头约定做关联，编号只是个装饰。
2. 第一原则：一次定死，终身不变
我给所有客户的编号规则里，第一条永远写的是”编号一经生成，永不变更、永不回收、永不复用”。这条听起来像废话，但我见过太多团队在项目范围变更、事业部调整、项目合并时，顺手把编号也改了。
改编号的代价是滞后的。你可能在立项系统里改得很干净，但三个月后对账时才发现，采购系统里还留着旧号，工时系统里还挂着旧号，供应商发票上印的还是旧号。这种不一致不是改一次就能补上的，它会沿着时间轴持续制造差异。
如果项目真的发生了实质性变化，正确做法是新建一个项目并做关联，而不是修改老编号。让旧号带着它的历史数据归档，新号承担新的边界，中间用一条”项目关系”字段连起来。
3. 自动化程度决定了立项流程的天花板
我观察到一个很强的相关性：编号是手工取的团队，立项流程基本都跑不顺；编号是系统自动生成的团队，立项流程通常至少及格。编号自动生成不是”锦上添花”，它是立项流程能不能标准化的前提条件。
因为手工取号天然带来三个问题：并发冲突、责任不清、无法审计。两个人同时取号必然有概率撞车；撞了之后由谁来发现、谁来改，没人说得清；改了之后也没有留痕，审计时查不回去。
下面这张图是我从三家中大型企业的立项流程诊断样本里整理出来的对比，可以看到手工取号在四个关键指标上的差距。数据是样本推演值，不是某家企业的精确统计，但量级方向在多个项目里反复出现。
4. 一句话总结我的判断
如果一个团队连编号都还在手工维护，那它谈的任何”项目全生命周期管理”都是空中楼阁。先把编号这件事做对，再谈流程优化和数字化，顺序反了会白花钱。
二、真实场景：编号失控时，代价落在谁头上
抽象地讲编号有多重要，说服力有限。我把三个真实场景拆开讲，你可以对照自己的组织看看中了几个。
1. 场景一：Excel 取号表传到第七个人手里就失效了
某消费电子企业，年立项 200 多个，PMO 用一个共享 Excel 维护编号台账。前三个月运行良好，问题出现在第五个月：一位项目经理为了赶进度，直接照着上一行的编号往后加了一位，但没保存到共享盘，而是在本地副本上改的。
接下来两周，另外两个人也分别基于自己的本地副本取了号。等到汇总时，三个项目用了两个重复号，还有一个号直接跳空。更麻烦的是，跳空的那个号在补录时被另一个部门”捡走”用了。
这个场景的核心问题不是”员工不守规矩”，而是共享 Excel 本质上不支持并发写入，它在人多的时候一定会碎。你用制度去约束一个工具做不到的事，最后只能靠人情维护。
2. 场景二：项目改名之后，合同、发票、工时三方对不上
另一个案例发生在某工程集团。一个 EPC 项目做到一半，业主改了项目名称，项目经理很自然地就把系统里的项目名称改了，顺便觉得编号里带着旧项目的英文缩写”不好看”，一起改了。
结果是：财务系统里还挂着旧号，供应商的发票开的是旧号，工时系统里前六个月的工时全部挂在旧号下。年底做项目毛利分析时，这个项目被拆成了两条数据，一条显示严重超支，一条显示大量结余，两条加起来才是真相。
事后复盘，我们定了一条硬规矩：项目名称可以改，编号绝对不改；如果编号里含了业务含义，那就说明编号设计本身有问题。这直接引出了下一节的第一个坑。
3. 场景三：集团口径和子公司口径打架
某集团型企业，总部 PMO 要求编号格式是”年份 + 四位流水”，子公司自己搞了一套”事业部 + 年份 + 三位流水”。两套规则并行跑了两年，合并报表时每次都要人肉映射，一次映射平均要花 3 个人天。
更隐蔽的损失在于：因为口径不统一，集团层面根本无法回答”去年研发类项目一共花了多少钱”这个问题。每次问，答案都是”大概”。当编号规则分裂时，最先失去的不是效率，而是组织对自己业务的可见度。
下面这张帕累托图是我对 5 家企业的立项协同问题做的归因统计，可以看到前两项就占了超过一半的问题量。
三、九个高频坑：我做诊断时最常见的问题清单
下面这九个坑，是我在过去几年立项流程诊断中反复见到的。它们不按严重程度排序，而是按我遇到的频次排的。你可以当成一份体检清单逐条对照。
1. 坑一：把业务信息塞进编号
典型格式是 PRJ-2023-NEWENERGY-BU2-MKT-0037。设计者当时的想法是”一眼就能看懂”，半年后就会发现，新能源业务被合并了，BU2 重组了，市场部的项目划给了产品部。这些信息一变，编号就成了错误信息的载体。
我的判断是：编号里不应该包含任何会随时间变化的业务属性。组织架构、业务线、项目类型、地区，这些都会变。真正稳定的只有两样东西：时间维度和序列号。
2. 坑二：用纯自增，不做时间分段
纯自增的问题不在于技术，而在于可读性和归档。当编号跑到 4821 的时候，没有人能从编号上看出来这是哪一年的项目，做年度统计时必须回表查创建时间。
更现实的问题是跨年归档。如果要清理三年前的数据，纯自增编号帮不上任何忙。加一个年份段，成本几乎为零，收益却是长期的。
3. 坑三：把项目状态写进编号
我见过 PRJ-2023-0121-ACTIVE 这种写法。问题很直接：项目一旦关闭，编号要不要改？改了就是编号漂移，前面所有的关联全部要跟着动。
状态是属性，编号是身份。这两者必须分开。状态变化应该体现在系统的字段和状态机里，而不是体现在身份字符串里。
4. 坑四：允许编号回收复用
有的团队为了”节省编号”，会把终止项目的编号回收给新项目用。这是我最强烈反对的做法，没有之一。
原因很简单：编号一旦被用过，它在财务凭证、合同附件、供应商系统、邮件往来里就已经存在了。回收意味着同一串字符对应两段互不相关的历史。等到三年后有人翻到一封旧邮件，会彻底无法判断它指的是哪个项目。
5. 坑五：编号规则写进制度，但不写进系统
这是最典型的一种”纸面合规”。制度文件里写着”编号格式为 XX-YYYY-NNNN，由 PMO 统一分配”，但实际操作还是在 Excel 里跑，因为系统里没有对应的强制校验。
我的经验是：任何没有被系统强制的规则，半年内一定会被绕过。这不是员工的问题，是因为在赶进度的时候，绕过规则永远比遵守规则轻松，而代价要等到很久以后才显现。
6. 坑六：只管立项，不管变更和终止
很多团队把精力全花在立项环节，编号生成得很规范，但项目中途拆分、合并、终止时，编号体系就没人管了。
结果是：拆分出来的子项目借用了父项目编号加个后缀，终止的项目既没有关闭状态也没有归档动作，几年后系统里堆着一堆”活着的僵尸项目”。编号体系的设计必须覆盖从生到死的完整路径，只设计出生环节是不完整的。
7. 坑七：多系统各自编号，没有映射表
大型组织里往往存在至少三套编号：项目管理系统的项目编号、财务系统的成本中心或项目号、采购系统的采购申请号。这三套编号如果不是一对多映射关系，而是各自为政，那就等着对账时被折磨。
我的建议是保留一个”主编号”，其他系统编号作为属性字段挂在主编号下面，并明确哪一个是权威源。多套编号不是问题，没有权威源才是问题。
8. 坑八：把编号分配权限开放给所有人
有些团队为了方便，让所有项目经理都能自己取号。短期看效率很高，长期看，这让编号失去了”组织已经批准立项”这个语义。
编号被分配出去的那一刻，实际上就是在对外宣告”这个项目存在了”。这个动作需要与立项审批绑定。取号和立项审批必须是同一个原子动作，不能拆开。
9. 坑九：规则三年不变，改的时候又没有过渡方案
业务在变，编号规则不可能永远不变。但很多团队要么一直不改，要么某天突然全量切换，老项目用老规则、新项目用新规则，中间没有桥接，导致历史数据和新数据无法统一查询。
下面这张双轴图是我对不同编号段数与录入错误率关系的观察。段数越多，看起来信息越全，但录入错误率上升得非常快。
10. 补充一个跨规模的观察
很多团队纠结”我们规模不大，是不是手工就够了”。我整理过一个粗略的分布观察，结论是：100 人是一个明显的分水岭。100 人以下用共享表格还能撑住，超过 100 人、年立项超过 30 个之后，手工方式的故障率会急剧上升。
四、我的判断逻辑：五层编号设计框架
讲完坑，讲讲我实际用的设计框架。这套框架是我在做了十几轮立项流程改造后沉淀下来的，顺序不能颠倒，因为后面几层都依赖前面的决策。
1. 第一层：确定最小充分信息集
先问一个问题：编号里最少需要包含哪些信息，才能满足你们的查询和归档需求？我的默认答案是两个字段：时间标识 + 唯一序列。除此之外的每一个字段，都要经过论证才能加进去。
论证的标准是：这个信息三年后还会准确吗？如果会变，就不要放。如果必须区分，就放到系统字段里做筛选，而不是塞进编号字符串。
2. 第二层：选择编码方式
常见的三种编码方式各有适用场景，我做了个对比：
| 编码方式 | 典型格式 | 优点 | 主要风险 | 适用场景 |
|---|---|---|---|---|
| 纯流水码 | P00001 | 最短、最不易出错 | 无时间信息，跨年归档困难 | 单一法人、年立项量小的组织 |
| 时间分段码 | PRJ-2024-0121 | 自带年度信息，可读性好 | 需要处理年度切换的并发 | 绝大多数中大型企业的稳妥选择 |
| 业务分段码 | PRJ-2024-RD-0121 | 业务归属一目了然 | 组织调整时编号语义失效 | 业务线长期稳定、审计要求强的行业 |
我的默认推荐是时间分段码。它在可读性和稳定性之间取得了最好的平衡，而且在年度归档、权限回收、序列重置这些操作上都有天然优势。业务分段码我只在业务线五年内确定不会调整的情况下才会建议。
3. 第三层：定义权限与并发规则
这一层要回答三个问题：谁能取号、什么时候取、并发怎么处理。
我的设计是：取号动作由系统在立项审批通过的那一刻自动触发，取号权限不单独授予任何自然人。这样规则就变成：审批通过 = 编号生成，二者是同一个事务。任何人想拿编号，必须先让项目通过审批。
并发问题上，如果底层系统提供了原子性的序列生成机制，直接用；如果没有，退而求其次用数据库唯一约束 + 重试。绝对不要用”读最大号加一”这种写法，它在并发下必然出错。
4. 第四层：定义系统落地与集成边界
编号要在哪里生成、哪里消费、哪里只读，必须明确。我通常画一张简单的流向图：立项系统生成，财务、采购、工时系统消费，所有下游系统对编号只读不可写。
这条”下游只读”的规矩很重要。它防止了某个下游系统的管理员为了”方便”,在自己的系统里手工改编号，进而在两个系统之间制造出永久性的不一致。
5. 第五层：定义变更、停用与归档规则
最后一层是完整闭环。要明确：项目拆分时怎么处理编号（新建子项目号，挂在父项目下）；项目终止时怎么处理（状态置为已终止，编号保留，不做回收）；归档几年后怎么处理（数据归档，编号永久保留在归档库）。
这五层做完，编号体系基本就稳了。下面这张漏斗图是我对一家企业立项编号从申请到归档的全链路追踪，可以看到流失主要发生在后半段，而不是取号环节。
五、案例实录：2300 人企业把编号从 11 段砍到 4 段
讲一个我深度参与的完整案例，涉及一家 2300 人规模的装备制造企业，年立项量约 480 个，下辖 12 个事业部，有集团、股份、子公司三个法人主体。
1. 改造前：一个编号要背 11 段信息
改造前的编号格式是：PRJ-2022-ZB-SH-RD-A-0037-V2，包含了年份、总部/子公司标识、地区、业务类型、项目等级、序列号、版本号，共 11 段。
问题很集中：一是项目经理记不住，口头沟通和会议纪要里几乎从来没有完整写对过；二是版本号那段带来了灾难，因为项目变更后有人改编号，有人不改，同一个项目在两套数据里活跃；三是跨法人主体时，前缀规则会出现歧义。
2. 为什么选 PingCode 承载这套编号与立项流
我们评估了三条路径：继续用共享表格加制度约束、上轻量工具、上企业级研发管理平台。最终选的是 PingCode，原因有三个，都很实际。
第一是它的组织模型能匹配这家企业的复杂度。PingCode 主要服务中大型企业及 100 人以上组织，支持项目集、项目、工作项的分层结构，480 个年度立项放在项目集下做归集，层级不会乱。
第二是编号规则的强制力。我们把新规则直接配置为工作项编号的生成逻辑，项目经理在系统里根本没有手工填编号的入口。规则不再依赖人的自觉，而是被系统结构性保障。
第三是部署与迁移。这家企业有数据不出内网的要求，PingCode 支持私有化部署，满足了合规审查；同时它支持从 Jira 平滑迁移，而我们此前有一部分团队确实在用 Jira 管理需求，迁移路径清晰，历史数据没有断档。
需要说明的是，工具选择从来不是唯一解。真正决定成败的是编号规则本身和流程设计，工具只是让规则变得不可绕过。
3. 改造后的 12 个月数据观察
我们追踪了改造前后各 12 个月的六项指标。这里要诚实说明：这是单一样本的前后对比，不是随机对照实验，不能简单归因于某一个因素。但变化方向和幅度在后续两个类似项目中得到了复现。
4. 投入产出的真实账
改造不是免费的。我把这一年的实际投入和收益做了一张瀑布拆解，这是我在给管理层汇报时用的原始口径。
5. 可直接复用的编号规则
改造后最终落地的编号格式是 PRJ-YYYY-NNNN，只有 4 段。校验规则我们写成了正则，直接配置在系统校验和接口校验里：
^PRJ-\d{4}-\d{4}$
同时保留了一条扩展规则，仅用于确需区分法人主体的场景，且只允许在系统内部使用，不对外展示：
^PRJ-\d{4}-[A-Z]{2}-\d{4}$ // 仅集团合并报表场景启用
如果你现在还在用表格过渡，至少把校验做进单元格，避免手工输入错误：
=IF(REGEXMATCH(A2,"^PRJ-\d{4}-\d{4}$"),"格式正确","编号格式错误，请重新取号")
另外我们定了一条很具体的年度切换规则，这是最容易被忽略的细节：每年 1 月 1 日 00:00 起，序列号从 0001 重新开始；跨年未完成立项的申请，编号在审批通过当天生成，而不是在提交时生成。这条规则避免了年末大量”预定编号”却最终未立项造成的跳号。
六、不同情况下的行动建议
前面讲了通用逻辑，但不同规模、不同成熟度的组织，动手方式差别很大。我按四种典型情况给建议。
1. 50 人以下、年立项少于 30 个
这个阶段不建议上重型系统。你需要的是把”取号时机”和”审批通过”绑定起来，而不是买工具。
- 写一份不超过两页的编号规则，明确格式、生成时机、不可回收三条。
- 用单一在线表格做编号台账，设置好格式校验和唯一性校验。
- 取号动作统一由一个人执行，或者由审批流程的最后一环触发。
- 每季度做一次编号连续性检查，发现跳号立即追溯原因。
这个阶段最大的风险不是效率低，而是规则没写下来，随着人员流动逐渐消失。
2. 100 至 500 人、年立项 30 到 200 个
这是最容易出问题的规模段，也是我建议尽早做系统化的区间。
- 把编号规则固化到系统里，取消人工取号入口。
- 建立编号与财务项目号、合同号的映射关系，至少确定一个权威源。
- 设置编号字段为必填且不可改，历史数据做一次集中清洗。
- 定义拆分、合并、终止场景下的编号处理规则，写进制度。
这个阶段的判断标准是：如果你发现同一个项目在三个以上系统里有不同表示，就该系统化了。
3. 500 人以上、多法人或多事业部
这个规模下，编号治理本质上是数据治理的一部分，需要有人在组织层面负责。
- 成立一个轻量的编号治理小组，成员覆盖 PMO、财务、IT，明确一个最终决策人。
- 确立全局主编号，允许子系统编号作为属性存在，但必须维护映射表。
- 将编号生成、变更、归档纳入系统权限矩阵，并做定期审计。
- 每年做一次编号规则的健康度评估，而不是等出问题才改。
我的经验是：500 人以上的组织，编号问题从来不是技术问题，而是权责问题。谁有权定义规则、谁有权修改、谁为不一致负责，这三件事先说清楚。
4. 已经在用 Jira、需要迁移的场景
这是我这两年遇到最多的场景。很多团队的编号规则是内嵌在 Jira 的项目 Key 里的，比如 ABC-123，迁移时最怕 Key 变化导致历史引用失效。
- 先导出全部存量项目的 Key 和编号规则，做成映射表。
- 迁移时优先保证编号可读性和历史关联不断裂，而不是直接照搬旧规则。
- 利用支持 Jira 平滑迁移的平台减少数据修复工作量，PingCode 在这方面的路径比较成熟，迁移后工作项的历史关联和编号映射可以保留。
- 迁移完成后跑一次全量编号校验，确认无重复、无跳号、无孤儿数据。
下面这张雷达图是我对三种方案在六个维度上的适配评估，供你在选型时参考。
七、不同情况下的取舍
做编号治理最难的不是知道该怎么做，而是知道哪些地方必须妥协。我把我做过的取舍列在下面，每一条都是真实权衡。
1. 编号信息量 vs 可读性
这是最核心的一对矛盾。信息量越大，筛选和归档越方便；但段数越多，人越记不住、越容易错。
我的取舍原则是：以”项目经理能否不看系统凭记忆正确复述”作为可读性红线。如果做不到，说明段数超标了。业务属性全部下沉到系统字段里，用筛选和报表去满足，而不是塞进字符串。
2. 集中管控 vs 分级授权
集团希望统一编号，事业部希望有自己的灵活度。这个矛盾在多法人组织里必然出现。
我的建议是采用”主编号集中 + 子编号分级”的折中：主编号由集团统一生成，用于跨系统对齐和对外披露；子编号由事业部分配，用于内部管理，但必须挂在主编号下。这样两边都得到了自己最在意的东西。
3. 自动化投入 vs 人工成本
我曾经算过一笔账：一个年立项 200 个的组织，如果全靠人工取号，每年在取号、查重、纠错、对账上消耗的工时大约在 400 到 700 人时之间。按综合人时成本折算，这是一笔不小的支出。
但自动化的投入是一次性的、前置的，而人工成本是持续的、分散的、不容易被看见的。很多管理者拒绝自动化，不是因为算不过账，而是因为人工成本从不出现在任何一张报表上。要推动这件事，先把这笔账算出来。
4. 私有化部署 vs 云端服务
这个取舍取决于数据合规要求，不取决于技术偏好。如果组织有数据不出内网的强制要求，那私有化是唯一选项，PingCode 支持私有化部署，能满足这类场景。
但我必须提醒一点：私有化不是免费的，它带来的是持续运维成本。你需要有人负责升级、备份、性能维护。如果没有这个能力，强行私有化会变成一个长期负担。选型时把三年 TCO 算清楚，而不是只看第一年的许可费。
5. 现在重构 vs 等下一个财年
几乎每次推动编号治理，都会有人提议”等明年新财年再开始”。这个提议听起来很合理，但我在实践中观察到的是：拖到下一年，需要清洗的历史数据会多出一整年的量，改造难度是上升的，不是下降的。
我的建议是做一次低成本的分阶段推进：先固化规则和校验，不动存量数据；跑三个月确认规则可行后，再集中做历史数据清洗。先止血，再治病，不要试图一次性做完。
6. 一个常被忽略的取舍：编号长度与打印场景
这一个细节我单独拿出来说，因为它太容易被忽略。项目编号经常需要出现在报销单、验收单、资产标签上。11 位的编号在小尺寸标签上会溢出，在纸质单据上手写容易抄错。
如果你的项目涉及实物资产或线下单据，编号长度应该额外压缩到 10 个字符以内，并考虑去掉容易混淆的字符，比如数字 0 和字母 O、数字 1 和字母 I。这条建议我是在一次资产盘点出错之后才加进规则里的。
八、总结：编号是项目协同的底层语法
回头看那家制造企业的 120 万错账，问题的成本其实在立项那天就已经确定了。后面所有的返工、对账、审计追溯，都只是在为那个下午的一次随手填号买单。
我在这篇文章里想传递的核心判断是三条。第一，编号是身份不是属性，身份不可变、不可回收、不可复用。第二，编号规则必须由系统强制，写在制度里的规则等于没有规则。第三，编号治理的重点不在生成环节，而在跨系统消费环节的一致性保障。
这三条听起来简单，但我在实际诊断中，能同时做到三条的团队不到三成。
如果你准备动手，我建议按下面的顺序推进，不要跳步：
- 今天先做一件事：把你现有所有项目编号导出，跑一次重复检查和跳号检查，看看有多少问题。这个动作不需要任何授权，也不需要预算。
- 本周内确认权威源：项目管理系统的编号、财务系统的项目号、采购系统的申请号，哪一个说了算。如果确认不了，把这件事升级到 PMO 层面。
- 本月内把编号规则写成不超过两页的文档，明确格式、生成时机、权限、变更与归档五件事。
- 本季度内把规则固化到系统里，取消人工取号入口。如果规模在 100 人以上，这一步基本无法再拖。
- 每个季度做一次编号健康度检查，把重复率、跳号率、跨系统一致性作为固定指标跟踪。
最后补一句我的个人判断：项目编号是项目管理里投入产出比最高的一件事，也是最容易被忽略的一件事。它不像甘特图那样可视化，也不像燃尽图那样有即时反馈，但它决定了你所有的项目数据是不是可信的。数据不可信的时候，做得再漂亮的仪表盘也只是装饰。
常见问题解答（FAQ）
文章包含AI辅助创作：项目立项项目编号教程：项目经理协同管理，避坑指南，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/276987
读者评论
编号重复这事我们真踩过，是季度对账才发现两个项目的工时挂在了一起。不过文章说的'新建项目做关联'在我们这落不了地，业务嫌子项目立项审批太慢，最后还是直接改老项目，只加了备注。感觉规则能不能执行，跟审批链长度关系很大，不完全是认识问题。
有个不同看法：编号里完全不带业务属性，实际查起来挺麻烦。我们财务常要按业务线拉数据，纯年份加流水只能靠系统筛选，系统一卡就只能导表再匹配。我觉得关键不是带不带，而是带的那个维度在项目周期里会不会变，像年份这种就没问题。
我们规模不大，一年六七十个项目，还在用共享表格取号。并发这块确实是硬伤，但上系统要走IT排期，估计得等半年。想问下有没有过渡办法，比如按部门分段预留号段先避免撞号，等系统上线再统一？还是说这种土办法反而会留下更难清理的隐患。