T-Minus:从 T-27 到 T+30
飞行前准备,27 个工作日时钟的五个阶段及其退出标准和工件,关卡,六个工作流程,以及更大规模的部署如何通过增加波次而不是更长的阶段来实现。
从项目启动到正式上线,整个过程需要 27 个工作日,之后还有 30 天的辅导期。计算时请以工作日为准,而非自然日,并将客户的公共假期添加到“项目计划”工作簿的“设置”表中,以确保每个任务日期都是真实的。
| 阶段 | T日 | 天 | 落叶 |
|---|---|---|---|
| 飞行前 | T-27 之前 | — | 第一天时钟所需的一切 |
| 在实践中发现 | T-27 → T-18 | 10 | 适配账簿:每个缺口都标记为“立即配置”、“T-Plus”或“无需配置”。 |
| 在开放环境中配置 | T-17 → T-11 | 7 | 一个配置好的租户,每天都在客户的监督和推动下构建。 |
| 切换,已审核 | T-10 → T-3 | 8 | 已完成切换:试算表逐行与原有数据相符;试运行时间已确定 |
| 排练 | T-2 → T-1 | 2 | 彩排通过:与正式工作日同步进行——唯一可行的/不可行的决定 |
| 上线 | T-0 | 1 | 实时账簿:旧版只读,午餐前的第一张发票 |
| 教练进入状态 | T+1 → T+30 | — | 已采用的系统:超护理融入正常运营 |
飞行前准备:在计时开始之前(建议默认值)
T-27是倒计时的第一天,而不是关系的第一天。飞行前准备是对既定方法的补充:如果没有它,最初的几天就会浪费在追逐权限上,而不是在实践中探索。
| 商业的 | 人们 | 租户 | 数据 |
|---|---|---|---|
| 合同已签署;已收到经审计的收入。 | 指定倒计时所有者,并赋予当日权限 | 已提交入职表单:云平台、区域、网络、单点登录 | 对所有遗留源系统拥有读取权限 |
| 上线日期已确定并列入议程 | TRANXACT飞行主管已分配 | 租户已配置:三节点集群,数小时内即可上线 | 提取代表性样本数据用于发现 |
| 范围锚点:第一波的模块和实体 | 每个进程指定一个关键用户,并允许其参与倒计时。 | 关键用户可以登录 | 建议的切换日期和迁移范围(截至/期间)。 |
这与《技术部署指南》的契合之处在于:其提出的构建目标——包括入职表单、设计验收以及从代码构建(每个环节大约需要五个工作日),再加上五个工作日的Live DR ——都在倒计时开始前完成。倒计时的前提是环境已存在;这正是租户是预部署项目以及T-Minus没有环境构建里程碑的原因所在。
任何未勾选的飞行前检查项目都应视为不开始计时的理由。
每个阶段,以及它们的结局
| 阶段 | 会发生什么 | 退出标准 | 生产的文物 |
|---|---|---|---|
| T-27 → T-18 实践出真知 | 关键用户在自己的租户中根据代表性数据运行其真实角色;每次讨论都在实时屏幕上进行;每个差距都被记录和分类;对遗留提取进行分析;当角色看到其未来屏幕时,变更影响会被捕获。 | Fit Ledger 已完成,每一行都已标记;Countdown 所有者已签署第一批。 | Fit Ledger;迁移对象登记册(草稿);迁移范围决策;变更影响评估(初稿);利益相关者和沟通计划;RAID 日志已打开。 |
| T-17 → T-11 开阔配置 | 每日会话:无代码配置会计科目表、实体、货币、角色、审批、编号;ASK 批量创建主数据并草拟规则;配置检查在项目完成后运行;基于 API 构建集成;准备模拟加载 M1。 | 租户中已配置并检查了所有立即配置行。 | 配置工作簿;角色和采用准备情况登记表;测试计划(配置和集成检查);M1 映射已签署。 |
| T-10 → T-3 切换,已审核 | 模拟加载 M1 和 M2;试算表逐行与原有账目核对;子分类账与总账控制账户关联;根据运行手册进行完整的试运行;集成和角色测试;排练脚本已准备就绪。 | 试运行中试算表差异为零,且有审计追踪;试运行符合切换窗口。 | 试算表和明细账核对;切换运行手册及试运行时间表;演练脚本;缺陷日志。 |
| T-2 → T-1 彩排 | 客户一整天的交易记录,由 T+1 当天使用该系统的每个人,在其各自的角色中,在其操作队列处于活动状态时进行记录;结果与旧版本进行比较;通过,或当天执行简短的修复列表。 | 彩排通过——这是唯一的通行/不通行门槛。 | 包含结果的排练脚本;通过/不通过的门记录;每个用户的采用参与度;最终切换计划。 |
| T-0 正式上线 | 旧系统在截止时间冻结且只读;最终加载重复定时试运行;试算表已核对并签字;与生产环境集成;用户登录。 | 生产部门开具的第一张发票通常在午餐前发出。 | 切换运行手册(最后一列);已签署的对账;超维护异常日志;KPI:首张发票过账天数。 |
| T+1 → T+30 教练在流程中 | 队列会显示每个用户的实际工作,而 ASK 可以帮助他们完成工作;每天 15 分钟的紧急呼叫会逐渐减少到每周两次,然后进入正常运营;T-Plus 会逐步启用延迟范围。 | 例外情况趋于零;过度护理已融入正常节奏。 | Hypercare 异常日志;T-Plus 积压工作和分阶段计划;KPI 记分卡;采用情况跟进。 |
门(建议默认值)
正式的通过/不通过确认只有一次——彩排。其他所有环节都是可以核实的。
| 门 | 什么时候 | 标准 | 证据 | 由……决定 |
|---|---|---|---|---|
| 倒计时开始 | T-27 | 飞行前准备工作完成;日期已标注在板上 | 飞行前检查清单 | 倒计时所有者兼航班负责人 |
| 范围冻结(第一波) | T-18 | 每条 Fit Ledger 线都已标记;第一批已签名 | Fit Ledger | 倒计时所有者 |
| 配置完成 | T-11 | 所有立即配置行均已配置并检查 | 配置工作簿、测试计划 | 飞行领队 |
| 已协调的试运行 | T-3 | 零TB增量;子账簿持平;在窗口期内进行试运行 | 对账、切换运行手册 | 财务总监 |
| 彩排(通过/不通过) | T-1 | 实际营业日过去了,或者修复清单当天关闭了。 | 排练脚本,门录音 | 倒计时所有者 |
| 已确认上线 | T-0 | 最终试算平衡表已核对;首张发票已过账 | 已签署的对账单,KPI | 财务总监 |
| 超级护理退出 | 到 T+30 | 低于阈值的例外情况持续 5 个工作日 | 重症监护日志 | 倒计时所有者兼航班负责人 |
将每个阶段性结果记录在工具包的“通过/不通过阶段”表格中,并附上证据。审核员和指导委员会成员会阅读证据,而不是状态报告。
六个工作流程,一个时钟
| 工作流程 | 发现 | 配置 | 切换 | 排演 | 上线指导 |
|---|---|---|---|---|---|
| 核心实现 | 在实时屏幕上显示账本 | 每日无代码配置 | 仅配置修复 | 当天修复清单 | 同一周的变化 |
| 数据迁移 | 资料来源;范围截至/期间 | 地图绘制;模拟 M1 已准备就绪 | M1、M2、试运行、协调 | Delta 检查 | 最终装载,TB 签字确认 |
| 测试 | 测试计划草案 | 配置和集成检查 | 迁移验证、角色测试 | 排练 = 用户验收测试 | 异常分类 |
| 收养与培训 | 关键用户在其角色中 | 每个角色的队列和 ASK 设置 | 用户对排练数据的看法 | 每个 T+1 用户都会进行演练 | 教练进入状态 |
| 变革管理 | 变革影响、利益相关者 | 沟通:对我来说有哪些变化 | 准备脉冲 | 上线通讯 | 强化;摒弃旧习惯 |
| 技术与集成 | 租户在线;单点登录;访问权限 | 已构建的 API 集成 | 测试终点;DR钻探 | 生产终端已准备就绪 | 监测;超护理 |
规模扩大:波浪式发展,永不延长的阶段(建议的默认值)
多实体和多模块部署在同一账簿上重复执行 27 天倒计时。第一阶段:核心实体,包含会计、客户关系管理和供应链。第二阶段:其他实体和人力资源管理系统/薪资系统。第三阶段:制造、电子健康记录或学生生命周期管理。第 n 阶段:延迟的账簿范围和新区域。每个阶段都会根据配置切换启用模块和实体,因此增长不会触发重新实施。
第一阶段计划应围绕数据最清晰、参与度最高的实体或流程展开。它的成功将为后续阶段定下基调。
标有“建议默认值”的数值是该方法论推荐的起始点。请根据具体项目确认每个数值;合同、订单和服务水平协议(SLA)的最终解释权归其所有。