简而言之
对定制软件的抵触几乎从不针对技术,而是担心增加工作量或被取代。在实施前应该询问每天执行相关流程的人,而不是事后通知——不应引入任何要求额外录入的东西。
01 — 团队
如何让团队配合
- 早期纳入,而非早期通知。谁每天执行流程,谁就知道例外情况在哪里。这些信息只能提前获得,而非上线后。
- 认真对待阻力。它几乎从不针对技术,而是针对额外工作或被取代的担忧。两者都应公开回答。
- 不引入产生额外工作的系统。要求额外录入的系统会被绕过——理所当然。
- 指定一个人作为首要联系点。不是作为职责,而是为了避免问题石沉大海。
- 让成果可见。如果四周后没人知道是否有效果,留下的将是对变革的记忆,而非收益。
02 — 配合要求
我们需要您提供的内容
- 一位有决策权的联系人 — 而不仅仅是转达信息的人。
- 相关系统的访问权限,需要及时提供,而不是在上线当天才给。
- 来自日常业务的真实案例 — 越不规范,对测试就越有价值。
- 2至4小时用于沟通协调,分散在整个项目周期内。
- 对“什么是成功”这个问题的明确答案。没有这个答案,后期就无法评估效果。
03 — 衡量
如何衡量成效
- 事先确定一个数字。没有基准值,事后无法证明任何东西。计数两周就足以得出可靠的数量级。
- 每项流程的处理时间。最直接的衡量指标:受影响的流程现在需要多长时间,之后需要多长时间。
- 无需干预即可完成的案例比例。这一比率在前几周通常会随着优化而明显上升 — 是最好的早期指标。
- 对外响应时间。咨询者多快能得到首次确定的答复。
- 不应衡量的:前两周的团队满意度。任何变革在初期都会让人感觉比实际更糟。
04 — 问题
常见问题
定制软件相比标准软件何时值得?
当您的流程是真正的竞争优势,当标准软件只能满足百分之七十而其余部分需要手工完成,或者当每用户许可成本在几年内超过开发费用时。如果只是为了方便,标准软件更便宜。
如果我们不再合作会怎样?
您拥有代码、文档和访问权限。我们有意采用通用技术,使更换供应商成为可能,而无需从头重建一切。
这样的系统能承载多少用户?
这取决于架构,我们会根据您预期的增长进行规划——从企业内部的少数用户到跨多个地点的数百用户。
运行在我们自己的服务器上还是在云端?
两者都可以。对大多数企业而言,云解决方案维护更简单;当数据不得离开企业时,我们会在您自己的基础设施上部署。
我们可以从表格开始吗?
通常可以,这也是一个很好的测试。如果表格能反映流程,只是在多用户能力、权限或数据量方面受限,那么需求就是明确的,项目也是可估算的。
如果在开发过程中发现新需求怎么办?
这很正常且在计划之内,因为我们采用小步骤工作方式。新需求会纳入下一步骤,而不是拖延整个项目。
源代码属于谁?
属于您,完全归您所有,付款后即可。这在合同中明确规定。您可以将其交给任何其他开发者——这正是重点。
下一步
让我们简短讨论一下这对您是否划算。
二十分钟的对话通常就足以弄清一个项目是否有意义。如果没有,我们会直说——这对双方来说都比一份无人需要的报价更便宜。