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