固定系统需求收集起来可能有一箩筐。现在项目管理员需要考虑的是，这些都需要或者能够实现吗？如果能的话，该按什么样的顺序来执行呢？如果将他们一次性拿到桌面上进行部署的话，基本上是不可能的任务。毕竟用户的精力有限。为此项目管理员需要合理确定需求实现的顺序。在考虑需求实现顺序时，不能够盲目求进，也不能够在一棵树上吊死，对此笔者有如下的建议：

　　一、对需求进行分类

　　在实际工作中，笔者一般都会将用户的需求进行分类。如下图所示，笔者会按两个角度对需求进行归类，分别按难度与影响程度进行区分。如根据难度可以将需求分为容易实现和实现起来比较困难两个级别。而根据影响程度可以将需求分为影响大和影响小两类。

　　在具体进行分类时，可以在整理好的需求前面标上序号。然后根据企业的实际情况，将序号依次填入到上面这个表格中。注意在做这份工作时，项目实施顾问不能够闭门造车，而应该充分征询企业用户的意见。对于一些管理比较到位的企业，笔者是将这项工作交给企业内部的项目管理员的。他能够安排足够的时间跟企业各个部门的关键用户确认这方面的信息。只有得到用户的认可，再考虑系统的实际情况，得出来的结果才是比较可靠的。

　　二、要将容易实现并且对用户影响比较大的需求排在前面

　　在具体需求实现过程中，在同等条件下，需要将容易实现并且对用户影戏那个比较大的需求排在前面。这主要还是考虑到用户的一个接受程度。用户对固定资产管理系统系统有一个从潜到深的认识过程。为此让用户接受这个系统时，如果一开始就设置了一个拦路虎，将一个比较困难的需求放在他们面前。经过了半个月还不能够完成。这对用户来说是一个致命的打击。这会在很大程度上影响系统后续的工作。其实在日常生活中，大家都有这方面的感受。如以前在学校里参加中考或者高考的时候，出卷老师在安排题目时都会根据难易的程度来考虑出题的顺序。一般每种题型的前面几道题目都是比较简单的。而最后一道题目有一定的难度。如果出题老师讲最难的题目都放在开头。考生在第一道题目就卡住。那么有不少的考生由于心理素质不过关，会影响后续的正常发挥。故在考虑需求实现的顺序时，先将容易实现的内容放在前面，笔者认为更加的合理。

　　其次在考虑需求的实现顺序时，也要同时考虑需求对用户的影响程度。其实这也是一个比较浅显的道理。做一个不怎么恰当的比喻。驯兽师在教动物某个技巧的时候，往往会使用大棒加金钱的政策。当动物完成一个具体的动作时，会马上给他们东西吃。依此来强化动物的习惯。其实在实施固定资产管理系统项目时，这种规律在无形中也会得到体现。固定资产管理系统项目会增加员工的工作量。项目实施顾问在教员工怎么使用系统、要准备哪些资料、要做哪些改变，其实就好像是在教动物某个操作。如果只是让他们做，而没有给他们东西吃，怎么能够让他们配合你呢?此时固定资产管理系统的效果就是他们的食物。如果在刚开始完成某项工作时，效果就能够在第一时间内显现出来，而且对用户的影响比较大。如现在有一个客户销售订单毛利率分析的需求。这个需求由于涉及到多个部门，影响的用户数量比较多。从实现的角度讲，只要基础数据具备了，这只是一个数据的分析作业，难度也不是很大。在这种情况下，明显可以将这个需求放在前面实现。在项目一开始就让用户尝尝甜头，这会降低项目后续的工作难度。

　　也许有人会说，这种挑软柿子吃的策略，是在逃避责任。笔者并不这么认为。一方面，有时候硬的柿子放着放着就会变软。这是什么意思呢?在固定资产管理系统实施过程中，一些不怎么容易实现的需求往往是一些综合性的需求，需要多个部门配合才能够实现。此时随着后续固定资产管理系统系统使用的深入，这些刚开始难以实现的需求，到时候就会顺利成章的实现。而有些需求则是需要管理手段的改善才能够实现。这更加需要时间，不能够在短时期内实现。所以我们这里并不是放弃硬的柿子。而是提供必要的条件，让硬柿子变软，等软了再吃。其次企业是一个追求效益与利润的组织。在考虑问题时需要关注投入与产出的比率。如果投入大量的时间与精力，去实现一个影响比较小、难度又超大的需求。虽然攻克这个难题，项目管理员可能比较有成就感(这是很多技术出生的人的通病)。但是从投入产品比的角度看，这是一个失败的任务。应为投入过多，而没有得到相应的产出。即属于一笔亏本的买卖。此时无论对于企业来说，还是对于实施顾问来说，这都是得不偿失的。为此在上面这个图形中，笔者将难以实现的、同时影响又比较小的，放在最后的位置。

　　三、根据项目的规模可以对需求进行细化

　　如果固定资产管理系统项目的规模比较大，如涉及到集团型或者项目集成的业务，那么可以对以上的图表进行进一步细化，以实现对需求的精细化管理。如可以将难度分为简单、中等、困难、暂时不考虑等几个类别。同时可以将影响成果，也分为大、中、小等三个级别。具体要划分为多个档次，主要是根据需求的个数来说的。如笔者在实际项目中，如果需求的个数少于100个，那么使用两个级别基本上可以满足了。如果需求个数超过100、少于300，那么可以再增加一个级别，以此类推。

　　同时在项目实施过程中，需要注意，即要遵守这个图表，也要有所变化。如在项目推进过程中，关键用户往往会临时提出一些需求。这些需求是否要放到这个图表中呢?笔者的意见是，能不放则不妨。这就好像我们做一个生产计划。当遇到需要插单生产时，如果插一单不会对整体的生产计划产生很大的影响，如只需要晚上加加班就可以完成的，那么可以考虑加进去。但是如果一插单，会造成连锁反应，即后面的生产计划都无法按时完成。在这种情况下，插单对于企业来说是得不偿失的。将用户的临时性需求加入到这个图表中也是不合理的。为此在项目实施过程中，无论是项目管理员还是实施顾问都会受到来自用户个方面的压力。此时企业项目组应该挺住压力，严格按照这个表格确定的顺序来进行。如果开了口子的话，那么就会有第二个、第三个特殊情况的产生。

　　为了避免用户随意调整实施的顺序，这个图表在整理完成之后，最好能够让各个部门的关键用户进行签字确认。笔者负责的客户中，有不少企业在这方面做的非常的不错。如有些企业在笔者的建议下，会将这份表格制作成一个看板，挂在会议室上。完成一个需求，就将这个需求划掉。如此的话，很少会有跳步骤实施的情况。如果需要临时调整或者插入需求，需要整个项目小组的确认。同时将需求在看板的下面标示出来，跟其他需求进行区分。