Skip to Content
Author's profile photo Former Member

Requirement Gathering process for SAP BI/BW Implementation

To being with, this is my first web-blog written after I started handling Functional assignments in SAP BI (Business Intelligence) implementation. Would like to share with everyone, a few inputs that I gathered in beginner-journey in a Functional role. These may be tweaked upto a great extent to develop an ideal Requirement Gathering process. This blog will contain pointers that will help beginners and mid-level practicioners to perform an efficient result-oriented discussions with the client/users.

Intitial Preparation 

As a part of self-preparation, preparing and executing an agenda for ourself would surely help for requirement gathering process.

  1. Understanding the scope of BI/BW implementation from the Project Manager/Project Lead.
  2. Know the team/people involved. This may include: BI/BW Team (members and their roles), Client Project Team (members, functional area expertise, etc.), and team hierarchy.
  3. Areas to be a part of the BI/BW implementation as per the project scope (Eg. MM, PP, SD, etc.).

Requirement Gathering Discussion


To prepare before the actual discussion, a broad list of the business processes involved for the requirement can be noted. For example, for a requirement gathering discussion on Material Management (MM) reports, business processes involved may be Request for Quotation, Approve Quotation, Purchase requisition, Purchase order, Goods receipt, Payment.

An internal discussion with the BI/BW Functional team is useful to brain storm key points that can be discussed with the client.

Client Discussion
  1. The discussion can begin with a short brief about the capabilities of BI/BW possibly with a relevant example (related to the requirement).
  2. Understand the client’s current business process (as-is) in regards to the requirement.
  3. Discuss about the information flow across/with-in modules. This will help us evaluate dependencies, if any.
  4. Understand and suggest how the reporting requirement can be useful in analysis (purpose), resulting into improved decision making and business value.
  5. Some important highlights of the discussion should be:

– Process refinement needed (if any) to achieve the requirement

– Key Performance Indicators (KPIs) and their definition

– Data/information availability, frequency of reports

– Report layout

– Assumptions, business rules (if any)

– Degree of flexibility required (for changing requirements/business processes)

– Challenges to implement single reporting solution across locations  

The entire discussion can be summarized into a document, which can be initiate further activities like feasibility study, deadlines, task distribution, etc.


Note: Some of the above points may be the responsibility/part of Management Consultant/Techno-Functional Consultant. Feasibility study is not taken as a part of Requirement Gathering process.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Keep updating it..
      Author's profile photo Witalij Rudnicki
      Witalij Rudnicki
      I am curious what are biggest challanges with BI Requirements Gathering based on your experience?

      Thank you,

      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Hi Vitaliy,

      Based on my experience, some of the challenges in regards to BI requirement gathering are: users generally are strictly visioned to their core 'reporting' requirements rather than 'analytical' purpose of the information, its a challenge for us to read the users mind to understand what is user's basic requirement and how can he achieve the best with respect to time & effort, end to end vision is what we need to provide to the user since user is aware of his/her functions and operations but we have an added responsibility by being aware of the solution as well, flexibilty needs to be judged to accomodate requests/changes since i hav noted that it gives clear picture to the user only once the report is developed and shown, keeping a fair distance between technicalities and business operations while discussing on specific points to the user (hence not getting confused or confusing the audience), to fairly judge the design (data model) and fit it in the user requirements....
      These are some of the challenges that I have faced....further down the line I may be put to more defining situations 🙂

      Author's profile photo Witalij Rudnicki
      Witalij Rudnicki
      Hi Kunal,

      Completly agree. "'reporting' requirements rather than 'analytical'" - well noticed!

      I am about to blog about similar.


      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Will await for ur blog... I managed to quickly scan through your blogs..will go through each in detail..
      I am thinking to write the next on something related to the next process after requirement gathering..feasibility study..
      Nice to hear from u.


      -Kunal G

      Author's profile photo Former Member
      Former Member

      These are good insights to the BW requirements. will watch out for additional ones