SD组织架构设计--Sales Area篇

心已赠人 2022-03-02 01:35 297阅读 0赞

## SD组织架构设计--Sales Area篇 ##

(2013-07-10 13:53:46)

![sg_trans.gif][]转载*▼*

<table> 
 <tbody> 
  <tr> 
   <td>标签：&nbsp; <h3><a href="http://search.sina.com.cn/?c=blog&amp;q=%D7%E9%D6%AF%BC%DC%B9%B9&amp;by=tag" rel="nofollow">组织架构</a></h3> &nbsp; <h3><a href="http://search.sina.com.cn/?c=blog&amp;q=sap&amp;by=tag" rel="nofollow">sap</a></h3> &nbsp; <h3><a href="http://search.sina.com.cn/?c=blog&amp;q=sd&amp;by=tag" rel="nofollow">sd</a></h3> </td> 
   <td>分类：&nbsp;<a href="http://blog.sina.com.cn/s/articlelist_3506718455_2_1.html" rel="nofollow">SAP实施</a></td> 
  </tr> 
 </tbody> 
</table>

关于组织架构设计，一直想写点东西。SD的组织架构，说简单也简单，说复杂就复杂，关键还是对这些概念的掌握。一个公司最重要、最基础的就是组织架构，组织架构是业务能够执行的基础。每个客户都必然有自己的组织架构，给客户做实施的时候也不大可能去调整客户的组织架构（那是战略咨询要做的事），SAP也有一套组织架构的规则和理念，而如何把企业的组织架构合理的设计到SAP系统中，这个是我们实施的时候要考虑的问题。

