自2014年4月参与的一个农业生鲜项目创业失败后，一直未在该公众号及一些平台上上分享过内容；一是时间不允许，二来开始为生计奔波，想静静～（想静下心来干一些事情，毕竟我还很年轻）
这三年来一直从事于零售行业，做“互联网＋便利店”相关产品项目的研发与产品设计；3年来对这个行业，对做过的产品有过深刻的体会，经历了各种痛苦，也曾彷徨迷惘，到目前为止暂且不论项目的成败，对于我个人职业生涯的成长帮助非常的大！日后在此会对这3年来做项目的点点滴滴进行分享，希望对大家有所启发，对我也是一次复盘。
昨日在（注：产品经理社区是国内最早的产品经理社区）看到一位朋友提问“产品经理在系统后台如何进行模块化设计？”；看到此问题后，我内心深处很不平静，因为我仿佛能回想起这三年来每个日夜为此问题所付出的代价及走过的弯路…就在前两天，在“人人都是产品经理社区”（注：也是一个产品经理、产品爱好者的P分享学习交流平台）看到专栏作者：杨堃发布的一篇文章《深度｜从一个故事说起，谈谈企业应用架构的演变史》后，他文中所描述的案例与我这3年来所经历的项目中需要的问题非常的相似，他总结的非常棒；阅读完后，很有启发，今日总结之后分享给大家，希望能对各位有所帮助；
＝＝＝＝＝＝正文分割线＝＝＝＝＝＝＝
做后台系统设计之前首先先思考两个问题：
1、什么是后台？
顾名思义，就是与前台相反，前台我们都知道是用户查看信息，提交信息的地方，那么后台相应的就是创建元素信息，存储信息，处理信息的地方，他也叫后台管理系统。
打个比方，前台就好像我们去餐厅里，坐下来看菜单，然后告诉服务员我们今天要吃什么，服务员就蹦蹦跳跳的到了后厨，告诉厨师要做哪些菜，厨师记下桌号和菜品，就开始制作了。这里的后厨实际上就是我们所说的后台系统，而那个厨师就是后台管理员。
2、那后台都能做什么？给谁用？
就像上面所说的后台通常的作用就是创建信息，存储信息与处理信息，他管理着整个产品的正常运转。在论坛里后台管理者可以删帖，发帖，封号，创建账号，在门户网站可以添加新闻，增加栏目，增加评论，在电商系统里可以上下架产品，处理物流信息，做促销等等，功能强大吧。
不过强大的背后就会遇到问题，那就是越是功能强大，越不能一个人来完成所有部分，所以就有了「分权限管理」管理者可以细分成很多块，各司其职，提高效率。比如我正在编辑文章的微信后台，就包括管理者与运营者，运营者只能登录与群发信息，更高级的操作需要管理员授权或是不开放，电商网站更是多角色的典型。
一般来说，后台系统的设计都会按照各业务线需求，对模块进行划分，比如要设计一
个简单的电商交易平台，那面它的管理后台就需要具备以下功能模块：
所有系统的后台设计的目标是：提高业务运营管理效率，简单易操作；
故，一切不以提高运营效率和简单易操作的系统后台设计都是耍流氓，都在坑老板～～
下面以一个传统零售行业电商业务解决方案－后台系统设计为例，来简单的阐述下如何对电商后台分模块设计，并且如何从简单到复杂一步步迭代，让系统变的越来越强大越来越高效！
故事的开始，随着马云先生提出“新零售”，伴随着互联网＋便利店、互联网＋零售，互联网＋餐饮……等一切和互联网有关联的都火遍了大江南北，越来越的人开始参与到互联网＋的创业和从业浪潮中。
1、XXXX年XX月XX日：公司开了第一家零售店便利店：
上图采用了ER模型来描述三张表的逻辑结构，*和1的含义是表和表之间的关联关系，例如采购记录和商品信息是多对一关系，即采购记录表中的每条数据只能对应商品信息表中的一条数据，商品信息表中的一条数据可以对应采购记录表中的多条数据。
因为你采用了科学的数据表格管理，记录了门店的所有采购入库和销售数据，这让你的经营变得井井有条；通过这些原始数据，你可以准确的管理库存、计算利润、掌握畅销品和滞销品，还能通过数据透视表制作销售日报和月报。
实际上你通过以上三张表格管理自己的生意，已经是一个管理软件的雏形了。
所有的软件系统无非都是对数据的增删改查操作；
可以说，如果使用得当，Excel也可以做出一套小型的软件系统。
2、XXXX 年 XX 月 XX日： 从一个小店发展成为一家小型超市；
因为你善于使用信息技术来协助你做生意，你的买卖发展迅速；很快，你将小门店升级成为一家小型超市，并且雇佣了几个店员来帮你。
作为店长，你兴奋的绘制出自己的第一张组织架构图，梦想着事业会继续壮大。
经营的货品更加丰富，日交易量成倍增长，并且有好几名员工需要做数据录入分析工作，这时Excel已经难以满足经营管理的需要。
因此明智的你在开店之前，就决定采购一套ERP软件来协助你管理超市。
因为你还处于创业期，资金有限，通过仔细挑选，你选择了一套轻量级的ERP，并且只购买了其中的几个核心模块，这样既可以控制成本，又可以让你经营的软件设备升级。
3、XXXX 年 XX 月 XX日：开通了微信公众号建立了简单的CRM
为了更加准确的理解、认识你的客户，同时也为了能够拉近你和客户的距离，你打算通过CRM软件进行更加科学的客户管理。
你设计了一套会员积分制度，所有的客户都能免费办理会员，这样你就可以记录下关键的客户信息，而且你的小伙伴建议你开通一个微信公众号，让客户能够通过微信来查询自己的积分。
为了实现以上想法！你追加购买了几个ERP的模块，虽然ERP中也包含了CRM模块，但是研究后你认为内置的CRM模块功能有限，不支持对接微信，营销功能也不够强大，因此你新购买了一套CRM软件，和ERP进行了一定程度的对接，同时申请了微信公众号，找外包公司做了一些定制化开发。
可以看到，核心的客户信息资产模块都在CRM中实现，其中内置了营销模块、消息推送服务Msg模块，包括SMS、EDM（Email Direct Marketing）和微信消息推送。
1、CRM主要聚焦客户资料的管理和营销服务，主要用户为店长和运营人员；
2、ERP主要聚焦于超市的进销存以及财务业务，主要用户为营业员、出纳、采购、库管和会计。
请注意：这里已经产生了应用架构设计的概念。公共号、ERP和CRM每个系统都为了解决某一大类的业务问题而存在，有各自清晰地定位、分工和目标用户，每个系统相对独立又互有关联，内置若干模块，每个模块都是为了解决某一大类业务问题下的某一小类问题而设计。
在这张图中我们使用了分层描述，靠近C端用户的微信公众号在最上层，支持业务运转的ERP放在中间层，偏底层的客户信息集成CRM放在最下层，这样可以清晰地看出几个系统的层次关系，同时也在一定程度反映了系统和业务之间的逻辑对应关系。
4、XXXX 年 XX 月 XX日：生意越做越大，小便利店已经发展为了中型连锁超市，并有5家加盟店；
业务进展很顺利，你已经开了五家中型连锁超市了，员工数量达到了几百人。
公司走上了正轨，标准化的管理分工已经成型，不同职能单元各司其职。
为了有效管理团队，并且让内部流程更加顺畅，你邀请专业的IT咨询公司帮你重新梳理了公司的业务目标、组织架构、运营流程，通过引入OA、HRM以及重构ERP等手段，对不合理的制度，低效的流程进行了改造。
公司成立了信息技术部，其中项目部配合咨询公司以及软件外包公司进行系统改造或实施新系统，运维部负责保证服务器、网络的稳定。
数据对公司发展越来越重要，所有的管理决策都应该基于对数据的分析和判断，因此需要强化公司的数据分析能力。
需要启动数据仓库（Data Warehouse）和BI（BusinessIntelligence）项目，原因有几点：
1、ERP系统和CRM系统都有报表模块，但两个系统的数据相互孤立，不利于整合分析。
2、业务系统的底层数据结构并不适合做复杂的数据分析，常见的多维分析更需要一套数据仓库常用的星形数据结构和雪花型数据结构。
3、成熟的BI软件套件可以让你的报表分析与多维数据探查更轻松，其中的仪表盘更能够让你轻松掌控公司全局的核心指标变化。
4、企业经营中很常见的一个问题，就是经营分析指标统计口径太多，造成管理混乱和沟通障碍，除了在管理上规范公司级指标的定义，也需要一套底层数据架构，消除上游各个异构系统的孤岛和屏障，统一管理汇总数据和指标计算。
目前公司的业务系统还没有到非常复杂的阶段，但数据仓库可以帮助企业更快速高效准确的理解、捕获、使用数据，做好基础建设工作，培养员工的数据分析意识和方法，通过数据来进行决策。
随着业务的拓展和系统复杂性的提升，数据仓库的存在价值将越来越明显。
在数据仓库项目中，同时构建了数据集市（Data Mart）。数据集市介于BI展现层和DW数据底层之间，是数据仓库的数据子集。
数据仓库的服务对象通常为全公司或全集团，但是不同部门可能有自己的数据分析诉求与指标管理诉求，这时候通过统一的数据底层，封装出针对某个部门使用的小型数据集市，可以保证数据流的合理性、可追溯性，同时研发部门可以完全复用DW和BI的技术能力，轻松地设计实施DM。
如果希望数据仓库在企业中真正发挥作用，不仅仅是软件系统实施问题，更重要的是公司层面的经营分析思路体系化，指标管理规范化，以及数据部门组织架构、与业务部门合作流程设计问题，同时还需要提升全员数据化管理运营的概念和意识。软件本身并不能解决企业的问题，只有配套的架构、流程、制度与意识，才能发挥软件的功效。
5、XXXX 年 XX 月 XX日：公司开启开展B2B业务，主要目的是解决超市及零售便利店订货配送问题；
由于公司经营良好，很多商品可以从供应商处拿到很好的价格，经过供应商授权，公司决定开展2B业务，成立了大客户销售部，公司将作为供应商的B端渠道，挖掘企业客户。
为了让销售工作高效展开，对销售人员进行严格的过程管理，同时也为了保留客户资料，避免销售独占客户资源，根据CTO建议，公司决定实施操作型OCRM（Operating CRM）项目。
同时由于各部门经常出现个性化的软件开发诉求，软件外包维护的成本高，效率低，公司决定招聘研发团队，用自己的队伍进行软件的二次开发。
一般来讲：B端客户的数据模型和C端客户差异非常大，B端客户模型关注组织架构和人员角色的描述，C端客户模型关注客户本身个人信息的描述，即便应用系统中将客户模型和操作型系统分开建设，客户模型一定会做成两套以支持不同的上下游业务系统。
上图为了简化表述，只绘制了一个模块“客户信息”，但该模块应该包含B端、C端两套客户模型。
实际上有的公司会明确将两套客户模型在应用架构中分开设计并且分别建设，以便更加准确的体现应用架构中的业务概念。
广义上来讲，CRM代表一种企业对待核心客户资源的管理理念和运营方法，CRM是一种概念而非某一个独立的应用系统。
大型的企业涉及多条业务线，不同的业务线有不同的客户群。企业需要有统一的客户视图和管理理念，以及强大的IT系统支持，来实现准确的客户接触点管理，充分挖掘客户群体实现精准销售，积极有效的维护企业和客户的关系。
CRM体系化的系统建设中包含了客户建模、会员积分管理、营销中心、销售线索和过程管理、小型数据仓库或数据集市、统一客户视图、客户画像和数据挖掘、电话销售中心等等。
不同的企业对系统的划分和团队的管理各不相同，但所有CTO都应该明白CRM是一套应用体系，而不仅仅是某个单一的独立应用系统。
至此，我们已经绘制出一套一般企业的简化版应用架构图，以及一张常见的组织架构图。可以看到，应用系统的建设，是根据业务的发展变化逐步完成的，每个系统都有独立存在的意义和价值。
6、XXXX 年 XX 月 XX日：公司开始启动电商业务；
公司的零售业务发展进入了瓶颈期，CEO需要寻找新的增长点。
经过评估，决定开展电商业务，新成立了电商部，从市场上聘来了某电商平台VP作为部门负责人，直接给CEO汇报。为了学习互联网公司，以技术力量推动业务创新，电商部组织结构参考了一般互联网公司组织结构，有自己独立的研发团队，设置了产品岗位，产品技术总监给电商部负责人汇报。电商部受到CEO极度重视，给与极高自治权和最高资源支持，同时CEO还将之前线下的客服团队升级为公司一级部门，直接给CEO汇报，统一处理线上线下的客服与售后业务。
新业务开展，大家干劲十足，因为电商部产品技术总监和公司CTO之间不存在汇报关系，产品技术总监为了快速推进项目，所有决策基本只是告知CTO。产品技术总监作为纯互联网背景专家，认为购买现成软件套件不利于系统的二次开发和自主维护，长远来看会限制公司业务发展，希望整套系统实现自主研发。虽然CTO极力反对，但经过电商部负责人和产品技术总监的游说，CEO听取了总监的建议，并且总监承诺自己的研发团队效率极高，一定会在承诺之日交付系统。
产品技术总监设计的应用架构体系，包括PC和移动版的前端应用，以及完整的后端系统，包括订单、售后、客户信息、会员、营销、账号、CMS。此外，仓储、财务系统会接入现有ERP的服务，配送模块直接与第三方配送服务商系统对接。
对于这个架构设计，CTO比较不满，认为客户信息和账号管理不应该重复建设，而应该统一规划管理，但产品技术总监一心快速推进实施，对于信息技术部开发效率低的情况他早有耳闻，他可不希望被一些不可控力影响导致自己的项目延期，因此CTO的抗议他不予理会。
升级后的客服部门，新建了20人坐席的电销中心，以支持主要来自于线上的电话客服诉求。新成立的客服团队需要CallCenter系统开展业务，虽然CallCenter的主要服务群体是线上业务的客服话务员，但CEO为了在一定程度上安抚CTO的不满情绪，将CallCenter项目安排给CTO负责。CTO采购了一套成熟CallCenter来支持400热线业务，对此安排电商部的产品技术总监没有什么异议，但在CallCenter的实施中却出现了问题。
因为CallCenter系统只负责电话作业，其中的客户资料一般由上游系统提供。但是公司现有两套客户资料，一套是保存在CRM的线下业务客户资料库，一套是在线商城的客户资料库。
为此只能在CallCenter中新增一套客户库，将另外两套客户库数据同步过来，这样客服人员才能在CallCenter中查到公司级别的完整客户信息。
7、XXXX 年 XX 月 XX日：公司电商业务上线后，第一次架构升级；
电商系统如期上线，业务发展迅速，电商团队的运营和产品人员年轻，聪明，充满活力，思维活跃，玩法众多，电商技术团队响应迅速，产品经理和技术团队的无缝配合，让技术力量真正推动了业务的增长。
公司赚钱了，老板很开心。但很多问题也同时暴露了出来。我们先来看看之前的应用架构。
之前为了快速上线，有一些应用架构遗留问题没有解决。现在公司有三套客户资料库，线下客户通过微信公共号访问CRM系统中的客户信息，在线商城的客户通过线上商城访问e-Store系统的客户信息。
当客户致电400时，电销业务员（TSR）访问的是从e-Store和CRM同步过来的客户信息。
线上客户关注公共号后，查不到自己的资料，这让客户感觉很诡异。
线下客户想在线上商城下单，发现之前登记的账号不能使用，需要重新注册完善资料，客户很烦躁。
数据同步30分钟一次，有时候客户刚修改完资料再致电400，客服查到的客户信息不是最新的，让客户很生气，客服很苦恼。
有的客户喜欢打电话让客服改资料，因为客户资料是单向同步，客服无法协助客户修改资料，客户很气愤，为什么你们连这点服务都做不好！
很多客户在线上线下都消费，但由于在数据仓库中冗余出了两个客户对象，不论是线上团队还是线下团队，都无法做更准确的客户画像和跨渠道消费行为分析。
CEO很生气，找到CTO和电商产品技术总监，质问怎么回事。CTO回答，我们遇到了严重的信息孤岛问题！由于CRM和商城后台数据互相孤立，导致核心客户资源不同步，不统一，让公司无法得到一个完整准确的客户视图。如果要解决这个问题，必须对应用架构进行改造，并且
改造比较耗时。CEO很郁闷，没想到应用架构不合理会影响到业务发展，也没有想到组织架构的设计会导致应用架构出问题。
为此，CEO做了一些调整，产品技术总监实线向电商部经理汇报，虚线向CTO汇报；总体来讲产品技术总监对电商业务销售端负责，CTO对全公司IT架构管理和其他所有系统负责。
经过善意的沟通，CTO和产品技术总监的矛盾消除了，大家决定合力解决问题。
解决数据信息孤岛的方法很简单，那就是只保留一份客户信息库，这份客户信息库保存最核心的，与业务单元无关的客户属性和资料。至于积分、会员等扩展属性依然由各个应用系统维护管理。调整后的应用架构图如图所示；
将客户信息库独立，商城、CallCenter、CRM和微信公共号通过统一接口调用Customer Profile存储的核心客户档案，不论客户或业务员从哪个端口查看或修改信息，变化对其他端口都是透明、实时的。实际上这就是客户主数据管理MDM（Master Data Management）的设计理念。
在企业应用系统建设中，不可避免的会遇到信息孤岛问题，信息孤岛是指因为各种原因，每个应用系统独立建设时，没有和外界系统做良好的打通，导致应用系统之间存在流程或数据的孤立性，最终给业务带来严重影响。
解决数据信息孤岛的经典方法就是主数据管理（MDM）的思想，主数据管理通过应用架构的拓扑设计，配合相应的管理手段，帮助企业存储、识别唯一的关键数据，避免企业内部关键数据的冗余和不一致问题。
常见的主数据有客户主数据，商品主数据等。
主数据管理的设计理念应该自始至终贯穿企业应用架构的设计过程，需要注意的是，企业应该在合适的阶段实施主数据管理和治理。
主数据将应用架构变得更复杂，在初期阶段实施时需要投入更多时间和资源，而在企业发展的某些阶段，快速迭代上线意味着对商机的捕获和市场变化的迅速跟进，一个合格的架构师应该在应用架构设计和公司业务发展之间做出合理权衡，要根据现实的情况和资源，敢于在应用架构的和理性上做出妥协和让步。
主数据经常作为底层数据应用来管理，因此在架构图中我们将它和DW并列画在最底层。
8、XXXX 年 XX 月 XX日，公司应用系统全面服务化建设，第二次架构升级；
在企业应用系统建设中，不可避免的会遇到信息孤岛问题，信息孤岛是指因为各种原因，每个应用系统独立建设时，没有和外界系统做良好的打通，导致应用系统之间存在流程或数据的孤立性，最终给业务带来严重影响。
解决数据信息孤岛的经典方法就是主数据管理（MDM）的思想，主数据管理通过应用架构的拓扑设计，配合相应的管理手段，帮助企业存储、识别唯一的关键数据，避免企业内部关键数据的冗余和不一致问题。
常见的主数据有客户主数据，商品主数据等。
主数据管理的设计理念应该自始至终贯穿企业应用架构的设计过程，需要注意的是，企业应该在合适的阶段实施主数据管理和治理。
主数据将应用架构变得更复杂，在初期阶段实施时需要投入更多时间和资源，而在企业发展的某些阶段，快速迭代上线意味着对商机的捕获和市场变化的迅速跟进，一个合格的架构师应该在应用架构设计和公司业务发展之间做出合理权衡，要根据现实的情况和资源，敢于在应用架构的和理性上做出妥协和让步。
主数据经常作为底层数据应用来管理，因此在架构图中我们将它和DW并列画在最底层。
9、XXXX 年 XX 月 XX日，公司开始启动金融理财业务；
公司在寻找新的增长点，计划开展金融理财业务。公司的组织架构有了新的调整，管理模式也有了新的提升，形成了集团化治理模式，成立了财务共享中心，人力资源共享中心。
新设立的理财事业部，和零售事业部、电商事业部一起，调整为独立核算事业部编制，事业部聚焦经营和销售，集团层面给事业部提供基础运作支持。
信息技术部也与时俱进，将之前的需求管理部调整为产品部，信息技术部主要负责CRM、CallCenter、ERP、OA、HRM、DW、BI等应用系统，保证集团职能部门运
作，为事业部的应用系统提供基础架构和底层服务支持。
因为集团IT应用架构已经非常强健，理财业务的系统构建可以迅速展开，CTO和理财事业部的产品总监沟通后绘制了集团应用架构图。
理财业务只需要建设一套C端APP和一套基本的管理后台，而类似于客户数据、支付、Push服务、DW和BI都直接使用集团现有系统，无需重新开发。
10、XXXX 年 XX 月 XX日，公司开始构建企业通用应用架构对外开放，第三次架构升级；
第一层是对外系统。所有给企业外部客户使用的系统都在这一层，包括官网，普通用户或客户使用的C端。如果是类似于美团，天猫这种平台性质的业务，还会包括给商家使用的商家端。这类系统站在与客户接触的最前线，是公司实现商业模式的桥头堡。
第二层是对应C端系统的管理后台。常见的管理后台都会包含订单、CMS、商品等模块。每个C端业务形态都会对应一个管理后台，有些管理后台的模块可能会被抽离出来集中维护，例如风控，消息服务，客户主数据。
第三层是业务单元支持系统。绝大多数企业业务的开展，必然不能单纯靠线上的运作来实现经营，而可能包含电话销售，客服，地推，仓配等一系列业务单元共同运作。业务单元的运作需要强大的系统支撑。
第四层是职能单元支持系统。企业发展到一定规模后，必然会有完善的职能单元作为后勤部门支持业务单元的运转和企业的正常运作，例如法务、财务、人力、客服，每个部门的正常运转都需要相应系统的支持。
第五层是基础架构支持系统。信息化建设到达一定程度后，企业有必要将通用功能服务化，平台化，以保证应用架构的合理性，提升服务效率。这类系统主要给其他应用系统提供基础服务能力支持。
第六层是数据底层，和第五层类似，这一层主要集中在数据层面的统一和封装，对各个下游系统提供数据服务。
以上六层划分涵盖了企业所有的应用系统建设，每一个应用系统的存在都将定位在六层中的某一层。上图示例的系统涵盖了绝大多数正常企业经营运转常见的应用系统，在现实世界中，应用系统数量会远远多于上图所示，例如商业银行可能会有成百上千个系统存在。
但是理解一个常见企业的组织结构，部门定位，以及上述应用架构图形成的原因，可以让你更准确快速的理解、掌握、设计任意一个应用系统。
总结：
任何一次产品架构的升级都会伴随一定的策略及目标；
在不同的产品生命周期都会结合公司的业务及战略目标做出合理的组合；
＝＝版权说明＝＝
1、本人目前就职于国内首家“互联网＋便利店”公司从事做产品研发设计，擅长零售连锁、B2B供应链、互联网金融等产品设计，个人微信号：iweining；微信公众号nongbobowang
2、本文所分享的案例引用于人人都是产品经理专栏作者@杨堃（微信号公众号goYangKun) 分享发布的文章。若有引用版权问题，请联系本人，会及时进行修改出处。
3、若要转发本文请联系作者取得授权，否则后果自负。
