从第一次IT系统盘点到系统验收。整个航程中，始终由同一位顾问站在管理层一边。

1. IT系统与流程盘点

   我们究竟有什么？

   这是每一项实施决策的起点。在您选择系统、供应商或方向之前，先对自己已经拥有的一切形成清晰、有条理的认识。

   • 应用登记册，包括负责人、合同、许可证、成本和支持终止日期。
   • 有系统支持与无系统支持的流程图，集成关系图，以及数据需要手工重复录入的环节。
   • 风险登记册，包括单点故障和对供应商的依赖（vendor lock-in）。
   • 系统A/B/C/D分类，以及一页式管理层摘要。

   2–6周，低于公共采购门槛。

   IT系统盘点的完整范围

2. 需求分析与研讨会

   我们真正需要什么？

   通过内部研讨会，我们一起厘清组织真正需要什么。我常常用简单的问题把它挖掘出来：成功的定义是什么？这个项目在什么时候会被认为是成功的？企业和公共机构常常跳过这一步，要么以为自己什么都清楚，要么根本没有时间深入追问。这正是项目出问题最常见的原因之一。

   • 与管理层以及日常在流程中工作的人员共同开展研讨会：目标、期望、限制条件。
   • 成功的定义，以及判断项目是否奏效的标准。
   • 描述当前的痛点，以及未来应有的样子。
   • 为编写需求或开展市场调研提供依据，或者得出无需新系统的结论。

   我首先提出的问题 阶段完整说明

3. 数字化战略与目标架构

   我们去往何处，按什么顺序？

   这是一份不会被束之高阁的战略，因为它建立在组织实际拥有的基础之上，并指明下一个预算周期该做什么。

   • 分层构建的目标架构：登记册、流程、集成和访问。
   • 组织采纳的标准：权限模型、接口标准、需求文档编写规则。
   • 区分法规义务与投资的路线图。
   • 系统采购的采购规则，以及区分投资与运维的预算。

   阶段完整说明

4. 需求与项目准备

   如何描述需求，才能让供应商理解？

   在您发起招标或发出询价之前，用您自身流程的语言写成需求。有了它，各家报价才具有可比性，日后也能据此追究供应商的责任。

   • 访谈、流程图、数据模型、集成和测试场景。
   • 最重要的是回答：怎样才算实施成功，也就是我们为什么做这件事、期待什么结果。
   • 当管理层有想法却没有时间写成文字时：只需一次谈话，约2天内即可拿出概念方案或原型。

   阶段完整说明

5. 报价评估与供应商沟通

   如何有效比较不同供应商的报价？

   这是一份独立意见，与您自己IT团队的建议并列，而不是取而代之。管理层得到一份可以据以决策的比较，并且能在地方议会、所有者或集团总部面前站得住脚。

   • 向供应商提出的问题，以及基于您自身场景的演示。
   • 比较矩阵：将各份报价统一到相同范围，多年期总成本，运维条款和合同退出条款。
   • 对于子公司，按总部采购准则进行比较，必要时使用英文。
   • 作为采购方代表参加与供应商的会议。

   阶段完整说明

6. 实施、变革与验收

   如何让项目落地、说服员工，并让供应商履约担责？

   大型IT项目同时也是一场工作方式的变革。它往往是您组织里的第一次，但在我的职业实践中并非第一次。我在实施团队中代表管理层，并引导变革，使员工真正接受新系统。只有在需要作出决定时，管理层才需要重新介入。

   • 把控范围、进度和变更决策，并建立变更与决策记录。
   • 变革管理：了解组织文化和用户、适应策略、沟通计划、培训、各部门的变革推动者、与尚未被说服者的沟通，以及实施、采纳和成效的指标。进一步了解变革管理。
   • 简短摘要，供管理层使用，也用于与IT部门、地方议会或集团总部沟通。
   • 按照约定的测试场景和标准进行验收，数据迁移经过核验。
   • 运维合同不会让您对单一供应商的依赖超出必要程度。

   ERP实施中的具体做法 阶段完整说明

7. 项目协调与常态化秩序

   我们没有IT总监。谁来盯住全局和期限？

   这一角色在国际上被称为“兼职CIO（fractional CIO）”，区别只有一点：我不接管IT部门，也不接管其预算。我把管理层的意图转化为需求，评审IT部门的建议，并在与供应商的往来中代表采购方的利益。

   • 每月与秘书长（行政负责人）或总经理以及IT负责人会面一次，每月提交运营与风险报告。
   • 每季度审查风险和关键合同，重大采购前出具意见。
   • 最初90天：初步摸底并识别紧迫的“危险信号”，建立各类登记册并启动合同审查，向管理层提交附12–24个月路线图的报告。

   项目有好几个，而IT部门连系统维护都勉强应付时，就缺一个日常盯住全局的人。我以采购方一侧常任协调人的身份，维护项目、行动、风险、决策和文件的登记册，汇总进展，提醒期限，并在事情停滞时上报升级。我不接管执行，也不替你们做决定：每项行动在你们一侧都有负责人。

   • 一份保持更新的清单，涵盖项目、行动、风险、决策和文件，并载明负责人、期限和状态。
   • 每周的进展汇报和进展会议，附会议纪要和行动清单，每月向秘书长、总裁或管理层提交报告。
   • 提醒、文件完整性检查、风险预警以及上报升级的准备。
   • 与供应商的信息协调：进展、承诺和期限。

   协作节奏根据项目数量和你们IT团队的可用时间来确定：

   • 基础型，每月一次：更新登记册，最多两次进展会议，以及月度报告。
   • 常规型，每周一次：进展汇报、进展会议、登记册、跟进，以及面向管理层的月度报告。
   • 强化型，每周一至两次：项目组合较大，项目之间存在依赖，并为处于风险中的项目制定补救计划。
   • 过渡型，每周数次：持续数月，适用于组织在项目管理上出现空缺、需要迅速理顺项目组合的情形。之后再回到较轻的节奏。

   阶段完整说明

每个阶段需要多长时间，取决于组织和项目：组织的准备程度、组织文化，以及管理层给予的授权。因此，范围和时间安排在首次沟通后确定。每个阶段（包括IT系统盘点）的报价，我都会在30分钟的沟通之后提供。