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