Microsoft Dynamics vendors provide comparisons and opinions to professionals in the ERP/Accounting software selection process

 
 

ArcherPoint LLC

Five Things a Business Analyst Is (and Isn’t) in an ERP Project


Email | Print

Any good project manager will tell you that a successful ERP project begins with good business analysis.  However, there is a wide range of opinions of what, exactly, a “business analyst” does. This is not surprising, since there has not been a standardized definition of business analysis until relatively recently.

The International Institute of Business Analysis (IIBA) was founded in 2003 to “develop and maintain standards for the practice of business analysis and for the certification of its practitioners”. According to the IIBA, Business Analysis is “a set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization and to recommend solutions that enable the organization to achieve its goals”.

A recent job posting for a Business Analyst position read, in part, “Responsible for the analysis, design, development, implementation and communication of business solutions.” This posting certainly does not understand business analysis as stated by the IIBA.

Then what IS a business analyst?

  • The business analyst is a liaison among the stakeholders – all the stakeholders. On any given ERP project, there are multiple stakeholders and groups of stakeholders, each wanting their view represented. The Business Analyst represents the stakeholders by eliciting the requirements from each of these stakeholders and then confirming these requirements with them.
  • The business analyst is responsible for making sure there is consensus among the key stakeholders concerning the scope and requirements of the project, presenting clear and accurate requirements to those stakeholders with the responsibility of approval, and then ensuring approval of the requirements is obtained.
  • The business analyst is responsible for identifying the business need for a change by performing an Enterprise Analysis. This and other business analysis deliverables are part of the project charter owned by the project manager.
  • The job of the business analyst typically starts before the project begins and finishes after the project ends. The business analyst will be part of the project preparation and will remain to validate that the project that was delivered met the needs of the client as they were stated before the project commenced.
  • The business analyst will recommend solutions based on whether that solution will meet the needs and requirements of the stakeholders. Each requirement is mapped to the solution components to guarantee that the solution is the right one for the organization.

So, what ISN’T a business analyst?

  • The business analyst does not implement a solution. Although the individual performing the job function may also be an implementer, the ROLE of a business analyst will not include implementation.
  • The business analyst does not need specific knowledge of any particular system or technology. This allows a business analyst to uncover the true business needs of an organization without coming to premature or incorrect conclusions about a stakeholder’s need.
  • The business analyst does not blindly write down requirements as they come from the senior manager. They are tasked with eliciting (sometimes better called “extracting”) requirements from all stakeholders who will have any interaction with the finished solution.
  • The business analyst is not a tester. The requirements that come from the business analyst are used by the testers to develop test cases, and the business analyst may assist in developing those test cases. But the business analyst does not run the tests.
  • The business analyst is not worried about what would be “nice to have” in a solution. They are concerned about finding out what is necessary for a solution to meet an organization’s business needs, and this demands a comprehensive plan to elicit, confirm, validate, verify, approve, and model the requirements.

An ERP implementation is a major investment of time and resources. Performing a comprehensive business analysis correctly up front will help ensure the investment is worth it.

Greg Kaupp is the CEO of ArcherPoint, LLC, a Northern California Microsoft Dynamics NAV (Navision) partner. Greg has been involved in Dynamics NAV implementations for companies throughout the U.S. since 1997.

One Response to “Five Things a Business Analyst Is (and Isn’t) in an ERP Project”

  1. Ahmed Taha says:

    Hello Dear,

    We have implemented ERP in three departments in our company i need to unedsrstand what is my role after we implemented the ERP and how can i help the department on that. please give me a detail answer.

    Ahmed Taha
    KSA: 966561983600