领会根本需求 占取优势
领会根本需求 占取优势
企业的战略意图当然要讨论，并且要认真分析。因为信息化的目标就是要为企业的战略服务的。
从文中可以看出，蓝兰集团要实现内部供应链的管理模式是主要目的，具体的需求就是集团统一接单，然后将订单分派给集团内部各子公司以及各供应商。
具体目标是建造一个统一平台，将内部供应链做透，以方便客户、业务代表检查和监督订单执行的各个环节。不知道以前蓝兰公司是怎么做的？是由各分子公司自己联系业务、相互独立经营？还是条块分割，相互牵制？客户、业务代表和公司究竟是如何对订单进行管理的？要改变过去的模式究竟应该怎么做，需要制定什么样的制度和流程，软件在这中间究竟要发挥多大的作用？
完全由业务部门来写需求分析，存在的风险在于：由于不理解软件公司所提供的专业模版的具体意思，就敷衍了事，随便对付一下交差，不能反映出实际的需求和真正的意图。同时也会对项目抱过多的幻想和期待，提出一些不切合实际的要求，目标太多以至于导致项目无法完成。
更多的业务部门往往会过于计较细微末节的东西，如报表格式、录入习惯等。还有就是对传统工作方式的坚持和固执，不愿意变革。如果严格按照这样的需求进行设计，所做成的系统极有可能还是传统工作方式的电子化，所谓的穿新鞋走老路，偏离信息化项目真正的目标。
需求分析对于软件公司来说，其意义不亚于合同的商业附加条款。既然已经明确了要进行适应性改造，南方公司李封的做法，实际上是在回避问题。
"由顾问到现场对业务部门的需求责任人(大部分是管理人员)进行"模块需求规格说明书"编写的培训，然后确定实施与开发任务。"这里面的风险不仅是业务部门对专业术语的理解偏差，更主要的是南方公司的调研提纲，完全是按照自己已经设计好的软件架构和思路来"引导消费"，有可能会出现目标的偏差，能否响应公司老总确定的目标就很难说。或许他们就根本没考虑老板的最原始需求。
当然这样做的结果是：对南方公司而言是以自己已有的软件模版和框架为蓝本，对业务部门进行培训，由业务部门来写需求分析，最终双方签字画押进行确认，以此来引导、引诱乃至绑架最终用户的需求。这样可以使得将来的系统不至于陷入无休止的需求变更和二次开发的泥潭里，项目的最终目标相对明确，以利于最终能顺利脱身。
比较合理的做法是，企业的信息中心要真正发挥出主导作用。要和老板多交流，认真分析和领会老板的意图，因为这才是最终的目标、最根本的需求。要对软件公司所提供的软件解决方案进行分析，看到底能符合到什么程度，有多少问题能够解决，还有多少根本做不到。
如果和目标偏离的太多就不要搞什么需求分析了，干脆再换一家公司来做。如果偏差不大，绝大部分功能都能实现，则坐下来和软件公司的实施顾问一起研究，进行系统的模拟运行和推演，在确认可行的情况下，拿出具体的实施方案来给老板汇报，交给业务部门讨论。
基本原则就是确保最终目标不变，并尽可能照顾到业务部门的操作习惯等需求，以此来确认最终的实施和开发内容。只有这样做，系统才能达到预期的目标。
基本原则就是确保最终目标不变，并尽可能照顾到业务部门的操作习惯等需求。
网友评论