- 最后登录
- 2016-3-21
- 注册时间
- 2010-12-21
- 威望
- 531
- 金钱
- 1761
- 贡献
- 285
- 阅读权限
- 50
- 积分
- 2577
- 日志
- 52
- 记录
- 16
- 帖子
- 48
- 主题
- 18
- 精华
- 4
- 好友
- 90
该用户从未签到 - 注册时间
- 2010-12-21
- 最后登录
- 2016-3-21
- 积分
- 2577
- 精华
- 4
- 主题
- 18
- 帖子
- 48
|
本帖最后由 spcchenyue 于 2014-8-26 13:04 编辑
" p3 J! I8 r" g2 D8 i
# P9 J R+ ?' ^% g( C3 j谢谢楼上的,也祝你新年好:). L2 u4 }' }1 `, p6 k$ L2 j t
岗位信息收集齐全之后,接下来我做的是规范部门职能。7 |( K+ {1 F g% h* C* E0 P+ s
. d# O# _- z: q
之所以会着手做这方面工作,和我公司的实际情况有关。/ ?1 ]6 ]4 ^8 y: Y' X; }7 M
) C. D! E q, O3 O/ n 我公司是做应用软件开发的,主营自有知识产权的应用软件,也为客户定制开发系统,采用的组织结构是一种类似于职能型设计的形式,部门设计上包括行政部、人事部、财务部、客户服务部、软件开发部、软件研发部、软件测试部、商务部、企划部、总经办、产品部、咨询部等部门外加各地分公司。这样的结构也是经过很多年发展形成的。但是部门构建的过程当中,我们其实都不太懂组织管理,基本上是心里怎么想就怎么做,一个部门出现,只有创建者知道他大概是负责什么工作,但是并没有书面的文件或者相关的制度体系来规范它的职责,界定它的权益,明确它在组织中的地位,至于和组织建设休戚相关的沟通制度,越发没有涉及到了,这导致了很多问题,最明显的一个就是,有些业务多个部门都在参与但有些业务却没有人跟进;由于部门职 责不清晰,很多时候出了问题,也找不到相关的责任人。
; q! y7 X; j' c' r) o* N6 W
+ q6 W {5 V/ u) u: _ 这个问题早两年我已经发现,但是一直没有找到解决的机会,此次索性把它提出来一并解决了。7 k" ]. l' h4 p
- W# P0 L5 H& v3 s; {- J 在部门如何构建这个问题上,管理学中有很多理论,有的说应该以职能为基础构建部门,有的说应该以产品为基础构建部门,有的主张以顾客群为基础构建部门。就我个人的看法,我是觉得,采取什么方式不重要,条条大路通罗马,重要的是,一旦部门建立起来,就要明确其职责所在,有相关的考核体系,有相关的职权分配,当然,最最重要的是,要建立起相关的沟通制度,也就是职位之间和部门之间的报告关系,这一点真是太重要了。; L% Q2 c5 o( U. ?
4 I+ p8 d( C* x. Z 我不知道别人有这种感慨没有,组织越庞大,职位之间的报告关系就越是要严加规范,否则信息很可能会在传递过程中出现丢失,导致大量成本浪费。, S4 T8 _# `- ^6 E5 X5 Q: S0 z
9 \% _' p+ z" l3 `1 ^8 s( t 回头来说我的部门调整,我最终采取的还是职能制的调整方式,以职能为基础,逐个规范部门职能,这件事做起来倒是不复杂,我是这样做的:# u) |" J0 J$ `- |
: g0 t6 Q/ C% K# U3 S* U( i4 m
1, 定工作流。我将公司现有的工作流定义为软件、营销、人力行政、客服几个大类。6 M) Y( I1 }! Q
' C' |1 K5 A' }! z. a* o2 _ 2,根据工作流将相关部门负责人召集起来,一起讨论该工作流应当分为几个阶段,每个阶段主要工作包括哪些,其目标是什么,这些目标分解后具体由哪个部门承担。
8 r5 l y3 N6 D8 j6 z
, r6 J& f) _( Z: L: {) k 在明确部门需要承担的具体工作这个问题上,我没有受过专业的培训,不知道别人是怎么做的,我自己的一点心得,是这样的:首先确定部门承担工作流程中的哪个环节,其次使用了穷举法,把流程中这个环节可能会涉及到的工作,进行抽象概括和归类(这个时候岗位说明书上写的那些信息就显出大用处了),全部划入这个部门的职责范围,另外,一切和实现部门目标有直接关系、但是我没有列举出来的工作,也都归入该部门,除非有其他的部门愿意主动承担。
+ o2 ^; O/ X* ]+ D9 B+ X6 x- r- Y' ?$ I& K, P
举个例子说:比如我们的产品部,最后它被定义成了营销流的部门,在整个营销系统中,主要负责软件产品规划和普及工作。经过和大家的讨论之后,我最终这样定义它的职能:产品的市场分析、版本规划、产品整合、产品销售工具制作和开发、产品培训等一切能够或者有助于产品优化,提高产品竞争力的人力、物流、财力投入,均由产品部负责。! T; y9 P/ i% l% @# Z- s! S
1 {( z! D. v: i 这一点算是细节方面的注意事项,老实说,我觉得,这很考验个人的思维能力和表达能力。如果对于流程本身没有十足的把握,最好是和大家一起多合计。
' E# D, k# e3 D3 z+ J# d
; h% B* k( ~, |4 A3,每完成一个工作流的部门整合工作,就出一份类似于备忘录的阶段汇报,整个部门职能规划工作完成之后,更新组织框架图,公告给全公司。9 f X+ o# U9 Q
) I9 W9 e( ?, c5 l8 d s2 l
这件事做完之后,一些可有可无的部门被正式的合并掉了,另外一些带有附属性和服务性的部门(比如说我们的软件测试部),则并入了其主体部门。我当时这样说服总经理,此举会让整个组织反映更灵敏,因为减少了部门和部门的沟通成本。但是现在又觉得,为了追求这一点灵敏度,我其实增加了组织中层的管理难度(部门越大越难管理,岗位越多越难统御),不知道是不是值得。毕竟我们只是中等规模的公司,组织本身并没有庞大到可能出现官僚和反映迟钝的地步,而这样的公司,中层管理人员的素质普遍都是有待提高的。
5 B1 y3 s) Y$ l3 T, G; {) q' L4 ]$ u. Z6 D B; e+ ?
把这一步做完之后,我重新将重心转移到了部门内部的岗位设计上,目的是想要结合部门职责,重新审视部门内部的岗位设计,看看是否需要调整以及如何调整。我自己的想法是:当我把部门内部的岗位体系设计得足够合理,能够承担该部门正常的产出要求时,至少在理论基础上,我就可以估算这个部门的普遍产出率,再结合该部门的年度绩效考核指标以及现有人力资源储备,基本上应该就可以预估出该部门的人力需求了。6 M8 q3 k- w5 Y$ L- t: M% l
/ R& P& k( H1 y$ A8 b8 P0 `
我不肯定这种想法一定对,我和部门负责人交流的时候,将这种思路向他们解释,大家都吃不准是否行得通,但是都觉得可以尝试,这个大概就是在一个比较年轻的组织内工作的好处吧,条条框框比较少。
& @9 p% V! b/ a9 k( X
5 t7 H' M6 H$ n/ D9 g% X待续。。。。。。
9 N: W# v: T2 B |
-
总评分: 金钱 + 18
查看全部评分
|