ERP软件需求启发期间应遵循的最佳实践

ERP软件需求启发期间应遵循的最佳实践

“您将成为该项目的现场顾问”是一些人珍惜而其他人不愿听到的话。但是，对于业务分析师而言，不可避免地早晚会出现这种机会。公认的事实是，如今，业务分析师的角色已经多样化，其中包括创建文档，促进会议，批准计划，开发流程，建立客户关系甚至为团队共进午餐等活动。

但是，尽管责任增加了，但困扰ERP实施的内在问题仍然存在。主要实现所需的稳定时间是一个问题。在此期间，被记录为“计划”的流程开始形成，导致不熟悉和工作质量出现问题。人们常常声称业务绩效会下降，因为系统无法按预期运行。客户感到沮丧的迹象开始蔓延，客户认为解决方案无法按预期工作。尽管通常的罪魁祸首是在正确的时间缺乏深入的用户培训，但通常的根本原因可能是部分了解用户需求的失败或疏忽。那么如何避免这种情况呢？

自然，要做的第一件事就是为自己提供所有可用于需求激发的工具。惯常做法是准备调查表，安排客户访谈，集思广益会议，收集有关类似项目的信息。但是，看看一些可能被忽略的其他技术会增加价值：

仔细阅读建议书（RFP）：这是一个文档，通常乍一看就被忽略了。虽然它可能无法立即详细说明客户的需求，但从长远来看，它可以将其与应用程序进行比较以确定客户需求的趋势。仔细阅读合同或工作说明书（SOW）：不可避免地会与客户签订一份合同，其中包含广泛的条款，条款和条件以及描述应提供的功能和特性的工作说明书。 。尽管不能轻易将其理解为需求，但可以将其用于定义开发范围必须位于的边界。与离岸团队/其他项目团队进行集思广益或JAD会议：许多项目的需求是“发现”而不是“发现”的。根据工作说明书陈述明显的挑战和潜在问题，并邀请讨论进行。鼓励小组提出有关解决方案的想法会导致大量以前使用过的想法。尽管并非所有方法都可行，但它可以提示您先放弃哪些要求以适应您的预算。了解客户代表/主要用户的角色：提名的主用户通常是主管或不直接参与日常活动的人员（他们应该有时间。。！）。因此，人们倾向于根据他们所知道的或认为自己知道的知识来指定要求。而不是实际的业务需求。尽管没有错，但重要的是，要与从事实践工作的人员独立地获得不同的观点。参观实际的工作场所并跟随用户进行日常工作：虽然这似乎不是一个好主意，但它是一种有用的技术，可以验证正在遵循的当前流程，并且还可以为某些被忽略的事实提供有价值的见解。人们应该理解，人们通常很难详细地解释他们的日常生活。同时，由于业务分析师只需要对最终用户工作的特定子集感兴趣，因此应注意不要使其花费时间。提前获取并通过MPD / AMM / MOE：一定要事先从客户那里获得这些文件，并对它们进行时间表，间隔和特殊检查检查，以进行分析。这些信息构成了迁移和后续数据设置的关键。

一种好的做法是，对会议中讨论的内容进行详细的书面说明，以进行跟进。无论采用哪种方法进行启发，分析人员了解整体业务状况并关联特定项目目标如何支持或适合业务对于成功收集需求至关重要。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。