前面的文章我有提到过：“顾问走了之后，数据怎么办”的问题，从而引发了对于DRP项目的外部顾问撤走了之后，企业如何做数据治理的讨论（《管理手记：DRP项目中的数据治理》，http://tech.it168.com/m/p/2007-07-18/200707180903562.shtml） 。今天要讨论的还是老话题：“顾问走了之后，应该怎么办？”，但这个话题的侧重点不在于数据，而在于IT部门应该如何配置DRP的支持小组上。这个“怎么办”，是来说IT经理在人员配置上应该怎么办。
这件事情的讨论起缘于上次和老卓的一次讨论。
老卓是浙江某著名合资企业的IT经理，公司的DRP系统上线已经完成了有一段时间了，外部顾问基本上已经撤出，现在就要老卓来组织人马对这套系统进行维护了，但软件实施方在实施结束前，并未对老卓的DRP系统支持小组如何配置提出建议。当然，从另一个角度上来说，软件供应商可能只对软件产品比较了解，但对于软件系统运营和维护可能也没有太多经验，所以想要提出比较好的解决方案也就比较难了。
那么，我们在和老卓讨论时就想：是否可以试着提出一个方案，或者是有一个配置参考让IT经理能够在做人员配置可以参照。照着这个思路，我试着把原来自己部门里的人员配置作为原始框架，再向同行的几个朋友讨论了一下，对DRP系统支持小组的人员配置进行了如下整理。
对于DRP小组的人员配置，我觉的需要从以下几个角度来考虑。
一、 IT部门人员配置的参考理论基础：IT服务管理
从IT服务生命周期上来看，从软件的分析、设计、开发、实施上是属于IT系统开发的范畴，此时，主要使用CMM、IT项目管理等理论及方法对IT系统开发进行管理。
而从项目实施后期，就进入到了软件项目的运营维护直到报废结束IT系统的生命为止，此时IT系统运营维护在很长一段时间内是缺乏相关的IT服务管理方法论的，直到20世纪80年代后期，ITIL(IT Infrastructure Library，信息技术基础设施库)由英国计算机和电信中心 CCTA(2001年4月并入英国政府商务办公室OGC)提出，在英国开始应用。21世纪初，ITIL引入中国，中国IT服务管理也开始与国际接轨，并有了相应的理论基础。
ITIL由于是一个灵活的配置参考模型，因此，我们在做DRP项目支持小组的人员配置时，就可以以ITIL的模型为参考来做。
ITIL主要包括如下几个功能模块：
1、 IT服务管理实施规划：为客户如何确立远景目标，如何分析现状、确定合理目标并进行差距分析和如何实施活动的优先级，以及如何对实施的流程进行评审，提供了全面指导。
2、 ICT基础架构管理：确保提供一个稳定可靠的IT基础架构，以支持业务运营。
3、 应用管理：协调IT服务管理与应用系统的开发、测试和部署的关系，使它们一致的服务于客户的业务运营。
4、 安全管理：保护IT基础架构，对其采取合适的保护措施，使其免受未经授权的使用。
5、 服务管理：ITIL的核心内容，共分为10个管理流程及1项管理职能，被划分为两组：服务提供和服务支持；服务管理也是我们做项目小组配置的基础。
由于ITIL是一个复杂的模型，因文章所限，所以不能展开论述，如果您对ITIL感兴趣的话，可以通过ITIL组织的网站了解更多内容。
二、 企业规模及组织架构
要做DRP系统支持小组的人员配置之前，首先应该对企业的状况有一个深入的了解，那么我们应该先去了解企业的如下信息：
1、 企业现有的组织架构及DRP系统的覆盖部门：在这里我们可以用一个组织架构图来表示，了解这方面的信息是想让IT经理或企业高层清楚地认识到，DRP系统应用的好坏，是直接影响这些业务部门的工作效率的，而如果这些核心业务部门的工作效率受到影响，公司的经营就不可避免地会受到影响，从而加强公司高层对DRP系统重要性的认识。
图表 2
2、 DRP系统在企业内部的节点数，最近6个月的节点增长数：了解这个问题主要是为了对你做人员配置时，要考虑到人员招聘与培训是要有一定的周期的，而培训一个合格的支持人员，应该需要至少两个月时间，如你现在已经有了100个节点，是由1名支持人员来维护。那么，当你未来6个月会增加到300个节点的时候，你就要考虑在什么时间向公司提出增加人员配置的申请合适，使得公司不会因为提前招聘而员工的工作量不足，又不会出现因为人员没有到位而终端的服务请求频繁得不到及时响应，导致IT部门的服务质量下降的问题了。
3、 IT部门现有的人员配置情况，包括是否有DRP运维经验的员工数；由于DRP系统的运营与维护是一项较为细致且复杂的工作。因此，如果你现有的员工比较有经验，那么接下来做相关的运维工作会容易很多，如果你的员工都是新手，那么，IT经理就要考虑是否向软件厂商申请培训支持了。
图表 3
4、 企业现有的分公司数量，DRP系统已经覆盖的分公司有哪些，未来6个月将要覆盖的分公司有哪些，分公司的规模有多大，IT支持人员是否有必要常驻分公司，常驻的人员将采用当地招聘，总部培训的模式，还是由总部外派？支持人员是接受IT经理的异地管理还是分公司的本地管理？
5、 企业现有的代理商数量，DRP系统已经覆盖的代理商有哪些；企业现有的直营店数量，DRP系统已经覆盖的直营店有哪些；考虑上述这两个问题，也主要是评估工作量及人员的准备情况。
三、 支持小组的配置参考
1、 确定人员分工模式：人员分工基本上有两个思路，一是按ITIL的参考，按流程来划分，如划分为帮助台(Help Desk)、支持小组、安全小组、架构小组，等等，这样的划分方法可以不只是在DRP项目中使用，而是使公司的所有服务请求都在这个分工模式中得到响应。还有另一个思路是，为了DRP项目专门设立DRP项目的支撑小组，从DRP项目后期维护的工作主要职责来划分，可以划分为数据组、培训组、支持组三个小组。
从目前我所接触的企业来看，人员的岗位及职责划分还是基于部门的，而没有达到甚至流程或者是运营的层次，包括公司的考核机制也是按部门进行考核，因此，我在这里也采用了更为实际的方法就是按DRP项目的职责来划分人员分工。
人员分工可参照下图：
图表 4
2、 确定DRP支持小组的岗位成员：从上图可以看到，我把DRP支持小组主要分成三组：
•数据组——主要面对业务部门，负责DRP系统的基础配置管理，人员及权限管理、商品资料管理、数据准确性和及时性管理，业务部门数据分析需求整理及报表定制。
•培训组——主要针对新开专卖店(柜)的DRP系统培训，还有针对内部新员工的入职DRP系统培训，培训督导部门的督导使之能够协助在各专卖店进行DRP系统培训，DRP系统新功能的课程编制等。
•支持组——软件的应用疑难问题解决，设备故障，网络故障的反馈与服务，二次开发需求整理及与软件供应商的开发需求跟进，数据库定时备份等工作。
同时各个小组将由不同角色的岗位成员组成，各个岗位又涉及到具体的职位描述、工作流程与绩效考核，在此由于篇幅原因，就不展开论述，只对数据管理员的职位描述进行说明如下：
a) 系统档案类数据维护，包括：商品档案管理（商品信息维护、商品国际码生成）、价格管理（公司采购价格、分销价格及零售价格维护）、组织人员管理（代理商、门店、供应商、制造商及人员等的维护）、权限管理（对岗位人员及各代理商合理控制、分配权限）。
b) ERP软件资源管理：系统独立门店、脱机门店的控制；门店实施情况整理；软件使用授权号的索取、发放；软件站点使用信息的登记。
c) 月底公司及办事处的数据核对：核对系统是否存在异常数据；为核对好的组织做成本核算、结转。
d) 业务部门ERP系统使用问题解决：软件功能操作指导；错误单据处理；协助收集ERP使用的意见及建议。
e) 处理本部门内需要在ERP中操作的各类事务：协助与ERP相关设备的采购、发货及收货跟踪。
f) IT服务台的相关职责：接受客户的服务请求(电话、邮件、传真)；记录并跟踪事故和客户的意见；及时通知客户其请求的当前状态和最新进展；初步评估客户的请求，尽力解决它们或者将其安排给有关人员解决；对客户请求从提出直至验证和终止的整个过程进行管理；协调二线支持人员和第三方支持小组；提供管理方面的信息和建议以改进服务绩效。
3、 确定DRP支持小组的人数：从上图来看，DRP项目支持小组的人员配置会比较多，其实这只是进行细分之后的一个岗位配备，由于很多企业一个DRP支持小组可能只是一个人，那么就没有分工的说法，一个人全部包揽下来；可以根据具体的企业规模，企业发展规划，DRP系统的应用深度，DRP支持小组配备计划来确定人数。而在此之前讨论的DRP项目经验的IT人员此时就可以成为支持小组的骨干人员，可以充分利用他们的经验，让他们有机会去带领新员工一起开展工作，达到“以老带新”形成IT人员的梯队。
四、 支持小组在DRP项目的切入
DRP项目在最早的规划阶段，就可以将DRP支持小组的配置引进来，在做项目规划的时候，就需要将前面讨论的几个方面作为规划的一部分，这样的话，不至于在DRP项目实施结束之后，IT主管再向公司领导提出因为DRP系统项目上线，需要增加人手来进行管理与维护，使的公司领导觉的DRP系统的人力资源投入会过大。
当然，还有的IT主管，因为担心如果将支持小组的配置做到前期规划中，公司高层会觉的DRP项目的成本过高，而导致项目无法上线。其实这个担心的理由是存在的，特别是在公司规模不是太大的企业，公司高层对于DRP系统的还停留在买一个软件，而并没有一个整体的概念，这个时候如果IT主管不做一些引导，那系统到了运维阶段，能够用到什么样的程度还真的是难说了。
还有一个重要的问题是：如果不在规划阶段做好支持小组的配置，那么在支持小组人员没有到位的情况下启动DRP项目，对于支持人员的前期知识储备，提前进入项目，参与项目实施，DRP软件商的知识传递，业务部门需求理解，软件实施方法等都会存在不利的影响。
所以，DRP支持小组应该是DRP项目规划的一部分，从启动DRP项目那一天起支持小组就应该开始运作，并一直小掌控了DRP项目的整个生命周期。
=================
本文首发于IT168技术频道： http://tech.it168.com。转载请注明出处。
前面的文章我有提到过：“顾问走了之后，数据怎么办”的问题，从而引发了对于DRP项目的外部顾问撤走了之后，企业如何做数据治理的讨论（《管理手记：DRP项目中的数据治理》，http://tech.it168.com/m/p/2007-07-18/200707180903562.shtml） 。今天要讨论的还是老话题：“顾问走了之后，应该怎么办？”，但这个话题的侧重点不在于数据，而在于IT部门应该如何配置DRP的支持小组上。这个“怎么办”，是来说IT经理在人员配置上应该怎么办。
这件事情的讨论起缘于上次和老卓的一次讨论。
老卓是浙江某著名合资企业的IT经理，公司的DRP系统上线已经完成了有一段时间了，外部顾问基本上已经撤出，现在就要老卓来组织人马对这套系统进行维护了，但软件实施方在实施结束前，并未对老卓的DRP系统支持小组如何配置提出建议。当然，从另一个角度上来说，软件供应商可能只对软件产品比较了解，但对于软件系统运营和维护可能也没有太多经验，所以想要提出比较好的解决方案也就比较难了。
那么，我们在和老卓讨论时就想：是否可以试着提出一个方案，或者是有一个配置参考让IT经理能够在做人员配置可以参照。照着这个思路，我试着把原来自己部门里的人员配置作为原始框架，再向同行的几个朋友讨论了一下，对DRP系统支持小组的人员配置进行了如下整理。
对于DRP小组的人员配置，我觉的需要从以下几个角度来考虑。
一、 IT部门人员配置的参考理论基础：IT服务管理
从IT服务生命周期上来看，从软件的分析、设计、开发、实施上是属于IT系统开发的范畴，此时，主要使用CMM、IT项目管理等理论及方法对IT系统开发进行管理。
而从项目实施后期，就进入到了软件项目的运营维护直到报废结束IT系统的生命为止，此时IT系统运营维护在很长一段时间内是缺乏相关的IT服务管理方法论的，直到20世纪80年代后期，ITIL(IT Infrastructure Library，信息技术基础设施库)由英国计算机和电信中心 CCTA(2001年4月并入英国政府商务办公室OGC)提出，在英国开始应用。21世纪初，ITIL引入中国，中国IT服务管理也开始与国际接轨，并有了相应的理论基础。
ITIL由于是一个灵活的配置参考模型，因此，我们在做DRP项目支持小组的人员配置时，就可以以ITIL的模型为参考来做。
ITIL主要包括如下几个功能模块：
1、 IT服务管理实施规划：为客户如何确立远景目标，如何分析现状、确定合理目标并进行差距分析和如何实施活动的优先级，以及如何对实施的流程进行评审，提供了全面指导。
2、 ICT基础架构管理：确保提供一个稳定可靠的IT基础架构，以支持业务运营。
3、 应用管理：协调IT服务管理与应用系统的开发、测试和部署的关系，使它们一致的服务于客户的业务运营。
4、 安全管理：保护IT基础架构，对其采取合适的保护措施，使其免受未经授权的使用。
5、 服务管理：ITIL的核心内容，共分为10个管理流程及1项管理职能，被划分为两组：服务提供和服务支持；服务管理也是我们做项目小组配置的基础。
由于ITIL是一个复杂的模型，因文章所限，所以不能展开论述，如果您对ITIL感兴趣的话，可以通过ITIL组织的网站了解更多内容。
二、 企业规模及组织架构
要做DRP系统支持小组的人员配置之前，首先应该对企业的状况有一个深入的了解，那么我们应该先去了解企业的如下信息：
1、 企业现有的组织架构及DRP系统的覆盖部门：在这里我们可以用一个组织架构图来表示，了解这方面的信息是想让IT经理或企业高层清楚地认识到，DRP系统应用的好坏，是直接影响这些业务部门的工作效率的，而如果这些核心业务部门的工作效率受到影响，公司的经营就不可避免地会受到影响，从而加强公司高层对DRP系统重要性的认识。
图表 2
2、 DRP系统在企业内部的节点数，最近6个月的节点增长数：了解这个问题主要是为了对你做人员配置时，要考虑到人员招聘与培训是要有一定的周期的，而培训一个合格的支持人员，应该需要至少两个月时间，如你现在已经有了100个节点，是由1名支持人员来维护。那么，当你未来6个月会增加到300个节点的时候，你就要考虑在什么时间向公司提出增加人员配置的申请合适，使得公司不会因为提前招聘而员工的工作量不足，又不会出现因为人员没有到位而终端的服务请求频繁得不到及时响应，导致IT部门的服务质量下降的问题了。
3、 IT部门现有的人员配置情况，包括是否有DRP运维经验的员工数；由于DRP系统的运营与维护是一项较为细致且复杂的工作。因此，如果你现有的员工比较有经验，那么接下来做相关的运维工作会容易很多，如果你的员工都是新手，那么，IT经理就要考虑是否向软件厂商申请培训支持了。
图表 3
4、 企业现有的分公司数量，DRP系统已经覆盖的分公司有哪些，未来6个月将要覆盖的分公司有哪些，分公司的规模有多大，IT支持人员是否有必要常驻分公司，常驻的人员将采用当地招聘，总部培训的模式，还是由总部外派？支持人员是接受IT经理的异地管理还是分公司的本地管理？
5、 企业现有的代理商数量，DRP系统已经覆盖的代理商有哪些；企业现有的直营店数量，DRP系统已经覆盖的直营店有哪些；考虑上述这两个问题，也主要是评估工作量及人员的准备情况。
三、 支持小组的配置参考
1、 确定人员分工模式：人员分工基本上有两个思路，一是按ITIL的参考，按流程来划分，如划分为帮助台(Help Desk)、支持小组、安全小组、架构小组，等等，这样的划分方法可以不只是在DRP项目中使用，而是使公司的所有服务请求都在这个分工模式中得到响应。还有另一个思路是，为了DRP项目专门设立DRP项目的支撑小组，从DRP项目后期维护的工作主要职责来划分，可以划分为数据组、培训组、支持组三个小组。
从目前我所接触的企业来看，人员的岗位及职责划分还是基于部门的，而没有达到甚至流程或者是运营的层次，包括公司的考核机制也是按部门进行考核，因此，我在这里也采用了更为实际的方法就是按DRP项目的职责来划分人员分工。
人员分工可参照下图：
图表 4
2、 确定DRP支持小组的岗位成员：从上图可以看到，我把DRP支持小组主要分成三组：
•数据组——主要面对业务部门，负责DRP系统的基础配置管理，人员及权限管理、商品资料管理、数据准确性和及时性管理，业务部门数据分析需求整理及报表定制。
•培训组——主要针对新开专卖店(柜)的DRP系统培训，还有针对内部新员工的入职DRP系统培训，培训督导部门的督导使之能够协助在各专卖店进行DRP系统培训，DRP系统新功能的课程编制等。
•支持组——软件的应用疑难问题解决，设备故障，网络故障的反馈与服务，二次开发需求整理及与软件供应商的开发需求跟进，数据库定时备份等工作。
同时各个小组将由不同角色的岗位成员组成，各个岗位又涉及到具体的职位描述、工作流程与绩效考核，在此由于篇幅原因，就不展开论述，只对数据管理员的职位描述进行说明如下：
a) 系统档案类数据维护，包括：商品档案管理（商品信息维护、商品国际码生成）、价格管理（公司采购价格、分销价格及零售价格维护）、组织人员管理（代理商、门店、供应商、制造商及人员等的维护）、权限管理（对岗位人员及各代理商合理控制、分配权限）。
b) ERP软件资源管理：系统独立门店、脱机门店的控制；门店实施情况整理；软件使用授权号的索取、发放；软件站点使用信息的登记。
c) 月底公司及办事处的数据核对：核对系统是否存在异常数据；为核对好的组织做成本核算、结转。
d) 业务部门ERP系统使用问题解决：软件功能操作指导；错误单据处理；协助收集ERP使用的意见及建议。
e) 处理本部门内需要在ERP中操作的各类事务：协助与ERP相关设备的采购、发货及收货跟踪。
f) IT服务台的相关职责：接受客户的服务请求(电话、邮件、传真)；记录并跟踪事故和客户的意见；及时通知客户其请求的当前状态和最新进展；初步评估客户的请求，尽力解决它们或者将其安排给有关人员解决；对客户请求从提出直至验证和终止的整个过程进行管理；协调二线支持人员和第三方支持小组；提供管理方面的信息和建议以改进服务绩效。
3、 确定DRP支持小组的人数：从上图来看，DRP项目支持小组的人员配置会比较多，其实这只是进行细分之后的一个岗位配备，由于很多企业一个DRP支持小组可能只是一个人，那么就没有分工的说法，一个人全部包揽下来；可以根据具体的企业规模，企业发展规划，DRP系统的应用深度，DRP支持小组配备计划来确定人数。而在此之前讨论的DRP项目经验的IT人员此时就可以成为支持小组的骨干人员，可以充分利用他们的经验，让他们有机会去带领新员工一起开展工作，达到“以老带新”形成IT人员的梯队。
四、 支持小组在DRP项目的切入
DRP项目在最早的规划阶段，就可以将DRP支持小组的配置引进来，在做项目规划的时候，就需要将前面讨论的几个方面作为规划的一部分，这样的话，不至于在DRP项目实施结束之后，IT主管再向公司领导提出因为DRP系统项目上线，需要增加人手来进行管理与维护，使的公司领导觉的DRP系统的人力资源投入会过大。
当然，还有的IT主管，因为担心如果将支持小组的配置做到前期规划中，公司高层会觉的DRP项目的成本过高，而导致项目无法上线。其实这个担心的理由是存在的，特别是在公司规模不是太大的企业，公司高层对于DRP系统的还停留在买一个软件，而并没有一个整体的概念，这个时候如果IT主管不做一些引导，那系统到了运维阶段，能够用到什么样的程度还真的是难说了。
还有一个重要的问题是：如果不在规划阶段做好支持小组的配置，那么在支持小组人员没有到位的情况下启动DRP项目，对于支持人员的前期知识储备，提前进入项目，参与项目实施，DRP软件商的知识传递，业务部门需求理解，软件实施方法等都会存在不利的影响。
所以，DRP支持小组应该是DRP项目规划的一部分，从启动DRP项目那一天起支持小组就应该开始运作，并一直小掌控了DRP项目的整个生命周期。
=================
本文首发于IT168技术频道： http://tech.it168.com。转载请注明出处。
前面的文章我有提到过：“顾问走了之后，数据怎么办”的问题，从而引发了对于DRP项目的外部顾问撤走了之后，企业如何做数据治理的讨论（《管理手记：DRP项目中的数据治理》，http://tech.it168.com/m/p/2007-07-18/200707180903562.shtml） 。今天要讨论的还是老话题：“顾问走了之后，应该怎么办？”，但这个话题的侧重点不在于数据，而在于IT部门应该如何配置DRP的支持小组上。这个“怎么办”，是来说IT经理在人员配置上应该怎么办。
这件事情的讨论起缘于上次和老卓的一次讨论。
老卓是浙江某著名合资企业的IT经理，公司的DRP系统上线已经完成了有一段时间了，外部顾问基本上已经撤出，现在就要老卓来组织人马对这套系统进行维护了，但软件实施方在实施结束前，并未对老卓的DRP系统支持小组如何配置提出建议。当然，从另一个角度上来说，软件供应商可能只对软件产品比较了解，但对于软件系统运营和维护可能也没有太多经验，所以想要提出比较好的解决方案也就比较难了。
那么，我们在和老卓讨论时就想：是否可以试着提出一个方案，或者是有一个配置参考让IT经理能够在做人员配置可以参照。照着这个思路，我试着把原来自己部门里的人员配置作为原始框架，再向同行的几个朋友讨论了一下，对DRP系统支持小组的人员配置进行了如下整理。
对于DRP小组的人员配置，我觉的需要从以下几个角度来考虑。
一、 IT部门人员配置的参考理论基础：IT服务管理
从IT服务生命周期上来看，从软件的分析、设计、开发、实施上是属于IT系统开发的范畴，此时，主要使用CMM、IT项目管理等理论及方法对IT系统开发进行管理。
而从项目实施后期，就进入到了软件项目的运营维护直到报废结束IT系统的生命为止，此时IT系统运营维护在很长一段时间内是缺乏相关的IT服务管理方法论的，直到20世纪80年代后期，ITIL(IT Infrastructure Library，信息技术基础设施库)由英国计算机和电信中心 CCTA(2001年4月并入英国政府商务办公室OGC)提出，在英国开始应用。21世纪初，ITIL引入中国，中国IT服务管理也开始与国际接轨，并有了相应的理论基础。
ITIL由于是一个灵活的配置参考模型，因此，我们在做DRP项目支持小组的人员配置时，就可以以ITIL的模型为参考来做。
ITIL主要包括如下几个功能模块：
1、 IT服务管理实施规划：为客户如何确立远景目标，如何分析现状、确定合理目标并进行差距分析和如何实施活动的优先级，以及如何对实施的流程进行评审，提供了全面指导。
2、 ICT基础架构管理：确保提供一个稳定可靠的IT基础架构，以支持业务运营。
3、 应用管理：协调IT服务管理与应用系统的开发、测试和部署的关系，使它们一致的服务于客户的业务运营。
4、 安全管理：保护IT基础架构，对其采取合适的保护措施，使其免受未经授权的使用。
5、 服务管理：ITIL的核心内容，共分为10个管理流程及1项管理职能，被划分为两组：服务提供和服务支持；服务管理也是我们做项目小组配置的基础。
由于ITIL是一个复杂的模型，因文章所限，所以不能展开论述，如果您对ITIL感兴趣的话，可以通过ITIL组织的网站了解更多内容。
二、 企业规模及组织架构
要做DRP系统支持小组的人员配置之前，首先应该对企业的状况有一个深入的了解，那么我们应该先去了解企业的如下信息：
1、 企业现有的组织架构及DRP系统的覆盖部门：在这里我们可以用一个组织架构图来表示，了解这方面的信息是想让IT经理或企业高层清楚地认识到，DRP系统应用的好坏，是直接影响这些业务部门的工作效率的，而如果这些核心业务部门的工作效率受到影响，公司的经营就不可避免地会受到影响，从而加强公司高层对DRP系统重要性的认识。
图表 2
2、 DRP系统在企业内部的节点数，最近6个月的节点增长数：了解这个问题主要是为了对你做人员配置时，要考虑到人员招聘与培训是要有一定的周期的，而培训一个合格的支持人员，应该需要至少两个月时间，如你现在已经有了100个节点，是由1名支持人员来维护。那么，当你未来6个月会增加到300个节点的时候，你就要考虑在什么时间向公司提出增加人员配置的申请合适，使得公司不会因为提前招聘而员工的工作量不足，又不会出现因为人员没有到位而终端的服务请求频繁得不到及时响应，导致IT部门的服务质量下降的问题了。
3、 IT部门现有的人员配置情况，包括是否有DRP运维经验的员工数；由于DRP系统的运营与维护是一项较为细致且复杂的工作。因此，如果你现有的员工比较有经验，那么接下来做相关的运维工作会容易很多，如果你的员工都是新手，那么，IT经理就要考虑是否向软件厂商申请培训支持了。
图表 3
4、 企业现有的分公司数量，DRP系统已经覆盖的分公司有哪些，未来6个月将要覆盖的分公司有哪些，分公司的规模有多大，IT支持人员是否有必要常驻分公司，常驻的人员将采用当地招聘，总部培训的模式，还是由总部外派？支持人员是接受IT经理的异地管理还是分公司的本地管理？
5、 企业现有的代理商数量，DRP系统已经覆盖的代理商有哪些；企业现有的直营店数量，DRP系统已经覆盖的直营店有哪些；考虑上述这两个问题，也主要是评估工作量及人员的准备情况。
三、 支持小组的配置参考
1、 确定人员分工模式：人员分工基本上有两个思路，一是按ITIL的参考，按流程来划分，如划分为帮助台(Help Desk)、支持小组、安全小组、架构小组，等等，这样的划分方法可以不只是在DRP项目中使用，而是使公司的所有服务请求都在这个分工模式中得到响应。还有另一个思路是，为了DRP项目专门设立DRP项目的支撑小组，从DRP项目后期维护的工作主要职责来划分，可以划分为数据组、培训组、支持组三个小组。
从目前我所接触的企业来看，人员的岗位及职责划分还是基于部门的，而没有达到甚至流程或者是运营的层次，包括公司的考核机制也是按部门进行考核，因此，我在这里也采用了更为实际的方法就是按DRP项目的职责来划分人员分工。
人员分工可参照下图：
图表 4
2、 确定DRP支持小组的岗位成员：从上图可以看到，我把DRP支持小组主要分成三组：
•数据组——主要面对业务部门，负责DRP系统的基础配置管理，人员及权限管理、商品资料管理、数据准确性和及时性管理，业务部门数据分析需求整理及报表定制。
•培训组——主要针对新开专卖店(柜)的DRP系统培训，还有针对内部新员工的入职DRP系统培训，培训督导部门的督导使之能够协助在各专卖店进行DRP系统培训，DRP系统新功能的课程编制等。
•支持组——软件的应用疑难问题解决，设备故障，网络故障的反馈与服务，二次开发需求整理及与软件供应商的开发需求跟进，数据库定时备份等工作。
同时各个小组将由不同角色的岗位成员组成，各个岗位又涉及到具体的职位描述、工作流程与绩效考核，在此由于篇幅原因，就不展开论述，只对数据管理员的职位描述进行说明如下：
a) 系统档案类数据维护，包括：商品档案管理（商品信息维护、商品国际码生成）、价格管理（公司采购价格、分销价格及零售价格维护）、组织人员管理（代理商、门店、供应商、制造商及人员等的维护）、权限管理（对岗位人员及各代理商合理控制、分配权限）。
b) ERP软件资源管理：系统独立门店、脱机门店的控制；门店实施情况整理；软件使用授权号的索取、发放；软件站点使用信息的登记。
c) 月底公司及办事处的数据核对：核对系统是否存在异常数据；为核对好的组织做成本核算、结转。
d) 业务部门ERP系统使用问题解决：软件功能操作指导；错误单据处理；协助收集ERP使用的意见及建议。
e) 处理本部门内需要在ERP中操作的各类事务：协助与ERP相关设备的采购、发货及收货跟踪。
f) IT服务台的相关职责：接受客户的服务请求(电话、邮件、传真)；记录并跟踪事故和客户的意见；及时通知客户其请求的当前状态和最新进展；初步评估客户的请求，尽力解决它们或者将其安排给有关人员解决；对客户请求从提出直至验证和终止的整个过程进行管理；协调二线支持人员和第三方支持小组；提供管理方面的信息和建议以改进服务绩效。
3、 确定DRP支持小组的人数：从上图来看，DRP项目支持小组的人员配置会比较多，其实这只是进行细分之后的一个岗位配备，由于很多企业一个DRP支持小组可能只是一个人，那么就没有分工的说法，一个人全部包揽下来；可以根据具体的企业规模，企业发展规划，DRP系统的应用深度，DRP支持小组配备计划来确定人数。而在此之前讨论的DRP项目经验的IT人员此时就可以成为支持小组的骨干人员，可以充分利用他们的经验，让他们有机会去带领新员工一起开展工作，达到“以老带新”形成IT人员的梯队。
四、 支持小组在DRP项目的切入
DRP项目在最早的规划阶段，就可以将DRP支持小组的配置引进来，在做项目规划的时候，就需要将前面讨论的几个方面作为规划的一部分，这样的话，不至于在DRP项目实施结束之后，IT主管再向公司领导提出因为DRP系统项目上线，需要增加人手来进行管理与维护，使的公司领导觉的DRP系统的人力资源投入会过大。
当然，还有的IT主管，因为担心如果将支持小组的配置做到前期规划中，公司高层会觉的DRP项目的成本过高，而导致项目无法上线。其实这个担心的理由是存在的，特别是在公司规模不是太大的企业，公司高层对于DRP系统的还停留在买一个软件，而并没有一个整体的概念，这个时候如果IT主管不做一些引导，那系统到了运维阶段，能够用到什么样的程度还真的是难说了。
还有一个重要的问题是：如果不在规划阶段做好支持小组的配置，那么在支持小组人员没有到位的情况下启动DRP项目，对于支持人员的前期知识储备，提前进入项目，参与项目实施，DRP软件商的知识传递，业务部门需求理解，软件实施方法等都会存在不利的影响。
所以，DRP支持小组应该是DRP项目规划的一部分，从启动DRP项目那一天起支持小组就应该开始运作，并一直小掌控了DRP项目的整个生命周期。
=================
本文首发于IT168技术频道： http://tech.it168.com。转载请注明出处。
前面的文章我有提到过：“顾问走了之后，数据怎么办”的问题，从而引发了对于DRP项目的外部顾问撤走了之后，企业如何做数据治理的讨论（《管理手记：DRP项目中的数据治理》，http://tech.it168.com/m/p/2007-07-18/200707180903562.shtml） 。今天要讨论的还是老话题：“顾问走了之后，应该怎么办？”，但这个话题的侧重点不在于数据，而在于IT部门应该如何配置DRP的支持小组上。这个“怎么办”，是来说IT经理在人员配置上应该怎么办。
这件事情的讨论起缘于上次和老卓的一次讨论。
老卓是浙江某著名合资企业的IT经理，公司的DRP系统上线已经完成了有一段时间了，外部顾问基本上已经撤出，现在就要老卓来组织人马对这套系统进行维护了，但软件实施方在实施结束前，并未对老卓的DRP系统支持小组如何配置提出建议。当然，从另一个角度上来说，软件供应商可能只对软件产品比较了解，但对于软件系统运营和维护可能也没有太多经验，所以想要提出比较好的解决方案也就比较难了。
那么，我们在和老卓讨论时就想：是否可以试着提出一个方案，或者是有一个配置参考让IT经理能够在做人员配置可以参照。照着这个思路，我试着把原来自己部门里的人员配置作为原始框架，再向同行的几个朋友讨论了一下，对DRP系统支持小组的人员配置进行了如下整理。
对于DRP小组的人员配置，我觉的需要从以下几个角度来考虑。
一、 IT部门人员配置的参考理论基础：IT服务管理
从IT服务生命周期上来看，从软件的分析、设计、开发、实施上是属于IT系统开发的范畴，此时，主要使用CMM、IT项目管理等理论及方法对IT系统开发进行管理。
而从项目实施后期，就进入到了软件项目的运营维护直到报废结束IT系统的生命为止，此时IT系统运营维护在很长一段时间内是缺乏相关的IT服务管理方法论的，直到20世纪80年代后期，ITIL(IT Infrastructure Library，信息技术基础设施库)由英国计算机和电信中心 CCTA(2001年4月并入英国政府商务办公室OGC)提出，在英国开始应用。21世纪初，ITIL引入中国，中国IT服务管理也开始与国际接轨，并有了相应的理论基础。
ITIL由于是一个灵活的配置参考模型，因此，我们在做DRP项目支持小组的人员配置时，就可以以ITIL的模型为参考来做。
ITIL主要包括如下几个功能模块：
1、 IT服务管理实施规划：为客户如何确立远景目标，如何分析现状、确定合理目标并进行差距分析和如何实施活动的优先级，以及如何对实施的流程进行评审，提供了全面指导。
2、 ICT基础架构管理：确保提供一个稳定可靠的IT基础架构，以支持业务运营。
3、 应用管理：协调IT服务管理与应用系统的开发、测试和部署的关系，使它们一致的服务于客户的业务运营。
4、 安全管理：保护IT基础架构，对其采取合适的保护措施，使其免受未经授权的使用。
5、 服务管理：ITIL的核心内容，共分为10个管理流程及1项管理职能，被划分为两组：服务提供和服务支持；服务管理也是我们做项目小组配置的基础。
由于ITIL是一个复杂的模型，因文章所限，所以不能展开论述，如果您对ITIL感兴趣的话，可以通过ITIL组织的网站了解更多内容。
二、 企业规模及组织架构
要做DRP系统支持小组的人员配置之前，首先应该对企业的状况有一个深入的了解，那么我们应该先去了解企业的如下信息：
1、 企业现有的组织架构及DRP系统的覆盖部门：在这里我们可以用一个组织架构图来表示，了解这方面的信息是想让IT经理或企业高层清楚地认识到，DRP系统应用的好坏，是直接影响这些业务部门的工作效率的，而如果这些核心业务部门的工作效率受到影响，公司的经营就不可避免地会受到影响，从而加强公司高层对DRP系统重要性的认识。
图表 2
2、 DRP系统在企业内部的节点数，最近6个月的节点增长数：了解这个问题主要是为了对你做人员配置时，要考虑到人员招聘与培训是要有一定的周期的，而培训一个合格的支持人员，应该需要至少两个月时间，如你现在已经有了100个节点，是由1名支持人员来维护。那么，当你未来6个月会增加到300个节点的时候，你就要考虑在什么时间向公司提出增加人员配置的申请合适，使得公司不会因为提前招聘而员工的工作量不足，又不会出现因为人员没有到位而终端的服务请求频繁得不到及时响应，导致IT部门的服务质量下降的问题了。
3、 IT部门现有的人员配置情况，包括是否有DRP运维经验的员工数；由于DRP系统的运营与维护是一项较为细致且复杂的工作。因此，如果你现有的员工比较有经验，那么接下来做相关的运维工作会容易很多，如果你的员工都是新手，那么，IT经理就要考虑是否向软件厂商申请培训支持了。
图表 3
4、 企业现有的分公司数量，DRP系统已经覆盖的分公司有哪些，未来6个月将要覆盖的分公司有哪些，分公司的规模有多大，IT支持人员是否有必要常驻分公司，常驻的人员将采用当地招聘，总部培训的模式，还是由总部外派？支持人员是接受IT经理的异地管理还是分公司的本地管理？
5、 企业现有的代理商数量，DRP系统已经覆盖的代理商有哪些；企业现有的直营店数量，DRP系统已经覆盖的直营店有哪些；考虑上述这两个问题，也主要是评估工作量及人员的准备情况。
三、 支持小组的配置参考
1、 确定人员分工模式：人员分工基本上有两个思路，一是按ITIL的参考，按流程来划分，如划分为帮助台(Help Desk)、支持小组、安全小组、架构小组，等等，这样的划分方法可以不只是在DRP项目中使用，而是使公司的所有服务请求都在这个分工模式中得到响应。还有另一个思路是，为了DRP项目专门设立DRP项目的支撑小组，从DRP项目后期维护的工作主要职责来划分，可以划分为数据组、培训组、支持组三个小组。
从目前我所接触的企业来看，人员的岗位及职责划分还是基于部门的，而没有达到甚至流程或者是运营的层次，包括公司的考核机制也是按部门进行考核，因此，我在这里也采用了更为实际的方法就是按DRP项目的职责来划分人员分工。
人员分工可参照下图：
图表 4
2、 确定DRP支持小组的岗位成员：从上图可以看到，我把DRP支持小组主要分成三组：
•数据组——主要面对业务部门，负责DRP系统的基础配置管理，人员及权限管理、商品资料管理、数据准确性和及时性管理，业务部门数据分析需求整理及报表定制。
•培训组——主要针对新开专卖店(柜)的DRP系统培训，还有针对内部新员工的入职DRP系统培训，培训督导部门的督导使之能够协助在各专卖店进行DRP系统培训，DRP系统新功能的课程编制等。
•支持组——软件的应用疑难问题解决，设备故障，网络故障的反馈与服务，二次开发需求整理及与软件供应商的开发需求跟进，数据库定时备份等工作。
同时各个小组将由不同角色的岗位成员组成，各个岗位又涉及到具体的职位描述、工作流程与绩效考核，在此由于篇幅原因，就不展开论述，只对数据管理员的职位描述进行说明如下：
a) 系统档案类数据维护，包括：商品档案管理（商品信息维护、商品国际码生成）、价格管理（公司采购价格、分销价格及零售价格维护）、组织人员管理（代理商、门店、供应商、制造商及人员等的维护）、权限管理（对岗位人员及各代理商合理控制、分配权限）。
b) ERP软件资源管理：系统独立门店、脱机门店的控制；门店实施情况整理；软件使用授权号的索取、发放；软件站点使用信息的登记。
c) 月底公司及办事处的数据核对：核对系统是否存在异常数据；为核对好的组织做成本核算、结转。
d) 业务部门ERP系统使用问题解决：软件功能操作指导；错误单据处理；协助收集ERP使用的意见及建议。
e) 处理本部门内需要在ERP中操作的各类事务：协助与ERP相关设备的采购、发货及收货跟踪。
f) IT服务台的相关职责：接受客户的服务请求(电话、邮件、传真)；记录并跟踪事故和客户的意见；及时通知客户其请求的当前状态和最新进展；初步评估客户的请求，尽力解决它们或者将其安排给有关人员解决；对客户请求从提出直至验证和终止的整个过程进行管理；协调二线支持人员和第三方支持小组；提供管理方面的信息和建议以改进服务绩效。
3、 确定DRP支持小组的人数：从上图来看，DRP项目支持小组的人员配置会比较多，其实这只是进行细分之后的一个岗位配备，由于很多企业一个DRP支持小组可能只是一个人，那么就没有分工的说法，一个人全部包揽下来；可以根据具体的企业规模，企业发展规划，DRP系统的应用深度，DRP支持小组配备计划来确定人数。而在此之前讨论的DRP项目经验的IT人员此时就可以成为支持小组的骨干人员，可以充分利用他们的经验，让他们有机会去带领新员工一起开展工作，达到“以老带新”形成IT人员的梯队。
四、 支持小组在DRP项目的切入
DRP项目在最早的规划阶段，就可以将DRP支持小组的配置引进来，在做项目规划的时候，就需要将前面讨论的几个方面作为规划的一部分，这样的话，不至于在DRP项目实施结束之后，IT主管再向公司领导提出因为DRP系统项目上线，需要增加人手来进行管理与维护，使的公司领导觉的DRP系统的人力资源投入会过大。
当然，还有的IT主管，因为担心如果将支持小组的配置做到前期规划中，公司高层会觉的DRP项目的成本过高，而导致项目无法上线。其实这个担心的理由是存在的，特别是在公司规模不是太大的企业，公司高层对于DRP系统的还停留在买一个软件，而并没有一个整体的概念，这个时候如果IT主管不做一些引导，那系统到了运维阶段，能够用到什么样的程度还真的是难说了。
还有一个重要的问题是：如果不在规划阶段做好支持小组的配置，那么在支持小组人员没有到位的情况下启动DRP项目，对于支持人员的前期知识储备，提前进入项目，参与项目实施，DRP软件商的知识传递，业务部门需求理解，软件实施方法等都会存在不利的影响。
所以，DRP支持小组应该是DRP项目规划的一部分，从启动DRP项目那一天起支持小组就应该开始运作，并一直小掌控了DRP项目的整个生命周期。
=================
本文首发于IT168技术频道： http://tech.it168.com。转载请注明出处。
前面的文章我有提到过：“顾问走了之后，数据怎么办”的问题，从而引发了对于DRP项目的外部顾问撤走了之后，企业如何做数据治理的讨论（《管理手记：DRP项目中的数据治理》，http://tech.it168.com/m/p/2007-07-18/200707180903562.shtml） 。今天要讨论的还是老话题：“顾问走了之后，应该怎么办？”，但这个话题的侧重点不在于数据，而在于IT部门应该如何配置DRP的支持小组上。这个“怎么办”，是来说IT经理在人员配置上应该怎么办。
这件事情的讨论起缘于上次和老卓的一次讨论。
老卓是浙江某著名合资企业的IT经理，公司的DRP系统上线已经完成了有一段时间了，外部顾问基本上已经撤出，现在就要老卓来组织人马对这套系统进行维护了，但软件实施方在实施结束前，并未对老卓的DRP系统支持小组如何配置提出建议。当然，从另一个角度上来说，软件供应商可能只对软件产品比较了解，但对于软件系统运营和维护可能也没有太多经验，所以想要提出比较好的解决方案也就比较难了。
那么，我们在和老卓讨论时就想：是否可以试着提出一个方案，或者是有一个配置参考让IT经理能够在做人员配置可以参照。照着这个思路，我试着把原来自己部门里的人员配置作为原始框架，再向同行的几个朋友讨论了一下，对DRP系统支持小组的人员配置进行了如下整理。
对于DRP小组的人员配置，我觉的需要从以下几个角度来考虑。
一、 IT部门人员配置的参考理论基础：IT服务管理
从IT服务生命周期上来看，从软件的分析、设计、开发、实施上是属于IT系统开发的范畴，此时，主要使用CMM、IT项目管理等理论及方法对IT系统开发进行管理。
而从项目实施后期，就进入到了软件项目的运营维护直到报废结束IT系统的生命为止，此时IT系统运营维护在很长一段时间内是缺乏相关的IT服务管理方法论的，直到20世纪80年代后期，ITIL(IT Infrastructure Library，信息技术基础设施库)由英国计算机和电信中心 CCTA(2001年4月并入英国政府商务办公室OGC)提出，在英国开始应用。21世纪初，ITIL引入中国，中国IT服务管理也开始与国际接轨，并有了相应的理论基础。
ITIL由于是一个灵活的配置参考模型，因此，我们在做DRP项目支持小组的人员配置时，就可以以ITIL的模型为参考来做。
ITIL主要包括如下几个功能模块：
1、 IT服务管理实施规划：为客户如何确立远景目标，如何分析现状、确定合理目标并进行差距分析和如何实施活动的优先级，以及如何对实施的流程进行评审，提供了全面指导。
2、 ICT基础架构管理：确保提供一个稳定可靠的IT基础架构，以支持业务运营。
3、 应用管理：协调IT服务管理与应用系统的开发、测试和部署的关系，使它们一致的服务于客户的业务运营。
4、 安全管理：保护IT基础架构，对其采取合适的保护措施，使其免受未经授权的使用。
5、 服务管理：ITIL的核心内容，共分为10个管理流程及1项管理职能，被划分为两组：服务提供和服务支持；服务管理也是我们做项目小组配置的基础。
由于ITIL是一个复杂的模型，因文章所限，所以不能展开论述，如果您对ITIL感兴趣的话，可以通过ITIL组织的网站了解更多内容。
二、 企业规模及组织架构
要做DRP系统支持小组的人员配置之前，首先应该对企业的状况有一个深入的了解，那么我们应该先去了解企业的如下信息：
1、 企业现有的组织架构及DRP系统的覆盖部门：在这里我们可以用一个组织架构图来表示，了解这方面的信息是想让IT经理或企业高层清楚地认识到，DRP系统应用的好坏，是直接影响这些业务部门的工作效率的，而如果这些核心业务部门的工作效率受到影响，公司的经营就不可避免地会受到影响，从而加强公司高层对DRP系统重要性的认识。
图表 2
2、 DRP系统在企业内部的节点数，最近6个月的节点增长数：了解这个问题主要是为了对你做人员配置时，要考虑到人员招聘与培训是要有一定的周期的，而培训一个合格的支持人员，应该需要至少两个月时间，如你现在已经有了100个节点，是由1名支持人员来维护。那么，当你未来6个月会增加到300个节点的时候，你就要考虑在什么时间向公司提出增加人员配置的申请合适，使得公司不会因为提前招聘而员工的工作量不足，又不会出现因为人员没有到位而终端的服务请求频繁得不到及时响应，导致IT部门的服务质量下降的问题了。
3、 IT部门现有的人员配置情况，包括是否有DRP运维经验的员工数；由于DRP系统的运营与维护是一项较为细致且复杂的工作。因此，如果你现有的员工比较有经验，那么接下来做相关的运维工作会容易很多，如果你的员工都是新手，那么，IT经理就要考虑是否向软件厂商申请培训支持了。
图表 3
4、 企业现有的分公司数量，DRP系统已经覆盖的分公司有哪些，未来6个月将要覆盖的分公司有哪些，分公司的规模有多大，IT支持人员是否有必要常驻分公司，常驻的人员将采用当地招聘，总部培训的模式，还是由总部外派？支持人员是接受IT经理的异地管理还是分公司的本地管理？
5、 企业现有的代理商数量，DRP系统已经覆盖的代理商有哪些；企业现有的直营店数量，DRP系统已经覆盖的直营店有哪些；考虑上述这两个问题，也主要是评估工作量及人员的准备情况。
三、 支持小组的配置参考
1、 确定人员分工模式：人员分工基本上有两个思路，一是按ITIL的参考，按流程来划分，如划分为帮助台(Help Desk)、支持小组、安全小组、架构小组，等等，这样的划分方法可以不只是在DRP项目中使用，而是使公司的所有服务请求都在这个分工模式中得到响应。还有另一个思路是，为了DRP项目专门设立DRP项目的支撑小组，从DRP项目后期维护的工作主要职责来划分，可以划分为数据组、培训组、支持组三个小组。
从目前我所接触的企业来看，人员的岗位及职责划分还是基于部门的，而没有达到甚至流程或者是运营的层次，包括公司的考核机制也是按部门进行考核，因此，我在这里也采用了更为实际的方法就是按DRP项目的职责来划分人员分工。
人员分工可参照下图：
图表 4
2、 确定DRP支持小组的岗位成员：从上图可以看到，我把DRP支持小组主要分成三组：
•数据组——主要面对业务部门，负责DRP系统的基础配置管理，人员及权限管理、商品资料管理、数据准确性和及时性管理，业务部门数据分析需求整理及报表定制。
•培训组——主要针对新开专卖店(柜)的DRP系统培训，还有针对内部新员工的入职DRP系统培训，培训督导部门的督导使之能够协助在各专卖店进行DRP系统培训，DRP系统新功能的课程编制等。
•支持组——软件的应用疑难问题解决，设备故障，网络故障的反馈与服务，二次开发需求整理及与软件供应商的开发需求跟进，数据库定时备份等工作。
同时各个小组将由不同角色的岗位成员组成，各个岗位又涉及到具体的职位描述、工作流程与绩效考核，在此由于篇幅原因，就不展开论述，只对数据管理员的职位描述进行说明如下：
a) 系统档案类数据维护，包括：商品档案管理（商品信息维护、商品国际码生成）、价格管理（公司采购价格、分销价格及零售价格维护）、组织人员管理（代理商、门店、供应商、制造商及人员等的维护）、权限管理（对岗位人员及各代理商合理控制、分配权限）。
b) ERP软件资源管理：系统独立门店、脱机门店的控制；门店实施情况整理；软件使用授权号的索取、发放；软件站点使用信息的登记。
c) 月底公司及办事处的数据核对：核对系统是否存在异常数据；为核对好的组织做成本核算、结转。
d) 业务部门ERP系统使用问题解决：软件功能操作指导；错误单据处理；协助收集ERP使用的意见及建议。
e) 处理本部门内需要在ERP中操作的各类事务：协助与ERP相关设备的采购、发货及收货跟踪。
f) IT服务台的相关职责：接受客户的服务请求(电话、邮件、传真)；记录并跟踪事故和客户的意见；及时通知客户其请求的当前状态和最新进展；初步评估客户的请求，尽力解决它们或者将其安排给有关人员解决；对客户请求从提出直至验证和终止的整个过程进行管理；协调二线支持人员和第三方支持小组；提供管理方面的信息和建议以改进服务绩效。
3、 确定DRP支持小组的人数：从上图来看，DRP项目支持小组的人员配置会比较多，其实这只是进行细分之后的一个岗位配备，由于很多企业一个DRP支持小组可能只是一个人，那么就没有分工的说法，一个人全部包揽下来；可以根据具体的企业规模，企业发展规划，DRP系统的应用深度，DRP支持小组配备计划来确定人数。而在此之前讨论的DRP项目经验的IT人员此时就可以成为支持小组的骨干人员，可以充分利用他们的经验，让他们有机会去带领新员工一起开展工作，达到“以老带新”形成IT人员的梯队。
四、 支持小组在DRP项目的切入
DRP项目在最早的规划阶段，就可以将DRP支持小组的配置引进来，在做项目规划的时候，就需要将前面讨论的几个方面作为规划的一部分，这样的话，不至于在DRP项目实施结束之后，IT主管再向公司领导提出因为DRP系统项目上线，需要增加人手来进行管理与维护，使的公司领导觉的DRP系统的人力资源投入会过大。
当然，还有的IT主管，因为担心如果将支持小组的配置做到前期规划中，公司高层会觉的DRP项目的成本过高，而导致项目无法上线。其实这个担心的理由是存在的，特别是在公司规模不是太大的企业，公司高层对于DRP系统的还停留在买一个软件，而并没有一个整体的概念，这个时候如果IT主管不做一些引导，那系统到了运维阶段，能够用到什么样的程度还真的是难说了。
还有一个重要的问题是：如果不在规划阶段做好支持小组的配置，那么在支持小组人员没有到位的情况下启动DRP项目，对于支持人员的前期知识储备，提前进入项目，参与项目实施，DRP软件商的知识传递，业务部门需求理解，软件实施方法等都会存在不利的影响。
所以，DRP支持小组应该是DRP项目规划的一部分，从启动DRP项目那一天起支持小组就应该开始运作，并一直小掌控了DRP项目的整个生命周期。
=================
本文首发于IT168技术频道： http://tech.it168.com。转载请注明出处。
前面的文章我有提到过：“顾问走了之后，数据怎么办”的问题，从而引发了对于DRP项目的外部顾问撤走了之后，企业如何做数据治理的讨论（《管理手记：DRP项目中的数据治理》，http://tech.it168.com/m/p/2007-07-18/200707180903562.shtml） 。今天要讨论的还是老话题：“顾问走了之后，应该怎么办？”，但这个话题的侧重点不在于数据，而在于IT部门应该如何配置DRP的支持小组上。这个“怎么办”，是来说IT经理在人员配置上应该怎么办。
这件事情的讨论起缘于上次和老卓的一次讨论。
老卓是浙江某著名合资企业的IT经理，公司的DRP系统上线已经完成了有一段时间了，外部顾问基本上已经撤出，现在就要老卓来组织人马对这套系统进行维护了，但软件实施方在实施结束前，并未对老卓的DRP系统支持小组如何配置提出建议。当然，从另一个角度上来说，软件供应商可能只对软件产品比较了解，但对于软件系统运营和维护可能也没有太多经验，所以想要提出比较好的解决方案也就比较难了。
那么，我们在和老卓讨论时就想：是否可以试着提出一个方案，或者是有一个配置参考让IT经理能够在做人员配置可以参照。照着这个思路，我试着把原来自己部门里的人员配置作为原始框架，再向同行的几个朋友讨论了一下，对DRP系统支持小组的人员配置进行了如下整理。
对于DRP小组的人员配置，我觉的需要从以下几个角度来考虑。
一、 IT部门人员配置的参考理论基础：IT服务管理
从IT服务生命周期上来看，从软件的分析、设计、开发、实施上是属于IT系统开发的范畴，此时，主要使用CMM、IT项目管理等理论及方法对IT系统开发进行管理。
而从项目实施后期，就进入到了软件项目的运营维护直到报废结束IT系统的生命为止，此时IT系统运营维护在很长一段时间内是缺乏相关的IT服务管理方法论的，直到20世纪80年代后期，ITIL(IT Infrastructure Library，信息技术基础设施库)由英国计算机和电信中心 CCTA(2001年4月并入英国政府商务办公室OGC)提出，在英国开始应用。21世纪初，ITIL引入中国，中国IT服务管理也开始与国际接轨，并有了相应的理论基础。
ITIL由于是一个灵活的配置参考模型，因此，我们在做DRP项目支持小组的人员配置时，就可以以ITIL的模型为参考来做。
ITIL主要包括如下几个功能模块：
1、 IT服务管理实施规划：为客户如何确立远景目标，如何分析现状、确定合理目标并进行差距分析和如何实施活动的优先级，以及如何对实施的流程进行评审，提供了全面指导。
2、 ICT基础架构管理：确保提供一个稳定可靠的IT基础架构，以支持业务运营。
3、 应用管理：协调IT服务管理与应用系统的开发、测试和部署的关系，使它们一致的服务于客户的业务运营。
4、 安全管理：保护IT基础架构，对其采取合适的保护措施，使其免受未经授权的使用。
5、 服务管理：ITIL的核心内容，共分为10个管理流程及1项管理职能，被划分为两组：服务提供和服务支持；服务管理也是我们做项目小组配置的基础。
由于ITIL是一个复杂的模型，因文章所限，所以不能展开论述，如果您对ITIL感兴趣的话，可以通过ITIL组织的网站了解更多内容。
二、 企业规模及组织架构
要做DRP系统支持小组的人员配置之前，首先应该对企业的状况有一个深入的了解，那么我们应该先去了解企业的如下信息：
1、 企业现有的组织架构及DRP系统的覆盖部门：在这里我们可以用一个组织架构图来表示，了解这方面的信息是想让IT经理或企业高层清楚地认识到，DRP系统应用的好坏，是直接影响这些业务部门的工作效率的，而如果这些核心业务部门的工作效率受到影响，公司的经营就不可避免地会受到影响，从而加强公司高层对DRP系统重要性的认识。
图表 2
2、 DRP系统在企业内部的节点数，最近6个月的节点增长数：了解这个问题主要是为了对你做人员配置时，要考虑到人员招聘与培训是要有一定的周期的，而培训一个合格的支持人员，应该需要至少两个月时间，如你现在已经有了100个节点，是由1名支持人员来维护。那么，当你未来6个月会增加到300个节点的时候，你就要考虑在什么时间向公司提出增加人员配置的申请合适，使得公司不会因为提前招聘而员工的工作量不足，又不会出现因为人员没有到位而终端的服务请求频繁得不到及时响应，导致IT部门的服务质量下降的问题了。
3、 IT部门现有的人员配置情况，包括是否有DRP运维经验的员工数；由于DRP系统的运营与维护是一项较为细致且复杂的工作。因此，如果你现有的员工比较有经验，那么接下来做相关的运维工作会容易很多，如果你的员工都是新手，那么，IT经理就要考虑是否向软件厂商申请培训支持了。
图表 3
4、 企业现有的分公司数量，DRP系统已经覆盖的分公司有哪些，未来6个月将要覆盖的分公司有哪些，分公司的规模有多大，IT支持人员是否有必要常驻分公司，常驻的人员将采用当地招聘，总部培训的模式，还是由总部外派？支持人员是接受IT经理的异地管理还是分公司的本地管理？
5、 企业现有的代理商数量，DRP系统已经覆盖的代理商有哪些；企业现有的直营店数量，DRP系统已经覆盖的直营店有哪些；考虑上述这两个问题，也主要是评估工作量及人员的准备情况。
三、 支持小组的配置参考
1、 确定人员分工模式：人员分工基本上有两个思路，一是按ITIL的参考，按流程来划分，如划分为帮助台(Help Desk)、支持小组、安全小组、架构小组，等等，这样的划分方法可以不只是在DRP项目中使用，而是使公司的所有服务请求都在这个分工模式中得到响应。还有另一个思路是，为了DRP项目专门设立DRP项目的支撑小组，从DRP项目后期维护的工作主要职责来划分，可以划分为数据组、培训组、支持组三个小组。
从目前我所接触的企业来看，人员的岗位及职责划分还是基于部门的，而没有达到甚至流程或者是运营的层次，包括公司的考核机制也是按部门进行考核，因此，我在这里也采用了更为实际的方法就是按DRP项目的职责来划分人员分工。
人员分工可参照下图：
图表 4
2、 确定DRP支持小组的岗位成员：从上图可以看到，我把DRP支持小组主要分成三组：
•数据组——主要面对业务部门，负责DRP系统的基础配置管理，人员及权限管理、商品资料管理、数据准确性和及时性管理，业务部门数据分析需求整理及报表定制。
•培训组——主要针对新开专卖店(柜)的DRP系统培训，还有针对内部新员工的入职DRP系统培训，培训督导部门的督导使之能够协助在各专卖店进行DRP系统培训，DRP系统新功能的课程编制等。
•支持组——软件的应用疑难问题解决，设备故障，网络故障的反馈与服务，二次开发需求整理及与软件供应商的开发需求跟进，数据库定时备份等工作。
同时各个小组将由不同角色的岗位成员组成，各个岗位又涉及到具体的职位描述、工作流程与绩效考核，在此由于篇幅原因，就不展开论述，只对数据管理员的职位描述进行说明如下：
a) 系统档案类数据维护，包括：商品档案管理（商品信息维护、商品国际码生成）、价格管理（公司采购价格、分销价格及零售价格维护）、组织人员管理（代理商、门店、供应商、制造商及人员等的维护）、权限管理（对岗位人员及各代理商合理控制、分配权限）。
b) ERP软件资源管理：系统独立门店、脱机门店的控制；门店实施情况整理；软件使用授权号的索取、发放；软件站点使用信息的登记。
c) 月底公司及办事处的数据核对：核对系统是否存在异常数据；为核对好的组织做成本核算、结转。
d) 业务部门ERP系统使用问题解决：软件功能操作指导；错误单据处理；协助收集ERP使用的意见及建议。
e) 处理本部门内需要在ERP中操作的各类事务：协助与ERP相关设备的采购、发货及收货跟踪。
f) IT服务台的相关职责：接受客户的服务请求(电话、邮件、传真)；记录并跟踪事故和客户的意见；及时通知客户其请求的当前状态和最新进展；初步评估客户的请求，尽力解决它们或者将其安排给有关人员解决；对客户请求从提出直至验证和终止的整个过程进行管理；协调二线支持人员和第三方支持小组；提供管理方面的信息和建议以改进服务绩效。
3、 确定DRP支持小组的人数：从上图来看，DRP项目支持小组的人员配置会比较多，其实这只是进行细分之后的一个岗位配备，由于很多企业一个DRP支持小组可能只是一个人，那么就没有分工的说法，一个人全部包揽下来；可以根据具体的企业规模，企业发展规划，DRP系统的应用深度，DRP支持小组配备计划来确定人数。而在此之前讨论的DRP项目经验的IT人员此时就可以成为支持小组的骨干人员，可以充分利用他们的经验，让他们有机会去带领新员工一起开展工作，达到“以老带新”形成IT人员的梯队。
四、 支持小组在DRP项目的切入
DRP项目在最早的规划阶段，就可以将DRP支持小组的配置引进来，在做项目规划的时候，就需要将前面讨论的几个方面作为规划的一部分，这样的话，不至于在DRP项目实施结束之后，IT主管再向公司领导提出因为DRP系统项目上线，需要增加人手来进行管理与维护，使的公司领导觉的DRP系统的人力资源投入会过大。
当然，还有的IT主管，因为担心如果将支持小组的配置做到前期规划中，公司高层会觉的DRP项目的成本过高，而导致项目无法上线。其实这个担心的理由是存在的，特别是在公司规模不是太大的企业，公司高层对于DRP系统的还停留在买一个软件，而并没有一个整体的概念，这个时候如果IT主管不做一些引导，那系统到了运维阶段，能够用到什么样的程度还真的是难说了。
还有一个重要的问题是：如果不在规划阶段做好支持小组的配置，那么在支持小组人员没有到位的情况下启动DRP项目，对于支持人员的前期知识储备，提前进入项目，参与项目实施，DRP软件商的知识传递，业务部门需求理解，软件实施方法等都会存在不利的影响。
所以，DRP支持小组应该是DRP项目规划的一部分，从启动DRP项目那一天起支持小组就应该开始运作，并一直小掌控了DRP项目的整个生命周期。
=================
本文首发于IT168技术频道： http://tech.it168.com。转载请注明出处。
前面的文章我有提到过：“顾问走了之后，数据怎么办”的问题，从而引发了对于DRP项目的外部顾问撤走了之后，企业如何做数据治理的讨论（《管理手记：DRP项目中的数据治理》，http://tech.it168.com/m/p/2007-07-18/200707180903562.shtml） 。今天要讨论的还是老话题：“顾问走了之后，应该怎么办？”，但这个话题的侧重点不在于数据，而在于IT部门应该如何配置DRP的支持小组上。这个“怎么办”，是来说IT经理在人员配置上应该怎么办。
这件事情的讨论起缘于上次和老卓的一次讨论。
老卓是浙江某著名合资企业的IT经理，公司的DRP系统上线已经完成了有一段时间了，外部顾问基本上已经撤出，现在就要老卓来组织人马对这套系统进行维护了，但软件实施方在实施结束前，并未对老卓的DRP系统支持小组如何配置提出建议。当然，从另一个角度上来说，软件供应商可能只对软件产品比较了解，但对于软件系统运营和维护可能也没有太多经验，所以想要提出比较好的解决方案也就比较难了。
那么，我们在和老卓讨论时就想：是否可以试着提出一个方案，或者是有一个配置参考让IT经理能够在做人员配置可以参照。照着这个思路，我试着把原来自己部门里的人员配置作为原始框架，再向同行的几个朋友讨论了一下，对DRP系统支持小组的人员配置进行了如下整理。
对于DRP小组的人员配置，我觉的需要从以下几个角度来考虑。
一、 IT部门人员配置的参考理论基础：IT服务管理
从IT服务生命周期上来看，从软件的分析、设计、开发、实施上是属于IT系统开发的范畴，此时，主要使用CMM、IT项目管理等理论及方法对IT系统开发进行管理。
而从项目实施后期，就进入到了软件项目的运营维护直到报废结束IT系统的生命为止，此时IT系统运营维护在很长一段时间内是缺乏相关的IT服务管理方法论的，直到20世纪80年代后期，ITIL(IT Infrastructure Library，信息技术基础设施库)由英国计算机和电信中心 CCTA(2001年4月并入英国政府商务办公室OGC)提出，在英国开始应用。21世纪初，ITIL引入中国，中国IT服务管理也开始与国际接轨，并有了相应的理论基础。
ITIL由于是一个灵活的配置参考模型，因此，我们在做DRP项目支持小组的人员配置时，就可以以ITIL的模型为参考来做。
ITIL主要包括如下几个功能模块：
1、 IT服务管理实施规划：为客户如何确立远景目标，如何分析现状、确定合理目标并进行差距分析和如何实施活动的优先级，以及如何对实施的流程进行评审，提供了全面指导。
2、 ICT基础架构管理：确保提供一个稳定可靠的IT基础架构，以支持业务运营。
3、 应用管理：协调IT服务管理与应用系统的开发、测试和部署的关系，使它们一致的服务于客户的业务运营。
4、 安全管理：保护IT基础架构，对其采取合适的保护措施，使其免受未经授权的使用。
5、 服务管理：ITIL的核心内容，共分为10个管理流程及1项管理职能，被划分为两组：服务提供和服务支持；服务管理也是我们做项目小组配置的基础。
由于ITIL是一个复杂的模型，因文章所限，所以不能展开论述，如果您对ITIL感兴趣的话，可以通过ITIL组织的网站了解更多内容。
二、 企业规模及组织架构
要做DRP系统支持小组的人员配置之前，首先应该对企业的状况有一个深入的了解，那么我们应该先去了解企业的如下信息：
1、 企业现有的组织架构及DRP系统的覆盖部门：在这里我们可以用一个组织架构图来表示，了解这方面的信息是想让IT经理或企业高层清楚地认识到，DRP系统应用的好坏，是直接影响这些业务部门的工作效率的，而如果这些核心业务部门的工作效率受到影响，公司的经营就不可避免地会受到影响，从而加强公司高层对DRP系统重要性的认识。
图表 2
2、 DRP系统在企业内部的节点数，最近6个月的节点增长数：了解这个问题主要是为了对你做人员配置时，要考虑到人员招聘与培训是要有一定的周期的，而培训一个合格的支持人员，应该需要至少两个月时间，如你现在已经有了100个节点，是由1名支持人员来维护。那么，当你未来6个月会增加到300个节点的时候，你就要考虑在什么时间向公司提出增加人员配置的申请合适，使得公司不会因为提前招聘而员工的工作量不足，又不会出现因为人员没有到位而终端的服务请求频繁得不到及时响应，导致IT部门的服务质量下降的问题了。
3、 IT部门现有的人员配置情况，包括是否有DRP运维经验的员工数；由于DRP系统的运营与维护是一项较为细致且复杂的工作。因此，如果你现有的员工比较有经验，那么接下来做相关的运维工作会容易很多，如果你的员工都是新手，那么，IT经理就要考虑是否向软件厂商申请培训支持了。
图表 3
4、 企业现有的分公司数量，DRP系统已经覆盖的分公司有哪些，未来6个月将要覆盖的分公司有哪些，分公司的规模有多大，IT支持人员是否有必要常驻分公司，常驻的人员将采用当地招聘，总部培训的模式，还是由总部外派？支持人员是接受IT经理的异地管理还是分公司的本地管理？
5、 企业现有的代理商数量，DRP系统已经覆盖的代理商有哪些；企业现有的直营店数量，DRP系统已经覆盖的直营店有哪些；考虑上述这两个问题，也主要是评估工作量及人员的准备情况。
三、 支持小组的配置参考
1、 确定人员分工模式：人员分工基本上有两个思路，一是按ITIL的参考，按流程来划分，如划分为帮助台(Help Desk)、支持小组、安全小组、架构小组，等等，这样的划分方法可以不只是在DRP项目中使用，而是使公司的所有服务请求都在这个分工模式中得到响应。还有另一个思路是，为了DRP项目专门设立DRP项目的支撑小组，从DRP项目后期维护的工作主要职责来划分，可以划分为数据组、培训组、支持组三个小组。
从目前我所接触的企业来看，人员的岗位及职责划分还是基于部门的，而没有达到甚至流程或者是运营的层次，包括公司的考核机制也是按部门进行考核，因此，我在这里也采用了更为实际的方法就是按DRP项目的职责来划分人员分工。
人员分工可参照下图：
图表 4
2、 确定DRP支持小组的岗位成员：从上图可以看到，我把DRP支持小组主要分成三组：
•数据组——主要面对业务部门，负责DRP系统的基础配置管理，人员及权限管理、商品资料管理、数据准确性和及时性管理，业务部门数据分析需求整理及报表定制。
•培训组——主要针对新开专卖店(柜)的DRP系统培训，还有针对内部新员工的入职DRP系统培训，培训督导部门的督导使之能够协助在各专卖店进行DRP系统培训，DRP系统新功能的课程编制等。
•支持组——软件的应用疑难问题解决，设备故障，网络故障的反馈与服务，二次开发需求整理及与软件供应商的开发需求跟进，数据库定时备份等工作。
同时各个小组将由不同角色的岗位成员组成，各个岗位又涉及到具体的职位描述、工作流程与绩效考核，在此由于篇幅原因，就不展开论述，只对数据管理员的职位描述进行说明如下：
a) 系统档案类数据维护，包括：商品档案管理（商品信息维护、商品国际码生成）、价格管理（公司采购价格、分销价格及零售价格维护）、组织人员管理（代理商、门店、供应商、制造商及人员等的维护）、权限管理（对岗位人员及各代理商合理控制、分配权限）。
b) ERP软件资源管理：系统独立门店、脱机门店的控制；门店实施情况整理；软件使用授权号的索取、发放；软件站点使用信息的登记。
c) 月底公司及办事处的数据核对：核对系统是否存在异常数据；为核对好的组织做成本核算、结转。
d) 业务部门ERP系统使用问题解决：软件功能操作指导；错误单据处理；协助收集ERP使用的意见及建议。
e) 处理本部门内需要在ERP中操作的各类事务：协助与ERP相关设备的采购、发货及收货跟踪。
f) IT服务台的相关职责：接受客户的服务请求(电话、邮件、传真)；记录并跟踪事故和客户的意见；及时通知客户其请求的当前状态和最新进展；初步评估客户的请求，尽力解决它们或者将其安排给有关人员解决；对客户请求从提出直至验证和终止的整个过程进行管理；协调二线支持人员和第三方支持小组；提供管理方面的信息和建议以改进服务绩效。
3、 确定DRP支持小组的人数：从上图来看，DRP项目支持小组的人员配置会比较多，其实这只是进行细分之后的一个岗位配备，由于很多企业一个DRP支持小组可能只是一个人，那么就没有分工的说法，一个人全部包揽下来；可以根据具体的企业规模，企业发展规划，DRP系统的应用深度，DRP支持小组配备计划来确定人数。而在此之前讨论的DRP项目经验的IT人员此时就可以成为支持小组的骨干人员，可以充分利用他们的经验，让他们有机会去带领新员工一起开展工作，达到“以老带新”形成IT人员的梯队。
四、 支持小组在DRP项目的切入
DRP项目在最早的规划阶段，就可以将DRP支持小组的配置引进来，在做项目规划的时候，就需要将前面讨论的几个方面作为规划的一部分，这样的话，不至于在DRP项目实施结束之后，IT主管再向公司领导提出因为DRP系统项目上线，需要增加人手来进行管理与维护，使的公司领导觉的DRP系统的人力资源投入会过大。
当然，还有的IT主管，因为担心如果将支持小组的配置做到前期规划中，公司高层会觉的DRP项目的成本过高，而导致项目无法上线。其实这个担心的理由是存在的，特别是在公司规模不是太大的企业，公司高层对于DRP系统的还停留在买一个软件，而并没有一个整体的概念，这个时候如果IT主管不做一些引导，那系统到了运维阶段，能够用到什么样的程度还真的是难说了。
还有一个重要的问题是：如果不在规划阶段做好支持小组的配置，那么在支持小组人员没有到位的情况下启动DRP项目，对于支持人员的前期知识储备，提前进入项目，参与项目实施，DRP软件商的知识传递，业务部门需求理解，软件实施方法等都会存在不利的影响。
所以，DRP支持小组应该是DRP项目规划的一部分，从启动DRP项目那一天起支持小组就应该开始运作，并一直小掌控了DRP项目的整个生命周期。
=================
本文首发于IT168技术频道： http://tech.it168.com。转载请注明出处。
前面的文章我有提到过：“顾问走了之后，数据怎么办”的问题，从而引发了对于DRP项目的外部顾问撤走了之后，企业如何做数据治理的讨论（《管理手记：DRP项目中的数据治理》，http://tech.it168.com/m/p/2007-07-18/200707180903562.shtml） 。今天要讨论的还是老话题：“顾问走了之后，应该怎么办？”，但这个话题的侧重点不在于数据，而在于IT部门应该如何配置DRP的支持小组上。这个“怎么办”，是来说IT经理在人员配置上应该怎么办。
这件事情的讨论起缘于上次和老卓的一次讨论。
老卓是浙江某著名合资企业的IT经理，公司的DRP系统上线已经完成了有一段时间了，外部顾问基本上已经撤出，现在就要老卓来组织人马对这套系统进行维护了，但软件实施方在实施结束前，并未对老卓的DRP系统支持小组如何配置提出建议。当然，从另一个角度上来说，软件供应商可能只对软件产品比较了解，但对于软件系统运营和维护可能也没有太多经验，所以想要提出比较好的解决方案也就比较难了。
那么，我们在和老卓讨论时就想：是否可以试着提出一个方案，或者是有一个配置参考让IT经理能够在做人员配置可以参照。照着这个思路，我试着把原来自己部门里的人员配置作为原始框架，再向同行的几个朋友讨论了一下，对DRP系统支持小组的人员配置进行了如下整理。
对于DRP小组的人员配置，我觉的需要从以下几个角度来考虑。
一、 IT部门人员配置的参考理论基础：IT服务管理
从IT服务生命周期上来看，从软件的分析、设计、开发、实施上是属于IT系统开发的范畴，此时，主要使用CMM、IT项目管理等理论及方法对IT系统开发进行管理。
而从项目实施后期，就进入到了软件项目的运营维护直到报废结束IT系统的生命为止，此时IT系统运营维护在很长一段时间内是缺乏相关的IT服务管理方法论的，直到20世纪80年代后期，ITIL(IT Infrastructure Library，信息技术基础设施库)由英国计算机和电信中心 CCTA(2001年4月并入英国政府商务办公室OGC)提出，在英国开始应用。21世纪初，ITIL引入中国，中国IT服务管理也开始与国际接轨，并有了相应的理论基础。
ITIL由于是一个灵活的配置参考模型，因此，我们在做DRP项目支持小组的人员配置时，就可以以ITIL的模型为参考来做。
ITIL主要包括如下几个功能模块：
1、 IT服务管理实施规划：为客户如何确立远景目标，如何分析现状、确定合理目标并进行差距分析和如何实施活动的优先级，以及如何对实施的流程进行评审，提供了全面指导。
2、 ICT基础架构管理：确保提供一个稳定可靠的IT基础架构，以支持业务运营。
3、 应用管理：协调IT服务管理与应用系统的开发、测试和部署的关系，使它们一致的服务于客户的业务运营。
4、 安全管理：保护IT基础架构，对其采取合适的保护措施，使其免受未经授权的使用。
5、 服务管理：ITIL的核心内容，共分为10个管理流程及1项管理职能，被划分为两组：服务提供和服务支持；服务管理也是我们做项目小组配置的基础。
由于ITIL是一个复杂的模型，因文章所限，所以不能展开论述，如果您对ITIL感兴趣的话，可以通过ITIL组织的网站了解更多内容。
二、 企业规模及组织架构
要做DRP系统支持小组的人员配置之前，首先应该对企业的状况有一个深入的了解，那么我们应该先去了解企业的如下信息：
1、 企业现有的组织架构及DRP系统的覆盖部门：在这里我们可以用一个组织架构图来表示，了解这方面的信息是想让IT经理或企业高层清楚地认识到，DRP系统应用的好坏，是直接影响这些业务部门的工作效率的，而如果这些核心业务部门的工作效率受到影响，公司的经营就不可避免地会受到影响，从而加强公司高层对DRP系统重要性的认识。
图表 2
2、 DRP系统在企业内部的节点数，最近6个月的节点增长数：了解这个问题主要是为了对你做人员配置时，要考虑到人员招聘与培训是要有一定的周期的，而培训一个合格的支持人员，应该需要至少两个月时间，如你现在已经有了100个节点，是由1名支持人员来维护。那么，当你未来6个月会增加到300个节点的时候，你就要考虑在什么时间向公司提出增加人员配置的申请合适，使得公司不会因为提前招聘而员工的工作量不足，又不会出现因为人员没有到位而终端的服务请求频繁得不到及时响应，导致IT部门的服务质量下降的问题了。
3、 IT部门现有的人员配置情况，包括是否有DRP运维经验的员工数；由于DRP系统的运营与维护是一项较为细致且复杂的工作。因此，如果你现有的员工比较有经验，那么接下来做相关的运维工作会容易很多，如果你的员工都是新手，那么，IT经理就要考虑是否向软件厂商申请培训支持了。
图表 3
4、 企业现有的分公司数量，DRP系统已经覆盖的分公司有哪些，未来6个月将要覆盖的分公司有哪些，分公司的规模有多大，IT支持人员是否有必要常驻分公司，常驻的人员将采用当地招聘，总部培训的模式，还是由总部外派？支持人员是接受IT经理的异地管理还是分公司的本地管理？
5、 企业现有的代理商数量，DRP系统已经覆盖的代理商有哪些；企业现有的直营店数量，DRP系统已经覆盖的直营店有哪些；考虑上述这两个问题，也主要是评估工作量及人员的准备情况。
三、 支持小组的配置参考
1、 确定人员分工模式：人员分工基本上有两个思路，一是按ITIL的参考，按流程来划分，如划分为帮助台(Help Desk)、支持小组、安全小组、架构小组，等等，这样的划分方法可以不只是在DRP项目中使用，而是使公司的所有服务请求都在这个分工模式中得到响应。还有另一个思路是，为了DRP项目专门设立DRP项目的支撑小组，从DRP项目后期维护的工作主要职责来划分，可以划分为数据组、培训组、支持组三个小组。
从目前我所接触的企业来看，人员的岗位及职责划分还是基于部门的，而没有达到甚至流程或者是运营的层次，包括公司的考核机制也是按部门进行考核，因此，我在这里也采用了更为实际的方法就是按DRP项目的职责来划分人员分工。
人员分工可参照下图：
图表 4
2、 确定DRP支持小组的岗位成员：从上图可以看到，我把DRP支持小组主要分成三组：
•数据组——主要面对业务部门，负责DRP系统的基础配置管理，人员及权限管理、商品资料管理、数据准确性和及时性管理，业务部门数据分析需求整理及报表定制。
•培训组——主要针对新开专卖店(柜)的DRP系统培训，还有针对内部新员工的入职DRP系统培训，培训督导部门的督导使之能够协助在各专卖店进行DRP系统培训，DRP系统新功能的课程编制等。
•支持组——软件的应用疑难问题解决，设备故障，网络故障的反馈与服务，二次开发需求整理及与软件供应商的开发需求跟进，数据库定时备份等工作。
同时各个小组将由不同角色的岗位成员组成，各个岗位又涉及到具体的职位描述、工作流程与绩效考核，在此由于篇幅原因，就不展开论述，只对数据管理员的职位描述进行说明如下：
a) 系统档案类数据维护，包括：商品档案管理（商品信息维护、商品国际码生成）、价格管理（公司采购价格、分销价格及零售价格维护）、组织人员管理（代理商、门店、供应商、制造商及人员等的维护）、权限管理（对岗位人员及各代理商合理控制、分配权限）。
b) ERP软件资源管理：系统独立门店、脱机门店的控制；门店实施情况整理；软件使用授权号的索取、发放；软件站点使用信息的登记。
c) 月底公司及办事处的数据核对：核对系统是否存在异常数据；为核对好的组织做成本核算、结转。
d) 业务部门ERP系统使用问题解决：软件功能操作指导；错误单据处理；协助收集ERP使用的意见及建议。
e) 处理本部门内需要在ERP中操作的各类事务：协助与ERP相关设备的采购、发货及收货跟踪。
f) IT服务台的相关职责：接受客户的服务请求(电话、邮件、传真)；记录并跟踪事故和客户的意见；及时通知客户其请求的当前状态和最新进展；初步评估客户的请求，尽力解决它们或者将其安排给有关人员解决；对客户请求从提出直至验证和终止的整个过程进行管理；协调二线支持人员和第三方支持小组；提供管理方面的信息和建议以改进服务绩效。
3、 确定DRP支持小组的人数：从上图来看，DRP项目支持小组的人员配置会比较多，其实这只是进行细分之后的一个岗位配备，由于很多企业一个DRP支持小组可能只是一个人，那么就没有分工的说法，一个人全部包揽下来；可以根据具体的企业规模，企业发展规划，DRP系统的应用深度，DRP支持小组配备计划来确定人数。而在此之前讨论的DRP项目经验的IT人员此时就可以成为支持小组的骨干人员，可以充分利用他们的经验，让他们有机会去带领新员工一起开展工作，达到“以老带新”形成IT人员的梯队。
四、 支持小组在DRP项目的切入
DRP项目在最早的规划阶段，就可以将DRP支持小组的配置引进来，在做项目规划的时候，就需要将前面讨论的几个方面作为规划的一部分，这样的话，不至于在DRP项目实施结束之后，IT主管再向公司领导提出因为DRP系统项目上线，需要增加人手来进行管理与维护，使的公司领导觉的DRP系统的人力资源投入会过大。
当然，还有的IT主管，因为担心如果将支持小组的配置做到前期规划中，公司高层会觉的DRP项目的成本过高，而导致项目无法上线。其实这个担心的理由是存在的，特别是在公司规模不是太大的企业，公司高层对于DRP系统的还停留在买一个软件，而并没有一个整体的概念，这个时候如果IT主管不做一些引导，那系统到了运维阶段，能够用到什么样的程度还真的是难说了。
还有一个重要的问题是：如果不在规划阶段做好支持小组的配置，那么在支持小组人员没有到位的情况下启动DRP项目，对于支持人员的前期知识储备，提前进入项目，参与项目实施，DRP软件商的知识传递，业务部门需求理解，软件实施方法等都会存在不利的影响。
所以，DRP支持小组应该是DRP项目规划的一部分，从启动DRP项目那一天起支持小组就应该开始运作，并一直小掌控了DRP项目的整个生命周期。
=================
本文首发于IT168技术频道： http://tech.it168.com。转载请注明出处。
前面的文章我有提到过：“顾问走了之后，数据怎么办”的问题，从而引发了对于DRP项目的外部顾问撤走了之后，企业如何做数据治理的讨论（《管理手记：DRP项目中的数据治理》，http://tech.it168.com/m/p/2007-07-18/200707180903562.shtml） 。今天要讨论的还是老话题：“顾问走了之后，应该怎么办？”，但这个话题的侧重点不在于数据，而在于IT部门应该如何配置DRP的支持小组上。这个“怎么办”，是来说IT经理在人员配置上应该怎么办。
这件事情的讨论起缘于上次和老卓的一次讨论。
老卓是浙江某著名合资企业的IT经理，公司的DRP系统上线已经完成了有一段时间了，外部顾问基本上已经撤出，现在就要老卓来组织人马对这套系统进行维护了，但软件实施方在实施结束前，并未对老卓的DRP系统支持小组如何配置提出建议。当然，从另一个角度上来说，软件供应商可能只对软件产品比较了解，但对于软件系统运营和维护可能也没有太多经验，所以想要提出比较好的解决方案也就比较难了。
那么，我们在和老卓讨论时就想：是否可以试着提出一个方案，或者是有一个配置参考让IT经理能够在做人员配置可以参照。照着这个思路，我试着把原来自己部门里的人员配置作为原始框架，再向同行的几个朋友讨论了一下，对DRP系统支持小组的人员配置进行了如下整理。
对于DRP小组的人员配置，我觉的需要从以下几个角度来考虑。
一、 IT部门人员配置的参考理论基础：IT服务管理
从IT服务生命周期上来看，从软件的分析、设计、开发、实施上是属于IT系统开发的范畴，此时，主要使用CMM、IT项目管理等理论及方法对IT系统开发进行管理。
而从项目实施后期，就进入到了软件项目的运营维护直到报废结束IT系统的生命为止，此时IT系统运营维护在很长一段时间内是缺乏相关的IT服务管理方法论的，直到20世纪80年代后期，ITIL(IT Infrastructure Library，信息技术基础设施库)由英国计算机和电信中心 CCTA(2001年4月并入英国政府商务办公室OGC)提出，在英国开始应用。21世纪初，ITIL引入中国，中国IT服务管理也开始与国际接轨，并有了相应的理论基础。
ITIL由于是一个灵活的配置参考模型，因此，我们在做DRP项目支持小组的人员配置时，就可以以ITIL的模型为参考来做。
ITIL主要包括如下几个功能模块：
1、 IT服务管理实施规划：为客户如何确立远景目标，如何分析现状、确定合理目标并进行差距分析和如何实施活动的优先级，以及如何对实施的流程进行评审，提供了全面指导。
2、 ICT基础架构管理：确保提供一个稳定可靠的IT基础架构，以支持业务运营。
3、 应用管理：协调IT服务管理与应用系统的开发、测试和部署的关系，使它们一致的服务于客户的业务运营。
4、 安全管理：保护IT基础架构，对其采取合适的保护措施，使其免受未经授权的使用。
5、 服务管理：ITIL的核心内容，共分为10个管理流程及1项管理职能，被划分为两组：服务提供和服务支持；服务管理也是我们做项目小组配置的基础。
由于ITIL是一个复杂的模型，因文章所限，所以不能展开论述，如果您对ITIL感兴趣的话，可以通过ITIL组织的网站了解更多内容。
二、 企业规模及组织架构
要做DRP系统支持小组的人员配置之前，首先应该对企业的状况有一个深入的了解，那么我们应该先去了解企业的如下信息：
1、 企业现有的组织架构及DRP系统的覆盖部门：在这里我们可以用一个组织架构图来表示，了解这方面的信息是想让IT经理或企业高层清楚地认识到，DRP系统应用的好坏，是直接影响这些业务部门的工作效率的，而如果这些核心业务部门的工作效率受到影响，公司的经营就不可避免地会受到影响，从而加强公司高层对DRP系统重要性的认识。
图表 2
2、 DRP系统在企业内部的节点数，最近6个月的节点增长数：了解这个问题主要是为了对你做人员配置时，要考虑到人员招聘与培训是要有一定的周期的，而培训一个合格的支持人员，应该需要至少两个月时间，如你现在已经有了100个节点，是由1名支持人员来维护。那么，当你未来6个月会增加到300个节点的时候，你就要考虑在什么时间向公司提出增加人员配置的申请合适，使得公司不会因为提前招聘而员工的工作量不足，又不会出现因为人员没有到位而终端的服务请求频繁得不到及时响应，导致IT部门的服务质量下降的问题了。
3、 IT部门现有的人员配置情况，包括是否有DRP运维经验的员工数；由于DRP系统的运营与维护是一项较为细致且复杂的工作。因此，如果你现有的员工比较有经验，那么接下来做相关的运维工作会容易很多，如果你的员工都是新手，那么，IT经理就要考虑是否向软件厂商申请培训支持了。
图表 3
4、 企业现有的分公司数量，DRP系统已经覆盖的分公司有哪些，未来6个月将要覆盖的分公司有哪些，分公司的规模有多大，IT支持人员是否有必要常驻分公司，常驻的人员将采用当地招聘，总部培训的模式，还是由总部外派？支持人员是接受IT经理的异地管理还是分公司的本地管理？
5、 企业现有的代理商数量，DRP系统已经覆盖的代理商有哪些；企业现有的直营店数量，DRP系统已经覆盖的直营店有哪些；考虑上述这两个问题，也主要是评估工作量及人员的准备情况。
三、 支持小组的配置参考
1、 确定人员分工模式：人员分工基本上有两个思路，一是按ITIL的参考，按流程来划分，如划分为帮助台(Help Desk)、支持小组、安全小组、架构小组，等等，这样的划分方法可以不只是在DRP项目中使用，而是使公司的所有服务请求都在这个分工模式中得到响应。还有另一个思路是，为了DRP项目专门设立DRP项目的支撑小组，从DRP项目后期维护的工作主要职责来划分，可以划分为数据组、培训组、支持组三个小组。
从目前我所接触的企业来看，人员的岗位及职责划分还是基于部门的，而没有达到甚至流程或者是运营的层次，包括公司的考核机制也是按部门进行考核，因此，我在这里也采用了更为实际的方法就是按DRP项目的职责来划分人员分工。
人员分工可参照下图：
图表 4
2、 确定DRP支持小组的岗位成员：从上图可以看到，我把DRP支持小组主要分成三组：
•数据组——主要面对业务部门，负责DRP系统的基础配置管理，人员及权限管理、商品资料管理、数据准确性和及时性管理，业务部门数据分析需求整理及报表定制。
•培训组——主要针对新开专卖店(柜)的DRP系统培训，还有针对内部新员工的入职DRP系统培训，培训督导部门的督导使之能够协助在各专卖店进行DRP系统培训，DRP系统新功能的课程编制等。
•支持组——软件的应用疑难问题解决，设备故障，网络故障的反馈与服务，二次开发需求整理及与软件供应商的开发需求跟进，数据库定时备份等工作。
同时各个小组将由不同角色的岗位成员组成，各个岗位又涉及到具体的职位描述、工作流程与绩效考核，在此由于篇幅原因，就不展开论述，只对数据管理员的职位描述进行说明如下：
a) 系统档案类数据维护，包括：商品档案管理（商品信息维护、商品国际码生成）、价格管理（公司采购价格、分销价格及零售价格维护）、组织人员管理（代理商、门店、供应商、制造商及人员等的维护）、权限管理（对岗位人员及各代理商合理控制、分配权限）。
b) ERP软件资源管理：系统独立门店、脱机门店的控制；门店实施情况整理；软件使用授权号的索取、发放；软件站点使用信息的登记。
c) 月底公司及办事处的数据核对：核对系统是否存在异常数据；为核对好的组织做成本核算、结转。
d) 业务部门ERP系统使用问题解决：软件功能操作指导；错误单据处理；协助收集ERP使用的意见及建议。
e) 处理本部门内需要在ERP中操作的各类事务：协助与ERP相关设备的采购、发货及收货跟踪。
f) IT服务台的相关职责：接受客户的服务请求(电话、邮件、传真)；记录并跟踪事故和客户的意见；及时通知客户其请求的当前状态和最新进展；初步评估客户的请求，尽力解决它们或者将其安排给有关人员解决；对客户请求从提出直至验证和终止的整个过程进行管理；协调二线支持人员和第三方支持小组；提供管理方面的信息和建议以改进服务绩效。
3、 确定DRP支持小组的人数：从上图来看，DRP项目支持小组的人员配置会比较多，其实这只是进行细分之后的一个岗位配备，由于很多企业一个DRP支持小组可能只是一个人，那么就没有分工的说法，一个人全部包揽下来；可以根据具体的企业规模，企业发展规划，DRP系统的应用深度，DRP支持小组配备计划来确定人数。而在此之前讨论的DRP项目经验的IT人员此时就可以成为支持小组的骨干人员，可以充分利用他们的经验，让他们有机会去带领新员工一起开展工作，达到“以老带新”形成IT人员的梯队。
四、 支持小组在DRP项目的切入
DRP项目在最早的规划阶段，就可以将DRP支持小组的配置引进来，在做项目规划的时候，就需要将前面讨论的几个方面作为规划的一部分，这样的话，不至于在DRP项目实施结束之后，IT主管再向公司领导提出因为DRP系统项目上线，需要增加人手来进行管理与维护，使的公司领导觉的DRP系统的人力资源投入会过大。
当然，还有的IT主管，因为担心如果将支持小组的配置做到前期规划中，公司高层会觉的DRP项目的成本过高，而导致项目无法上线。其实这个担心的理由是存在的，特别是在公司规模不是太大的企业，公司高层对于DRP系统的还停留在买一个软件，而并没有一个整体的概念，这个时候如果IT主管不做一些引导，那系统到了运维阶段，能够用到什么样的程度还真的是难说了。
还有一个重要的问题是：如果不在规划阶段做好支持小组的配置，那么在支持小组人员没有到位的情况下启动DRP项目，对于支持人员的前期知识储备，提前进入项目，参与项目实施，DRP软件商的知识传递，业务部门需求理解，软件实施方法等都会存在不利的影响。
所以，DRP支持小组应该是DRP项目规划的一部分，从启动DRP项目那一天起支持小组就应该开始运作，并一直小掌控了DRP项目的整个生命周期。
=================
本文首发于IT168技术频道： http://tech.it168.com。转载请注明出处。
前面的文章我有提到过：“顾问走了之后，数据怎么办”的问题，从而引发了对于DRP项目的外部顾问撤走了之后，企业如何做数据治理的讨论（《管理手记：DRP项目中的数据治理》，http://tech.it168.com/m/p/2007-07-18/200707180903562.shtml） 。今天要讨论的还是老话题：“顾问走了之后，应该怎么办？”，但这个话题的侧重点不在于数据，而在于IT部门应该如何配置DRP的支持小组上。这个“怎么办”，是来说IT经理在人员配置上应该怎么办。
这件事情的讨论起缘于上次和老卓的一次讨论。
老卓是浙江某著名合资企业的IT经理，公司的DRP系统上线已经完成了有一段时间了，外部顾问基本上已经撤出，现在就要老卓来组织人马对这套系统进行维护了，但软件实施方在实施结束前，并未对老卓的DRP系统支持小组如何配置提出建议。当然，从另一个角度上来说，软件供应商可能只对软件产品比较了解，但对于软件系统运营和维护可能也没有太多经验，所以想要提出比较好的解决方案也就比较难了。
那么，我们在和老卓讨论时就想：是否可以试着提出一个方案，或者是有一个配置参考让IT经理能够在做人员配置可以参照。照着这个思路，我试着把原来自己部门里的人员配置作为原始框架，再向同行的几个朋友讨论了一下，对DRP系统支持小组的人员配置进行了如下整理。
对于DRP小组的人员配置，我觉的需要从以下几个角度来考虑。
一、 IT部门人员配置的参考理论基础：IT服务管理
从IT服务生命周期上来看，从软件的分析、设计、开发、实施上是属于IT系统开发的范畴，此时，主要使用CMM、IT项目管理等理论及方法对IT系统开发进行管理。
而从项目实施后期，就进入到了软件项目的运营维护直到报废结束IT系统的生命为止，此时IT系统运营维护在很长一段时间内是缺乏相关的IT服务管理方法论的，直到20世纪80年代后期，ITIL(IT Infrastructure Library，信息技术基础设施库)由英国计算机和电信中心 CCTA(2001年4月并入英国政府商务办公室OGC)提出，在英国开始应用。21世纪初，ITIL引入中国，中国IT服务管理也开始与国际接轨，并有了相应的理论基础。
ITIL由于是一个灵活的配置参考模型，因此，我们在做DRP项目支持小组的人员配置时，就可以以ITIL的模型为参考来做。
ITIL主要包括如下几个功能模块：
1、 IT服务管理实施规划：为客户如何确立远景目标，如何分析现状、确定合理目标并进行差距分析和如何实施活动的优先级，以及如何对实施的流程进行评审，提供了全面指导。
2、 ICT基础架构管理：确保提供一个稳定可靠的IT基础架构，以支持业务运营。
3、 应用管理：协调IT服务管理与应用系统的开发、测试和部署的关系，使它们一致的服务于客户的业务运营。
4、 安全管理：保护IT基础架构，对其采取合适的保护措施，使其免受未经授权的使用。
5、 服务管理：ITIL的核心内容，共分为10个管理流程及1项管理职能，被划分为两组：服务提供和服务支持；服务管理也是我们做项目小组配置的基础。
由于ITIL是一个复杂的模型，因文章所限，所以不能展开论述，如果您对ITIL感兴趣的话，可以通过ITIL组织的网站了解更多内容。
二、 企业规模及组织架构
要做DRP系统支持小组的人员配置之前，首先应该对企业的状况有一个深入的了解，那么我们应该先去了解企业的如下信息：
1、 企业现有的组织架构及DRP系统的覆盖部门：在这里我们可以用一个组织架构图来表示，了解这方面的信息是想让IT经理或企业高层清楚地认识到，DRP系统应用的好坏，是直接影响这些业务部门的工作效率的，而如果这些核心业务部门的工作效率受到影响，公司的经营就不可避免地会受到影响，从而加强公司高层对DRP系统重要性的认识。
图表 2
2、 DRP系统在企业内部的节点数，最近6个月的节点增长数：了解这个问题主要是为了对你做人员配置时，要考虑到人员招聘与培训是要有一定的周期的，而培训一个合格的支持人员，应该需要至少两个月时间，如你现在已经有了100个节点，是由1名支持人员来维护。那么，当你未来6个月会增加到300个节点的时候，你就要考虑在什么时间向公司提出增加人员配置的申请合适，使得公司不会因为提前招聘而员工的工作量不足，又不会出现因为人员没有到位而终端的服务请求频繁得不到及时响应，导致IT部门的服务质量下降的问题了。
3、 IT部门现有的人员配置情况，包括是否有DRP运维经验的员工数；由于DRP系统的运营与维护是一项较为细致且复杂的工作。因此，如果你现有的员工比较有经验，那么接下来做相关的运维工作会容易很多，如果你的员工都是新手，那么，IT经理就要考虑是否向软件厂商申请培训支持了。
图表 3
4、 企业现有的分公司数量，DRP系统已经覆盖的分公司有哪些，未来6个月将要覆盖的分公司有哪些，分公司的规模有多大，IT支持人员是否有必要常驻分公司，常驻的人员将采用当地招聘，总部培训的模式，还是由总部外派？支持人员是接受IT经理的异地管理还是分公司的本地管理？
5、 企业现有的代理商数量，DRP系统已经覆盖的代理商有哪些；企业现有的直营店数量，DRP系统已经覆盖的直营店有哪些；考虑上述这两个问题，也主要是评估工作量及人员的准备情况。
三、 支持小组的配置参考
1、 确定人员分工模式：人员分工基本上有两个思路，一是按ITIL的参考，按流程来划分，如划分为帮助台(Help Desk)、支持小组、安全小组、架构小组，等等，这样的划分方法可以不只是在DRP项目中使用，而是使公司的所有服务请求都在这个分工模式中得到响应。还有另一个思路是，为了DRP项目专门设立DRP项目的支撑小组，从DRP项目后期维护的工作主要职责来划分，可以划分为数据组、培训组、支持组三个小组。
从目前我所接触的企业来看，人员的岗位及职责划分还是基于部门的，而没有达到甚至流程或者是运营的层次，包括公司的考核机制也是按部门进行考核，因此，我在这里也采用了更为实际的方法就是按DRP项目的职责来划分人员分工。
人员分工可参照下图：
图表 4
2、 确定DRP支持小组的岗位成员：从上图可以看到，我把DRP支持小组主要分成三组：
•数据组——主要面对业务部门，负责DRP系统的基础配置管理，人员及权限管理、商品资料管理、数据准确性和及时性管理，业务部门数据分析需求整理及报表定制。
•培训组——主要针对新开专卖店(柜)的DRP系统培训，还有针对内部新员工的入职DRP系统培训，培训督导部门的督导使之能够协助在各专卖店进行DRP系统培训，DRP系统新功能的课程编制等。
•支持组——软件的应用疑难问题解决，设备故障，网络故障的反馈与服务，二次开发需求整理及与软件供应商的开发需求跟进，数据库定时备份等工作。
同时各个小组将由不同角色的岗位成员组成，各个岗位又涉及到具体的职位描述、工作流程与绩效考核，在此由于篇幅原因，就不展开论述，只对数据管理员的职位描述进行说明如下：
a) 系统档案类数据维护，包括：商品档案管理（商品信息维护、商品国际码生成）、价格管理（公司采购价格、分销价格及零售价格维护）、组织人员管理（代理商、门店、供应商、制造商及人员等的维护）、权限管理（对岗位人员及各代理商合理控制、分配权限）。
b) ERP软件资源管理：系统独立门店、脱机门店的控制；门店实施情况整理；软件使用授权号的索取、发放；软件站点使用信息的登记。
c) 月底公司及办事处的数据核对：核对系统是否存在异常数据；为核对好的组织做成本核算、结转。
d) 业务部门ERP系统使用问题解决：软件功能操作指导；错误单据处理；协助收集ERP使用的意见及建议。
e) 处理本部门内需要在ERP中操作的各类事务：协助与ERP相关设备的采购、发货及收货跟踪。
f) IT服务台的相关职责：接受客户的服务请求(电话、邮件、传真)；记录并跟踪事故和客户的意见；及时通知客户其请求的当前状态和最新进展；初步评估客户的请求，尽力解决它们或者将其安排给有关人员解决；对客户请求从提出直至验证和终止的整个过程进行管理；协调二线支持人员和第三方支持小组；提供管理方面的信息和建议以改进服务绩效。
3、 确定DRP支持小组的人数：从上图来看，DRP项目支持小组的人员配置会比较多，其实这只是进行细分之后的一个岗位配备，由于很多企业一个DRP支持小组可能只是一个人，那么就没有分工的说法，一个人全部包揽下来；可以根据具体的企业规模，企业发展规划，DRP系统的应用深度，DRP支持小组配备计划来确定人数。而在此之前讨论的DRP项目经验的IT人员此时就可以成为支持小组的骨干人员，可以充分利用他们的经验，让他们有机会去带领新员工一起开展工作，达到“以老带新”形成IT人员的梯队。
四、 支持小组在DRP项目的切入
DRP项目在最早的规划阶段，就可以将DRP支持小组的配置引进来，在做项目规划的时候，就需要将前面讨论的几个方面作为规划的一部分，这样的话，不至于在DRP项目实施结束之后，IT主管再向公司领导提出因为DRP系统项目上线，需要增加人手来进行管理与维护，使的公司领导觉的DRP系统的人力资源投入会过大。
当然，还有的IT主管，因为担心如果将支持小组的配置做到前期规划中，公司高层会觉的DRP项目的成本过高，而导致项目无法上线。其实这个担心的理由是存在的，特别是在公司规模不是太大的企业，公司高层对于DRP系统的还停留在买一个软件，而并没有一个整体的概念，这个时候如果IT主管不做一些引导，那系统到了运维阶段，能够用到什么样的程度还真的是难说了。
还有一个重要的问题是：如果不在规划阶段做好支持小组的配置，那么在支持小组人员没有到位的情况下启动DRP项目，对于支持人员的前期知识储备，提前进入项目，参与项目实施，DRP软件商的知识传递，业务部门需求理解，软件实施方法等都会存在不利的影响。
所以，DRP支持小组应该是DRP项目规划的一部分，从启动DRP项目那一天起支持小组就应该开始运作，并一直小掌控了DRP项目的整个生命周期。
=================
本文首发于IT168技术频道： http://tech.it168.com。转载请注明出处。
前面的文章我有提到过：“顾问走了之后，数据怎么办”的问题，从而引发了对于DRP项目的外部顾问撤走了之后，企业如何做数据治理的讨论（《管理手记：DRP项目中的数据治理》，http://tech.it168.com/m/p/2007-07-18/200707180903562.shtml） 。今天要讨论的还是老话题：“顾问走了之后，应该怎么办？”，但这个话题的侧重点不在于数据，而在于IT部门应该如何配置DRP的支持小组上。这个“怎么办”，是来说IT经理在人员配置上应该怎么办。
这件事情的讨论起缘于上次和老卓的一次讨论。
老卓是浙江某著名合资企业的IT经理，公司的DRP系统上线已经完成了有一段时间了，外部顾问基本上已经撤出，现在就要老卓来组织人马对这套系统进行维护了，但软件实施方在实施结束前，并未对老卓的DRP系统支持小组如何配置提出建议。当然，从另一个角度上来说，软件供应商可能只对软件产品比较了解，但对于软件系统运营和维护可能也没有太多经验，所以想要提出比较好的解决方案也就比较难了。
那么，我们在和老卓讨论时就想：是否可以试着提出一个方案，或者是有一个配置参考让IT经理能够在做人员配置可以参照。照着这个思路，我试着把原来自己部门里的人员配置作为原始框架，再向同行的几个朋友讨论了一下，对DRP系统支持小组的人员配置进行了如下整理。
对于DRP小组的人员配置，我觉的需要从以下几个角度来考虑。
一、 IT部门人员配置的参考理论基础：IT服务管理
从IT服务生命周期上来看，从软件的分析、设计、开发、实施上是属于IT系统开发的范畴，此时，主要使用CMM、IT项目管理等理论及方法对IT系统开发进行管理。
而从项目实施后期，就进入到了软件项目的运营维护直到报废结束IT系统的生命为止，此时IT系统运营维护在很长一段时间内是缺乏相关的IT服务管理方法论的，直到20世纪80年代后期，ITIL(IT Infrastructure Library，信息技术基础设施库)由英国计算机和电信中心 CCTA(2001年4月并入英国政府商务办公室OGC)提出，在英国开始应用。21世纪初，ITIL引入中国，中国IT服务管理也开始与国际接轨，并有了相应的理论基础。
ITIL由于是一个灵活的配置参考模型，因此，我们在做DRP项目支持小组的人员配置时，就可以以ITIL的模型为参考来做。
ITIL主要包括如下几个功能模块：
1、 IT服务管理实施规划：为客户如何确立远景目标，如何分析现状、确定合理目标并进行差距分析和如何实施活动的优先级，以及如何对实施的流程进行评审，提供了全面指导。
2、 ICT基础架构管理：确保提供一个稳定可靠的IT基础架构，以支持业务运营。
3、 应用管理：协调IT服务管理与应用系统的开发、测试和部署的关系，使它们一致的服务于客户的业务运营。
4、 安全管理：保护IT基础架构，对其采取合适的保护措施，使其免受未经授权的使用。
5、 服务管理：ITIL的核心内容，共分为10个管理流程及1项管理职能，被划分为两组：服务提供和服务支持；服务管理也是我们做项目小组配置的基础。
由于ITIL是一个复杂的模型，因文章所限，所以不能展开论述，如果您对ITIL感兴趣的话，可以通过ITIL组织的网站了解更多内容。
二、 企业规模及组织架构
要做DRP系统支持小组的人员配置之前，首先应该对企业的状况有一个深入的了解，那么我们应该先去了解企业的如下信息：
1、 企业现有的组织架构及DRP系统的覆盖部门：在这里我们可以用一个组织架构图来表示，了解这方面的信息是想让IT经理或企业高层清楚地认识到，DRP系统应用的好坏，是直接影响这些业务部门的工作效率的，而如果这些核心业务部门的工作效率受到影响，公司的经营就不可避免地会受到影响，从而加强公司高层对DRP系统重要性的认识。
图表 2
2、 DRP系统在企业内部的节点数，最近6个月的节点增长数：了解这个问题主要是为了对你做人员配置时，要考虑到人员招聘与培训是要有一定的周期的，而培训一个合格的支持人员，应该需要至少两个月时间，如你现在已经有了100个节点，是由1名支持人员来维护。那么，当你未来6个月会增加到300个节点的时候，你就要考虑在什么时间向公司提出增加人员配置的申请合适，使得公司不会因为提前招聘而员工的工作量不足，又不会出现因为人员没有到位而终端的服务请求频繁得不到及时响应，导致IT部门的服务质量下降的问题了。
3、 IT部门现有的人员配置情况，包括是否有DRP运维经验的员工数；由于DRP系统的运营与维护是一项较为细致且复杂的工作。因此，如果你现有的员工比较有经验，那么接下来做相关的运维工作会容易很多，如果你的员工都是新手，那么，IT经理就要考虑是否向软件厂商申请培训支持了。
图表 3
4、 企业现有的分公司数量，DRP系统已经覆盖的分公司有哪些，未来6个月将要覆盖的分公司有哪些，分公司的规模有多大，IT支持人员是否有必要常驻分公司，常驻的人员将采用当地招聘，总部培训的模式，还是由总部外派？支持人员是接受IT经理的异地管理还是分公司的本地管理？
5、 企业现有的代理商数量，DRP系统已经覆盖的代理商有哪些；企业现有的直营店数量，DRP系统已经覆盖的直营店有哪些；考虑上述这两个问题，也主要是评估工作量及人员的准备情况。
三、 支持小组的配置参考
1、 确定人员分工模式：人员分工基本上有两个思路，一是按ITIL的参考，按流程来划分，如划分为帮助台(Help Desk)、支持小组、安全小组、架构小组，等等，这样的划分方法可以不只是在DRP项目中使用，而是使公司的所有服务请求都在这个分工模式中得到响应。还有另一个思路是，为了DRP项目专门设立DRP项目的支撑小组，从DRP项目后期维护的工作主要职责来划分，可以划分为数据组、培训组、支持组三个小组。
从目前我所接触的企业来看，人员的岗位及职责划分还是基于部门的，而没有达到甚至流程或者是运营的层次，包括公司的考核机制也是按部门进行考核，因此，我在这里也采用了更为实际的方法就是按DRP项目的职责来划分人员分工。
人员分工可参照下图：
图表 4
2、 确定DRP支持小组的岗位成员：从上图可以看到，我把DRP支持小组主要分成三组：
•数据组——主要面对业务部门，负责DRP系统的基础配置管理，人员及权限管理、商品资料管理、数据准确性和及时性管理，业务部门数据分析需求整理及报表定制。
•培训组——主要针对新开专卖店(柜)的DRP系统培训，还有针对内部新员工的入职DRP系统培训，培训督导部门的督导使之能够协助在各专卖店进行DRP系统培训，DRP系统新功能的课程编制等。
•支持组——软件的应用疑难问题解决，设备故障，网络故障的反馈与服务，二次开发需求整理及与软件供应商的开发需求跟进，数据库定时备份等工作。
同时各个小组将由不同角色的岗位成员组成，各个岗位又涉及到具体的职位描述、工作流程与绩效考核，在此由于篇幅原因，就不展开论述，只对数据管理员的职位描述进行说明如下：
a) 系统档案类数据维护，包括：商品档案管理（商品信息维护、商品国际码生成）、价格管理（公司采购价格、分销价格及零售价格维护）、组织人员管理（代理商、门店、供应商、制造商及人员等的维护）、权限管理（对岗位人员及各代理商合理控制、分配权限）。
b) ERP软件资源管理：系统独立门店、脱机门店的控制；门店实施情况整理；软件使用授权号的索取、发放；软件站点使用信息的登记。
c) 月底公司及办事处的数据核对：核对系统是否存在异常数据；为核对好的组织做成本核算、结转。
d) 业务部门ERP系统使用问题解决：软件功能操作指导；错误单据处理；协助收集ERP使用的意见及建议。
e) 处理本部门内需要在ERP中操作的各类事务：协助与ERP相关设备的采购、发货及收货跟踪。
f) IT服务台的相关职责：接受客户的服务请求(电话、邮件、传真)；记录并跟踪事故和客户的意见；及时通知客户其请求的当前状态和最新进展；初步评估客户的请求，尽力解决它们或者将其安排给有关人员解决；对客户请求从提出直至验证和终止的整个过程进行管理；协调二线支持人员和第三方支持小组；提供管理方面的信息和建议以改进服务绩效。
3、 确定DRP支持小组的人数：从上图来看，DRP项目支持小组的人员配置会比较多，其实这只是进行细分之后的一个岗位配备，由于很多企业一个DRP支持小组可能只是一个人，那么就没有分工的说法，一个人全部包揽下来；可以根据具体的企业规模，企业发展规划，DRP系统的应用深度，DRP支持小组配备计划来确定人数。而在此之前讨论的DRP项目经验的IT人员此时就可以成为支持小组的骨干人员，可以充分利用他们的经验，让他们有机会去带领新员工一起开展工作，达到“以老带新”形成IT人员的梯队。
四、 支持小组在DRP项目的切入
DRP项目在最早的规划阶段，就可以将DRP支持小组的配置引进来，在做项目规划的时候，就需要将前面讨论的几个方面作为规划的一部分，这样的话，不至于在DRP项目实施结束之后，IT主管再向公司领导提出因为DRP系统项目上线，需要增加人手来进行管理与维护，使的公司领导觉的DRP系统的人力资源投入会过大。
当然，还有的IT主管，因为担心如果将支持小组的配置做到前期规划中，公司高层会觉的DRP项目的成本过高，而导致项目无法上线。其实这个担心的理由是存在的，特别是在公司规模不是太大的企业，公司高层对于DRP系统的还停留在买一个软件，而并没有一个整体的概念，这个时候如果IT主管不做一些引导，那系统到了运维阶段，能够用到什么样的程度还真的是难说了。
还有一个重要的问题是：如果不在规划阶段做好支持小组的配置，那么在支持小组人员没有到位的情况下启动DRP项目，对于支持人员的前期知识储备，提前进入项目，参与项目实施，DRP软件商的知识传递，业务部门需求理解，软件实施方法等都会存在不利的影响。
所以，DRP支持小组应该是DRP项目规划的一部分，从启动DRP项目那一天起支持小组就应该开始运作，并一直小掌控了DRP项目的整个生命周期。
=================
本文首发于IT168技术频道： http://tech.it168.com。转载请注明出处。
前面的文章我有提到过：“顾问走了之后，数据怎么办”的问题，从而引发了对于DRP项目的外部顾问撤走了之后，企业如何做数据治理的讨论（《管理手记：DRP项目中的数据治理》，http://tech.it168.com/m/p/2007-07-18/200707180903562.shtml） 。今天要讨论的还是老话题：“顾问走了之后，应该怎么办？”，但这个话题的侧重点不在于数据，而在于IT部门应该如何配置DRP的支持小组上。这个“怎么办”，是来说IT经理在人员配置上应该怎么办。
这件事情的讨论起缘于上次和老卓的一次讨论。
老卓是浙江某著名合资企业的IT经理，公司的DRP系统上线已经完成了有一段时间了，外部顾问基本上已经撤出，现在就要老卓来组织人马对这套系统进行维护了，但软件实施方在实施结束前，并未对老卓的DRP系统支持小组如何配置提出建议。当然，从另一个角度上来说，软件供应商可能只对软件产品比较了解，但对于软件系统运营和维护可能也没有太多经验，所以想要提出比较好的解决方案也就比较难了。
那么，我们在和老卓讨论时就想：是否可以试着提出一个方案，或者是有一个配置参考让IT经理能够在做人员配置可以参照。照着这个思路，我试着把原来自己部门里的人员配置作为原始框架，再向同行的几个朋友讨论了一下，对DRP系统支持小组的人员配置进行了如下整理。
对于DRP小组的人员配置，我觉的需要从以下几个角度来考虑。
一、 IT部门人员配置的参考理论基础：IT服务管理
从IT服务生命周期上来看，从软件的分析、设计、开发、实施上是属于IT系统开发的范畴，此时，主要使用CMM、IT项目管理等理论及方法对IT系统开发进行管理。
而从项目实施后期，就进入到了软件项目的运营维护直到报废结束IT系统的生命为止，此时IT系统运营维护在很长一段时间内是缺乏相关的IT服务管理方法论的，直到20世纪80年代后期，ITIL(IT Infrastructure Library，信息技术基础设施库)由英国计算机和电信中心 CCTA(2001年4月并入英国政府商务办公室OGC)提出，在英国开始应用。21世纪初，ITIL引入中国，中国IT服务管理也开始与国际接轨，并有了相应的理论基础。
ITIL由于是一个灵活的配置参考模型，因此，我们在做DRP项目支持小组的人员配置时，就可以以ITIL的模型为参考来做。
ITIL主要包括如下几个功能模块：
1、 IT服务管理实施规划：为客户如何确立远景目标，如何分析现状、确定合理目标并进行差距分析和如何实施活动的优先级，以及如何对实施的流程进行评审，提供了全面指导。
2、 ICT基础架构管理：确保提供一个稳定可靠的IT基础架构，以支持业务运营。
3、 应用管理：协调IT服务管理与应用系统的开发、测试和部署的关系，使它们一致的服务于客户的业务运营。
4、 安全管理：保护IT基础架构，对其采取合适的保护措施，使其免受未经授权的使用。
5、 服务管理：ITIL的核心内容，共分为10个管理流程及1项管理职能，被划分为两组：服务提供和服务支持；服务管理也是我们做项目小组配置的基础。
由于ITIL是一个复杂的模型，因文章所限，所以不能展开论述，如果您对ITIL感兴趣的话，可以通过ITIL组织的网站了解更多内容。
二、 企业规模及组织架构
要做DRP系统支持小组的人员配置之前，首先应该对企业的状况有一个深入的了解，那么我们应该先去了解企业的如下信息：
1、 企业现有的组织架构及DRP系统的覆盖部门：在这里我们可以用一个组织架构图来表示，了解这方面的信息是想让IT经理或企业高层清楚地认识到，DRP系统应用的好坏，是直接影响这些业务部门的工作效率的，而如果这些核心业务部门的工作效率受到影响，公司的经营就不可避免地会受到影响，从而加强公司高层对DRP系统重要性的认识。
图表 2
2、 DRP系统在企业内部的节点数，最近6个月的节点增长数：了解这个问题主要是为了对你做人员配置时，要考虑到人员招聘与培训是要有一定的周期的，而培训一个合格的支持人员，应该需要至少两个月时间，如你现在已经有了100个节点，是由1名支持人员来维护。那么，当你未来6个月会增加到300个节点的时候，你就要考虑在什么时间向公司提出增加人员配置的申请合适，使得公司不会因为提前招聘而员工的工作量不足，又不会出现因为人员没有到位而终端的服务请求频繁得不到及时响应，导致IT部门的服务质量下降的问题了。
3、 IT部门现有的人员配置情况，包括是否有DRP运维经验的员工数；由于DRP系统的运营与维护是一项较为细致且复杂的工作。因此，如果你现有的员工比较有经验，那么接下来做相关的运维工作会容易很多，如果你的员工都是新手，那么，IT经理就要考虑是否向软件厂商申请培训支持了。
图表 3
4、 企业现有的分公司数量，DRP系统已经覆盖的分公司有哪些，未来6个月将要覆盖的分公司有哪些，分公司的规模有多大，IT支持人员是否有必要常驻分公司，常驻的人员将采用当地招聘，总部培训的模式，还是由总部外派？支持人员是接受IT经理的异地管理还是分公司的本地管理？
5、 企业现有的代理商数量，DRP系统已经覆盖的代理商有哪些；企业现有的直营店数量，DRP系统已经覆盖的直营店有哪些；考虑上述这两个问题，也主要是评估工作量及人员的准备情况。
三、 支持小组的配置参考
1、 确定人员分工模式：人员分工基本上有两个思路，一是按ITIL的参考，按流程来划分，如划分为帮助台(Help Desk)、支持小组、安全小组、架构小组，等等，这样的划分方法可以不只是在DRP项目中使用，而是使公司的所有服务请求都在这个分工模式中得到响应。还有另一个思路是，为了DRP项目专门设立DRP项目的支撑小组，从DRP项目后期维护的工作主要职责来划分，可以划分为数据组、培训组、支持组三个小组。
从目前我所接触的企业来看，人员的岗位及职责划分还是基于部门的，而没有达到甚至流程或者是运营的层次，包括公司的考核机制也是按部门进行考核，因此，我在这里也采用了更为实际的方法就是按DRP项目的职责来划分人员分工。
人员分工可参照下图：
图表 4
2、 确定DRP支持小组的岗位成员：从上图可以看到，我把DRP支持小组主要分成三组：
•数据组——主要面对业务部门，负责DRP系统的基础配置管理，人员及权限管理、商品资料管理、数据准确性和及时性管理，业务部门数据分析需求整理及报表定制。
•培训组——主要针对新开专卖店(柜)的DRP系统培训，还有针对内部新员工的入职DRP系统培训，培训督导部门的督导使之能够协助在各专卖店进行DRP系统培训，DRP系统新功能的课程编制等。
•支持组——软件的应用疑难问题解决，设备故障，网络故障的反馈与服务，二次开发需求整理及与软件供应商的开发需求跟进，数据库定时备份等工作。
同时各个小组将由不同角色的岗位成员组成，各个岗位又涉及到具体的职位描述、工作流程与绩效考核，在此由于篇幅原因，就不展开论述，只对数据管理员的职位描述进行说明如下：
a) 系统档案类数据维护，包括：商品档案管理（商品信息维护、商品国际码生成）、价格管理（公司采购价格、分销价格及零售价格维护）、组织人员管理（代理商、门店、供应商、制造商及人员等的维护）、权限管理（对岗位人员及各代理商合理控制、分配权限）。
b) ERP软件资源管理：系统独立门店、脱机门店的控制；门店实施情况整理；软件使用授权号的索取、发放；软件站点使用信息的登记。
c) 月底公司及办事处的数据核对：核对系统是否存在异常数据；为核对好的组织做成本核算、结转。
d) 业务部门ERP系统使用问题解决：软件功能操作指导；错误单据处理；协助收集ERP使用的意见及建议。
e) 处理本部门内需要在ERP中操作的各类事务：协助与ERP相关设备的采购、发货及收货跟踪。
f) IT服务台的相关职责：接受客户的服务请求(电话、邮件、传真)；记录并跟踪事故和客户的意见；及时通知客户其请求的当前状态和最新进展；初步评估客户的请求，尽力解决它们或者将其安排给有关人员解决；对客户请求从提出直至验证和终止的整个过程进行管理；协调二线支持人员和第三方支持小组；提供管理方面的信息和建议以改进服务绩效。
3、 确定DRP支持小组的人数：从上图来看，DRP项目支持小组的人员配置会比较多，其实这只是进行细分之后的一个岗位配备，由于很多企业一个DRP支持小组可能只是一个人，那么就没有分工的说法，一个人全部包揽下来；可以根据具体的企业规模，企业发展规划，DRP系统的应用深度，DRP支持小组配备计划来确定人数。而在此之前讨论的DRP项目经验的IT人员此时就可以成为支持小组的骨干人员，可以充分利用他们的经验，让他们有机会去带领新员工一起开展工作，达到“以老带新”形成IT人员的梯队。
四、 支持小组在DRP项目的切入
DRP项目在最早的规划阶段，就可以将DRP支持小组的配置引进来，在做项目规划的时候，就需要将前面讨论的几个方面作为规划的一部分，这样的话，不至于在DRP项目实施结束之后，IT主管再向公司领导提出因为DRP系统项目上线，需要增加人手来进行管理与维护，使的公司领导觉的DRP系统的人力资源投入会过大。
当然，还有的IT主管，因为担心如果将支持小组的配置做到前期规划中，公司高层会觉的DRP项目的成本过高，而导致项目无法上线。其实这个担心的理由是存在的，特别是在公司规模不是太大的企业，公司高层对于DRP系统的还停留在买一个软件，而并没有一个整体的概念，这个时候如果IT主管不做一些引导，那系统到了运维阶段，能够用到什么样的程度还真的是难说了。
还有一个重要的问题是：如果不在规划阶段做好支持小组的配置，那么在支持小组人员没有到位的情况下启动DRP项目，对于支持人员的前期知识储备，提前进入项目，参与项目实施，DRP软件商的知识传递，业务部门需求理解，软件实施方法等都会存在不利的影响。
所以，DRP支持小组应该是DRP项目规划的一部分，从启动DRP项目那一天起支持小组就应该开始运作，并一直小掌控了DRP项目的整个生命周期。
=================
本文首发于IT168技术频道： http://tech.it168.com。转载请注明出处。
前面的文章我有提到过：“顾问走了之后，数据怎么办”的问题，从而引发了对于DRP项目的外部顾问撤走了之后，企业如何做数据治理的讨论（《管理手记：DRP项目中的数据治理》，http://tech.it168.com/m/p/2007-07-18/200707180903562.shtml） 。今天要讨论的还是老话题：“顾问走了之后，应该怎么办？”，但这个话题的侧重点不在于数据，而在于IT部门应该如何配置DRP的支持小组上。这个“怎么办”，是来说IT经理在人员配置上应该怎么办。
这件事情的讨论起缘于上次和老卓的一次讨论。
老卓是浙江某著名合资企业的IT经理，公司的DRP系统上线已经完成了有一段时间了，外部顾问基本上已经撤出，现在就要老卓来组织人马对这套系统进行维护了，但软件实施方在实施结束前，并未对老卓的DRP系统支持小组如何配置提出建议。当然，从另一个角度上来说，软件供应商可能只对软件产品比较了解，但对于软件系统运营和维护可能也没有太多经验，所以想要提出比较好的解决方案也就比较难了。
那么，我们在和老卓讨论时就想：是否可以试着提出一个方案，或者是有一个配置参考让IT经理能够在做人员配置可以参照。照着这个思路，我试着把原来自己部门里的人员配置作为原始框架，再向同行的几个朋友讨论了一下，对DRP系统支持小组的人员配置进行了如下整理。
对于DRP小组的人员配置，我觉的需要从以下几个角度来考虑。
一、 IT部门人员配置的参考理论基础：IT服务管理
从IT服务生命周期上来看，从软件的分析、设计、开发、实施上是属于IT系统开发的范畴，此时，主要使用CMM、IT项目管理等理论及方法对IT系统开发进行管理。
而从项目实施后期，就进入到了软件项目的运营维护直到报废结束IT系统的生命为止，此时IT系统运营维护在很长一段时间内是缺乏相关的IT服务管理方法论的，直到20世纪80年代后期，ITIL(IT Infrastructure Library，信息技术基础设施库)由英国计算机和电信中心 CCTA(2001年4月并入英国政府商务办公室OGC)提出，在英国开始应用。21世纪初，ITIL引入中国，中国IT服务管理也开始与国际接轨，并有了相应的理论基础。
ITIL由于是一个灵活的配置参考模型，因此，我们在做DRP项目支持小组的人员配置时，就可以以ITIL的模型为参考来做。
ITIL主要包括如下几个功能模块：
1、 IT服务管理实施规划：为客户如何确立远景目标，如何分析现状、确定合理目标并进行差距分析和如何实施活动的优先级，以及如何对实施的流程进行评审，提供了全面指导。
2、 ICT基础架构管理：确保提供一个稳定可靠的IT基础架构，以支持业务运营。
3、 应用管理：协调IT服务管理与应用系统的开发、测试和部署的关系，使它们一致的服务于客户的业务运营。
4、 安全管理：保护IT基础架构，对其采取合适的保护措施，使其免受未经授权的使用。
5、 服务管理：ITIL的核心内容，共分为10个管理流程及1项管理职能，被划分为两组：服务提供和服务支持；服务管理也是我们做项目小组配置的基础。
由于ITIL是一个复杂的模型，因文章所限，所以不能展开论述，如果您对ITIL感兴趣的话，可以通过ITIL组织的网站了解更多内容。
二、 企业规模及组织架构
要做DRP系统支持小组的人员配置之前，首先应该对企业的状况有一个深入的了解，那么我们应该先去了解企业的如下信息：
1、 企业现有的组织架构及DRP系统的覆盖部门：在这里我们可以用一个组织架构图来表示，了解这方面的信息是想让IT经理或企业高层清楚地认识到，DRP系统应用的好坏，是直接影响这些业务部门的工作效率的，而如果这些核心业务部门的工作效率受到影响，公司的经营就不可避免地会受到影响，从而加强公司高层对DRP系统重要性的认识。
图表 2
2、 DRP系统在企业内部的节点数，最近6个月的节点增长数：了解这个问题主要是为了对你做人员配置时，要考虑到人员招聘与培训是要有一定的周期的，而培训一个合格的支持人员，应该需要至少两个月时间，如你现在已经有了100个节点，是由1名支持人员来维护。那么，当你未来6个月会增加到300个节点的时候，你就要考虑在什么时间向公司提出增加人员配置的申请合适，使得公司不会因为提前招聘而员工的工作量不足，又不会出现因为人员没有到位而终端的服务请求频繁得不到及时响应，导致IT部门的服务质量下降的问题了。
3、 IT部门现有的人员配置情况，包括是否有DRP运维经验的员工数；由于DRP系统的运营与维护是一项较为细致且复杂的工作。因此，如果你现有的员工比较有经验，那么接下来做相关的运维工作会容易很多，如果你的员工都是新手，那么，IT经理就要考虑是否向软件厂商申请培训支持了。
图表 3
4、 企业现有的分公司数量，DRP系统已经覆盖的分公司有哪些，未来6个月将要覆盖的分公司有哪些，分公司的规模有多大，IT支持人员是否有必要常驻分公司，常驻的人员将采用当地招聘，总部培训的模式，还是由总部外派？支持人员是接受IT经理的异地管理还是分公司的本地管理？
5、 企业现有的代理商数量，DRP系统已经覆盖的代理商有哪些；企业现有的直营店数量，DRP系统已经覆盖的直营店有哪些；考虑上述这两个问题，也主要是评估工作量及人员的准备情况。
三、 支持小组的配置参考
1、 确定人员分工模式：人员分工基本上有两个思路，一是按ITIL的参考，按流程来划分，如划分为帮助台(Help Desk)、支持小组、安全小组、架构小组，等等，这样的划分方法可以不只是在DRP项目中使用，而是使公司的所有服务请求都在这个分工模式中得到响应。还有另一个思路是，为了DRP项目专门设立DRP项目的支撑小组，从DRP项目后期维护的工作主要职责来划分，可以划分为数据组、培训组、支持组三个小组。
从目前我所接触的企业来看，人员的岗位及职责划分还是基于部门的，而没有达到甚至流程或者是运营的层次，包括公司的考核机制也是按部门进行考核，因此，我在这里也采用了更为实际的方法就是按DRP项目的职责来划分人员分工。
人员分工可参照下图：
图表 4
2、 确定DRP支持小组的岗位成员：从上图可以看到，我把DRP支持小组主要分成三组：
•数据组——主要面对业务部门，负责DRP系统的基础配置管理，人员及权限管理、商品资料管理、数据准确性和及时性管理，业务部门数据分析需求整理及报表定制。
•培训组——主要针对新开专卖店(柜)的DRP系统培训，还有针对内部新员工的入职DRP系统培训，培训督导部门的督导使之能够协助在各专卖店进行DRP系统培训，DRP系统新功能的课程编制等。
•支持组——软件的应用疑难问题解决，设备故障，网络故障的反馈与服务，二次开发需求整理及与软件供应商的开发需求跟进，数据库定时备份等工作。
同时各个小组将由不同角色的岗位成员组成，各个岗位又涉及到具体的职位描述、工作流程与绩效考核，在此由于篇幅原因，就不展开论述，只对数据管理员的职位描述进行说明如下：
a) 系统档案类数据维护，包括：商品档案管理（商品信息维护、商品国际码生成）、价格管理（公司采购价格、分销价格及零售价格维护）、组织人员管理（代理商、门店、供应商、制造商及人员等的维护）、权限管理（对岗位人员及各代理商合理控制、分配权限）。
b) ERP软件资源管理：系统独立门店、脱机门店的控制；门店实施情况整理；软件使用授权号的索取、发放；软件站点使用信息的登记。
c) 月底公司及办事处的数据核对：核对系统是否存在异常数据；为核对好的组织做成本核算、结转。
d) 业务部门ERP系统使用问题解决：软件功能操作指导；错误单据处理；协助收集ERP使用的意见及建议。
e) 处理本部门内需要在ERP中操作的各类事务：协助与ERP相关设备的采购、发货及收货跟踪。
f) IT服务台的相关职责：接受客户的服务请求(电话、邮件、传真)；记录并跟踪事故和客户的意见；及时通知客户其请求的当前状态和最新进展；初步评估客户的请求，尽力解决它们或者将其安排给有关人员解决；对客户请求从提出直至验证和终止的整个过程进行管理；协调二线支持人员和第三方支持小组；提供管理方面的信息和建议以改进服务绩效。
3、 确定DRP支持小组的人数：从上图来看，DRP项目支持小组的人员配置会比较多，其实这只是进行细分之后的一个岗位配备，由于很多企业一个DRP支持小组可能只是一个人，那么就没有分工的说法，一个人全部包揽下来；可以根据具体的企业规模，企业发展规划，DRP系统的应用深度，DRP支持小组配备计划来确定人数。而在此之前讨论的DRP项目经验的IT人员此时就可以成为支持小组的骨干人员，可以充分利用他们的经验，让他们有机会去带领新员工一起开展工作，达到“以老带新”形成IT人员的梯队。
四、 支持小组在DRP项目的切入
DRP项目在最早的规划阶段，就可以将DRP支持小组的配置引进来，在做项目规划的时候，就需要将前面讨论的几个方面作为规划的一部分，这样的话，不至于在DRP项目实施结束之后，IT主管再向公司领导提出因为DRP系统项目上线，需要增加人手来进行管理与维护，使的公司领导觉的DRP系统的人力资源投入会过大。
当然，还有的IT主管，因为担心如果将支持小组的配置做到前期规划中，公司高层会觉的DRP项目的成本过高，而导致项目无法上线。其实这个担心的理由是存在的，特别是在公司规模不是太大的企业，公司高层对于DRP系统的还停留在买一个软件，而并没有一个整体的概念，这个时候如果IT主管不做一些引导，那系统到了运维阶段，能够用到什么样的程度还真的是难说了。
还有一个重要的问题是：如果不在规划阶段做好支持小组的配置，那么在支持小组人员没有到位的情况下启动DRP项目，对于支持人员的前期知识储备，提前进入项目，参与项目实施，DRP软件商的知识传递，业务部门需求理解，软件实施方法等都会存在不利的影响。
所以，DRP支持小组应该是DRP项目规划的一部分，从启动DRP项目那一天起支持小组就应该开始运作，并一直小掌控了DRP项目的整个生命周期。
=================
本文首发于IT168技术频道： http://tech.it168.com。转载请注明出处。
扫一扫
3364
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