SD模块涉及到的的主要组织架构如下：Sales Area、Sales Office、Sales Group、Credit Control Area(CCA,在财务配置里，但是SD很常用）、Shipping Point(后勤执行，做交货单使用)当然还有Loading point, transportation planning point，这俩由于博主也没咋用过，所以就不说了。一般做运输的时候才会用到。

这篇主要说的是Sales Area的设计，也就是销售范围（有的翻译成销售区域）。

稍微了解点SD的人都知道，Sales Area里面有3要素，Sales Organization(销售组织)、Distribution Channel(分销渠道)和Division（产品组）。这三个东西都是做什么的呢？通过按F1当然可以看到SAP给的标准解释，不过这种解释基本上跟没解释也没什么区别。其实很好理解，销售组织就是发生销售的主体，分销渠道是销售的通路，产品组是产品的大类，销售范围就是指定了谁，通过什么方式，销售什么东西。这样一说就理解了，缺了任何一个元素，都没法进行销售业务。这也就是为什么销售所有的业务都是发生在一个指定的Sales Area中，而不是只有一个Sales Org.了。

那么如何把这三个元素跟实际企业组织架构对应呢？博主做面试的时候很喜欢问这个问题，发现能够给出合理解释的并不多。一般都是告诉我，把销售部门设计成销售组织，渠道就分成内销、外销、产品组按产品去设计，或者只做一个通用产品组。这样的说法并不确切，一个企业里面可以叫做“销售部门”的组织架构可能有很多，层次关系也不一样，什么样的可以当成Sales Org.用，什么样的只能作为Sales Office呢？

那么博主怎么去做组织架构设计呢？答：倒着来。先做产品组，再做分销渠道，最后定销售组织。

产品组这个事其实最好定，按照产品线分，每个顾问都会，一般也错不了。但是博主还真见过把产品组用做别的功能的，实在不建议。因为产品组虽然是SD的组织架构，但同时也是物料主数据上的一个属性，最终还是要把物料分配给某个产品组的。同时产品组作为一个标准字段，在CO-PA是可以获取到的。

再说分销渠道。很多顾问都喜欢这么分：内销+外销，或者批发+零售+B2B，类似这种。然后我就会问这样一个问题：为什么要分？为什么一定要在分销渠道上面分？

回答这个问题之前，插个思考题：通过销售范围能够做什么？这些功能是否仅能够通过销售范围来区分？

回到分销渠道拆分的问题。其实渠道，或者说通路，往往是跟客户对应的。国内很多企业所说的渠道，通路，多半都是对客户的划分。所以博主区分分销渠道的原则也很简单，那就是：是否存在同样的客户，即做A渠道的销售，又做B渠道的销售？如果没有，那么做客户分类（通过基本视图上Nielsen ID、Customer class、Industry或者销售视图上Customer group、ABC class来区分，再不济可以做增强视图）。如果有，又需要区分A\\B渠道的销售业务，那就要分分销渠道。

再看插播的思考题。通过销售范围能确定的功能，很多顾问马上就可以联想到定价过程确定。那如果按照我上面的做法，不分渠道，就不能分出定价过程了吗？当然不是，客户主数据上面还有个定价过程分组不是，不同的客户分类指定不同的定价过程分组，就可以做不同的定价过程了。

最后来确定销售组织。为什么最后做？很简单，如果通过产品组、分销渠道能把业务分出来，满足企业要求了，那就不用再分销售组织了。因为有些行业如制造业，就是按照产品线来分销售事业部，这种情况产品线的组合就可以确定一个事业部的业务，不用分销售组织。有些行业如分销，按照不同的渠道来分事业部，那按照分销渠道就可以确定一个事业部的业务，也不用分销售组织。再有的通过分销渠道+产品组可以确定的，也没必要区分。如果企业的销售部门（或者叫事业部）业务上有交叉，但是业绩又是分开计算，考核也是分开考核（有的是因为地域不同，有的是因为老大不同），这时候不能通过分销渠道或者产品组来区分业务，那就得考虑分销售组织了。这里博主讲的是“考虑”，为什么呢？因为还有2个组织架构可以用，那就是Sales Office(销售部门或者叫销售办公室）和销售组。上面的情况也可以通过设置一个销售组织+多个销售部门来解决。如果这么做，那要考虑2个问题：一个是销售部门上面没有标准的权限控制，如果要分权限，需要做增强，比较麻烦。再一个是如果企业在组织架构上是3层以上结构，要在SD中体现的话，那么就得在销售组织上区分最高层结构，销售部门和销售组用来指定低层。

说了挺多理论上的，举个例子来说明一下，也是博主做过的一个项目。

某分销企业，销售事业部分为：渠道部、大客户部、售后服务部。分别下分一部、二部……，渠道部再往下按产品分销售组，客户部再往按客户口分为企业、政府等，服务部再往下按服务站所处位置区分服务站。该企业有多家法人，每个法人都会按照这样的区分去分组，这是典型的矩阵式结构。也就是说，每个人既在横向上按照法人公司接受考核，又在纵向上按照事业部接受考核。公司的销售指标、销售分析也都是2个维度上的。

按照上面博主的办法，产品组先按产品分好。没什么问题。

本来博主打算用分销渠道来区分这三个事业部（而且用分销渠道区分事业部有个好处，就是做报表时想看某个事业部，就直接选一个分销渠道即可。如果是用销售组织区分事业部，那就要把每个法人下这个事业部的销售组织选出来刷报表），结果客户还有另外两家公司，电子公司、信息公司，不是按照渠道来划分的公司，考虑到后面可能还要并购别的公司，并购的公司又不见得按照原公司的事业部来划分，所以只好将事业部分成了销售组织，下面的一部、二部对应到销售部门，再往下的一级分到了销售组。

还是上面的例子，如果该企业都是按照三个事业部来设计所有的分公司，那么通过分销渠道来区分最好不过。

总结一下，组织架构的设计一定要能体现企业的真实组织架构，并且要达到企业销售管理、销售分析的维度要求。在此基础上，一定要做到最简，能通过产品组、分销渠道来区分的，就尽量不要分销售组织。因为起码产品组、分销渠道还都有通用一说，可以减少主数据维护的量，一旦把销售组织分开了，那么主数据的量是一定避免不了了。

[sg_trans.gif]: /images/20220302/0c9e80b388ee4699b770e8c0ba16165a.png