- 最后登录
- 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 编辑
% h) o$ A* Q* c; f8 s
0 O; A1 R1 b; W& i谢谢楼上的,也祝你新年好:)3 ]" k/ e) W& o. z' y' I
岗位信息收集齐全之后,接下来我做的是规范部门职能。
" ?3 M2 E2 W9 h$ c, T9 ~' Y0 m8 o, b& e. i" C: l: Z
之所以会着手做这方面工作,和我公司的实际情况有关。, a8 C: S" y; t: e
# }4 R% T, |& G! |$ I
我公司是做应用软件开发的,主营自有知识产权的应用软件,也为客户定制开发系统,采用的组织结构是一种类似于职能型设计的形式,部门设计上包括行政部、人事部、财务部、客户服务部、软件开发部、软件研发部、软件测试部、商务部、企划部、总经办、产品部、咨询部等部门外加各地分公司。这样的结构也是经过很多年发展形成的。但是部门构建的过程当中,我们其实都不太懂组织管理,基本上是心里怎么想就怎么做,一个部门出现,只有创建者知道他大概是负责什么工作,但是并没有书面的文件或者相关的制度体系来规范它的职责,界定它的权益,明确它在组织中的地位,至于和组织建设休戚相关的沟通制度,越发没有涉及到了,这导致了很多问题,最明显的一个就是,有些业务多个部门都在参与但有些业务却没有人跟进;由于部门职 责不清晰,很多时候出了问题,也找不到相关的责任人。
* F/ _7 U2 g5 E$ q" c* H/ U* i* | s% O& x( i8 b, `
这个问题早两年我已经发现,但是一直没有找到解决的机会,此次索性把它提出来一并解决了。& h) D3 ^0 ` q$ A
- _% l) L# U; h2 Y0 v+ k
在部门如何构建这个问题上,管理学中有很多理论,有的说应该以职能为基础构建部门,有的说应该以产品为基础构建部门,有的主张以顾客群为基础构建部门。就我个人的看法,我是觉得,采取什么方式不重要,条条大路通罗马,重要的是,一旦部门建立起来,就要明确其职责所在,有相关的考核体系,有相关的职权分配,当然,最最重要的是,要建立起相关的沟通制度,也就是职位之间和部门之间的报告关系,这一点真是太重要了。% P/ n- w0 m0 f; {/ }1 J" e
8 ^ ^0 t+ M t% O% N
我不知道别人有这种感慨没有,组织越庞大,职位之间的报告关系就越是要严加规范,否则信息很可能会在传递过程中出现丢失,导致大量成本浪费。
& [: S+ M2 l2 m; m9 J7 R
. Y" K: O, J1 s3 _8 s 回头来说我的部门调整,我最终采取的还是职能制的调整方式,以职能为基础,逐个规范部门职能,这件事做起来倒是不复杂,我是这样做的:
( R% {' _% }8 n& k1 x3 t. F
0 y; C# j9 q; ]3 E7 y 1, 定工作流。我将公司现有的工作流定义为软件、营销、人力行政、客服几个大类。2 f2 J& C% j% V
: H* w* j9 y- `0 W { 2,根据工作流将相关部门负责人召集起来,一起讨论该工作流应当分为几个阶段,每个阶段主要工作包括哪些,其目标是什么,这些目标分解后具体由哪个部门承担。" ]+ n2 G, B6 @$ F
) W" H0 L& ]; o* [- i+ \9 U9 b 在明确部门需要承担的具体工作这个问题上,我没有受过专业的培训,不知道别人是怎么做的,我自己的一点心得,是这样的:首先确定部门承担工作流程中的哪个环节,其次使用了穷举法,把流程中这个环节可能会涉及到的工作,进行抽象概括和归类(这个时候岗位说明书上写的那些信息就显出大用处了),全部划入这个部门的职责范围,另外,一切和实现部门目标有直接关系、但是我没有列举出来的工作,也都归入该部门,除非有其他的部门愿意主动承担。5 m# Q" H1 H. X5 g: g- ^3 r% @0 ]
0 E7 t) A+ c. d1 m i
举个例子说:比如我们的产品部,最后它被定义成了营销流的部门,在整个营销系统中,主要负责软件产品规划和普及工作。经过和大家的讨论之后,我最终这样定义它的职能:产品的市场分析、版本规划、产品整合、产品销售工具制作和开发、产品培训等一切能够或者有助于产品优化,提高产品竞争力的人力、物流、财力投入,均由产品部负责。9 Y6 J# Q3 X2 S6 q7 I, g: f
$ q% P) v# t7 i8 I9 T9 ?+ c X
这一点算是细节方面的注意事项,老实说,我觉得,这很考验个人的思维能力和表达能力。如果对于流程本身没有十足的把握,最好是和大家一起多合计。
8 _- ?- ?7 U/ U! P4 p
9 P1 L0 K( v! B" O4 y0 a3,每完成一个工作流的部门整合工作,就出一份类似于备忘录的阶段汇报,整个部门职能规划工作完成之后,更新组织框架图,公告给全公司。$ j3 w% [7 p8 d9 }
; W2 f$ }/ {% c4 {, _ 这件事做完之后,一些可有可无的部门被正式的合并掉了,另外一些带有附属性和服务性的部门(比如说我们的软件测试部),则并入了其主体部门。我当时这样说服总经理,此举会让整个组织反映更灵敏,因为减少了部门和部门的沟通成本。但是现在又觉得,为了追求这一点灵敏度,我其实增加了组织中层的管理难度(部门越大越难管理,岗位越多越难统御),不知道是不是值得。毕竟我们只是中等规模的公司,组织本身并没有庞大到可能出现官僚和反映迟钝的地步,而这样的公司,中层管理人员的素质普遍都是有待提高的。
4 a& _6 G' z9 ^0 s! S% {# T
2 C5 Z% v5 | ~ 把这一步做完之后,我重新将重心转移到了部门内部的岗位设计上,目的是想要结合部门职责,重新审视部门内部的岗位设计,看看是否需要调整以及如何调整。我自己的想法是:当我把部门内部的岗位体系设计得足够合理,能够承担该部门正常的产出要求时,至少在理论基础上,我就可以估算这个部门的普遍产出率,再结合该部门的年度绩效考核指标以及现有人力资源储备,基本上应该就可以预估出该部门的人力需求了。9 M' X7 |, c; [* a3 |- W
; @6 i9 d3 C. u/ y+ @* T0 S
我不肯定这种想法一定对,我和部门负责人交流的时候,将这种思路向他们解释,大家都吃不准是否行得通,但是都觉得可以尝试,这个大概就是在一个比较年轻的组织内工作的好处吧,条条框框比较少。
1 K- G- q n2 K3 |8 _% {; [
7 J( ?8 s- x( i待续。。。。。。
% W# b7 i4 L9 G: Q4 w" \9 ]* s P |
-
总评分: 金钱 + 18
查看全部评分
|