B端大PM必备：多组织架构设计
共 5530字，需浏览 12分钟
·
2021-03-20 10:46
01 什么是B端大产品经理
相对于C端产品，B端产品有着更强的管理工具属性。其设计难度，往往随着业务复杂度呈指数级上升。因此，我们评价一个B端产品经理的能力，往往需要首先了解他所支撑的业务。
B端产品设计的难度首先取决于单一业务的复杂度。比如，商品管理模块，由于涉及到单位、规格、批次和权限管理等，可能就需要相对精巧的设计，才能够满足业务需要。
同时，不同业务板块之间的关联关系，是产品设计中相对困难的部分。比如，在贸易型业务中，采购价格构成商品成本，销售价格则构成商品收入。收入减去成本，剔除增值税的金额，则会得到销售毛利。销售毛利对经营管理非常重要，财务部门一方面需要按照不同维度对销售毛利进行分析；另一方面也可能在研发、销售阶段对毛利进行审核，防止过低的毛利，保护企业的利润。
要支撑这样的业务，往往需要B端产品经理具有宽广的知识面，也具备多个业务板块的产品设计能力。这样的能力我统称为架构能力，而拥有复杂架构能力的产品经理，则是我理解的大产品经理。
02 高难度的架构能力
对于B端产品来说，越是底层的功能，架构难度越大，对产品经理要求越高。
以商品管理中的“单位”为例。
“单位”作为“商品”的必需字段，被采购、销售、库存、生产制造等业务板块广泛使用。同一类型的商品，不同部门往往有不同的管理要求。因此，对于“单位”的设计，首先需要有整体架构的考量。
比如，假设我们需要设计一款管理奶制品的B端产品。
对于酸奶的制造企业，由于生产和销量的批量都很大，因此他们对于酸奶往往采用“唯一基本单位”进行生产、库存和销售管理。比如用“箱”作为单位，就比较便于销售和库存盘点等。当然，出于运输计费、管理统计等需要，制造企业可能用启用标准箱、吨等辅助单位，在进行相关费用或销量计算时，把箱换算为标准箱或者吨。
而对于酸奶的分销商，由于其采购订单即是制造企业的销售订单，因此采购管理的单位会与制造企业的基本单位保持一致，即使用“箱”作为单位。但是在库存和销售管理中，由于销售频次较高、频繁拆箱销售，经销商往往需要进行多单位的管理。比如，在库存盘点时，经销商希望系统显示的库存量为：3箱3瓶而不是3.5箱，这样就更便于进行散货的盘点。再比如，带货销售的销售人员在移动端下单时，由于可能拆箱销售，如果便利店购买了1箱8瓶的酸奶，系统需要忠实记录销售的数量，以便于销售人员核对实物数量。同时，系统也需要进行单位换算，以正确冲减销售人员车辆上的库存。
在进行快消品管理系统的设计时，需要充分考虑到制造企业、经销商、销售人员在采购、库存和销售等不同环节的需求，这样才能设计出满足需求，便于未来扩展的产品。
关于一般架构能力的培养，大家可以参考我的文章，点击即可阅读:《我的实践：如何提升B端产品架构能力》
03 架构设计的顶端：多组织架构设计
在所有架构设计中，最为复杂的，往往是多组织架构设计。因为组织架构是企业战略的落地，反映了企业责权利的划分，决定了组织间协同与风险管控策略。
比如，一个小微企业，由于业务量较小，也出于成本控制的需要，往往一人多岗，部门精简。高度简化的组织架构，使得部门协同和风险管控也极为简单。此时，用Excel进行流程管理也许就足够了。
随着企业业务量的增加，单个环节的工作量与要求也随之增加。此时企业开始按职能划分部门，部门协同和风险管控的问题也日益突出。
比如，HR职能可能从综合管理部门独立出来，负责人员的招聘、培养和人事管理工作。如果企业进一步扩大，HR部门还可能进一步裂变为招聘、培训和人事管理等独立部门。此时各个部门可能开始进行信息化管理，各信息系统间也需要一些简单的集成。比如由HR系统提供统一的人员和部门信息，便于其他业务系统直接使用；而业务系统则提供业务单据，便于财务系统进行会计核算和经营分析。
此时，信息系统开始涉及组织、角色和权限的管理，也涉及到数据隔离和数据流转等问题。多组织架构开始成为信息系统的重要基础。
当企业的商业模式得到验证，为进一步扩大销售规模，企业可能在多个省市建立分公司，并配备相应的管理团队。为了避免依赖单一业务，也为了实现经营的二次飞跃，企业可能会开辟多条产品线。此时事业部制的管理开始浮上水面。如果企业的产品在国际上也具备竞争力，部分企业会开展国际贸易，甚至在海外设立独立经营的子公司。
在这一过程中，随着企业规模不断扩大、组织架构和集团管控日趋复杂，业务数据的隔离、权限的管理、分子公司间的内部交易、财务报表合并等都成为非常重要的业务和管理问题。而解决这一系列问题，都依赖于多组织架构设计。
04 多组织架构的核心概念
多组织架构并不是一个纯粹人造的概念。事实上，它不过是忠实反映了集团组织划分的原则、组织间竞争与合作的关系，代表了集团对各组织的激励和管控策略。
比如，两个事业部之间的销售与利润数据是严格屏蔽的，因为他们分别是独立核算的主体，甚至可能存在业绩竞争的关系。在业务管理策略上，两个事业部可以有独立的价格管理和客户管理策略。在进行数据处理时，两个事业部会出具独立的财务报表，以便于衡量和比较两个公司的业绩。
理解多组织架构，实际上也就理解了集团管控策略，理解了一个跨国集团公司的运作机制。
要理解多组织架构，首先要理解其中最核心的概念，包括：
1、成本中心
正如其字面意思所示，成本中心意味着该组织需要独立核算成本。这同时也意味着它可以独立处理成本相关的业务，比如采购入库、库存管理和费用报销等。
一般来说，成本中心对应公司的一个独立部门，比如仓储部门或研发部。这些部门需要评估成本投入，但是并不承担收入的指标。
2、利润中心
利润中心意味着该组织需要独立核算利润。利润中心包含一个或多个成本中心，并且有独立的销售部门。这使得利润中心可以出具利润报表，从而让集团评估该组织创造利润的能力。
利润中心往往对应公司的一个事业部。如果集团将某个组织设置为利润中心，意味着该组织的负责人，需要对业务盈利负责。当然，他也因此会获得相应的权力，包括独立的价格和促销管理体系、独立的客户管理与渠道管理体系，甚至独立的产品开发体系。
3、收入中心
收入中心主要是针对销售部门。从数据处理逻辑上来说，收入中心与利润中心是类似的。不过集团只考核其收入指标的完成情况，以及评估其部分成本消耗情况。
4、内部交易
分子公司之间的交易往往是频繁发生的。为了降低交易成本，内部交易往往会预先制定交易和结算规则，从而使得流程尽可能自动化。
比如，内部交易可能会预先定义好内部交易价格，订单处理、结算、会计核算等流程会自动触发，尽可能减少人为的处理。
5、法人主体
法人主体是指有营业执照、税务登记证和组织机构代码证等证照的“法人”。
在B端产品中，作为法人主体的组织可能需要记录一些国家要求的信息，比如公司名称、地址和电话号码等。
6、账套
账套是指存放一个核算主体所有会计业务数据文件的总称。
一般来说，一个公司仅需要一个账套来归集所有会计数据。但是因为外部审计与内部管理的要求不同，部分公司可能会建立两个账套。一个账套按照会计准则进行凭证编制，出具对外的法定报表；另一个账套则根据公司管理需要进行凭证编制，出具对内的经营分析报表。
如果公司的规模较大，特别是集团制公司，由于不同事业部高度自治，财务数据也需要进行有效隔离。这种情况下也可能为每个事业部建立独立的账套。当需要出具集团层面报表时，再进行数据的合并。
因为账套的意义主要是用于数据统一归集和处理，因此它提供了统一的数据规则，一旦部分数据不符合规则，可能就需要另建账套进行处理。这些规则包括：
统一的科目表：
财务会根据核算的需要，建立财务科目的结构。比如，财务可能会设立一个“项目段”，所有业务单据都必须标记其所归属的项目（如果有）。这样财务就可以统计某个项目的收入、成本和费用等数据，为管理层提供项目视角的经营分析报表。
统一的日历：
按照财务核算的原则，任何业务单据都必须对应到一个发生期间，财务报表也必须按照会计期间进行出具。
比如，美国上市公司的财年期间普遍是每年的7月1日到次年6月30日，那么它的会计日历就必须以7月1日到次年6月30日作为一个年度会计期间。中国上市企业则普遍采用1月1日到当年12月31日做作为财年，因此其会计日历就和美国上市公司存在明显差异。
统一的本位币
比如一个中国外贸企业，可能和国外客户签署了美元结算合同。在月底结账时，就需要将销售收入按照汇率统一换算为人民币，并评估汇兑损益，以便于管理层对企业经营情况进行评估。
统一的会计准则
一个账套内的数据，必须遵守一个会计准则。
比如中国会计准则与法国会计准则差异就较大。同样的业务数据，按中国会计准则核算是盈利的，按法国会计准则核算可能就是亏损的。因此，两套存在差异的会计准则无法共存于一个账套。如果中国企业在法国建立了子公司，那么该子公司往往需要单独建立账套。
由于一个集团可能存在多个独立的账套，但是出于集团管理的需要，也出于外部审计的需要，会将多个账套的报表数据合并到一个账套，以便于从整体上评估集团公司的经营结果。我们把这个目标账套称之为合并账套。
以上各个概念存在较为严密的逻辑关系，比如成本中心一定对应到某个收入中心或利润中心，法人主体则一定对应到某个账套。一个典型的多组织架构如下图所示：
05 设计多组织架构的要点
如同前文所述，多组织架构的本质是权责利的划分，反映的是集团公司激励和管控各公司的策略。同时，企业也需要遵守外部的规则，比如不同国家的会计准则，因此，多组织架构也反映了外部对企业的约束。
要完整的理解多组织架构，具备一定的财务知识是必不可少的。因为经营管理最重要的方法，就是通过会计核算对企业的经营情况进行分析，从而找到降低成本、提高利润的方法。关于如何学习财务，大家可以参考我的文章《我的实践：如何提升B端产品架构能力》
首先我们需要根据账套的四个原则：科目表、日历、本位币和会计准则，来判断是否需要建立多账套和合并账套的组织架构。一般来说，只有集团化企业才会有这样的需求。但是，随着中国企业的发展，甚至有更多企业走向世界，相信多账套的组织架构会越来越普遍。
其次我们需要区分企业存在多少法人。法人是一个法律层面的概念，不同法人可能需要独立出具利润表、现金流量表等财务报表。
接下来我们需要根据是否独立核算，标识出利润中心和收入中心。从产品设计的角度来说，利润中心和收入中心的特征是一样的，不同之处在于数据处理。利润中心会归集所有的收入和成本数据，而收入中心主要是归集收入数据。从公司管控角度来说，利润中心往往是以盈利指标为主，其负责人具有相对完整的权力；而收入中心则往往是以销售量和销售结构指标为主，其负责人具有销售渠道管理、客户管理等部分权力。
成本中心往往具有独立的库存数据。如果是行政部门，则意味着他们的费用需要单独归集。这其中的关键是成本中心不承担收入和利润指标，但是企业需要统计它的费用投入，以便于考核其管理绩效，并衡量它对财务指标的影响。
最后，我们还需要收集内部交易的信息。一般来说，内部交易存在于两个独立核算的利润中心或收入中心，因此我们需要设计组织间的交易和结算规则，以便于随着商流、物流和资金流的流转，系统能自动对交易进行处理。另外，还存在一种非交易的内部调拨。比如一个利润中心下的两个成本中心之间，进行了库存调拨。此时主要是需要记录调拨的数据，并实时更新成本。因为同一个商品在不同成本中心，可能具有不同的成本。比如，在中国生产的商品，调拨到美国仓库后，其成本会相应发生变化。
了解清楚可能存在的组织类型后，我们就可以针对不同的组织类型，设计不同的组织参数。
比如，账套的组织参数必然包含“科目表、日历、本位币和会计准则”四个要素，而利润中心由于具备相对完整的经营权力，则需要包含采购合同、价格表、客户管理、促销方案等独立参数与功能。
另外，组织间数据的安全性也非常关键。我们遵循的原则是：能不开放的数据，尽量不开放。比如，利润中心之间的数据，是严格屏蔽的，因为他们是相互独立的经营主体。当然，作为集团公司的财务人员或业务负责人，则可能需要查看多个利润中心的财务与业务数据。因此，多组织的数据安全性需要具备灵活的配置能力，能够将不同主体的不同数据，分配给不同组织的不同角色。
06 总结
多组织架构设计是B端产品的高阶功能，同时也是非常底层的架构能力。对于有志于做大产品的B端产品经理，掌握多组织架构的概念和要点还只是第一步。对自身知识体系特别是财务知识的完善，对集团管控的理解，甚至掌控一套相对成熟的B端软件，都是非常重要的学习工作。
以上文章，如果大家喜欢的话，可以关注作者的公众号。接下来推荐一下我的新书：
我的新书《B端产品经理必修课2.0》已经开售了。
这是对我的第一本书的全新改版，也是关于B端产品的方方面面。
查看具体内容：我的《B端产品经理必修课》升级了
推荐阅读：