案例场景
我们以案例故事的方式，说明企业在项目管理上遇到的问题以及每个层面适用的情况。案例故事的主体是一家ERP系统开发公司，相关数据如下：
案例主体：某本土ERP系统开发公司
营业额：XX亿元
员工：XX人
产业特性：接到订单后，必须依据客户要求列出待开发的功能项目，交由研发部门执行程序开发，并整合成为系统功能的一部分，再由客服部门提供导入的服务，工程师会协助客户安装系统以及提供使用者教育训练。
产品模块：财务模块、薪酬模块、库存管理模块、制造管理模块、订单处理模块、采购模块等等。
负责A客户系统导入的项目负责人李勇拿着手上的单子，怒气冲冲的朝着研发部门走去，原来他已向客户承诺明天前往安装新系统功能，但是刚刚手下的工程师通知他研发部门还没将功能开发完成，情急之下就想找研发主管理论。
李勇见到研发主管齐威时，本着专业的态度先压下心中怒火，以还算委婉的语气询问两周前即已提出的功能开发需求，为何到今天尚未完成。由于李勇面色不善，一向不喜与人争执的齐经理耐着性子向李勇解释：“由于这两周的开发项目比较多，其中有大型客户预定的开发项目，必须到下周一才能将A客户的功能需求完成。”
经过齐经理的解释后，李勇怒气未消，质疑着说依过去的经验，A客户所需的功能只要60个工作小时即可完成，研发部门有那么多人，为何已花了两个礼拜的时间还无法完成。虽然因李勇的逼人语气而有些不高兴，齐经理还是很有耐心的说明，A客户所需功能的开发时数不只60小时，此外由于研发人员擅长的项目不尽相同，而且还有新人要训练，所以研发部门要将预计开发的项目与人员的专长作调配，再来排时程，不太可能直接将工作时数换算成天数来交件。另一方面齐经理也指出，李勇当时只是传来一张联络单要求开发的功能项目及日期，并未与研发部门进一步确认这些功能开发的难易度及时程；齐经理进一步质疑A客户的需求早在上个月中即已收集完毕，李勇为何不早点提出，造成研发部门上个月有2名人员闲置，而这个月所有人员都得加班的不平衡现象，增加齐经理管理上的困扰。
看着齐经理柔中带刚的态度加上知道自己理亏，李勇心里明白没有继续争辩的理由，除了请齐经理早日定下研发项目的标准工时以及主动提供研发时程等信息给相关项目负责人，也只能自认倒霉回去想想要编什么样的理由向客户解释，不过客户对公司服务不满意，是可以预见的。
企业在资源管理方面常遇到下列问题：
●规划项目应完成的工作时，无法合理估计需要多少资源，包含人力、设备、共同资源及其他辅助单位的支持。
●项目执行时，原本预定的资源遭挪用，由于人力断层导致项目进度中断或延后；或是提供支持的部门迟迟无法将工作完成，影响到研发部门后续工作的进行。
●部门人力资源分配不均，有些人员业务繁重，有些人员则游手好闲。
●对部门资源的需求未作适当安排，造成某些月份工作量大，某些月份人员闲置。
●缺乏客观的数据来评估部门或人员执行工作的效率，也没有预计与实际工作时数的比较数据。
为了解决这些问题，在资源管理方面应建立以下制度：
1、标准工时
——将参与研发流程的相关部门区分为主体部门、共享资源部门、支持部门。
——由各个部门依据细部工作清单，估计每个项目的标准工时或工时范围：
（1）可视情况，选择周、天、或小时作为计算标准工时的单位；
（2）在选择标准工时的计算单位，应从“精确程度”、“控制效果”、与“误差高低”三个角度来衡量。
——制作ISO文件及项目规范，项目规范中应说明如何在标准时数内完成各工作项目。
——机器设备或其他资源亦可采用类似方法评估标准工时，作为资源分配的依据。
2、部门资源分配
——评估人员的素质，初步计算部门对于每个工作项目所能提供的最大产能。
——设计资源分配表，显示资源分配及耗用情形：
（1）应重视人员的能力、成长性，使实际执行情形与标准工时相符；
（2）运用项目研究等资源分配工具。
——规定资源挪用的权限、判断标准与机制。
3、部门/人员项目时程规划
——律定时程变更的机制。
——设计各部门及人员的工作排程方式。
——将此信息以及时的方式提供给其他部门：
（1）考虑人员的人格特质，尽可能人性化；
（2）搭配项目研究的工具以及排程软件。
4、资源耗用统计
——设计工时报告并要求人员填写。
——累积资源耗用时数。
——其他部分可参考ABC、ABM之作法。[@more@]
我们以案例故事的方式，说明企业在项目管理上遇到的问题以及每个层面适用的情况。案例故事的主体是一家ERP系统开发公司，相关数据如下：
案例主体：某本土ERP系统开发公司
营业额：XX亿元
员工：XX人
产业特性：接到订单后，必须依据客户要求列出待开发的功能项目，交由研发部门执行程序开发，并整合成为系统功能的一部分，再由客服部门提供导入的服务，工程师会协助客户安装系统以及提供使用者教育训练。
产品模块：财务模块、薪酬模块、库存管理模块、制造管理模块、订单处理模块、采购模块等等。
负责A客户系统导入的项目负责人李勇拿着手上的单子，怒气冲冲的朝着研发部门走去，原来他已向客户承诺明天前往安装新系统功能，但是刚刚手下的工程师通知他研发部门还没将功能开发完成，情急之下就想找研发主管理论。
李勇见到研发主管齐威时，本着专业的态度先压下心中怒火，以还算委婉的语气询问两周前即已提出的功能开发需求，为何到今天尚未完成。由于李勇面色不善，一向不喜与人争执的齐经理耐着性子向李勇解释：“由于这两周的开发项目比较多，其中有大型客户预定的开发项目，必须到下周一才能将A客户的功能需求完成。”
经过齐经理的解释后，李勇怒气未消，质疑着说依过去的经验，A客户所需的功能只要60个工作小时即可完成，研发部门有那么多人，为何已花了两个礼拜的时间还无法完成。虽然因李勇的逼人语气而有些不高兴，齐经理还是很有耐心的说明，A客户所需功能的开发时数不只60小时，此外由于研发人员擅长的项目不尽相同，而且还有新人要训练，所以研发部门要将预计开发的项目与人员的专长作调配，再来排时程，不太可能直接将工作时数换算成天数来交件。另一方面齐经理也指出，李勇当时只是传来一张联络单要求开发的功能项目及日期，并未与研发部门进一步确认这些功能开发的难易度及时程；齐经理进一步质疑A客户的需求早在上个月中即已收集完毕，李勇为何不早点提出，造成研发部门上个月有2名人员闲置，而这个月所有人员都得加班的不平衡现象，增加齐经理管理上的困扰。
看着齐经理柔中带刚的态度加上知道自己理亏，李勇心里明白没有继续争辩的理由，除了请齐经理早日定下研发项目的标准工时以及主动提供研发时程等信息给相关项目负责人，也只能自认倒霉回去想想要编什么样的理由向客户解释，不过客户对公司服务不满意，是可以预见的。
企业在资源管理方面常遇到下列问题：
●规划项目应完成的工作时，无法合理估计需要多少资源，包含人力、设备、共同资源及其他辅助单位的支持。
●项目执行时，原本预定的资源遭挪用，由于人力断层导致项目进度中断或延后；或是提供支持的部门迟迟无法将工作完成，影响到研发部门后续工作的进行。
●部门人力资源分配不均，有些人员业务繁重，有些人员则游手好闲。
●对部门资源的需求未作适当安排，造成某些月份工作量大，某些月份人员闲置。
●缺乏客观的数据来评估部门或人员执行工作的效率，也没有预计与实际工作时数的比较数据。
为了解决这些问题，在资源管理方面应建立以下制度：
1、标准工时
——将参与研发流程的相关部门区分为主体部门、共享资源部门、支持部门。
——由各个部门依据细部工作清单，估计每个项目的标准工时或工时范围：
（1）可视情况，选择周、天、或小时作为计算标准工时的单位；
（2）在选择标准工时的计算单位，应从“精确程度”、“控制效果”、与“误差高低”三个角度来衡量。
——制作ISO文件及项目规范，项目规范中应说明如何在标准时数内完成各工作项目。
——机器设备或其他资源亦可采用类似方法评估标准工时，作为资源分配的依据。
2、部门资源分配
——评估人员的素质，初步计算部门对于每个工作项目所能提供的最大产能。
——设计资源分配表，显示资源分配及耗用情形：
（1）应重视人员的能力、成长性，使实际执行情形与标准工时相符；
（2）运用项目研究等资源分配工具。
——规定资源挪用的权限、判断标准与机制。
3、部门/人员项目时程规划
——律定时程变更的机制。
——设计各部门及人员的工作排程方式。
——将此信息以及时的方式提供给其他部门：
（1）考虑人员的人格特质，尽可能人性化；
（2）搭配项目研究的工具以及排程软件。
4、资源耗用统计
——设计工时报告并要求人员填写。
——累积资源耗用时数。
——其他部分可参考ABC、ABM之作法。[@more@]
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7839396/viewspace-955691/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/7839396/viewspace-955691/
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
