如何从零开始构建一套B端产品，来支持一条业务线。这其实是相当有挑战的，设计人员要完成业务梳理、流程设计、组织架构设计、数据建模、界面设计、权限设计等一系列工作，既要有对宏观的把控能力，又要有对细节的专注力；如果涉及的是商业化售卖的产品，还需要对市场、客户有着充分的理解认知，并作出正确的决策。
为了便于大家理解，我们将结合一个完整的案例——设计一个分销平台，来讲述B端产品设计中各个环节的方法、要素和技巧。
很多产品经理入行后，可能一直在做迭代优化的工作，没有机会参与从0到1设计一套产品的过程。当积累了足够多的经验后，产品人一定要为自己争取或创造机会，亲历一次从零开始的产品设计与落地的过程，锻炼自己的全局性思维和设计能力。
现在，让我们做好准备，开始这场有趣的B端产品建设旅程吧！
B端产品建设概述
B端产品往往涉及复杂的业务关系和场景，该如何设计并实施一套B端产品呢？其实是有规律可循的，遵循标准的流程逐步开展工作，可以提升效率、少走弯路。本章将从总体上介绍B端产品建设的一般流程，以及流程中每个环节的要点。此外，我们还将对比B端和C端产品建设流程的区别，帮助大家理解二者的不同。
B端产品的总体建设流程
我们探讨B端产品建设，首先要区分两种情况，第一种是设计自研自用的软件系统，给公司内部使用；第二种是设计商业化对外售卖的软件产品。这两种情况下，产品设计的核心过程相同，但又有不同之处，尤其是产品设计的思维模式，在某些方面两者区别很大。在后续的章节中，我们会随着内容的深入，在不同环节分别讲解两类B端产品的区别。
B端产品的总体建设流程需要借鉴软件工程自顶向下的设计思路，从抽象到具体逐步展开工作，大体上可分为市场与业务分析、设计产品方案、执行并优化产品方案三大阶段，每个阶段包含具体的关键步骤，不同阶段会涉及不同的参与人员，如下图所示。按照这个流程和思路来梳理业务、进行产品设计，比较容易保障工作效果。
B端产品的总体建设流程图
业务调研
如果是商业化对外售卖的产品，在初期的工作首先是市场分析，找到细分的目标客户群体以及种子客户，从而进一步开展调研工作。
在业务调研阶段，产品经理要全面研究并理解业务的现状和规划，挖掘并总结业务问题。尽可能地用各种手段和工具收集业务关键信息，通过对业务负责人、一线业务人员等角色进行访谈，获取全面的信息；另外，可以邀请技术负责人一起参与业务调研，确保对业务的理解是一致的。
通过业务调研找到关键业务问题和客户痛点，这是设计产品解决方案的核心前提，也是产品找准商业化定位的核心要点。
产品整体方案设计
B端产品整体方案设计讲究体系性、结构性。基于对业务现状与发展方向的理解，产品经理需要和架构师、技术负责人一起，规划产品的功能范围、定位，以及和公司现有产品体系如何融合，形成对后续细节设计有指导意义的整体方案，包含以下方面。
核心业务流程：梳理整个业务主干流程，并确定其中哪些环节需要由该产品实现线上化。
产品定位：在商业层面上，确定产品的目标客群和核心价值；在执行层面上，明确该产品有哪些子系统，分别支持哪些业务流程和业务版块。
应用架构：考虑该产品和公司现有系统的融合关系。
功能模块：基于对业务的理解，抽象出该产品的具体功能模块。
演进蓝图：根据业务优先级与发展策略，制订实现各功能模块的计划和节奏。
在产品整体方案设计阶段，业务负责人有必要参与讨论，并且所有参与者需要通过讨论得出一致认可的结果。
产品细节方案设计
梳理了核心流程、产品定位、应用架构、功能模块和演进蓝图，相当于完成了万丈高楼建设的规划蓝图；接下来的细节方案设计就要基于蓝图，逐一分析业务细节，设计产品的具体功能。
数据建模，也叫业务建模或领域建模，是细节方案设计中最重要的环节，是保证产品设计严谨可行的关键工作。只有基于对业务的理解，抽象出合理且灵活的数据模型，才能设计出有持续灵活性和扩展性的应用系统。在后续的学习中，你会慢慢理解为什么数据建模是产品细节设计成功的基石。
角色与流程设计会涉及业务团队的组织架构和岗位编制，需要产品经理与业务负责人一起讨论决定。
界面与报表是业务用户直接看到的部分，在设计时最好能提供可以体验的交互界面，让业务用户提前感受并反馈意见，减少不必要的返工。
技术方案设计
产品的整体方案、细节方案都设计好后，就需要技术人员做技术方案设计了，从而保证软件系统在正确的技术选型和合理的技术架构下进行编码开发工作。产品经理一般不需要直接参与技术方案设计，但还是有必要理解相关技术知识。
项目管理与实施
技术方案设计完毕，接下来就要进入具体的开发实施环节了。
B端产品往往涉及多个业务部门，需要多个业务系统的跨端配合，如何推进跨端项目？如何保证项目如期高质量交付？做好项目管理是关键：完善的项目管理机制可以保证实施环节顺利进行；相反，如果项目管理混乱，任意变更需求、扩大项目范围，就会导致项目无限延期。
运营迭代
新系统上线后，产品经理要和业务人员一起参与产品的运营迭代工作，包括宣传、推广、使用效果分析、问题和反馈意见的收集，以及持续的迭代优化。
如果是商业化售卖的B端产品，运营工作可能包括了市场获客、销售转化、项目实施、客户成功等工作。
如果是内部使用的B端产品，运营工作可能包括了系统落地推广、培训、问题处理、需求采集等工作。
对于迭代优化工作，B端产品也有自己的特点，我们需要管理好需求、定义好优先级、分配好研发资源、选择合适的迭代模式。
B端产品与C端产品建设流程的区别
在产品从0到1的建设过程中，B端产品和C端产品在很多环节上是完全不同的。下图将两者的建设流程对比呈现出来了，我们可以清晰地看出两者的异同点。其中，C端产品的建设流程是根据经验总结抽象出的常见流程，不同的需求和背景下的流程可能略有不同。
B端产品和C端产品建设流程对比图
从上图可以看出，B端和C端产品的建设流程很大不同，具体体现在如下方面。
设计起点不同
进行产品设计之前都需要进行调研，这是设计的起点。因为B端和C端产品的定位、目标完全不同，所以两者的设计起点不同：
B端产品是为了解决业务问题而设计的，在自研自用的情况下，设计的起点是进行业务调研，研究业务问题；在商业化售卖的情况下，设计的起点需要做市场分析，但同样也要做业务调研，因为B端不可能脱离了业务做设计。
C端产品要实现公司商业模式的落地，承载着公司的商业目标，设计的起点是对商业模式本身的分析与研究，包括客群分析，商业模式分析等。
MVP思路不同
MVP是《精益创业》一书中提出的产品理念，在互联网公司中被广泛接受并实践，简单讲就是用最小的投入去验证业务，通过快速迭代逐步优化。
在建设B端和C端产品时，大的原则是类似的，都是先做加法，即充分讨论、穷举所有需求和可能性；然后再做减法，选出最核心的需求点；最后设计具体方案并将其落地，用最短的时间和最低的成本支持业务启动。
但是在选取最小功能集合时，B端和C端产品的区别很大：
B端产品要支持业务整体运作，所以在选取最小功能集合时，即便再简化，也要保证一个核心业务流程的运转，因此B端MVP往往是一个具备一定复杂度的系统，不可能是一个或几个功能点。
C端产品需要解决用户的痛点，需要挑选一个核心痛点去打动用户，如果核心痛点定位错误，就会导致验证失败。所以在选取最小功能集合时，C端产品要聚焦用户的核心痛点，C端MVP可能只包含一两个功能点。
细节设计不同
两类产品在细节设计上的关注点可谓完全不同。
B端产品面临复杂的业务场景和用户场景，因此进行细节设计时，必须关注建模、抽象、角色、权限等问题。
C端产品面临的场景相对单一，并且使用者是相对独立的单个用户，因此不用关心角色、权限管理，而要关注用户的体验，需要在交互设计上投入很大精力。
对运营的依赖程度不同
相对B端产品来说，C端产品对运营更依赖：
B端产品上线后，如果是自研自用产品，要进行全员宣导培训，产品运营工作相对简单，可以说，B端产品上线后肯定有用户使用，因为公司会要求自己的业务团队使用新产品；如果是商业化产品，尤其是SaaS产品，运营工作就会更重要，承载了获客、转化、服务的重任。不过即便是SaaS产品，运营的套路和手段与C端也完全不同。
C端产品上线只是走完了万里长征的第一步，接下来需要运营团队进行持续推广，并且通过快速迭代迅速优化产品，响应用户需求。可以说C端产品上线后还要靠运营团队继续奋战，才可能走向成功。在 B端产品和C端产品建设流程对比图中，我们将C端产品运营迭代的过程绘制得更长一些，以体现运营工作对C端产品的重要性。
案例：M电商公司的渠道分销产品设计
通过B端产品的总体建设流程的讲解，大家对B端产品的整体建设流程应该有了初步认识。接下来，我们会通过一个贯穿设计篇和管理篇的大案例，按照B端产品的总体建设流程图中的流程，带领大家一步步搭建一个B端产品。首先，我们来介绍一下案例的背景。
案例背景与目标
背景
M集团是一家经营了十几年的成功企业，旗下拥有零售连锁超市、生鲜电商、金融理财多条业务线，业务发展良好，系统建设成熟。
M公司是M集团下属的电商公司，成立5年，主营生鲜商品，以C端客户为主，业务稳定。
M公司在三个月前尝试开展分销业务，成立销售团队，将生鲜品卖给企业客户。分销业务的目标客户是大型的餐饮连锁集团，以及大型生鲜分销商等企业级客户，需要注意的是，M公司并不会参与客户对商品的二次转卖环节。
业务试点在北京、上海开展，三个月以来业务发展迅速。目前分销业务月流水50万元，以每月20%的增幅快速发展。但是，在高速发展中，若干流程、管理、风险问题越来越突出。
诉求
由于分销业务发展迅速，现急需配套的软件系统来提升业务效率，控制经营风险。
公司希望寻找新的业务增长方向，考虑到在生鲜领域的数字化实践水平较高，希望这次搭建的分销系统，除了给自己使用，未来还可以作为SaaS化软件产品对外售卖，发展成为公司的新业务。
评估
经管理层评估，公司决定投入研发资源建设软件系统，支撑分销业务发展。项目期间CTO全力提供资源支持。
目标
在2~3个月的时间内搭建一套分销业务平台，至少支撑分销业务在未来2年内的高速发展，有效地提升效率、控制经营风险。
在内部系统落地成熟后，将这套分销业务平台SaaS化对外售卖。
以上就是案例的大概背景。之所以选择一家集团企业下属电商公司的分销业务作为案例，是因为它非常有代表性：
首先，M集团是一家成熟集团，拥有完善的应用架构，大家可以了解如何将新设计的产品与公司现有产品架构融合。
其次，分销业务场景具备足够的复杂性，既要支持公司对客户的运营管理，又要支持客户的自主管理，涉及的系统具备比较全面的功能。
再次，分销业务模式涉及复杂的多层级子母账号管理和组织机构管理，这是B端产品设计中的典型问题，也是设计的难点。
最后，很重要的一点，案例中提到，IT部门要实现的系统，未来还要做商业化售卖；实际上这种模式也是国内很多公司在实践的方法，当甲方企业的自研信息化、数字化建设到一定水平后，都会成立相应的科技公司，将自己的系统商业化改造后对外售卖，追求新的业务增长点；
另外如果把案例稍微改一下，M公司请的是外部IT公司来开发实施，同样也很有代表性。国内很多IT厂商，都会借着一个行业领先客户做一套系统，最后产品化改造后，卖给更多同类客户。
在B端软件产品领域，很多时候创业的起点并不是通过对市场的分析找打一个机会进入，而是因为有了一个标杆客户，围绕这个标杆客户项目制的设计一套系统，最后理解吸收客户的最佳实践，融入自己的产品灵魂，进行产品化改造，卖给更多同类客户。当然，多数情况下，B端软件产品的创业者都是在行业中已经摸爬滚打多年的资深人士了。
为了让大家更加聚焦产品设计而非业务规则，我们将会对一些无关紧要的业务细节做处理，大家阅读时请重点关注业务分析、产品设计的思路，忽略案例中可能存在的数据和流程上的小瑕疵。
制订工作计划
假设你是产品经理，接到公司安排的这项任务：在2~3个月的时间内搭建一套支撑分销业务的软件系统，你会怎样入手呢？这是一项大任务，产品经理首先需要做的是梳理工作思路，拆解任务，并制订时间计划，只有严格遵循时间计划执行工作，才能保证整体工作有序展开，如期落地。
在制订项目计划时需要略微卡紧节奏，我们按照两个月来安排，这样能够为各种意外情况留一些应对时间。假设目标是两个月时系统一期上线，进行倒逼排期：最后一到两周联调，往前三到四周开发，最开始的三周完成业务调研、方案设计工作。当然，这只是产品经理初步安排的时间表，接下来需要尽快了解更多信息和情况，才能做出更合理细致的时间预估。
分销平台项目整体计划表
上图是一个简化版的甘特图，虽然简单，但非常实用。左侧列出了拆分后的具体任务、负责人、进度，右侧列出了项目计划的时间周期，采用了比较粗的周粒度来计划时间，这样，任务的先后顺序、时间计划就都清晰了。在刚开始的阶段，这个表格可能只是产品经理自己的行动计划，并没有向团队或项目组展示，但是它可以让产品经理对事情有基本的判断和预期。随着工作的深入，工作表会被拆分得越来越细，甚至细化到天，每日跟踪计划和风险点，保证项目如期进行。
当我们接手一件比较复杂的工作时，制订明确的工作计划是一种良好的工作习惯。即便是个人管理使用，梳理思路并拆解出关键任务和计划的时间点，也是非常有必要的，会让自己感到踏实，有节奏感。如果没有进行时间管理，则很容易感到焦头烂额，难以控制。因此，不论做什么事情，都应该先从总体上理清思路，列好时间计划。
制订好工作计划后，我们就可以进入业务调研环节，不过在此之前，我们还有两个重要话题需要继续讨论下。
精益创业与PMF
在B端产品的总体建设流程中，我们从工程实践的角度，介绍了B端产品设计研发过程，但大家也要认识到，一款商业化软件产品的运作，是理性和艺术相结合的工作，把一个点子变成一门成功的生意，是相当有挑战的事情。
在传统的软件研发模式中，一个新产品的诞生，从前期的市场分析、设计，到投产、销售，要经历一个相对较长的周期，有时候甚至可能需要花费一两年时间，结果上线后，发现市场需求已经发生了较大的变化，设计出来的产品已经不符合最新的诉求而卖不出去。
为了降低新产品设计研发的风险，针对高科技企业的精益创业方法论由Eric Ries在2008年提出，并于2011年总结成《精益创业》一书，鼓励创业者通过快速迭代，小步快跑，不断试错优化调整的方式，来迅速检验产品市场，缩短研发周期，降低运作风险。
在精益创业的基础上，Benchmark资本的联合创始人Andy Rachleff提出了PMF的概念，进一步强调了对初期市场的验证与评估。
PMF将新产品市场评估为四个阶段。
概念阶段：提出了早期的创意想法和产品概念；
原型阶段：将产品的外观样貌实现出来，可以让潜在客户试用并提出感受；
MVP阶段：定义产品的最小可行性版本并实现；
PMF阶段：将MVP版本投入市场，检验市场接受度；
虽然MVP和PMF的概念都是为了解决C端产品而提出，但是其中蕴含的思想对B端产品依然有很好地借鉴价值；即便业务型B端软件比较厚重，但在商业层面的运作上，一定要始终秉承尊重市场，尊重客户，找准定位，快速迭代的理念。
【资源推荐】
我们身处VUCA时代，VUCA时代的商业创新与实践需要全新的思路和方法论，Eric Ries的《精益创业》，以及Ash Maurya的《精益创业实战》，正是针VUCA时代高科技产品创新的商业实战指导，教你如何将一个好点子变成一门好生意。尤其是《精益创业实战》，书中给出的精益画布，是对《商业模式新生代》一书中的商业画布的升级版，我认为更适用于软件产品的场景。在后续，我们还会深入探讨精益画布工具的应用。
为什么互联网公司都喜欢自研软件系统
相信很多人都有困惑，为什么互联网科技公司，都喜欢自研业务系统，而不是采购市面上成熟的商业软件套件呢？各类商业软件发展了这么多年，再加上各种SaaS产品，很多业务问题都有丰富的软件解决方案，为何不直接使用，而要费力的从无到有去做自研呢？
这个问题曾经困扰了我很长时间。我刚毕业的前三年，在一家外资保险公司做开发，所有系统都是外采成熟的商业软件产品加定制化开发，后来去了转行产品经理，所有业务系统都是自研，当时非常不理解，觉得很奇葩，但随着工作的深入，后来又经历了两家独角兽公司整个业务平台从无到有的搭建过程，对这个问题思考了很久，也慢慢有了答案。
为什么互联网公司都喜欢自研业务系统？我认为原因有以下几点。
业务特殊，没有现成商业软件可以采购使用
首先，最基本的一点，互联网公司很多业务形态比较新颖，对应的业务运营模式也比较独特，面对这些特殊的、创新的业务运作模式，很难从市面上找到一款直接能够使用的成熟管理软件。
例如，美团的骑手管理，这种业务形态本身就是从无到有的创新产物，没有任何参考，而对应的管理软件系统，更没有相关的沉淀可以借鉴，所以必须由产品经理和业务人员一起，根据自身业务特点，从头设计运作流程、机制，以及对应的软件系统。
即便是对于某些经典成熟的业态，互联网公司也有很独特的运作管理模式，例如美团对于地推团队的管理，虽然属于CRM SFA的领域和范畴，但是基于餐饮门店这种强POI管理的CRM系统，以及和客户的经营管理等数据、操作做深度集成，市面上任何一款商用CRM产品，都很难做简单改造就能适用，甚至做定制化改造的成本可能比自研还要高，而且软件的底层架构可能也不适合调整。
业务变化快，调整频繁
互联网公司的一个显著特点，就是业务探索开展特别快，业务调整取消也特别快。例如，很多O2O平台曾经尝试切入早餐业务，有些可能做一年就停了，有些甚至做半年就停了，这样的节奏，在传统企业是很少见的。
不论是成熟的互联网公司做各种业务探索尝试，还是创业中的互联网公司不断调整方向去寻找自己的主营业务模式，在互联网公司工作的人可能都深有体会，很多项目上马快，下线更快；有些项目三个月以后落地的思路，已经和当时的规划预期完全不同。
例如，某宇宙条公司曾经要迅速切入1对1在线英语赛道，短时间投入大量资源瞬间补齐团队，杀入市场，但没过多久，业务又产生重大调整，人员大量转岗。再往后，公司又再次将教育放在战略核心，更进一步的加大资源投入。
面临这么快速变化和调整的业务，背后对应的业务运营和管理模式更是需要不断调整、变化，在摸索中前进。而对于支持业务运作的管理软件系统设计来说，这将是一场灾难。
管理软件的建设，最希望面临稳定的业务，规范的管理体系，经过抽象设计，实现优雅的规划和迭代计划。如果业务本身多变，经常推倒重来，对于管理软件设计人员来说，将会非常痛苦，首先无法准确的做软件抽象，其次即便准确做了设计方案，也有可能被一个变化调整轻易地摧毁。更痛苦的是，用心设计的系统，辛苦上线后，还没用多久，业务就取消了。
这些都是互联网业务中很现实的客观存在，互联网本身就是在各种天马行空的探索中找到突破、进行奇袭、取得奇胜。作为企业内部B端产品经理，很重要的能力和心态，就是通过自己的专业能力，帮助企业以最合理的资源投入取得业务的胜利。
面对这样快速变化的业务，如果一上来就选择外采软件，那么会带来非常多的问题，比如业务模式不固定，外采商业软件无法做落地实施；比如实施周期长，还没上线，需求可能早已完全改变；比如成本高，其实只需要个滑板，但必须买来个小汽车，还得把车身卸掉才能用。
可见，面临这种多变的业务，对于内部管理软件系统建设，其实现思路和传统IT做项目完全不同，必须本着能用Excel就不上系统，能做个滑板就绝对不要滑板车的套路，用有限的资源投入，最高效的支持业务。
系统从0开发，包袱轻，初期迭代优化速度快
面对多变的业务，从无到有的自研业务系统，还有一个很大的好处，就是没有任何历史包袱，可以任意的发挥，快速的上线。虽然做的系统一团糟，但是迭代快，可以很好地支持更加混乱的业务。
在很多产品专家看来，很多互联网创业公司的内部业务平台，设计的简直不堪入目。但重要的是，正是这样的系统，助力公司业务一路狂奔，收入倍增，融资从A轮一路来到C轮。
有经验的B端产品经理都知道，如果想把软件系统做的完美、灵活，第一需要业务核心稳定不变，第二需要较多的资源投入和沉淀。对于初创互联网公司或新业务来说，显然时间就是生命，业务在前端飞奔，后端的系统建设必须硬着头皮跟上。
在这种情况下，从无到有设计的系统，最容易跟着业务快速跑，而且越简单的软件底层，早期的开发和调整也越快。如果一上来就采用一套成熟的商业软件套件，自以为可以灵活定制快速支持业务，实际上是不太可能的，因为你根本无法想象业务变化的有多快。
基本上所有的互联网创业公司或新业务的内部业务系统建设，都会经历这么几个阶段，第一个阶段是飞速发展，疯狂支持业务需求，不考虑架构合理性；第二个阶段是业务继续飞速发展，系统bug满天飞，改bug严重制约了新需求研发，但只能咬着牙继续抗；第三个阶段，是业务增速放缓，或者稍微可以喘口气，系统满身补丁完全跑不动，此时投入大量资源拆了大重构。
一般公司在A轮和B轮融资时，处在阶段一或阶段二，到了C轮时，必须完成阶段三。如果到了D轮，才进入阶段三，那么系统问题以及技术债，会显著地影响业务发展。
系统架构可灵活调整
做业务系统设计，要考虑企业应用架构的合理性问题。但很多时候，架构合理性，和投入资源以及交付时间之间，存在着不可能三角。你不可能既要求架构合理，又想要投入资源少，并且上线时间快。
我自己长期以来的实践观点，是在创业企业或业务内部，只要是为了业务快速发展，不错过增长的时间窗口，就允许存在不合理的架构设计。试想，很多时候如果过多考虑所谓架构合理性问题，业务最后都黄了，合理架构还有存在的前提么？
自研业务系统，在考虑新系统和现有的应用架构的整合、融入、抽象、复用时，可以给研发人员充分的自由度来实现各种设计方案，在成本、时间、架构合理性之间取得最优解。
试错成本低，投入产出比高
通过以上几点，我们已经可以看出，在互联网企业多变的业务探索中，必须谨慎的投入资源实现业务系统来支撑业务开展，而自研业务系统，相对来讲，是一种更可控、成本相对更低的选择。
试想，某新业务开展，需要CRM软件支持，但经过评估，符合业务诉求的市面CRM软件，加上定制化投入，最低算下来也得大几十万，而且实施周期长。
如果选择自研，基本上一个高级PM + 三个后端RD + 半个FE + 一个QA + 半个UE，两个月的研发时间可以提交一个能抗半年的MVP版本，假设以上岗位平均企业用人成本在4万/月，基本投入也只需三十多万元。
可见，只要产品经理能够把握核心需求，充分调用资源，只做不得已功能，那么整体研发资源投入还是比较可控且合理的。其实算一算经济账，很多功能即便暂时不做，招聘几个工资比较低的初级业务员手工去处理，也都是比较好的选择。
对于互联网公司来讲，探索性业务被随时叫停，投入了不少资源的自研系统被关停，这都是很常见的现象。
所以，自研系统要跟着业务一起摸着石头过河，跟着业务一起成长壮大，在合适的时间点做壮士断腕的重构。千万不要一上来就画大饼，搞得过于复杂，浪费人感情不要紧，关键耽误业务啊！
不仅互联网公司，这两年越来越多有实力的传统企业甲方公司，也开始逐步采用自研的方式建设系统。我接触过的很多金融、制造、零售、房地产领域的传统企业IT部门，都在持续扩大研发部门编制，进行自研软件开发。
和这些企业沟通交流后发现，主要原因在于首先企业对数字化建设的重视程度越来越高，投入资源也越来越大；其次在于以前做业务，模式相对稳定，外采的系统做一些定制化就够用了，但是现在随着市场竞争的家居，企业需要作出灵活多变的响应，这对软件研发也提高了要求，外采系统虽然成熟，但总是得削足适履适应企业自身业务，而且响应不一定快，因此很多CIO决定自研系统，来快速支持业务，这和互联网的思路一致。
对于企业如何应对灵活多变的业务，Gartner提出了双模式IT的理念，将IT体系分为敏态和稳态两个体系，这个话题在本书进阶篇关于应用架构的部分会进一步探讨。
说了这么多，还想再补充一点，并不是所有情况都建议自研系统，某些情况下就完全不适合。
比如说，报表引擎这种产品，高度的标准化，而且买来就能用，自研本身难度也高，就没必要自主研发了。另外，类似于FMS、OA这类业务非常标准的管理软件，也可以考虑直接采购成熟产品，当然，有钱的互联网巨头不在此列，对于巨头来讲，万物皆可自研，我甚至见过自研财务总账系统的互联网公司。
作者：杨堃 数字颗粒创始人，前viplid产品总监，《决胜B端》作者，聊聊产品、职场、成长，也会分享经典的B端文章。
