目录
前言
多数企业都会遵循一个渐进式发展的过程，早期业务单一，一人身兼数职，职能性组织就足够了。
这个阶段一般也是老板直接带队，各个部门协调也比较顺畅。
如果较真的话，也算是一个简版的跨职能团队。
企业的核心矛盾在业务模式、业务发展上。
当然，如果这个阶段企业踩到了风口，实现快速发展和扩张，组织矛盾也会迅速成为瓶颈。
就拿一个小饭馆为例，最初的组织结构非常简单：
-
- 采购部：负责采买食材；
- 厨房部：负责把所有食材做成菜；
- 前厅部：负责把菜卖给客人，收钱。
这个阶段潜在问题是不同部门会各管一摊，管理差一点的企业遇到问题就会出现甩锅推诿问题。
比如客户抱怨："你们的西红柿炒鸡蛋太咸了！"、"为什么鸡蛋老是炒老了？"等等这些问题。
这个时候各个部门就开始推诿：
-
- 采购部说："我买的西红柿和鸡蛋都是最新鲜的，问题不在我。"
- 厨房部说："我就是按标准流程炒的，是前面客人口味太刁。"
- 前厅部说："客人不满意，以后不来了，生意差了别怪我。"
本质是没人对 "西红柿炒鸡蛋"这道菜最终在客人那里的好坏（市场成功） 负责。
大家都只对自己的职能模块负责，有了部门墙。
这是第一个阶段。
强矩阵
然后，针对这些问题，开始进入第二阶段。
建立强矩阵结构，为重要产品设立产品线。
任命一个PL经理，比如西红柿炒鸡蛋产品线经理。
这个人不属于采购、厨房或前厅任何一个部门。
他要对对市场成功和财务成功负责，唯一KPI就是：
让"西红柿炒鸡蛋"这道菜卖得更好、赚得更多、客人更满意！
组建跨部门团队（PDT团队）：
-
- 从采购部抽调一个人，负责确保食材源头的品质和成本；
- 从厨房部抽调最好的厨师，负责研发和改进烹饪标准；
- 从前厅部抽调一个服务员，负责收集客户反馈和推广销售。
权力重新分配（纵向vs横向）：
纵向（资源线）：采购、厨房、前厅的部门经理。
他们负责培养专业人才（比如培养更好的厨师）、制定专业标准（比如切菜标准）、管理资源池；
横向（业务线）：PL拥有业务指挥权，为了炒好这盘菜，可以指挥PDT团队里的采购专家、厨师、营销专家做什么、什么时候做。
现在出了问题，比如客户说菜咸了。
PL经理会立刻组织团队排查：是采购的盐不对？是厨师手抖？还是前台没问清客人口味？
很快就能定位问题并改进，这道菜有了一个" owner "。
随着企业发展，开始进入第三个阶段：三维矩阵。
经典菜系"西红柿炒鸡蛋"火遍全国了，在上海和成都分店都在卖。
上海客人：喜欢甜口，鸡蛋要嫩滑。
成都客人：喜欢麻辣，鸡蛋要焦香。
如果全由总部的PL经理指挥，就会"一刀切"，不符合本地市场。
三维矩阵
于是，三维矩阵出现了：
-
- 产品维度："西红柿炒鸡蛋"PL经理（在北京总部）；
- 区域维度：上海分公司经理、成都分公司经理；
- 职能维度：采购、厨房、前厅等职能部门；
如何运作呢？
总部的PL经理负责制定全球统一的基准，比如：必须用无菌蛋、西红柿成熟度标准、食品安全标准。
区域的分公司经理可以根据本地客户需求进行适配。
比如：上海可以推出"甜口版"，成都可以推出"麻辣版"。
职能部门（如厨房部）则既要向总部厨房总监汇报（提升厨艺），也要支持各地"西红柿炒鸡蛋"的烹饪工作。
这样就可以做到既保证品牌的统一性和质量底线，又快速响应了不同市场的需求。
总部的产品线和区域的公司像两根麻花一样，相互借力，相互制约，越拧越紧，越做越强。
流程矩阵
接下来就是流程型矩阵组织。
再后来，你开了成千上万家店，靠人管人已经管不过来了。
于是就打造了一套完美的"西红柿炒鸡蛋"烹饪流程（业务流）。
流程里清晰地定义了：每一步谁该做什么（角色），用什么标准（规则），输出什么（交付件）。
前端（服务员） 接到客户订单（呼唤炮火），系统（流程）自动拉动：
后端（厨房） 开始按标准流程炒菜。
后端（采购） 根据系统预测自动补货。
管理者的角色变了，从每天的"监工"，变成了流程的优化者和维护者。
比如，发现炒蛋时间总是超时，就去优化流程。
这个阶段组织的运转不再依赖于某个强大的PL经理或区域经理，而是依赖于一套高效的、不依赖个人的流程。
作者简介
卫朋，《硬件产品经理》作者，实战派产品及流程专家，人人都是产品经理受邀专栏作家，CSDN认证博客专家、嵌入式领域优质创作者，阿里云开发者社区专家博主。