本文写给那些在系统采购上签字负责的人:政府机关中的秘书(sekretarz)与财务官(skarbnik)、市属公司(spółka komunalna)的总经理、财务总监,以及企业主。同样也写给负责准备招标或询价文件的IT经理,他们希望了解在文件获得管理层批准之前,管理层应该关注哪些要点。
这个问题为何会出现
大多数与供应商的问题根源都在采购方一方,而且早在签约之前就已埋下。这并非出于恶意:准备一份采购需求本身就是一项工作,而组织内部往往缺乏时间和相应能力,供应商也乐于"帮忙"完成这项工作。他们会带来现成的功能说明、演示和报价。结果是,采购方买到的是供应商擅长销售的东西,而不是自己真正需要的东西。另一个问题是,采购决策往往掌握在业务部门手中,而IT部门只扮演安全把关人的角色。缺乏标准和长期的IT战略,导致组织所做的采购并不总是符合本应用于降低风险的框架。
这些同样的错误,我在政府机关和企业中都反复见到。不同的只是采购程序,机制本身并无差异。
十二个错误
- 根据某一家供应商的报价或演示撰写的需求书。 这会限制竞争,并在你们尚未选定承包商之前就固化了对该供应商的依赖。关于这一点,我在《招标文件(SWZ)中的供应商锁定(vendor lock-in)问题》一文中有更详细的说明。
- 缺乏业务责任人。 项目在形式上有项目经理,但没有任何拥有管理层授权的人来决定各项流程应该如何运作。
- 签约前缺乏验收标准与测试场景。 验收变成了关于解释的争论,而不是核实项目成果是否满足实施成功标准的检验。
- 对现有系统情况的不了解。 你们购买了新系统,却不清楚现有的哪些合同、许可和功能会与之重叠。
- 遗漏的系统集成。 新系统需要与哪些系统交换数据、方向如何、哪个系统作为主系统、交换哪些数据、采用什么格式,以及供应商是否知晓这一切,并保证会提供必要的机制、并对其持续运行承担责任。
- 仅用一句话描述的数据迁移。 没有明确哪些数据、来自哪个时间段、由谁清理、由谁核实结果。
- 以功能清单形式而非流程描述形式呈现的需求。 对于"是否具备某功能"这样的问题,每家供应商都会回答"是"。但对于"如何处理你们具体的业务场景"这样的问题,答案就会千差万别。
- 只比较起始价格而非总体成本。 许可费只是开始。维护、变更和系统集成的费用要持续支付多年。关于这一机制,我在《总拥有成本(TCO)与温水煮青蛙》一文中有所论述。
- 缺乏范围变更规则。 不清楚谁来提出变更、谁来估算成本、谁来批准。
- 没有退出条款的合同。 缺少关于数据导出、文档交付以及将维护工作移交给另一方的条款。也没有降低风险的机制。
- 直接采用供应商范本的维护合同。 这样一来,服务水平、响应时间和变更成本都由一方单独决定。
- 决策被拖延到期限最后一刻才做出。 当法定期限或旧系统支持终止的时间临近时,已没有空间去比较报价或进行谈判。
从第一到第三的错误是根源性的。如果消除了它们,大多数其余问题就会在准备阶段而非执行阶段暴露出来。
对于议会、监事会或总部而言,最重要的是选择供应商的决定是否有文件记录的依据。上面十二点同时也是一份问题清单,值得在管理层批准采购文件之前提出来。
实践案例
我们的一位客户从其ERP系统供应商那里得到保证,称将其正在实施的公文管理系统(EZD/电子送达系统,e-Doręczenia)中的往来单位数据进行双向交换"不会有任何问题"。公文管理系统通常保存所有往来单位的数据,而不仅仅是那些已发生业务事件的单位,即已成为客户或供应商的单位。也就是说,新往来单位的数据生命周期往往在发生业务事件之前很久就已经开始了。
在实施过程中发现,ERP系统供应商为实现往来单位数据双向交换而对API接口进行改造的成本,占整个成本类文档流程实施项目总价值的80%——该项目还包括与KSeF、OCR、WIES、GUS的对接,并最终将数据导出至财务会计系统。这一项集成,如果没有在项目初期与供应商仔细讨论清楚,几乎使整个项目的成本翻了一倍。
何时需要独立顾问
如果你们有经验丰富的团队,曾经准备过几次类似的采购,这份清单可以作为核查工具使用。当采购规模对组织而言较大、需求是在与单一供应商接触过程中形成的、决定日后需要向审计机关、议会或总部作出说明,或者采购方内部没有人真正了解这些系统的内部运作时,引入独立视角就很有意义。
我可以在招标公告发布或询价函发出之前审阅相关文件,协助准备需求与测试场景,或对已经提交的报价进行评估。在政府机关(JST),起点略有不同,我在地方政府单位(JST)专属页面中做了说明。