2．企业规模及组织架构
要做DRP系统支持小组的人员配置之前，首先应该对企业的状况有一个深入了解，我们应该先去了解企业的如下信息：
n 企业现有的组织架构及DRP系统的覆盖部门：在这里可以用一个组织架构图来表示，了解这方面的信息是想让IT经理或企业高层清楚地认识到，DRP系统应用的好坏是直接影响这些业务部门的工作效率的，而如果这些核心业务部门的工作效率受到影响，公司的经营就不可避免地会受到影响，从而加强公司高层对DRP系统重要性的认识；
n DRP系统在企业内部的节点数，最近6个月的节点增长数：了解这个问题主要是为了做人员配置时，要考虑到人员招聘与培训是要有一定的周期的，而培训一个合格的支持人员，应该需要至少两个月时间，如现在已经有了100个节点，是由1名支持人员来维护，那么，当你未来6个月会增加到300个节点的时候，你就要考虑在什么时间向公司提出增加人员配置的申请合适，使得公司不会因为提前招聘而员工的工作量不足，又不会出现因为人员没有到位而终端的服务请求频繁得不到及时响应，导致IT部门的服务质量下降的问题了。
n IT部门现有的人员配置情况，包括有DRP运维经验的员工数；由于DRP系统的运营与维护是一项较为细致且复杂的工作，因此，如果你现有的员工比较有经验，那么接下来做相关的运维工作会容易很多，如果你的员工都是新手，那么，IT经理就要考虑是否向软件厂商申请培训支持了。
n 企业现有的分公司数量，DRP系统已经覆盖的分公司有哪些，未来6个月将要覆盖的分公司有哪些，分公司的规模有多大，IT支持人员是否有必要常驻分公司，常驻的人员将采用当地招聘、总部培训的模式，还是由总部外派？支持人员是接受IT经理的异地管理还是分公司的本地管理？
n 企业现有的代理商数量，DRP系统已经覆盖的代理商有哪些；企业现有的直营店数量，DRP系统已经覆盖的直营店有哪些；考虑上述这两个问题，也主要是评估工作量及人员的准备情况。
3．支持小组的配置参考
n 确定人员分工模式：人员分工基本上有两个思路，一是按ITIL的参考，按流程来划分，如划分为帮助台（Help Desk）、支持小组、安全小组、架构小组等，这样的划分方法可以不只是在DRP项目中使用，而是使公司的所有服务请求都在这个分工模式中得到响应；还有另一个思路是，为DRP项目专门设立DRP项目的支撑小组，从DRP项目后期维护工作的主要职责来划分，可以划分为数据组、培训组、支持组三个小组。
从目前我所接触的企业来看，人员的岗位及职责划分还是基于部门的，而没有达到流程或者是运营的层次，包括公司的考核机制也是按部门进行考核，因此，我在这里也采用了更为实际的方法就是按DRP项目的职责来划分人员分工。
人员分工可参照下图：
n 确定DRP支持小组的岗位成员：从上图可以看到，我把DRP支持小组主要分成三组：数据组，主要面对业务部门，负责DRP系统的基础配置管理，人员及权限管理，商品资料管理，数据准确性、及时性管理，业务部门数据分析需求整理及报表定制；培训组：主要针对新开专卖店（柜）的DRP系统培训，还有针对内部新员工的入职DRP系统培训，培训督导部门的督导使其能够协助在各专卖店进行DRP系统培训，DRP系统新功能的课程编制等；支持组：软件的应用疑难问题解决，设备故障、网络故障的反馈与服务，二次开发需求整理及与软件供应商的开发需求跟进，数据库定时备份等工作。同时各个小组将由不同角色的岗位成员组成，各个岗位又涉及到具体的职位描述、工作流程与绩效考核，在此由于篇幅原因，就不展开论述，只对数据管理员的职位描述进行说明如下：
a） 维护系统档案类数据：商品档案管理——商品信息维护、商品国际码生成；价格管理——公司采购价格、分销价格及零售价格维护；组织人员管理——代理商、门店、供应商、制造商及人员等的维护；权限管理：对岗位人员及各代理商合理控制、分配权限；
b） 管理ERP软件资源：系统独立门店、脱机门店的控制；门店实施情况整理；软件使用授权号的索取、发放；软件站点使用信息的登记；
c） 核对月底公司及办事处的数据：核对系统是否存在异常数据；为核对好的机构做成本核算、结转；
d） 解决业务部门ERP系统使用问题：软件功能操作指导；错误单据处理；协助收集ERP使用的意见及建议；
e） 处理本部门内需要在ERP中操作的各类事务：协助与ERP相关设备的采购、发货及收货跟踪；
f） IT服务台的相关职责：接受客户的服务请求（电话、邮件、传真）；记录并跟踪事故和客户的意见；及时通知客户其请求的当前状态和最新进展；初步评估客户的请求，尽力解决或者将其安排给有关人员解决；对客户请求从提出直至验证和终止的整个过程进行管理；协调二线支持人员和第三方支持小组；提供管理方面的信息和建议以改进服务绩效。
n 确定DRP支持小组的人数：从上图来看，DRP项目支持小组的人员配置会比较多，其实这只是进行细分之后的一个岗位配备，由于很多企业的DRP支持小组可能只是一个人，那么就没有分工的说法，一个人全部包揽下来；可以根据具体的企业规模，企业发展规划，DRP系统的应用深度，DRP支持小组配备计划来确定人数。而在此之前讨论的DRP项目经验的IT人员此时就可以成为支持小组的骨干人员，可以充分利用他们的经验，让他们有机会去带领新员工一起开展工作，达到“以老带新”形成IT人员的梯队。
4．支持小组在DRP项目的切入
DRP项目在最早的规划阶段，就可以将DRP支持小组的配置引进来，在做项目规划的时候，就需要将前面讨论的几个方面作为规划的一部分，这样的话，不至于在DRP项目实施结束之后，IT主管再向公司领导提出因为DRP系统项目上线，需要增加人手来进行管理与维护，使公司领导觉得DRP系统的人力资源投入会过大。
有的IT主管，因为担心如果将支持小组的配置做到前期规划中，公司高层会觉得DRP项目成本过高，而导致项目无法上线。其实这个担心的理由是存在的，特别是在公司规模不是太大的企业，公司高层对于DRP系统还停留在买一个软件，而并没有一个整体的概念，这个时候如果IT主管不做一些引导，那系统到了运维阶段，能够用到什么样的程度还真的是难说了。
还有一个重要的问题是：如果不在规划阶段做好支持小组的配置，那么在支持小组人员没有到位的情况下启动DRP项目，对于支持人员的前期知识储备、提前进入项目、参与项目实施、DRP软件商的知识传递、业务部门需求理解、软件实施方法等都会存在不利的影响。
所以，DRP支持小组应该是DRP项目规划的一部分，从启动DRP项目那一天起支持小组就应该开始运作，并一直掌控DRP项目的整个生命周期。
