论文部分内容阅读
本文关键字 信息化咨询 IT咨询 ERP监理 ERP评估
案例中王志这样的项目经理是比较负责的,遇到问题时主动争取更多的客户资料来配合项目的进展;而更有比较被动(或者说不负责任)者在项目实施过程中与客户扯皮、互相推诿责任。
作为IT 服务商(也有叫系统集成商、实施厂商等,这里不再细分)针对案例里的这些问题应该怎么想、怎么做才能提出较好的解决方案?下面仅谈一些个人的观点:
甲方?乙方? 其实是一家人。
IT 服务商与客户合作,以甲乙方的身份签订商务合同,虽然各有利益责权,但“项目做得好大家一起笑,项目做不好大家一起哭”,双方可以建立基于项目的整体理解和全局观念,争取有效而统一的管理。
先从项目资源计划开始
到底怎样做才能将双方的有限资源有效整合呢? ERP 是企业资源计划,那么我们自己在做事情的时候是不是也应该先做好项目的资源计划呢?文章中提到“公司要党政学习、制造部要放假、业务要运作、外派业务人员调回困难”等现实问题影响到了项目的进展,而这些无非是资源计划不到位而导致的问题。
首先项目资源应该包括参与项目的所有人、财、物、时间以及可以利用的一切直接、间接的资源。这些资源(不论是甲方的、乙方的)都必须由项目资源管理小组统一管理、统一安排,然后再根据各自的分工分割为项目实施小组、关键用户小组,如图所示:
其次,项目资源管理小组应该从企业实际运作的需要和项目实施的需要双方面来统一管理。文章中提到的“公司要党政学习、制造部要放假、业务要运作、外派业务人员调回困难”等,这些都不属于突发事件的紧急对应,甲方的管理人员应该提前甚至很久以前就知道了,但是由于没有通过项目资源管理小组的统一管理和信息共享,导致在乙方的项目实施计划中并没有这些安排。结果是甲方必须在保证业务正常运作的情况下调整资源,加班加点来尽可能配合乙方的工作计划。因此,不妨试试在项目之初就把所有的资源,不分甲方乙方,放在一张表上进行统一管理,相信可以在很大程度上规避这类问题。最后,对于资源计划中发生的变化,如:请假、人事变动、组织学习等都必须经过项目资源小组的审批,同时伴随着进行资源计划的统一调整和正规的变更管理,才能保证项目可以有序、高效率地进行。
尽量把系统测试放在设计阶段
不仅是对乙方,对甲方更想谈一下这个问题:都到系统测试阶段了,大家居然都不知道做出来的系统是不是能够“走得通、走的对” ——大家就不害怕么?“甲方的压迫(时间、成本)、乙方的无奈、软件坟场上的悲哀”,几乎所有的项目都是这副德行。为什么呢?个人认为是前期设计工作和中后期变更管理没做到位。
说到设计工作,大多数人想到的是系统需求设计书、概要设计书、详细设计书等等,但是这些都只是为了说明系统要做什么。其实设计工作中还有一项非常重要的事情,就是要说清楚系统最终做成什么样子;也就是在做各种设计书的同时,应该同步做出对应的测试计划书。测试计划书中应该列举出明确的数据和实例用以论证对应的设计书的正确性。关键用户论证设计是否正确不应该只看设计书,还应该用设计书结合测试计划书来进行系统正确性的论证,之后才能进行系统的开发、改造、环境准备等工作。
有的朋友会说:“前期准备再充分也都是无用功,客户在中后期会不停地变动需求啊”。没错,这属于变更管理的范畴。每次客户需求的变动首先应该进行变更的申请,经过项目资源管理小组进行讨论,判明该不该变以及轻重缓急之后,放在变更计划中分步实施;同时必须保证变更的可追溯性。不言而喻,这个过程也可以让甲方清楚地了解到变更给项目实施过程带来的风险和增加的成本。
最后要提醒朋友们注意的是进行变更处理的时候一定要保证需求、设计、测试、系统、手册和环境等的版本统一。需求的变更经常是牵一发动全身的事情,因此必须要通过项目资源管理小组进行统一的管理。
案例中王志这样的项目经理是比较负责的,遇到问题时主动争取更多的客户资料来配合项目的进展;而更有比较被动(或者说不负责任)者在项目实施过程中与客户扯皮、互相推诿责任。
作为IT 服务商(也有叫系统集成商、实施厂商等,这里不再细分)针对案例里的这些问题应该怎么想、怎么做才能提出较好的解决方案?下面仅谈一些个人的观点:
甲方?乙方? 其实是一家人。
IT 服务商与客户合作,以甲乙方的身份签订商务合同,虽然各有利益责权,但“项目做得好大家一起笑,项目做不好大家一起哭”,双方可以建立基于项目的整体理解和全局观念,争取有效而统一的管理。
先从项目资源计划开始
到底怎样做才能将双方的有限资源有效整合呢? ERP 是企业资源计划,那么我们自己在做事情的时候是不是也应该先做好项目的资源计划呢?文章中提到“公司要党政学习、制造部要放假、业务要运作、外派业务人员调回困难”等现实问题影响到了项目的进展,而这些无非是资源计划不到位而导致的问题。
首先项目资源应该包括参与项目的所有人、财、物、时间以及可以利用的一切直接、间接的资源。这些资源(不论是甲方的、乙方的)都必须由项目资源管理小组统一管理、统一安排,然后再根据各自的分工分割为项目实施小组、关键用户小组,如图所示:
其次,项目资源管理小组应该从企业实际运作的需要和项目实施的需要双方面来统一管理。文章中提到的“公司要党政学习、制造部要放假、业务要运作、外派业务人员调回困难”等,这些都不属于突发事件的紧急对应,甲方的管理人员应该提前甚至很久以前就知道了,但是由于没有通过项目资源管理小组的统一管理和信息共享,导致在乙方的项目实施计划中并没有这些安排。结果是甲方必须在保证业务正常运作的情况下调整资源,加班加点来尽可能配合乙方的工作计划。因此,不妨试试在项目之初就把所有的资源,不分甲方乙方,放在一张表上进行统一管理,相信可以在很大程度上规避这类问题。最后,对于资源计划中发生的变化,如:请假、人事变动、组织学习等都必须经过项目资源小组的审批,同时伴随着进行资源计划的统一调整和正规的变更管理,才能保证项目可以有序、高效率地进行。
尽量把系统测试放在设计阶段
不仅是对乙方,对甲方更想谈一下这个问题:都到系统测试阶段了,大家居然都不知道做出来的系统是不是能够“走得通、走的对” ——大家就不害怕么?“甲方的压迫(时间、成本)、乙方的无奈、软件坟场上的悲哀”,几乎所有的项目都是这副德行。为什么呢?个人认为是前期设计工作和中后期变更管理没做到位。
说到设计工作,大多数人想到的是系统需求设计书、概要设计书、详细设计书等等,但是这些都只是为了说明系统要做什么。其实设计工作中还有一项非常重要的事情,就是要说清楚系统最终做成什么样子;也就是在做各种设计书的同时,应该同步做出对应的测试计划书。测试计划书中应该列举出明确的数据和实例用以论证对应的设计书的正确性。关键用户论证设计是否正确不应该只看设计书,还应该用设计书结合测试计划书来进行系统正确性的论证,之后才能进行系统的开发、改造、环境准备等工作。
有的朋友会说:“前期准备再充分也都是无用功,客户在中后期会不停地变动需求啊”。没错,这属于变更管理的范畴。每次客户需求的变动首先应该进行变更的申请,经过项目资源管理小组进行讨论,判明该不该变以及轻重缓急之后,放在变更计划中分步实施;同时必须保证变更的可追溯性。不言而喻,这个过程也可以让甲方清楚地了解到变更给项目实施过程带来的风险和增加的成本。
最后要提醒朋友们注意的是进行变更处理的时候一定要保证需求、设计、测试、系统、手册和环境等的版本统一。需求的变更经常是牵一发动全身的事情,因此必须要通过项目资源管理小组进行统一的管理。