3.2如何构建部门
有一天，项目拓展部的经理小越来找我，说是要HR这边给他招聘个助理，因为事情实在太多了，做不过来。我就问他：“你想要助理来替你做哪些事？”他想了半天，说：“就是替我处理下文案方面的工作。”我说：“那你要的是文秘？”他又说：“也不能说文秘，我那边文字内容不多，主要还是标书和方案。”我说：“那你是要一个助理了，除了标书和方案之外，还有什么？”
他又想了一会儿，说：“暂时就这么多，招聘条件方面，你找一个有一定行业经验的就行。”我心里琢磨了下，总觉得这些描述实在是太抽象了，于是我说：“这样，我给你个员工招聘申请表，你参照里边的项目大致填写一下你的要求，送去给老板审批，完了再交给我。”
第二天正好开例会，散会的时候我顺便问了一下老板关于项目拓展部要招人的事，结果老板黑着脸说：“那个小赵，想一出是一出，他那点事，半个人都干完了，还要再招人来干嘛，给他打扇子啊？”
但是下午的时候小赵又来找我，说老板同意给他招人了，让我着手替他物色人选。我听得一脑门子雾水，让他把招聘申请表拿来我看（如果老板同意招人，上边会有老板的签名），他就支支吾吾的，说申请表老板还没签字，但是他确实已经同意招人了。
我看他那情况，猜他的想法应该是想要先把人手找到然后再和老板商量要不要用，如果不用就直接干掉，如果用他就赚了，但是这样一来我的成本就大了，很可能费了大力气找来个合适的人，最后还被老板说一通的。
但是这个是不能直接点出来的，不然他脸上就十分难看了，我说：“这样，招聘广告我先不发，等你申请书拿来给我再发，在这之前我先在人才网后台帮你留意下，看看有没有合适的人，如果有就叫过来看看，你觉得呢？”
他却很坚持，说：“你先发招聘广告，我现在就去找老板，把这事儿给定下来。”
我看着他进了老板的办公室，没多大功夫，又臭着脸出来，路过我旁边的时候，气冲冲地说了一句：“DK，你不用替我招人了，我要辞职，我不干了！”
说完他就跑了，第二天也没来上班。我向公司和他要好的同事打听他的情况，希望他去做工作让小赵回来，结果人家对我说：“DK，我觉得吧，还是让小赵辞职的好，他那个工作实在太难做了，我都替他憋气。”
我就没再吭声，这样又熬了几天，终于老板忍不住了，率先让步，把小赵的招聘申请给批了，并让我去找他回来。我打小赵的电话跟他说这个事，他告诉我说：“随便吧，我想休一段时间的假，以后再说吧。”
老板知道这件事之后，脸色阴沉沉的，十分不好看。可能是没想到小赵会这么倔。
我开始按部就班的招人，但是心里也是没谱儿，因为没有人二面，速度非常缓慢，一星期之后我找了三个觉得还算合适的人，硬着头皮去请示老板要找谁二面。老板很不耐烦地说：“找文员还不简单，你自己定就行了，不用二面。”
我赶紧说：“可是小赵不要文员哦，他要的是能写方案有行业经验的人。”
老板就说了：“他找这样的人干嘛？公司这样的人还少吗？他那个猪脑子，想什么呢？”
我大着胆子说道：“老板，你究竟给小赵分配了些什么工作啊，你们好像有很多误会，我上次跟XX（跟小赵很要好的那位同事）聊过，他说小赵工作干的很憋气，都建议他辞职了。”
老板说：“项目拓展项目拓展，那不就是拓展项目市场嘛，所以只要跟项目拓展有关的，都归他。”
我听得一头黑线，公司目前的组织结构是这样的：营销中心之下，有一个商务部，一个项目拓展部，商务部负责的是自有著作权的软件产品的销售以及部分和软件结合的硬件销售，项目拓展部负责的是项目拓展（注：即主要是定制开发系统或以现有软件为基础做大量二次开发的业务，和商务部的业务相比，项目部的业务特点是不容易成交但是一旦成交金额就非常大）。商务部有12人，项目拓展部只有经理1人，商务部归营销总监管，项目拓展部则是挂在商务部下，但是工作不向营销总监汇报。营销总监的业绩指标不包含项目拓展部的业绩指标。
考虑到项目拓展需要干的活儿，项目拓展部1人编制，怎么能做得完。我开始觉得，项目拓展经理想要招人的想法是可以理解的了。
但是紧接着老板说的话又改变了我的想法。
老板说：“项目拓展部看起来只有经理1个人，其实并不是，实施部、商务部、产品部以及开发部的人，只要项目拓展需要，都可以调动，项目拓展部实际上干的是个找信息和跟踪的活儿，有项目了他就找各个部门协调，把活儿丢给他们就行了，到点收东西，拿起给客户就行了，说得难听点他就是个拉皮条的，就这么个活儿，还需要几个人做啊！”
我明白他的意思了，项目拓展部实行的实际上是矩阵式管理，对于矩阵式管理的组织来说，最最重要的不是团队管理，而是责权体系。小赵的工作貌似是做得很辛苦，这让我怀疑老板是否有将项目拓展部的责权体系在公司内部各个部门通告到位。
我转过头去找XX（跟小赵很要好的那位同事），向他打听小赵平时都是怎么工作的。结果XX替小赵向我诉苦，说：“DK，小赵的日子真的很难过，拿一个项目不容易，要做方案，跟客户演示，算人工，还要应酬客户，所有事情都自己干，我看着都替他累。”我说：“这些事情他可以找开发部和商务部的人帮忙啊。”XX说：“他们帮个啥啊！都是他自己在搞！”
我把这件事跟老板说，老板大皱眉头，说：“方案那个东西这么专业，他哪是那块材料，做这个干嘛，他想什么呢！你再去做点工作，看看是怎么回事。”
我想了想，说：“老板，你当初设计这个项目拓展部的时候，是如何跟各个部门沟通的？有没有出相关的管理制度？”老板说：“啥管理制度啊，我就跟几个部门的负责人说了声。”
我笑了出来，老板他果然是没把项目拓展部的责权体系通告清楚。我说：“老板你读圣经么，圣经写过这样的话：神说，要有光，就有了光。神看光是好的，就把光和暗分开了，神称光为昼，称暗为夜。老板，我看到你，就看到我自己的锦绣前程。因为你基本就是把自己当做神仙了，以为什么事情都能想当然，这样一定会出问题，有问题出，我就有用武之地了。”
老板脸色很不好看，我赶在他扔鞋子砸我之前，飞奔出门。
玩笑归玩笑，问题还是要解决的。
我开始想，我要怎么着手来做这件事。我要怎么做才能把项目拓展部建设好？
很多种原因都会导致部门构建，比如说：公司规模扩大，内部分工变得更加细致；公司管理开始上轨道，流程变得规范，岗位之间粘合度增加，能够形成小范围的组织；有时候甚至可能是出现了出类拔萃或者资历不凡的人，这些都可能会出现部门构建（比如说将公司资深的售前顾问集合起来，组成一个顾问部，我就干过这活儿），但是不管是哪种原因导致部门构建，关于部门建设不可颠覆的两条原则，是始终都要遵守的，这两项原则是：
.部门的职责必须明确。以构建房屋来做对比，部门的职责就好比是房屋的地基，而砖瓦砌成的墙壁、原木造就的屋顶、门窗、台阶、走廊凡此种种，都要建立在地基之上。部门构建也是一样，明确的部门职责是部门能够生存发展的前提条件，一个连职责都不清楚的部门，没有人会向他求助或者求教，这样的部门存在于组织中，要么是纯粹的装饰，要么就是各项脏活累活儿各种想淘汰又淘汰不了的员工汇集的地方，这样的部门是没有生机的，宛如危房，一旦倒塌，损害的不仅是公司员工，还有公司本身。
.部门的权属关系必须明确。所谓权，指的是部门本身具有多大程度的权限，也就是说，他对哪些部门是可控的，或者是可要求的；所谓的属，是说他隶属于哪个系统，哪个部门或者岗位，简单地说就是他的顶头上司是谁，权是用来帮助部门员工做事的，属是用来监督部门员工做事并且在必要的时候提供帮助。一个部门如果连自己的权属关系都不清楚，部门的人一定会觉得自己像流浪汉，不管做什么，都好像是在哀求其他部门施舍，而自己受了何种委屈，又没有办法为外人所道。这样的部门，就算做出了业绩来，部门的员工内心也都是很憋闷的，而且可以肯定，他们付出的努力，一定是别人所想象不到的多。
用这两条标准来衡量公司现在的项目拓展部，就不难想象，项目拓展经理想要找人的想法是多么可以理解了。他一定是发现无法调动其他部门的同事帮助他把事情做好，而老板又时刻盯着他要业绩，无奈之下，只能想法自己培养团队，而他在工作开展中所遭遇到的各种困难，因为没有一个明确的上司，老板又知之甚少。他看到的只是项目拓展经理没有产出或者产出缓慢，至于项目拓展经理为此作出的解释，在他看来，都是在替自己的无能辩解。所以这日子过得就憋屈了。
如果工作带来的只有憋屈，这工作必不长久。
可是，尽管我知道小赵心里憋屈，但我却不能因此，就硬性的建议老板，把各个部门的负责人都提过来抽打一顿，然后命令他们，必须要无条件的配合项目拓展经理的工作需要，该出人的时候出人，该出力的时候出力。这是行不通的，部门有部门的工作安排，没有可能让一个人随时调遣。
很多部门负责人都很排斥自己的部门成为矩阵式管理组织的一员，这是由矩阵式管理的结构特点所决定的。在矩阵式管理中，整个组织职能部门被分为两种，一种是传统的职能部门，另一种是为完成某一项专门任务而由各职能部门派人联合组成的专门小组，并指定专门负责人领导，当任务出现时，任务负责人从传统职能部门中抽调人选组成专门小组，任务完成后，该小组成员就各回原部门。用通俗的话来说，使用矩阵式的管理结构，传统职能部门（也就是员工直属部门负责人）就好像是养了一屋子花儿的园丁，而专门小组的负责人则好像是路过的邻居或者走动频繁的亲戚朋友，每回来都要参观花园不说，还要顺手摘走两朵开得正好的小花儿，一个园丁再慷慨大方也禁不起频繁的拜访啊，于是不乐意的就会想方设法的推脱，不肯配合的情况自然会发生。
每个部门都有自己例行的工作安排，每个人头上都背着任务，一个人每天只有那么多时间，做了项目的事就做不成部门的事，这都是大家看得到的。要说以产出论英雄，你项目拓展部的人也不敢说，每个项目都能拓展成功，很多人力成本实际上是沉淀了的，只能从长期的收益中分摊出去。
所以这件事，从性质上来说，不是老板一声令下就可以解决的事。
总体来说，在解决项目拓展部这个问题，我的目标很清楚：明确项目拓展部的职责和权属，缓解项目拓展经理的压力，同时，判断项目拓展部的工作饱和度，确定是否需要增加人手。但是我的解决方案还是模糊的，到现在为止我只知道让老板下行政命令强迫各个部门的人配合项目拓展部工作行不通，但是哪种路径是行得通的，我还没找到。
我决定从各个部门处了解一下情况，看看他们对项目拓展部有什么想法和需求。
在此之前，我找了XX（因为小赵不在公司），问他项目拓展部主要都负责哪一类的项目拓展。
XX告诉我说，项目拓展部负责的主要是政府资金申请项目，行业性电子商务平台和区域性的信息化建设项目，这些项目标的都很大，但是跟踪的周期很长，另外，解决方案一般都很难做，做好之后可能也要根据对方给的要求反复地修改，是件很耗时间和精力的事。最主要的是，它和我们主营产品关系不大（和主营产品有关的项目拓展，是由公司的顾问部和产品部门在负责的），换句话说，即便这种项目拱下来，嫁接我们自有系统的可能性也不大，而且还需要组织专人负责开发实施和维护工作。
尽管如此，因为标的很大，这类项目的利润是惊人的，有时候一个项目相当于主营业务的好几个项目利润之和。实际上，也正是因为这个原因，老板才打定主意要设这个项目拓展部，让小赵专职做项目拓展经理，拨给他的项目拓展经费，也是非常可观的。
然后我给小赵打电话，把老板安排我做的事情向他简单介绍了一下，然后问他说：“你有啥要求，趁机提出来吧，我想办法借着这次机会一并解决了。”
小赵说：“也没什么要求，就一点，你让产品部、开发部和行政部的人听话一点，不要我每次去找他们的时候都把我当乞丐对待，不，简直比乞丐还不如，你给乞丐白眼的时候，还是要施舍他两块钱的嘛，我连那两块钱都没有，白赚了很多白眼。”
我笑着说：“不是他们不好，是制度设计得不合理，我想办法调整一下，让他们都很喜欢你就是了。”
我做事情，喜欢就事论事，不喜欢和人讲抽象的大道理，我深信各种管理的缺陷以及流程的混沌节点都会体现在具体的问题上，收集的问题越多，你对产生问题的根源越是有深刻而直观的认识，针对问题设计的方案，就更具有针对性，在实施起来的时候，遭遇的阻力也更小。
接着我去找产品部的总监，我的主旨是要了解，项目拓展部都向他提过哪些配合要求。
产品部的负责人说：“主要就是写解决方案了，公司所有的售前顾问都挂在我部门里，他出去找的项目，方案基本都是我部门顾问写的。小赵本人是不错，但是他要我们出的那些解决方案，真是太极品了，能折腾死人。就拿最近一个他在争取的项目来说吧，他想去争取一个水利局的防汛项目，那个项目标的确实很大，要真是拿下来足够我们部门吃半年的了，但问题是他拿回来的标书太麻烦了，里面有一半的功能要求是我们现在没有的，这个开发工作量有多大姑且不论，光是解决方案本身就是个大问题，第一我们没有人懂水利行业，光是研究技术资料就要好长时间，哪可能在几天之内就写出来，第二这个领域本身我们没资源，就算方案勉强做出来了，能中标的可能性也不大，这种活儿换了谁都不愿意做啊。别说售前顾问不干，我自己也不干。
还有一些政府申报项目，都是些搞概念包装的，让写可行性报告，你得比着他的概念去想个项目，然后还得给这项目编市场容量分析和行业前景预测，还得做项目预测，动不动就是八九百万的开支，我们做软件项目的，没有硬件捆绑，哪有那么大能耐一两年的项目执行期就干掉八九百万的研发开支啊，那得是多大的项目小组才有的成本，所以只能给他编，编来编去，骗自己都骗不过去，哪能骗过专家。所以归根结底一句话，就是拓展部那边送来的项目，我是看不到有啥赚钱的希望，都是白投入人力。
老板觉得潜力大，所以专门成立个部门来做这个，但他也得看看实际情况啊，产品部本来就缺人缺得不得了，实在顾不上拓展部那摊事儿。”
简单地说，产品部负责为项目拓展部写解决方案，产生协调障碍的原因在于对项目盈利能力不乐观，且部门目前人手已经短缺。
其他几个部门的理由也都类似，研发部主要负责根据产品部售前顾问的解决方案出技术方案，因为很多解决方案和目前技术框架不符，需要根据解决方案编写新的技术方案，而不能用已有的方案框架来改，这是很花时间的，当然最主要的是，这部分投入是看不到的，项目拓展成功了，研发部也没有任何收益，写技术方案的人也不会有奖金。
实施部负责根据技术方案预测实施周期和实施人力成本，开发部负责根据技术方案预测开发周期和开发人力成本，这些都和项目最终的报价有关，所以也不能马虎，都是需要花时间投入又在短期之内看不到收益的事，做起来确实没什么干劲，最后说到行政部，理由让我啼笑皆非，行政部的文员妹妹听到我问项目拓展部的小赵每次来行政部都让他们做什么时，她简直像是逮到了天赐的机会，气呼呼地说那个小赵，简直是偷油老鼠，每次来打印，都要用掉至少一包纸，而且还不是一次，一个项目要打N次方案送去给招标方，每次还都要胶装，封面还要指定的铜版纸，要多豪华有多豪华。他不知道这样很增加我们行政部的成本啊？他不知道我们行政部的办公成本都是挂在我头上的吗？他每用一包纸，我的年终奖金就少了10块钱！可是他项目做出来了，又没有我的奖金，我都跟我们经理说了多少次了，让他以后去外边打印装订，费用拿回来报销嘛，又省人工又省成本，图文店孵化园门口就有，做的业务多还可以办VIP卡给打折！
我在各个部门绕了一圈之后，总体觉得，项目拓展部的经理，日子过得真是太窘迫了。
而我的收获是，现在我知道，对于应该如何配合项目拓展部的工作，各个部门其实很清楚，只是配合的意愿不高，另外，在配合中产生的诸多分歧，没有一个部门或者岗位负责协调。
现在我需要做的就是，设计一种方案，让各个部门对项目拓展部的工作从“知道且应该配合”转变为“知道且认为有必要”配合，另外，再给项目拓展部找一个上级主管部门，用来协调在配合过程中产生的诸多分歧，这种分歧不是因为配合度不高引起的，而是对项目本身有不同看法而产生的。
我决定从绩效激励制度上着手。
正如一个古老的故事说的那样，两位神打赌，看谁能够让凡人脱衣，一位神发起狂风暴雨、电闪雷鸣，但是人们裹紧衣衫，跑的比谁都快；另外一位神设下和风习习、春意拂面，人们自然而然解开了衣裳。
我如果让老板强调各个部门必须要配合项目拓展部的工作，结果一定是大家口服心不服，但如果我可以将各个部门和项目拓展部的利益捆绑在一起，结果应该会不一样。
我找了小赵，问他一个问题：“老板给他的绩效考核指标是什么？”小赵十分尴尬的说：“因为项目本身很难做，所以暂时还没有绩效考核指标。”
我觉得设立一个绩效考核指标是必要的，有指标，才能引出绩效激励制度，设立了指标，也会迫使项目拓展经理在分析项目信息的时候权衡利弊，不会像现在这样不加分析的见到项目就扑上去，花费很多不必要的时间和精力。而且，在一个每个部门都有绩效考核指标的组织里，有一个部门却没有，这也很突兀。
但是小赵却有不同看法，说：“没有考核指标我已经干得很吃力了，有了考核指标，照现在这种局面，那就是逼我辞职走人了。”
我说：“那倒未必，只要有考核指标，就有可能产生利润，只要把利润分给各个部门一点，你部门就是他部门的客户了，到那时候，你就不用看他们脸色了，反过来应该是他们尽心尽力为你服务。”
我说服了小赵接受考核指标，又让他回来上班，然后把收集到的情况汇总了一下，去找老板，这一次我想要解决的是另外一个问题：老板打算每年从项目拓展部获得多少利润？
老板摸了摸他光光的脑袋，为难的说道：“这个问题我也不知道，其实项目拓展部跟的那些项目，都是别人告诉我的，我觉得不跟可惜，跟的话周期又长，商务部和产品部估计都没什么干劲，所以就整了个项目拓展部，让小夏专门来跟这些项目。这些项目跟出一个来就赚了，跟不出来，花的也只是小夏的工资成本。到今年为止项目拓展部成立半年，有一个项目已经快要下来了，我觉得还是有钱赚的。”
我说：“等这个项目下来，小赵估计也该辞职了。”
老板却很有信心的说：“不会，小赵在公司干了五年了，我了解他这个人，他对公司有感情，辞职的事，就是口头说一说，工作嘛，难免会有做得烦躁的时候，但他不会辞职。”
现在我知道事情棘手了。
首先，从项目拓展部的职能设计上来说，老板定性为非常规项目的跟踪，他的资源来源只有老板，部门本身没有筛选项目的权力，老板让做什么项目，就要做什么项目。换句话说，这个部门就好像是计划经济时代的国有企业，做什么怎么做都由官家说了算，没有惩罚也没有奖励，做好做坏一个样，做或不做一个样，可是我们其他部门却是不折不扣商品经济下的私企，做好了有奖励，做的不好就要挨罚，干一天活才有一天的工资。这两种格局下，部门之间有冲突是必然的。
我说：“老板，现在项目拓展部这边，我有两个方案提供，一个是关闭项目拓展部，把小赵调进总经办，做你的特别助理，只跟踪你提供的信息，还有一个是扩充项目拓展部，让他们专注做大型项目开发，既跟你提供的信息，自己也要去找信息，给他们设计考核指标和绩效激励制度，比照商务部的模式来运作。两种必须要选一个，不然问题解决不了。你说小赵不会辞职，我看未必的，我估计现在的工作方式如果不改变，他应该在最近这个项目做下来之后就会辞职，现在不走，不是因为对公司有感情，是因为没做出业绩，走得脸上无光，一旦有了业绩，他肯定会走。再深的感情，也经不起严重的内耗，这份工作本身让他很憋气，又没有考核指标，钱也不多，换了我也不会干。”
老板很吃惊，说：“事情已经严重到这地步了？”
我说：“老板，我给你一个建议，当你发现有新业务是现有团队消化不了的时候，你可以招人来跟踪这些业务，但不要轻易设立部门，要设立一个部门，有三件事是必须要做的，第一是明确部门的职能，第二是明确部门的权属，第三是建立能让部门正常运作的管理和制衡机制。做这些工作是很麻烦的。但如果没有这些，部门就算有业绩，投入和产出也都是不成正比的，就用小赵这个例子来说，你看到的是最近有一个项目马上就要签单了，而你的投入只有小赵的工资，但是你没有看到他在这过程当中花费了多少沟通成本和时间成本，这两项成本都是双向的，有投入的不仅仅是他一人，还包括其他部门，算起来也不是小数，这些成本在大量的消耗组织的人力资源，它导致很多问题，比如推脱、懈怠、挫折感、部门隔阂和虚无主义，这些问题会影响组织长期的竞争力。
我给你的两个选择，关闭项目拓展部，把小赵调进总经办，但是这种方案只能部分的解决问题，因为这样的做法只是赋予了小赵更多的权利去要求别人配合他，但导致小赵和各部门发生冲突的根本原因仍然存在。”
老板说：“不行，小赵不合适调进总经办。你还是替我招人吧，就照你的思路，照正规军的规格，给我建一个项目拓展部，专门负责做大型项目，做的好有提成，做不好扣工资。”
好了，到现在为止，我终于可以着手开始描述，如何构建部门了。
如何构建部门？
我可以用两个流程图来表示它的始终：
.站在组织角度设计部门地位，流程为：设计部门职能→规划部门权属→更新组织管理制度→更新组织结构图。这是宏观意义上的部门构建。站在部门角度规划部门管理，流程为：设计部门岗位→编写岗位说明书→设计部门管理制度→制作部门介绍课件。这是微观意义上的部门构建。
以下是有关上述两个流程的说明。
首先是宏观意义上的部门构建流程说明。
（1）设计部门职能
这个不需要多做阐述，相信大家都能明白，这一步是在概括的回答部门是做什么的，但是在描述过程当中，针对不同的部门描述也有差异。传统的职能部门，比如财务部、行政部、客服部，职能是非常清楚的，它的主要职能和其他部门发生交叉的可能性不大，要财务报销不可能去行政部门，要购买办公用品也不可能去财务部申请，除非是特别的规定。
细分的职能部门则未必，尤其是流程交接点出现两个以上粘合度很高的岗位且岗位本身分属不同部门时，职能描述就要精细有针对性了。因为职能描述不清晰所导致的问题很多，随便举一个简单的例子，以系统开发为例，稍具规模的公司，基本都会将系统开发、实施和售后维护分别放在开发部、实施部和客服部来做，但是很多公司对于这三个部门的职能设计，表现得很模糊，管理者理所当然的认为，开发部的职能为系统开发和功能整合，实施部的职能为系统实施和试运行跟踪，客服部职能为产品售后维护，认为这样已经很清楚了，但是实际的情况是，在开发完成、实施开始之前，在实施完成、售后维护开始之前，还存在很多工作，按照这种职能规划，是不属于这三者当中任何一个部门但是却必须要由三者当中的某个部门完成的，比如说，开发完成之后，根据客户调需求对系统进行配置（熟悉软件行业的人都知道，这其实是个有一定技术含量的活儿，而且有时候工作量可能还会很大），这既不是在开发系统，也不是在部署实施，这种工作有时候是简单的实施人员就可以做，但也有复杂的，实施人员做不了，这时候，找谁来负责？
我相信很多公司应该都遇到过这样的问题，作为解决方案，我们可以通过细化岗位职责来解决，而明确岗位职责，就会牵涉到部门职责的调整。这个时候，已经是事后补救，发现漏洞来修补漏洞，在此之前花费的人力成本和沟通成本已经不可计量，如果可以在做部门职责设计的时候考虑周全，这些或可避免。但究竟如何避免，我是没有好的方法，能够给到的建议有两个，都是很笨的。，第一是找熟悉流程的人和人力资源部一起做，第二是将和职能有关的流程起止终点引入流程描述中。
（2）规划部门权属
从管理学的角度来说，规划部门权属的意思，就是建立职位之间的报告关系，部门负责人的直属上级是谁，直属下级是谁，在业务的运营上，哪些部门负有支持义务，哪些部门负有检查义务，都属于部门权属规划之列。
在建立部门的权属关系时，通常会面临两大挑战：第一，如何创建指挥链；第二，采取何种管理幅度。
指挥链（chain of command）是流行于20世纪初的概念，不过，到现在也还仍然有其生命力，它指的是组织内各职位之间清楚而明确的命令关系。指挥链包括两个部分，一是指组织内部任何一个人都必须要有一位以上的上级，早期的指挥链还强调，这一位上级是有且仅有一人，但是现代的管理结构已经对指挥链所强调的这种独一无二性的要求发起了冲击，最明显的就是我们今天讨论的这个矩阵式管理结构下的部门组织，实际上，在矩阵式的管理结构里，每一个人都是有两个上级的，一个是直属部门上级，一个是专项小组负责人。这种矩阵式结构有其生命力，所以，对于指挥链所强调的这种上下级关系，我认为，前一点是可取的：即每个人都必须要有至少一个上级，不允许存在没有上级的人，除非是老板。
对于这一点，我和小赵商量，关于项目拓展部的直属上级究竟应该是营销总监还是老板本人。从组织构建的角度来说，项目拓展部如果定性为业务拓展部门，选择营销总监作为直属上级是合适的，但是另外一方面，考虑到目前营销中心的业务结构和项目拓展部基本不相关，营销总监本人对于项目拓展部的工作也完全不熟悉，加之项目拓展部和营销部发生关系的时候也非常少，而对于项目拓展部在和其他部门协调工作发生冲突时，营销总监能够起的作用也十分有限（公司的营销总监是销售起家的人，在技术领域没有权威，和研发部门乃至产品部门是平行存在），看起来似乎是不合适将项目拓展部放到营销中心去的。
但是将部门的直属上级列为老板，似乎也不太合适，因为作为直属上级，有很多下属无法跟进的工作（我相信在项目拓展部这边，只会多不会少），是需要直属上级从中协调的，但老板不可能有这么多时间、也不应该介入这些部门内部和部门之间的事务性工作。
我想了很久，最后引入了一个新的参数，即是工作相似度。项目拓展部本身属于销售部门，只不过它销售的是一种特殊的经验乃至思想，而不是成型的产品，具有这种职能的部门，公司已经有一个，即是产品部。
公司的产品部成员基本都是从开发一线提拔出来的、有五年以上行业经验且有丰富项目实施经验的复合型人才，他们日常的工作，一部分是在做行业分析和市场调研，升级产品系列以及完善产品功能，另外一部分就是在为大客户做解决方案，开拓主营业务的定制项目服务，他们的运作模式和项目拓展部差不多，唯一的区别只在于，产品部的目标客户群是主营业务客户群，方案基于现有技术框架和产品系列，有很多现成的技术文档与解决方案文档可以参考借鉴，项目拓展部的目标客户群是不特定的非主营业务客户群，方案基本要新造。
抛开这一点不谈，产品部门的负责人，也即是我们产品部的总监，不管是哪个方面，都很适合成为项目拓展部的直属上级，实际上项目拓展部的很多解决方案基本都是他在分配部门内部人员着手书写或者有时候干脆是他自己捉刀代笔。他在担任产品部负责人之前，有长达五年的研发经验和三年的项目实施经验，在两个部门都累计有相当的权威，由他来协调项目拓展部与各部的沟通关系，是最合适不过的。
这件事我交给老板去安排，我的职权尚不够规划产品总监的权属关系。
指挥链的另外一部分含义，是有关下级往上的汇报体系，它要求组织必须要有一条清晰的、不可破坏的最底层到最高层的命令链，用通俗的话来说，即是层级汇报制度，早期的指挥链概念将命令链定义为自下而上不可颠覆、不可越级的等级制度，现在的概念和以前则有所区别，因为越来越多的组织趋向于扁平化，指挥链中有关命令链的定义已经演变为组织必须要有一条清晰的、从最底层到最高层的命令链，但是允许组织成员越级汇报。
命令链如何设计，这和部门的岗位设计有关，在岗位设计没有做完之前，没有必要花费时间来讨论部门的命令链如何设计。
权属关系除了指挥链以外，另外还需要确定的一项，是部门负责人的管理幅度，也即是指部门负责任管理多少名报告者。不过，按照我自己的理解，我认为，权属关系界定应该包括两个部分，除了上述的报告者数量界定，应当还有一项支撑部门职能履行的报告者界定，用通俗的话来说，也就是要明确哪些部门是本部门的辅助部门，协助本部门工作展开是这些部门的义务，这种义务站在新建部门的角度来说，就转变为一种权利了。
明确这些权属关系，可有效杜绝部门之间相互推卸责任或非暴力不作为现象，当然，这需要有配套的绩效激励制度和考核体系作为支撑。
（3）更新组织管理制度
很多集团型公司会有一套自己的组织机构管理制度，用以规范集团内部的部门创建和组织调整工作，但是组织管理制度不完全等于组织机构管理制度，组织管理制度是为了使组织内部各个职能部门能够协调运作使组织工作更高效更有质量的制度，有的公司会有专门的组织管理制度，有的公司则是将组织管理制度规范的内容分解在职能部门管理制度中了。
一份组织管理制度，一般要包括以下这些内容：组织内部各部门职能，各部门权属认定，部门协作机制，部门之间冲突的解决方式，各部门信息沟通与传达方式。
作为宏观部门构建流程的第三步：更新组织管理制度的作用，是将流程第一步和第二步所规范的内容以书面的形式固化下来。这是组织运作的基本制度，从某种程度上来说，如果用法律的术语来描述公司内部各项制度的地位，组织管理制度毫无疑问是可以算入公司基本法之列的，人人都应遵守。
有成型的组织管理制度，更新工作会比较容易，但如果没有，就需要部门构建者对公司层面出具的各项管理制度进行清查，逐项修订了，如果觉得这项工作做起来不容易，要花费很多人力，那么我有一个小小的建议：创建一份组织管理制度，在管理制度的最后一行，不妨写定：本制度自执行之日起，现有制度中与本制度有冲突的，以本制度为准。人力资源部（或者公司总经办）对本制度有解释权。
（4）更新组织结构图
组织结构图是什么东西相信不需要我多说大家都知道了，很多人，包括负责组织结构图更新的HR部门本身，都觉得更新组织结构图是件无足轻重的事，我自己一度也有这样的想法，但是我一位前同事改变了我。
这位部门同事是位女性，年纪比我还大一些，学历不高，我当初召她进公司，初衷只是做后勤，后来发现她做事非常细致，经手的所有物资物品乃至文件表单都整理得井井有条且始终如一保持这种高品质的工作，我觉得很难得，就把她调进人力部门核算薪酬。间中有一次，部门的人事专员不在，有新员工报到，她按照正常的工作流程为那位员工办理了入职各项手续，然后领了员工去各部门见领导。
这件事做完之后，她将以前的组织结构图翻出来，将最近新增加的两个办事处加进去，打印出来，放在了新员工手册的第一页上。然后她对我说，经理，我今天带着那位新员工去各个部门，向他介绍各部的负责人，我发现介绍完了之后他还是很茫然，连去过哪些部门都记不完，所以我建议在员工手册最前边增加一个公司的组织结构图，把各个部门的职能介绍一下，连各个部门的负责人都可以顺便列上去，让他们心里先有个数，等引荐的时候就有印象了。
我觉得她说的真是太有道理了，以前我一直觉得，组织结构图这个东西是用来做备忘的，用来提醒公司管理者公司曾经有过怎样的历史，此外，就是作为公司介绍列在各类上报材料中给那些对公司一无所知但是和公司有潜在利益关系的人（比如说风险投资商）查阅了，此刻我才发现，我忽略了组织结构图的一个最为关键、也最为基础的作用，即是帮助初入公司的人更快地了解和熟悉公司，更快地融入环境，开展工作。
从这个角度出发，我发现，组织结构图更新不仅要及时，还要尽可能通知到公司所有员工。
更新了组织结构图之后，宏观的部门构建工作基本就算完成了。
接下来是微观层面，部门内部各项工作建设。
（1）部门岗位设计
岗位本身应该如何设计，这个问题在其他地方已经说过，在此就不多啰嗦。站在部门的角度来做岗位设计，需要关注以下这些问题：根据部门的职能，应该设计多少个岗位，每个岗位应该规划多少人，每个岗位之间的协调以及报告关系是怎样的。
①部门内应有多少个岗位影响岗位数量的因素有很多，我觉得首先需要提出来的是：部门职能的复杂程度和整合程度。
如果部门职能比较复杂——这种复杂有时候是说部门处理的问题本身比较复杂（也就是说部门的能级较高），有时候则是说部门负责的工作比较多而且杂——在设计部门岗位的时候，就要充分考虑这些职能的整合程度了，所谓的整合程度，即是部门处理的这些问题在多大程度上可以归类汇总，整合程度高的，岗位就少，整合程度低的，岗位就会多，因为你不能让一个人同时兼任两项性质有差异的工作，这样会影响他的工作质量。
举个简单的例子：现在很多公司都有综合部这样的部门，由该部门统揽公司的人力、行政、办公、后勤工作，从实务的角度来说，这些工作分解到具体的事项，都很简单，稍微有一定工作经验的人都会做，所以很多公司的行政文员兼了办公后勤和行政的工作，或者人事文员把行政后勤的工作也都兼了的情况并不少见，可是，从HR的角度来做岗位分析，实际上，这些工作本身的整合度并不高，你可以将这些工作统到一个部门来做，但是在岗位的设计上，是要做细分的，否则工作效率和质量都不高，而且很多事情会做漏掉，这一点我估计很多人都深有体会。
②现有的人力结构
工作的复杂程度和整合程度从理论上决定岗位设计的理想状态，而现有人力结构以及未来一段时间内可获得的人力资源则决定岗位设计的实际状态。最终确认的岗位结构是这两者的综合。
以项目拓展部的岗位设计为例，最初，我比照项目拓展部的职能，与产品总监和项目拓展部经理一起，规划的岗位有3个，但是随后，项目实施部一位同事了解到拓展部的新职能和岗位设计，主动找我说，想要调到新部门来，经过和他原部门负责人沟通之后，公司同意他转入新部门，而这位同事的资质、经验值，乃至他个人的优劣势，都表示他可以胜任我原本规划的3个岗位中的两个，他自己也对这两个岗位的工作都很感兴趣，最后我将这两个岗位的工作合并在了一起，部门预设的岗位减为2个。当然，这是有前提的——我们最初之所以会将工作分拆为两个岗位胜任，是考虑到这些工作复杂程度较高，如果合并在一起，不容易找到能够胜任的人。
在做岗位设计的时候，还需要考虑另外一个问题：如果现有的以及在今后一段时间内可获得的人力资源不足以支撑某些工作需求，那么这些工作需求是否需要体现在岗位上？
以项目拓展部的岗位设计为例，假设我设计了一个项目顾问的岗位，根据拓展部的职能要求，项目顾问的工作内容之一是根据项目需求撰写解决方案，而胜任这项工作需要硕士以上学历，5~7年行业经验，擅长撰写某几类行业分析报告，这样的人可能是很难遇到，或者价格高昂，超出公司的承受能力。如果是这样，项目顾问这个岗位我是否需要规划出来？不规划出来，拓展部的业务就可能做不好，业务指标也完成不了，规划出来，可能找不到人也是白搭，或者找到了人，但是距离理想的高度有差距，于是在薪酬和考核方面的纠结可能就会很多了（将一个达不到任职能级的人放到任职岗位上，对公司对个人都是挑战和考验）。
我是倾向于不规划这样的岗位的。
我个人的经验，一般情况下，如果一个部门的发展是得到公司支持的，只要岗位规划出来，不管过程如何，结果都能找到任职的人。对于那些资历上稍微欠缺一点的，到任之后，通常有两种考核方式，一是较低的薪酬，有竞争力的奖金，一是较高的薪酬，做的不好就要倒扣。第一种称之为增加法，第二种称之为倒扣法。
但不管是增加法还是倒扣法，基本的要求都是一样的，那就是任职者只有能级上升之后，薪酬才会有上升空间，但是任职者能级提高不外两种方式，一种是得到内部资源帮助，一种是依靠人力资源部为他安排的各种外部培训（不用考虑任职者个人的资源了，在他入职之前，他个人的资源已经被HR作价评估过了）。
问题是，任职者能得到的来自内部资源的帮助不多，因为通常情况下，只有内部实在选拔不出人手之后，才会考虑对外招聘；他能得到的外部培训资源也不会太多，一则是因为HR对空降部队的谨慎，二则是专业性太强的培训，也实在是很难在培训市场上搜索到。
于是结果就是，采用增加法的任职者，很长一段时间内，薪酬对他来说都是不合心意的，采用倒扣法的任职者，则更加郁闷，每个月都要被扣很多钱，慢慢的对工作也就没什么心思了，有的索性离职，有的则是做一天和尚撞一天钟。
所以，我个人是建议，对于那些现有人力资源无法支持的工作需求，还是不规划出来。作为弥补，公司可以在绩效考核指标上做适当让步——没有高手坐镇，那就把目标放低。
（2）编写岗位说明书
岗位说明书的编写在前面的小节中已经介绍过，在此就不重复了。
（3）制定部门管理制度
基本的部门管理制度，应该要包括以下这些内容吧：
①部门工作制度
部门工作制度是用来规范部门内部运作用的，它告诉部门的人，本部门工作要如何开展、各项事务负责人有哪些、各个岗位之间要如何配合、团队应该如何沟通、信息要如何传递、出现问题时要如何协调解决及部门文件应该如何管理等。最常见的部门工作制度是部门例会制度，这个几乎大多数公司都会有，此外，还有部门信息保密制度、进出文件控制制度、部门资源库管理制度及公告通知制度等。庞大的部门内部还会分出若干小组，组与组之间的分工合作，也是部门工作制度的重要内容。有些公司为了方便部门工作，索性建立一个部门自用的局域网，把所有和部门有关的各项信息都公布在局域网内，如果该部门属于公司的核心部门，这个局域网还可设置成拒绝其他部门访问的形式。
②部门绩效考核制度绩效考核制度既有针对部门的，也有针对部门下设岗位的。需要特别注意的是，当新建部门和其他部门之间存在较多资源共用的情况（在矩阵式管理结构中这一点尤为普遍），为部门做绩效考核指标设计时，不能忽略对资源共用部门绩效制度的调整，否则新建部门的资源保障将会成为大问题。
以本节中的项目拓展部为例，经过重新规划以后的项目拓展部，尽管不再像从前那样完全依靠各个部门资源过活，有一些职能的履行也还是需要借助到其他部门资源，简单地说，重新构建出的项目拓展部变成了一个半矩阵式管理结构，一部分资源为部门自有，一部分资源则要取自其他部门，所以在做部门绩效指标设计时，我专门就这个问题，和老板讨论过，如果项目拓展部要借用其他部门的资源，他要如何补偿其他部门？
有关这个问题的一个简单实例，是这样的：假设项目拓展部争取到一个项目，需要研发部帮手写一个技术方案，要使研发部的负责人非常爽快地把这个任务接下来，项目拓展部要许给他们何种好处？
最后讨论结果是这样：有业绩指标压力的部门向项目拓展部出借资源，根据其参与项目的程度，按比例划分项目成交额，算为部门（或个人）业绩，得冲抵部门（个人）业绩指标；对于没有业绩指标压力的部门，则由部门负责人和项目拓展部将项目拓展部需求折算为工作量，由项目拓展部支付出借部门补贴（这些补贴对出借部门来说是外快，只要工作没有大的疏漏，这就是部门的利润了），该笔补贴计为项目拓展部成本。
确定这项思路之后，各部门对项目拓展部提交的业务需求有了很大的转变，处理起来的速度明显快了很多，而且时不时还会关怀项目的进度，主动要求提供帮助，从前的过街老鼠摇身一变成了贵客，以至于项目拓展部经理都有点不习惯。
③部门资源管理制度
这是用来管理部门资源用的，在部门内部，除了有形的资源以外，还有更多无形的资源，尤其是知识型组织，如部门内部的工作手册、客户信息、技术文档、计划模板、方案模板等。
这些只是最基本的部门管理制度，根据部门的属性不同，构建者可能还需要设计适应部门职能的特别制度。
（4）制定部门介绍
（5）制作宣讲课件，通告公司全体成员
在这里介绍的部门构建方式，属于从上而下构建部门，在实际的管理工作中，有时候当公司发展到一定阶段，部门也会自然形成，或者已有的部门分裂出新部门，不过，不管是哪一种产生方式，使一个部门能够有序运作的要求是基本相同的，上述这些流程中所涉及的事项，有一些会在实务中被省略，而有些在实务中存在的流程我却并没有提及，我想说的是，流程是死的，人是活的，而设计部门的方法则是千变万化的，所以只要规划得当，对流程和制度进行增删改查，都是可行的。设计得好的部门可能很长时间内都无法证明设计者的功力，但是设计得不好的部门却不需多少时间，就会用它的表现——始终没有业绩、工作无序、员工懒散、人员流动频繁、效率低下等等——将设计者的缺陷一一暴露出来。
简而言之，部门构建是一个比岗位设计复杂，比组织调整细致的工作，对构建者来说，部门设计的成功与否，往往只是一个念头之间的距离，正如那句谚语所说的：Success is often justAn ideaAway。
