接触后台系统（主要是CRM系统）才刚刚足月，写下这篇出发点仅仅是自我沉淀，并不奢望能够输出一些有价值的观点。0.1版本主要设计比较“宽泛”的概念层面上的东东，具体的模块设计、后台构架之类的东西会放到1.1甚至2.1中。
1.背景
cherry是一个刚刚研究生毕业的产品汪，在接触到公司的CRM系统前，对后台产品基本一无所知。在最初的一个星期，跟着师傅做了几个小小的功能优化（从需求方获取需求，再跟专门对接的RD沟通，简单到连原型图都不用画）。后来组里业务发展的特别快，一线工作职责、流程发生了很大的变化，由只负责售后流程转变为售前、售后一手抓，于是系统后台也从主站的BD后台迁移到了我们组的CRM系统里来。恰巧这个时候我的师傅身体抱恙，整个迁移，就在我一个产品小白的折腾下进行（还好有个PM哥哥很nice地对我进行了指导，否则真的hold不住）。
系统迁移之后，基本就是对之前我自己设计的这个流程的不足进行各种打补丁（期间我还回学校忙毕业，离开了一个多月），再回来的时候，发现后台系统还是那个系统，只是各个模块下的功能点越来越多，整个系统显得特别臃肿，权限结构连负责的PM都搞不清楚。这个时候整个工作状态就是，业务提一个需求，产品跟进一个，开发做一个，整体后台系统和后台架构都比较混乱。究其原因：业务常见的使用场景、流程被我们拆散了，只是按照对业务的理解，贴着业务来做，导致功能过于分散，并且功能的复用比较低，同样的事情，这里做了一次，那里还需要做一次，这样，我们的后台就会变得巨复杂和繁琐，不便捷。
2.反思
2.1关于概念的思考
其实最原始的困惑源于对“后台管理系统”、“CRM系统”概念的界定，没有人告诉我什么算是后台管理系统，难道给自己人用的就是后台系统？什么是CRM系统，难道存有客户资料的系统都是CRM系统？说实话，我至今对这两个概念都没有彻底弄清楚。为了能输出一个像样的文档，这里我只能借用他人的思考和定义。
后台系统，在目前接触来看，主要分几种：管人、管事、管物。管人的，有对内和对外的两种类型，对外的CRM（客户关系管理）、对内的考勤系统；管事的，简而言之，就是人可以做什么事、可以怎样去做事，这种最经典的就是数据统计后台、业务流管理后台；管物的，主要是指电商类型的商城管理后台，用于管理商品的交易
如果按照上述所说，cherry的CRM系统兼顾管人和管事两个智能，基础建立在“客户的资料”而延伸出了各种业务流程操作。
cherry的CRM目前具有的功能包含了销售、服务和部分运营三大块。当然目前也只能进行粗浅的理解，还需要不断地沉积才能深入了解更贴近本质的东西。
2.2 系统架构
其实在这里用“系统架构”这词有点夸大的嫌疑，也许用“功能模块”会更贴切一些。
从本质上看，后台主要有权限管理、工作流、记录流三大方面。可以归结为一句话，谁可以对什么进行怎样的操作，需要产生什么记录：简称who-where-how-what
其实在我通俗的理解里，组织架构（权限系统）就是一个系统的骨架，工作流是血液，而记录流则是肉体。在刚刚开始接触工作的时候最被我忽视的就是骨架——权限系统，也觉得这货是个复杂的东东，果然没错，后来也了解到权限系统这个东西，在系统初期确实被考虑的较少，往往都是待系统较为成熟的时候会进行改善。
而在cherry的CRM系统中，主要的模块在师傅的指点下分为了四个部分，虽然说Cherry也不能完全理解：组织结构、商家关系、过程管理、数据报表。其实套用刚刚的三大方面，商家关系、过程管理可以一并视作工作流的范畴。
