Skip to Content
Product Information

Why Scenario/Versions Important in SAP IBP

Many consultants are confused with scenarios and versions. But there is a big difference between scenario and version.


Why the scenario/version planning so important in IBP planning….

  1. What if you could make changes to your model and save them independently for subsequent analysis and comparison against the base case without affecting the work of others or the base case itself?
  2. That’s exactly what scenarios and versions let you do: perform structured and ad hoc changes to the model, saving as desired to evaluate alternatives. How did we wind up with two options? Simple—due to valid business reasons and strong input from early customers.
  3. When SAP IBP was first released, only versions were available. Although they address the basic need to perform and save what-if analyses, versions were considered restrictive, because a version had to be initialized from another version before it could be used and it had to have been created in the configuration UI to be available. As a result, versions are most useful for enabling structured tasks within a planning cadence and providing the opportunity for formal approval before promotion to the baseline or another version.
  4. However, customer requests and a legitimate need for more flexible what-ifs prompted the inclusion of scenarios. Like versions, scenarios are accessed from the command ribbon. The difference is that a scenario may be created on the fly by any user whose role has appropriate permissions.
  5. A scenario is created by selecting Create Scenario instead of Save after running unconstrained planning (or another planning operator) to recalculate the model. As the scenario is created, the active view is also modified to reflect that the scenario is being shown.

Difference between Scenario/Version



Best Regards,

You must be Logged on to comment or reply to a post.
  • Hi Lingiah,


    \Will the master and key figure data be saved for a scenrio in the ibp cloud data base, as in the versions and also the below shine through method.




    Change Method
    Customers copy data between versions. As a result, a version is based on a copy (or an overlay of multiple copies) and not on a collection of deltas. Changes to the base version (or to another version that you copied from) do not automatically “shine through” in the target version of the copy.
    The system keeps track of all changes to key-figure values as delta records inside the scenario. If, at the same time, changes are made in the base version, these are visible in the scenarios, unless there are conflicting scenario deltas, in which case those take precedence. This change method could be thought of as “shine-through” logic.