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 該編寫商業計劃書了
一般來說，隨着方案細節的落實，團隊已經可能拿出方案的預算了。如果團隊受僱與一個組織，此時就是提交富有預算的方案企劃以獲得批准的時候。如果這是一個需要融資創業團隊，一份商業計劃書是必不可少的。實際上這兩種情況下的文件格式並沒有本質區別，真正的區別來自有團隊外部環境的不同而產生的資源的來源和方案所對應的業務目的的差異。