7.2 设计论证
在明确了，或者说至少是阶段性地明确了用户需求之后，实施团队就需要设计方案并论证其可行性。设计和论证的依据都是需求分析的结果。这个过程是一个迭代，因为经常在论证的过程中随着对方案理解的加深而发现之前需求获取和分析过程中的盲区与错误。设计论证的结果就是产生了可实施部署的指导性文件。
如果说需求分析是在论证这个解决方案存在的必要性，那么设计论证的过程就是在论证其可行性。当你认为自己终于弄清楚了用户想要什么，马上思考如何去实现这个需求就是自然而然的事情。一般来说，人们心中的“怎么去做”首先是指技术架构，也就是怎么打造一个物理上存在的系统去满足这个需求。但是不要忘记，在商业社会中，我们多数的活动都暗含着一个财务上可持续性发展的要求。这就涉及到这个系统的具体商业模式，我们是要把他做成一个可重复销售的产品、一个一次性交付的项目还是持续运营的服务模式？也就是说，我们怎么从中赚钱能？如果你是公益性非盈利解决方案，你也许认为用赚钱来描述这个目标不甚合适，但是你一定也希望这个整个解决方案可以如期收回成本，甚至可以获得一定的收益以支持我们预想中的扩张。所以，无论怎样，评价一个解决方案的可行性的时候，一定有财务指标的考核。此外，最后出场但并不代表就最不重要的是，解决方案的社会影响评估。
7.2.1 技术可行性论证
技术架构是需要工程师和技术专家们全力工作的重点。这里主要讨论的是如何判断技术可行性以及如何综合平衡财务和技术上的可行性。
需要注意的是，我们一般说的技术可行性，是暗含了一个时间概念：短期。有多短？就是你的财务可行性要求的那么短。如果用量化的时间来表示，对于一个初创企业，也许只有三个月；而对于有充足政府预算的市政项目，也许是几年。
在构建了技术架构之后，方案团队可能会面临下面几种情形中的一种：
一、在这个需求面前，现有技术就好比想登上月球的人刚爬上了一棵树。
一般这种情况就是技术上基本是不可行的。如果必须满足则只有投入研发，而且研发的风险在于对某一领域的基本认知不足。不见得说这样的解决方案就是不值得去做的，判断的关键更多在意你的身份：这是大学和科研机构的工作，或者政府为了某种长远的考虑给予长期的支持，或者某些富有的个人和团体不断地赞助。这样的解决方案包括登月、研发抗癌药物等。这些不是方案团队一个组织的工作，而是整个人类的历史性任务。如果你得团队的身份很不幸不在这其中，你就要三思了。不过凡是总有例外，就像SpaceX火箭一样，一个罕见取得成功的私人商业支持的航天项目。在工业物联网中，类似的例子一般是一些创新的传感器技术，以及云端仿真的高级数据处理技术。一旦发现手头这个方案的成败取决于这类尚未成熟甚至完全没有的技术时，是否继续投入就要有充分的论证了。
二、这个需求从技术角度来看，好比是踮起脚尖就能摘到的果实。
现有技术并不能满足需求，但是差距是属于可克服的，需要对投入研发、调整架构还是削减需求进行决策。
现实中相当多的解决方案落入这个区间。这是很自然的，因为行业普遍关注的问题都是具有共性的，也是在外部的推动下在市场的多个角落同时出现的。也就是说，当你的客户觉得这事情不是什么天方夜谭而决定来找你试试的时候，一般也的确是可以试试的时候。这里的“差距”，有时候是功能上的一点不满足，有时候是性能上的问题，也有的时候单纯就是面向最终用户的价格降不下来，达不到一个用户可接受的程度。
这种情况下的论证本身就是艺术。团队往往需要以内部成员或者外部专家的直觉判断和集体表决来行事，比如，投票某种原型技术开发可能需要的时间或人工数，或者推测某个技术路线对性能提升的概率。最后可能需要某种工具来整合，比如经典的决策树方法。
三、现有技术只要简单的再组织、再集成就可以满足需求。
这就是所谓的没有技术门槛，主要靠商业模式或者市场进入时机、市场份额成长速度取胜的情况了。这种类型的东西在各类领域中都很常见，尤其是某些历史较为悠久的传统领域的工业信息化。这种情况下由业务流程所定义的需求非常清晰，可利用的实现技术也都是现成的。甚至于，针对此类场景市场上已经有了成熟的解决方案供应商，你之所以遇到这样的客户，仅仅是客户并不了解市场行情，或者客户误以为自己和同行有很大的不同从而不适合现存的集成商。
另外要提醒一下经济学中的老话：“风险越大，收益也越大”。没有风险溢价的企业，往往也难以有业务快速增长的机会。
7.2.2 商业模式选择
前面一章已经讨论了商业模式。对商业模式的选择一般放在设计论证阶段，但这并不是说不可以更加提前。对于服务于整个行业生态的工业物联网平台来说，实际上往往一开始就已经确定了商业模式，并将其作为需求的一项加以考虑了。也的确，商业模式本身对技术架构的选择有一定的影响。
实际上，有些持有相对激进的观点的人也许认为，对于商业模式的考虑应该放到方案企划阶段而不是在设计论证阶段。这从一个侧面说明了这一点的重要性。这一点在互联网行业尤其重要，所以那个领域的产品经理们在做产品的需求分析的时候，一般都不会忘记业务运营和市场推广层面的需求。而对于公共服务模式的工业互联网解决方案，因为其带有一定的互联网属性也因此被建议尽早规划完善商业模式层面的设计。本书将商业模式放在设计论证阶段的原因，是因为总的来说，相当多的解决方案在没有将技术方案的框架做足够的评估之前，其财务模型相对比较难以建立，对讨论具体的商业模式也就缺少了立论的基础。这也是实际上笔者认为财务模型的部分应该被视作分析论证商业模式的可行性的一类工具。工具应该在工作的过程被使用，而不是单独作为一个工作的阶段。这一点也许让人有点迷惑，因为财务模型的部分一般会在项目可行性报告或商业计划书中独立成章。但是请记住，那只是在一个文件中将论证结果的模型展示给读者，并不是展示其论证过程。在论证的过程中，会随时按照当前的假设重新核算财务模型，以帮助得出当前的设计（在财务上）是否合理的论断。
当然，现实中我们都是生活在某种或隐或现的规则之下，就某一特定的领域而言，其在某一阶段或某一地区其实大家都在遵从某种特定的商业模式，或具有类似的成本结构，这种情况下，商业模式的讨论差不多就可以直接切入主题。
7.2.3 财务可行性论证
根据所选择的商业模式和技术方案，构建起全生命周期的假象财务模型，从而核算其在财务上是否可是经济的、可行的。
财务可行性的核算要注意这里面实际上存在两个角度：卖方和买方。我们要明白的是，卖方的成本加上利润，也就是卖方的售价，才是买方的成本，而买方能承受多大的成本，是要取决于这个解决方案上线后能为买方带来多少效益，以及市场上同类方案的售价等因素来决定的。作为卖方，切不可单纯考虑自身的成本和期望利润来定价。对于为买方定制的项目型解决方案，这个阶段往往就已经开始了卖方和买方之间的商务合同的讨论，甚至签订合同。而对于服务产品型商业模式的而解决方案中，这一阶段的预订价对未来整个方案的成败十分关键。
7.2.4 社会影响论证
7.2.4.1 政府政策与法律法规
自从政府出现在人类历史上一来，它的导向就从来不是可以随便忽视的。毕竟，之所以能出现这种协调一个人群的行为模式的组织，本身就是人类社会发展的需要。这里无意去讨论有关政府的方方面面，只是列举几点可能对解决方案构建的影响。
很多领域因其专业性而受到相关的法律法规和行业技术规范的约束。比如容易产生危险的高压容器、汽车、电气设施等。还有的是可能被不法分子利用谋取暴利的工具，比如食品、药品、管制刀具等等。还有的情况，因为其高额的利润或者处于国家安全、保护特殊贸易群体而制定的各种政府政策，比如烟草专卖、粮食收购等。一般来说，处于各领域的传统从业者普遍会对这些政策法规具有一定的了解，毕竟了解这些政策本身也是其专业性的一部分。但是，随着信息化、物联网技术的普及，以及近年来对所谓跨界的商业模式创新的热衷，一些原本不熟悉本领域的工业联网创业者和解决方案构造者大量涌现。如果你恰好也是这其中的一位，请注意，每进入一个新的领域，一定要借助该领域的专业人事或者法律专家对潜在的政策和法律风险做一个评估。
然而，不等于说你的团队要完全屈从于这种评估的结论。这类政府监管跟不上技术发展的现象实际上屡见不鲜。该领域的现有专家未必能真的理解跨界者的思路，或者是因为自身的从业者的利益相关的立场，导致其本能地产生对新的搅局者的扼杀欲望。而立法部门的政策也难保其前瞻性，现存法律法规也许根本无法在新的商业模式上套用。所以，想新进入的领域的专家咨询也好，努力研读有关的法律法规也好，与政府有关部门交流也好，本质上是为了找到一条让解决方案变得更加可行的道路，而不是为了向现实屈服——毕竟，一个新的解决方案要解决的就是现实的传统势力未能解决的问题，不是么？
在讨论政策法规对方案的影响的时候，还要注意的是，这种影响是一个动态的过程而非一个静态的切面。你不能假设目前的影响一直存在，无论是好的还是坏的。特别是面对所谓的政策利好的时候，反而更加需要小心：政府只是影响社会经济的力量之一，并不是完全决定性力量，所以政策导向不等于必然性。如果你的解决方案的投资回收期过长，这种对政策法规的动态预测就更加重要。
7.2.4.2 社会理念与文化习惯
社会理念和文化习惯的影响和政策法规的影响有相似性，但是相比而言更隐蔽和难以捉摸。之所以这么说，就在于这些理念上的东西并不是成文的，也不是牢不可破的。对于其刚性真正能把握的人不多见。好在大多数的工业物联网解决方案并不存在这方面的问题，但也不能完全排除类似这样的问题：有的文化圈认为工人应该更积极地观察设备，所以并不赞同将太多来自设备的数据采集到服务器上的做法。
7.2.5 其他议题
7.2.5.1 设计论证阶段是一个一次性的流程还是一个反复迭代的过程
其实是一个迭代。实际上连如何进入这个阶段的入口都未必一定是技术架构还是商业模式。但有一点是明确的，无论是先确定了技术架构，再确定商业模式，还是反过来，都要必须再听过一个财务可行性和其他影响因素的分析。一旦发现分析的结果不甚理想，就需要调整可能的方面，重新论证知道新方案的总体指标满意为止。
7.2.5.2 各种可行性因素的平衡点
本章所讨论的内容都是关于可行性的不同角度。那么，怎样的解决方案最终会被判定为可行呢？这个最终促使方案团队及其客户和上司对方案建立信心的立基点在哪里？笔者的建议是你可以考虑这样的论证流程来帮助你找到这个平衡点：
一、遍历各主要宏观影响因素，查看是否存在否定性的因素。
二、如果没有，很好，继续。如果有，先将识别出来的宏观障碍记下来，同样继续考察微观因素。
三、遍历各微观影响因素，调整各角度和层面试图达到一种可行的状态。此时的调制不仅要达到微观技术和财务可行性，同样也要考虑上面识别出来的各宏观障碍。
四、如果最终可以找到无论在宏观和微观的角度均可行的解决方案，那么恭喜你，这一阶段就顺利地结束了。如果很不幸，你此时无论如何还留下几样障碍无法克服，那么，如果你不希望此时就宣布不可行，那就只有尝试去外部寻找有利于解决这些剩下来的障碍的资源。
7.2.5.3 需求分析与方案设计要分开么？
这里的第一条建议：不要过度执着于是否需要分开，而是要以切实找到问题的答案为己任。还有另外一条建议：在做需求分析的早期阶段，能分离还是尽量分离。分离需求和设计的理由很多，笔者更多认为其实是认知模式或者心理学上的原因：理解目标用户的需求和设计的确有不同的视角，过早思考实现的方式，很容易让你“爱”上你的技术方案而对用户的需求开始置若罔闻，甚至会有意无意地在需求采访中引导受访者、扭曲对获取的需求的理解、认为目标客户“都不懂、都不值得考虑”。这种认知上的潜在风险实际上非常可怕，实际上笔者认为这正是很多行业专家创业失败的根本原因。
但是随着你对问题研究的深入，你已经根据前几轮的需求分析做出了最初的设计，在后期的优化阶段，需求分析和设计是很难分开的。这种情况在你的解决方案本身也是一个面向技术环境的（如是针对某项技术性较强的需求而制订的解决方案）时候会更加明显。你或者团都会不由自主在讨论需求中夹杂着对实现细节的讨论。不用怕，实际上这是好事：这给了评价设计细节的合理性提供了早期的检验机会。注意，这里说的设计细节，是包括技术架构和商业模式的。对于偏重后期运行的服务型方案，这一点反而是分析的重点。
7.2.5.4 与客户沟通的时机
理论上来说，人们总是被鼓励要充分沟通，不过需要注意的是，充分沟通不等于说沟通的频度越高越好。在方案团队还没有适当的准备之前，过度的沟通很容易带来不要的误会。在团队还没有确定可以展示最终的需求分析或是方案设计的时候，建议采取的方式是：列出目前识别出的需要澄清的问题，约谈客户针对这些问题进行讨论，而不是急匆匆把目前未成形的方案直接就抛出去。后者很容易让客户认为过于草率和有失专业。极端的情况下，你甚至需要在完成设计阶段再与客户进行正式的汇报，否则难以回答诸如“大体预算、何时能完工”之类的问题。
7.2.5.5 敏捷开发或精益创业意味着不需要设计论证么？
敏捷开发的概念自诞生就一直被误解。很多时候，研发团队把敏捷开发当作在决策上不作为的理由，认为前瞻性的技术架构是不必要的。当商业模式和业务运营也引入了类似的概念之后，即所谓精益创业，一些创业者和业务主管也开始犯同样的毛病。
无论何时，对远景的预测和对当下利益的取舍都是需要平衡的。这种先建议一个最小可交付物（MVP原则）再逐渐完善的概念正是一种达成这种平衡的方法，而不是特别偏废某一端。一般的观点认为，如果过度关注长远利益，也许因为一开始就要搭建过于庞大的基础设施而陷于财务上的不利之地。有的时候，我们必须做好整个架构被彻底替代的准备，因为我们需要一个不那么完美的技术和业务架构来为我们的业务获取短期的现金流和市场份额。但是，我们在浑浊的河水中小步试探的目的是为了找到上岸的路，如果我们忘记了自己的目的地，那么也许永远要在河水里试探，直到冻僵在初春的河水里，也就是业务接近成功的黑暗前夜。
正确的做法是，用作初始迭代的方案必须来自对中长期利益考虑的解决方案的裁剪，以保证不轻易改变业务的愿景。而每次检讨当前的业务方案时，都不要忘记对当下的理解和经验对之前的愿景做一个修正。
7.2.5.6 组织战略与解决方案的关系是怎样的？
如果你的团队代表的不是整个组织，而所构建的解决方案实际上是整个组织的多个方案之一，此时方案的设计和评估还需要考虑与企业战略的关系。一个方案的诞生和运营，其所属的组织不见得是为了在其中直接获益，虽然这可能是最常见的模式；还有一种可能是该解决方案的存在主要是为了帮助其他方案的存在和健康发展。对于大多数商业企业，这种关系可能悻悻地概括为：要么自己赚钱，要么帮别人赚钱。这里面帮别人赚钱的方式很多：成为更大的解决方案的销售亮点、帮助其他解决方案节省内部运营成本、提升其他解决方案某项功能的潜力等等。
7.2.5.7 该编写商业计划书了
一般来说，随着方案细节的落实，团队已经可能拿出方案的预算了。如果团队受雇与一个组织，此时就是提交富有预算的方案企划以获得批准的时候。如果这是一个需要融资创业团队，一份商业计划书是必不可少的。实际上这两种情况下的文件格式并没有本质区别，真正的区别来自有团队外部环境的不同而产生的资源的来源和方案所对应的业务目的的差异。