可行性研究

在一笔大额支出之前给出答案：计划中的系统或自动化能否在预定的时间和预算内建成，依赖哪些数据，存在哪些限制。

与我们探讨您的项目查看范围

范围

客户找到我们时的情况

供应商的报价等着签字
供应商发来了一份系统报价。将要使用该系统的部门想签，财务部门则问：怎么知道这能成功？报价假定数据已经就绪、现有系统能够连接，但公司这边没有人核实过。管理层需要一个既不来自想要采购的部门、也不来自想要销售的公司的评估。
在没人看过的数据上做自动化
公司想把人工工作转为自动化：文档识别、回复咨询、发票核对。计划假定数据都在系统里，而且质量良好。实际上，一部分在扫描件里，一部分在邮箱里，还有一部分在各部门的电子表格里。需要检查自动化能否在公司实际拥有的数据上运行。
自建、外购还是梳理流程：各方都有自己的数字
IT部门想针对自身流程开发系统。运营总监更倾向于现成产品，因为一家类似的公司在用。还有人认为，只要调整工作顺序，系统就是多余的。各方都有自己的测算，彼此无法放在一起比较，于是决策一直悬而未决。

范围

我们的工作

可行性研究回答一个问题：您打算做的事，在您设想的条件下能否完成。我们把计划本身和它所依赖的假设分开记录，因为我们要检验的正是这些假设。
我们检查四个方面。数据：是否存在，存放在哪里，质量如何，归谁所有，是否允许用于这一目的，包括涉及个人数据的情况。系统：现有系统中哪些必须与新系统连接，每个系统提供什么数据交换途径，厂商许可条件如何。法规：哪些法规适用于这一计划，对范围有何影响，例如波兰《国家网络安全体系法》（KSC）和欧盟NIS2指令等网络安全法规、欧盟《通用数据保护条例》（GDPR）等个人数据法规，或您所在行业的要求。如需法律意见，由律师事务所出具。人员：谁会使用，上线后由谁维护，计划离不开的那些人是否有时间投入。
当答案取决于技术能否处理您的数据时，我们会做一次试验：在真实数据的一个片段上实现方案的一小部分。试验要在您为整体付费之前，揭示计划中比预想更薄弱的地方。
我们用同一套标准比较各个方案：针对自身流程开发、购买现成产品，或不上新系统而梳理流程。对每个方案，我们记录它覆盖哪部分工作、需要哪些数据和人员、会触发哪些限制，以及成功必须满足什么前提。每项风险都写明名称，并指定您这边负责盯住它的人。
研究只针对一项计划。公司全部系统的评估、未来几年的技术方向、决策之后的实施计划以及对被收购公司的技术评估，都属于另外的范围。
最终为管理层形成一个答案：可行、有条件可行，或以当前形式不可行；理由写在一页纸上，细节放在附件中。

范围

您将获得什么

- 计划说明和假设清单：要建成什么、为谁、在什么时间和预算内，并附每项假设的检验结果。
- 数据、系统、法规和人员四个方面的可行性评估，附限制清单。
- 方案比较：自建、外购，或不上系统而梳理流程，采用同一套标准，附建议及其前提条件。
- 风险与成功条件登记表：您这边必须满足什么，由谁盯住，条件未满足时怎么办。
- 数据试验结果（如在范围内）：哪些可行，哪些不可行，这对决策意味着什么。

范围

工作如何进行

1. 记录计划和假设。我们以计划的现有形态为起点，无论是供应商报价还是IT部门的备忘录，列出它所依赖的前提。成果：待检验的假设清单，按对决策的重要程度排序。
2. 从源头检验假设。我们在数据所在的地方查看数据，检查系统的数据交换能力和许可，将法规与范围对照，并与相关人员讨论日常工作。成果：限制清单，以及每项限制对计划的影响。
3. 必要时进行数据试验。成果：在影响最大的环节，用证据取代假设。
4. 比较方案并交付答案。我们与您和管理层一起讨论各个方案及其风险和成功条件。成果：基于已检验假设的答案，即使答案是“还不行”或“要换一种做法”。

范围

管理层应向可行性研究承包商提出的问题

1. 我们关于时间和预算的假设中，哪些你们从源头核实过，哪些直接沿用了报价中的说法？
2. 有没有人在我们的系统里实际查看过系统要处理的数据，还是只看了对数据的描述？
3. 现有系统中哪些必须与新系统连接？每一个这样的连接在厂商条件下是否都可行？
4. 我们这边必须满足什么，计划才能成功？签合同前由谁确认？
5. 你们否决了哪个方案，依据是什么：自建、现成产品，还是不上系统而调整流程？
6. 哪些法规会改变范围？其要求是否已纳入方案比较，还是要到验收时才暴露出来？
7. 合同是否接受“计划以当前形式没有意义”这一结论？届时如何结算？
检验假设的先后顺序取决于这笔支出所涉及的流程，因此第一步是分析这一流程以及它目前所依赖的系统。