Excited to listen SAPmasterminds Blogs!

Your success depends on choosing the right masterminds group and here we make you enhance your perception of SAP in rapidly fast growing business world.Take action today 

How SAP Works – How to write a Business change request document


The day has come. Both patience and Gautham's persistence took him from solution consultant to a business process expert. Now he will no more manage the solutions but he will be demanding solutions from his team. Gautham's hard work and customer handling was key to his success with his recent promotion as SAP business process expert .

But he was worried. He know only how to write a good functional specification document all these days.

As expected he received a call from one of a plant. It will be for requirement collection and he needs to prepare a Business change request document.

He panicked... He knows if he miss any one business requirement uncovered he would be responsible directly ..

Even there is a ART in getting the work done..

He left a voice message to SAPmasterminds to quickly highlight him on how to write a elegant change request document?

Welcome to another session .. On how SAP works..

Today we will see a critical learning over where experienced SAP consultant may or are facing.

How to write a good Change request document.

There is a system for writing a Change request document. As a Business owner we need to see how to draft a change request document which will help functional design consultants to easily grasp the requirement. Mostly if the change requests are easy like change request for performing some customization in SPRO , there should not be any worry but suppose if the requirement is critical and tough to be explained with complex scenario's then there should be a system to define all the expected changes.

Below are the 5 important understanding expected from a change request owner. But before understanding that lets understand who does what- a responsibility chart. In case a person learning SAP would like to understand who does what,

They are ...

"Business Owner from Industry in which SAP is getting implemented"

  • Responsible to write the business change request document.
  • Test [2nd level] the submitted solutions and responsible to close the change request document

"SAP consultant from Partner who is responsible to implement SAP"

  • Responsible to design Functional specification document
  • Also performs the 1st level test before submitted to Change request owner

"Plant owners/User from Plant who raised the requirement to Change request owner"

  • Performs the 3rd level testing
  • Confirms the solution is as per expectation

These are not a defined method but in most of the industry the above methodology still works.

Now let us see few disadvantages if a poor draft is given to functional owner who will design the requirement

  • The change request could lead to confusion and eventually the solution could not be designed
  • If the change request lacks clarity the functional owner may design an undesired solution
  • Wastage of time- Mostly there will be many meetings to understand the unclear change request document

Below are the 3 important points that any change request owner should keep in mind before he decides to draft a document.

  • Am I clear with requirement?
    • If yes enter the detailed requirement and send the copy to the plant user to cross validate it.
  • Did I covered all the requirements?
    • It’s not easy once the change request document is quoted and the work is started.
    • If missed to update the requirement in full scope there would be a possibility to amend the change request but for which the solution designers would again charge you.
  • Does this requirement is important in place to be done or do we have any workaround to solve this problem
    • It’s always good to find a simple solution before it becomes a mandatory change in need
    • We need to discuss the requirement to other modules to see if this requirement is covered in their domain. If yes we don't have to repeat the same work again.

Now let’s see how to draft a better change request document

Respect the process

  • As I mentioned earlier drafting the change request document is process or a system that needs to be respected.
  • System I referred is for example how you go from numbers in a series from 1, 2, 3... 10 if you try to miss any one entry this will completely confuse or collapse the point that to be addressed as a requirement.
  • Break the complex requirement into many multiple requirement. Address one by one.
  • Remember this is not a functional design document but a change request document, here we don't need to mention any technical points, table names, or BAPI or BADI that needs to be used unless the you are allowing as a hint to make him use that.
  • First write the mission statement that you are looking to achieve. For example this Change request document is to develop a report for production team to consolidate all the cost incurred during the production life cycle.

Don’t assume anything, rather request everything

  • It’s important to define how your expectations are. It’s always better to be precise and clear.
  • Though it could be a time consuming process, it will eventually save you loads of time as you don't need to deal with functional team with an unclear draft.
  • Incorporate Flow charts to explain the flow if business requirement are complex and who expect these changes. I have seen some times functional owners giving us a beautiful advice on how to manage the solution without these change.
  • Be very cautious that even if you are writing the change request document it’s also important to keep how the solution could be derived if the same document is given to you. Choose to switch the mental hats between owner and solution fixer with in you. This would help to design a better change request document.
  • Don’t forget the core rules and local rules respected in your industry. These are very mandatory. Sometime SAP would advise to perform a solution however globally the decision may have taken the solution in certain way. Which may not be in line with SAP suggestions. This is industry specific.
  • Try to send the draft version to both Plant user and solution designer and get their feedback on how they feel and get their feedback.

List all the potential test cases & expected Results

  • This point is very critical as this play a medium on understanding the requirement between requester and solution designer.
  • Define the possible test cases as much as possible and get the inputs also from plant user too. Understand how all the requirement may go wrong if any user who doesn't execute the report as per expectation.
  • This process will help functional designer of the solution to understand and design the robust solution.

List all the associated documents that a functional designers should refer

  • Functional owners should list possible other documents were he can utilize them to enhance his perception about the requirements
  • This will help to save time on speeding up to deliver the change request

Incorporate project details in change request documents

  • It’s important to provide details like
    • project name,
    • project logo,
    • heading of the change request ,
    • solution complexity ,
    • Indication for global change or local plant level change, who has requested with contact number and email information,
    • who has approved this request ,
    • When do you want this solution?
    • What kind of change is expected , to develop a report,


Excited to see the road map and considerations from SAPmasterminds Gautham designed an all-purpose Change request template and captured the business requirements fully. His manager was happy find him as a worthy resource.

Click Here to Leave a Comment Below 0 comments