运营总监进阶之：了解平台系统架构技术常识
如果说产品经理是产品的“生父”，那么研发完全可以算作产品的“生母”了——因为当产品经理规划设计好产品“DNA”（原型）之后，而真正需要通过“十月怀胎”来孕育和赋予产品血肉之躯及形态生命的，必须是研发。
而运营，通常被当做产品的“养父母”——对于背负培养产品“成才”重任的运营而言，不仅需要与产品经理能正常沟通，若能具备与产品的“生母”研发人员直接沟通的能力，则对运营过程中的产品问题优化及新需求提报，都会十分有益。
电商平台显然也属于产品范畴，而且是最复杂的产品——是由不同子功能模块的产品有机集成、且能同时满足不同类型用户主体使用的系统性产品。
其实电商运营总监也可分为很多类型，其中一类是完全依托于天猫或京东等第三方电商平台成长起来的品牌商家电商运营负责人，这一类运营总监的核心职能是以店铺的推广引流、商品信息策划包装、促销活动、店内数据分析为核心职能，基本没有太多机会熟悉关于电商平台系统模块的一些技术知识。
另一类就是天猫、京东、当当、小米商城、华为VMALL、海尔商城等自营电商平台自身的运营负责人类型，这类运营人员不仅具备关于电商用户、内容、活动、促销、数据等运营知识技能。同时也拥有更多关于平台产品运营以及产品系统技术的知识经验。
而后一类运营人员可以说更具备产品的视野及思维，更容易与产品经理或研发经理交流沟通，无论是对平台产品的运营优化，还是对运营功能工具需求的优化，都明显更具优势。
而且在从运营专员进阶运营总监的上，随着段位的提升，必然要承担更多关于平台综合管理的职责和义务，因此拥有更综合的运营知识经验的人员，也更容易获得职位晋升的机会。
此外，对于自营平台运营总监而言，熟悉掌握一些关于电商平台系统功能模块及平台系统架构的一些基础应用知识。不仅对平台业务的中远期运营规划、平台产品功能需求的提报优化十分有益，而且对于新平台在建设初期的技术选型评审，也意义重大。
对于互联网平台系统研发而言，最关键的是平台系统架构。平台系统架构有业务架构、应用架构、数据架构和技术架构四大维度。架构不仅关系到平台的基本性能：稳定性、可靠性、安全性、扩展兼容性等。当然也是直接关系到业务处理负载能力和用户交互体验的。
但后面两个数据架构和技术架构由于技术专业性太强，远超出运营总监的必须掌握的业务知识熟悉范畴。但掌握一些业务架构和应用架构的知识，对平台产品的运营和效率优化，还是很有帮助的。
淘宝平台在今天看来风光无比，双11销售额年年是芝麻开花节节高，但实际其内部从2003年发展至今，随着用户规模、业务数据量级的爆炸式增长，一直在不断的进行增加、调整优化平台的软硬件架构，几乎每隔2年就会有一次比较大的调优动作。从LAMP——IOE——JAVA双层（应用/数据）——JAVA三层（应用/服务/数据）——阿里云架构（应用/服务/只读数据迁云）
因此，对于我们这些外行而言，系统架构绝对是一门高深而复杂的学问，因此非技术背景的爆君，也只能纯粹从概念应用层面去理解讲述。
产品业务架构——即根据平台的系统生态规划及业务功能流程，平台必须提供或实现的配套功能或子系统模块，以及这些子系统模块的业务协作耦合关系及流程规则等。（电商系统的常用业务应用功能模块，后文详解。）
产品系统业务功能架构主要基于平台的业务生态规划及需求。任何一家企业规划的任何一个电商平台，都很难从市面上找到直接可用的现成系统原型。
因此几乎所有稍具野心和追求的互联网平台（非品牌B2C商城），都会以自主开发的系统为主，最多只是采用相对接近的基础开源系统打底，配合大量的二次开发工作来寻求上线进度与功能体验的平衡。
系统应用架构——涉及到业务、服务及资源的分层分布等问题，如表现层、业务层、服务层、核心应用层、数据层、资源层等。
这涉及到平台软硬件资源的部署分布、平台性能强弱、用户交互响应体验等问题。更严重的是还关系到平台常规业务量与峰值的负载均衡、系统抗能力以及未来平台业务的扩展兼容需求等。最后，系统的可运维性，也是极其关键的一点。
爆君当年在同洲电子负责电商业务时，曾因为公司早期采购的商城系统峰值订单处理能力不足，官网商城搞一次预约抢购活动，就会宕机一次。后来又追加花费了几十万采购CDN服务，稍微解决了些问题，但这显然不是长期解决方案。
是从传统电商资讯门户网站沿袭而来，而电商平台最大的内容是商品资讯，因此电商CMS也就是商品信息发布管理系统。此模块功能已十分成熟。
电商平台的CMS，除了要考虑要SKU管理特性外，通常还需要考虑结合与促销功能的结合，如价格方式的灵活多样，优惠券的关联使用等。
订单系统最难的两大点：第一是并单与拆单；第二是峰值处理能力。这两点可以说是考量电商平台订单业务能力的关键。
尤其是限时秒杀和预热抢购盛行的当下，爆君当年经历过多次秒杀抢购时宕机的经历。当然，在B2B平台中，对这两点的要求可能会大大降低。
CRM并非电商平台首创，而是传统商业沿袭多年的客户关系管理系统。但电商时代，为了区别传统的CRM，通常称之为e-CRM。但这也仅仅只是一个非严肃的概念而已，采购CRM系统绝对不能只看名称，仍然需要以实际试用评审为准。
电商CRM系统的几大评审关键点：用户的基本属性画像（淘宝的买家云图等）、会员等级权益、触达联系方式、消费习惯（RFM：近期消费、消费频次、消费金额——包含一定成都的用户活跃、复购、贡献等考量因素，但并不相同）、用户终身价值分析（CLV模型：历史价值、当前价值、潜在价值等）
通常包含入库（含质检）、出库、调库、虚仓、盘点等管理功能。在电商平台中，尤其是B2C平台，WMS通常是与OMS实时对接的，因此也包括含一部分订单的分拣处理和打单等衔接功能。
WMS系统的考量点同样不外乎三大方面：安全、效率、成本。WMS系统涉及的技术应包含以下几类：信息技术、无线射频技术、条码技术、电子标签技术、数字视频技术等。
ERP字面含义为“企业资源计划”，实质是基于企业供应链的制造与资源管理系统。几乎是所有实业型企业都会用到ERP系统。
狭义的ERP通常指进销存系统，广义的ERP应包括人、财、物三合一的综合管理功能。向前对接MES生产制造管理系统，向后对接FMS财务管理系统。
虽然传统的SAP、Oracle、Infor、IBM等ERP软件供应商拥有几十甚至上百年历史，但是客观的说，绝大多数企业的ERP系统实施及使用状况十分不理想。
一是ERP系统的功能十分庞杂，而且基本都是软件时代的系统交互设计逻辑，而非互联网的产品交互设计逻辑，在互联网用户看来“”的设计无处不在。
其次是绝大多数企业只使用了所购买ERP系统中，不到30%的功能，而绝大多数功能因不太适用，或者使用麻烦、培训学习成本高等因素而不实用。
第二、客服席位管理，包括客服席位智能自动分配、客服通话自动记录、通过记录抽检、客服KPI统计考核等；
Callcenter系统由于需要识别电话来源的用户信息，因此需要与CRM系统做打通。通常有第三方的子系统模块但也有部分CRM集成了CallCenter的基本功能。
除以上子系统模块外，电商平台系统通常还有其他一些较小的功能模块，如：促销管理、广告管理、数据统计等子功能模块，在此不做展开。
传统企业转型互联网平台时，经常在规划打造一个极其庞大的平台生态系统时，但研发团队仅有不足10人，按前后台、语言种类、或规划、开发、测试等职能一切分，实际每个岗位只有1人。
也有不少公司非常技术的力量，不仅所有的产品规划职能，划归技术之下，而且甚至还有更极端的，是把运营职能，也置于技术下面的奇葩方式。
也有一些企业对平台规划极其严格慎重，甚至某一个小功能老板都要亲自过问，但是在做基础系统采购选型时，决策非常草率。
有的公司纯粹是基于价格便宜考量；也有的公司是因为某位技术负责人的片面意见而做决定。而技术负责人即使在技术上很专业，但鉴于其部门立场缘故，一定会选择对其部门绩效KPI最有利的基础系统原型。
如果真正采用招投标的评审机制，由系统商深入的各自系统的功能特性优势，并选择多家系统原型进行横向的对比评审，总能发现一些前期未考虑到的问题或需求。
从平台使用角色的角度考虑，进行基础系统选型，也应集合相关平台使用的业务部门进行集体评审选型。这样才能在平台系统的基本功能满足度、各使用主体角色的某些特殊需求满足度、平台业务负载能力、二次开发难易度、平台兼容性与扩展性、未来运维难以度及成本开支、平台上线进度等综合维度进行平衡择优选择。
而平台系统选型的坑，可谓是“一入平台深似海，从此成本是人”。平台如果选择不当，除了烧钱外，更是对平台业务的正常开展、业务进度计划，以及士气的打击影响等都极为致命。