(2013-07-10 13:53:46)
转载▼
标签: 组织架构sapsd |
分类: SAP实施 |
关于组织架构设计,一直想写点东西。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个维度上的。
按照上面博主的办法,产品组先按产品分好。没什么问题。
本来博主打算用分销渠道来区分这三个事业部(而且用分销渠道区分事业部有个好处,就是做报表时想看某个事业部,就直接选一个分销渠道即可。如果是用销售组织区分事业部,那就要把每个法人下这个事业部的销售组织选出来刷报表),结果客户还有另外两家公司,电子公司、信息公司,不是按照渠道来划分的公司,考虑到后面可能还要并购别的公司,并购的公司又不见得按照原公司的事业部来划分,所以只好将事业部分成了销售组织,下面的一部、二部对应到销售部门,再往下的一级分到了销售组。
还是上面的例子,如果该企业都是按照三个事业部来设计所有的分公司,那么通过分销渠道来区分最好不过。
总结一下,组织架构的设计一定要能体现企业的真实组织架构,并且要达到企业销售管理、销售分析的维度要求。在此基础上,一定要做到最简,能通过产品组、分销渠道来区分的,就尽量不要分销售组织。因为起码产品组、分销渠道还都有通用一说,可以减少主数据维护的量,一旦把销售组织分开了,那么主数据的量是一定避免不了了。