我们不能回避用户的真实需求.doc

我们不能回避用户的真实需求在我们做项目需求调研，甚至项目实施的整个阶段中，我们都会遇到被用户的需求变更、反复，甚至无限发散问题搞得焦头烂额的情况。我们或许采取以我方的产品或者对业务理解、积累的程度、深度去强势主导用户的需求，或许则是被动的被用户的需求牵引着鼻子，你说什么我就做什么，你说怎么做我就怎么做。这都是错误的，不理智的，都意味着不考虑项目后果，意味着在短期利益驱使下而不顾项目长远利益，忽视用户利益，甚至供应商自身利益的背叛，不是认真做事的态度，更是让项目遥遥无期的“罪魁祸首”。做项目的目的就是要在解决用户方的管理问题、改变用户方的管理手段，一定程度上提升用户方管理水平的前提下获得自身的经济利益和业务、水平、知识的积累。在这样的大前提下，我们必须要勇敢的面对项目的需求问题，要理性的去思考、分析问题，更要果断的和用户一起确定需求的广度、深度和解决的策略，正确引导项目走向成功。首先，我们应该正确对待用户的需求，充分、详尽了解用户真实的业务现状，引导用户讲出自己的全部需求，通过系统、全面的分析，正确的捕获到我们需要的潜在需求，而不应该害怕用户说出自己的真实想法，害怕需求发散。事实上，如果用户有想法闷在心里，无论合理不合理都将对项目将来的发展产生潜在的威胁，一旦哪天爆发出来，都是不理性的，也基本上对项目都是灾难性的影响。其次，我们要清楚的认识到不是所有用户需求都必须要在系统中实现的。这是我们害怕用户需求发散，也是错误强加我们的想法给用户当作需求的根源，我们就此也要和用户达成一致共识。我们和用户之间的商务或者合作关系应该明确我们需要做事的范围、目标和效果，任何模糊的“一时之快”都将给项目人员带来面对用户需求的晕头转向。我们家庭买冰箱是用来冷藏，而不会要求它有看电视的功能，我们软件也一样，上EAM就不会要求具备CBM的功能，甚至包容生产管理。事实上，即使买个冰箱，即使为了冷藏，如果制冷范围在“-3-8”或是“-3-20”，我们基本都能够接受，不会因为我们为了理想的东西要求它非得达到零下几十度的范围，以便于我们将来一个时刻用得上。我们软件的需求也是这样，有的能在我们功能中实现，有的不能够，有的能够在短期里实现，有的虽然是好的想法，但必须是我们的认识、实现水平和用户管理都达到一定阶段后才能实现，如果一味的强行实现将来某个点的用户需求，无异于要求冰箱制冷达到零下几十度的功能，不是被我们废弃掉就是会“冻裂”我们现行的管理。第三，我们常常导引用户把业务功能、系统功能错误的理解为部门职能，这不是ERP概念下的系统，这是照猫画虎、照葫芦画瓢，是眉毛胡子一把抓，是手工翻版，更象是大锅菜，是最低级信息化的做法，更是我们面对用户需求显得手足无措，不够“专家”级别的表现，这也是我们无法实现软件产品化的真正业务原因。人事管理不应该是人事部门的管理，安全生产管理不应该是安全生产部的管理，我们在实际项目中，尤其在新项目中，这样的情况很多见。事实上，一个主体业务功能是贯穿多个职能部门的，虽然有少数部门作为主要负责部门牵头，但我们在做需求的时候，一定要把眼光抬得高一点，能够让自己站在用户企业的高度，以全局的观点去理解和落实，真正找到我们每个功能所应该对应的业务点。第四，我们在项目整个阶段中要把握的真正用户需求来自于企业的高管层，他们才是真正的项目受益者，是项目的决策者，而不是企业的中层管理者，更不是业务关键用户和操作员，后两者充其量仅仅起到锦上添花的作用。而如果我们盯住后者，一味的关注细节，项目不会真正成功，也不能客观上的对用户企业的管理实现较大的经济效益。高层需求是企业的战略需求，重视高层需求，实现项目成功，必定也会带来对很多细节的关注，但关注细节，不重视高层的需求，是不能够真正实现项目成功的。在我们的思想中，企业的高层仅仅被视为商务的标志，对接的摆设，形同虚设，没有也不具备机会主导项目需求，指导项目向着成功的方向发展。第五，人认识事物是一个逐步、渐进的过程，用户和我们对需求的把握也是一样的规律。事实上，市场经济下企业的管理本身也是随着时间的推移发展变化的，这一切都决定了项目的需求也是在变化中发展着，如果失去了这种变化，相信企业本身的经营管理也就没了希望。而ERP正是在这样现代企业管理模式推进下的时代产物，这就决定了ERP的发展也是一个逐步、渐进的完善过程，决定了我们和用户之间更多不是直接、单纯的商务关系，而是一个长期合作、共同进步、发展的伙伴关系。现在的关键问题就是需要我们在这种伙伴关系中如何界定互惠互利的关系、程度，如何界定哪些是免费的合作，哪些是需要付费的合作。这个问题在此暂不展开深究，关键是从项目一开始我们双方就应该能够达成共识，不去用传统行业对待传统产品的态度来看待IT行业，看待软件产品，不能主观的用多少钱买了个冰箱那样简单的推理方式来推导和软件有关的事物。最后，面对需求的主观和客观的变化，我们需要做好需求变更控制工作，需求变更控制本身不仅是在保护我们自己的利益，也在保护项目的利益，更是保护用户的利益。事实上，用户也需要一种合理的机制去约束、规范他们自身，弥补他们自身人性的缺陷，我们也需要。而往往由于我们对项目需