You have basic to intermediate knowledge of BPC script logic syntax and you have to troubleshoot a BPC logic issue.  By following the steps in this survival guide, you can identify the root cause for most logic issues and resolve them if they are due to known bugs.

Pre-requisites:

1. Basic knowledge of BPC logic syntax.  The following are the online help for Logic Keyword References and syntax

BPC 10.1 classic

BPC 10

BPC 7.5

1. Knowledge of UJKT.  UJKT is a BW transaction code that invokes an ABAP program through SAPGUI for testing BPC logic script.  UJKT will show you more detailed diagnostics and you can verify if your script is working correctly.
   • For more details see UJKT user guide
2. Access to an exact copy of the BPC environment/model where the logic is not working as expected.  This is required to run tests and to simplify the problem logic script. If you do not have an exact copy create a copy using BPC Administration functions.
3. The following steps should followed in the prescribed order.

Identify the problem with the following questions: The questions can be roughly divided as What, When and How

WHAT

1. What version of BPC and NW are in use?
2. What type of logic is executing? (Script logic or business rule)
3. Is the logic producing a specific error? If yes,
   1. Review and analyze the error in the logs or system dump
   2. Look for any existing notes and KBA for the error
4. Is the logic completing successfully but producing incorrect results?
5. Is the problem data dependent, e.g. happens only to a specific date or account?  If yes,
6. Is there anything special about the data region that is not producing correct results? For example, is it the start of a calendar year, or a specific base node that was recently added or moved (master data modification)?
7. Does the problem happen in all systems, DEV, QA, and production? If the problem does not happen in all systems then what are the differences between the systems.  Be Specific about
   1. Notes applied, SP version difference for BPC and BW,
   2. Transaction and master data differences, especially if the problem is data dependent

WHEN

1. When did the problem start
   1. Has the logic ever completed successfully for the problem data region?
   2. When was the last time the logic completed correctly?
   3. What has changed since it last worked as expected? If you don’t know the exact answers then establish a probable scenario by following questions
2. How often and when do you execute the logic?
3. When was the last time the logic validated correctly, was your system on the same version?
4. Who executes the logic
5. What is the usual process or the data region for executing the logic
6. Does the problem happen, every time the logic is executed?
7. If random when does it seem to happen most often?  Does it seem to happen after a recent master or transaction data modification?
8. How often does master data change and what changed in the last modification?

HOW

1. Steps to reproduce
   1. How is the problem logic invoked, is it through DM package or is it executed as default logic when sending data
   2. If the problem logic is the default logic, can be executed when sending data or through a DM package, are the results the same both ways?
2. Does the logic produce the same behavior when executed through UJKT?

Trouble Shooting Steps

1. Use a simplified version of the logic, it needs to be a single block of statements with one simplified *REC statement.  There are two ways that a logic script can have many blocks.
   1. The logic has multiple *WHEN/ENDWHEN, *RUNALLOCATION or *RUN_PROGRAM blocks repeated several times in one file.  Remove all but one block for testing.
   2. Logic file has several *INCLUDE statements.  Every *INCLUDE statement references a new logic file.  When you execute a logic with several included files, you are executing all the logic contained in all the included files. Find the logic within the included file that is causing the problem and test only that logic.  Simplify the logic as described in step 1.i before testing it.
2. Replace as many parameterized values (anything between %) or variables (anything between $) with hard coded values. Often the problem is due to parsing of a parameterized value.  Removing the parameters and then adding them back one by one will show which one is causing the problem
3. Use simplified test data region, either the problem data region or any data region with test data available.
   1. Reduce the data region that is tested by replacing parameterized scope statements in *XDIM_MEMBERSET with individual parent or child nodes.
   2. If the problem is occurring for a particular data region, then replace the parameters in *XDIM_MEMBERSET with only the members that are to be tested.
   3. If the problem is occurring for all data region, then use a random test date region.  Replace the parameters in *XDIM_MEMBERSET with the specific data region selected for testing.
   4. Reduce the scope by removing keywords likeunless if that is the root cause of the error.
4. Reduce the complexity of *REC statements. Remove all the nested WHEN/ENDWHEN and REC statements. Refer to Example 1 in attached file for more clarification.
5. Test the logic using UJKT, first by running in simulated mode
6. Review the error in UJKT.If you do not find any error when executing the simplified version of the logic through UJKT, add to the complexity of the original script in stages and test.
7. Review the diagnostics generated in UJKT.  Refer to example 2 in the attached document for more clarification
8. If the logic is for executing business rules, validate that the scope and context are passed correctly and then follow the guide for troubleshooting business rules, and master data configuration

Analysis of the information:

1. In most simple cases, you experience a problem after one or more of the following situations is met.  In such cases, you need to reproduce and verify the issue, using a simplified version of the logic and executing through UJKT. You can report the problem to SAP if it has not already been reported. The cases that qualify for this are:
   1. After System upgrade / migrate form a different version of BPC,
   2. After applying some notes,
   3. Changes made to master data
   4. Logic being executed for a new data region for the first time
2. If the problem is not due to any of the above conditions then you need to analyze the information further. Typically, you have development, QA and production systems.  You need to focus on two different lines of analysis when the problem happens in all systems and when it does not.
   1. The problem happens in all systems, but the same logic was working in the past few years and you don’t know exactly when the problem started,
      1. Focus on the last time the logic was validated and tested successfully in each system and confirm if you were on the same version of BPC and BW.  Sometime code bugs can remain hidden until you validate the logic. Refer to Example 3 in the attached document for further clarification
   2. The problem happens only in one system.  Analyze differences in master data and transaction data as well as system versions and configuration.
      1. Focus on differences between the problem system and working system.  Make sure to consider, notes, system upgrades, master data, transaction data
      2. If you confirm all versions and notes applied are the same across the system, then focus on master and transaction data differences.  By narrowing the scope to just one data region, as described in trouble shooting steps – items 2 and 3,  you can find and test the problem data region.
3. What if the error happens only when it is invoked a certain way?  This can be very well due to differences in the scope of the logic.  When the logic is invoked through data manager (DM) its scope is what is known as "external scope" set by the values selected through DM interface. When the logic is invoked through other methods it is subject to "internal scope" set by *XDIM_MEMBERSET.  For example default logic can be invoked by executing DM package DEFAULT_FORMULAS or when sending data through input forms.  The same default logic could have different results due to differences in the scope.  to learn more about the scope of default logic please review the SCN document.
   
   

When logic is executed through UJKT its scope can be controlled.  If the problem does not happen when executed with a simplified scope then the root cause is in the scope or the parsing of parameterized values for scope.

SAP had released a two versions for BPC 10.1; they are BPC 10.1 Classic and BPC 10.1 Embedded.

The Classic version can be considered an extension of previous versions in the BPC family, and can be used to implement both planning and consolidations solutions.

The Embedded version utilizes Integrated Planning and BPC features, and is designed for planning only. Integrated Planning (IP) is a planning tool introduced by SAP before BPC came into effect.

Let’s look some of the differences between the Classic and Embedded versions from a configuration perspective:

1. Master and transactional data objects

2. Data loads

3. Custom scripts

4. Template development

5. Security

Hello experts, I want to check if anyone has used the smartform UJW_EMAIL_DEFAULT to control the email content when work status notifications are sent to users. I know this smartform will be used to send emails when parameter APPROVALSTATUSMSG is blank in UJ0_PARAM_APP. This is achieved in the Web Client by turning on work status notification with option user-defined message and clearing all message text and only retaining a space text. The emails sent out of my test system are using this smartform.

Is there a transaction code/view available to modify table UJW_EMAIL10 and change the smartform being used? What I would like to do is to create a copy of UJW_EMAIL_DEFAULT smartform and set up UJW_EMAIL10 with this new smartform, to avoid overwriting the original UJW_EMAIL_DEFAULT.

If you want to use Dashboard on the BPC 10.1 Web on your project, you are going to love this.

You may encounter the following issue when using dashboard in BPC web.

1. Why the data displayed in the dashboard is not correct.

2. Why I changed the context member, but it seems that the member I selected in the BPC context bar is not reflected in the dashboard.

First of all, I would like share one of the KBA I found. Here, you can find some notes that you really need to implement, and something you need to be careful about, etc.

SAP KBA 2248465 - BPC dashboard issue troubleshooting guide

Besides this KBA, I really want to share today is how to use Chrome to help you troubleshoot the issue.

1. Use Chrome to open the BPC web and open the dashboard.

2. Click F12 to open Debug Tool.

3. Use select element function to point your dashboard.

4. After you click the select element button, put your mouse over the dashboard. The screen will be like below.

5. Then you will see the value in the Element tab. As you can see, the cube name is displayed there, but without context info, such as which dimension members you selected because this is the 1st time load the dashboard.(Due to your BPC 10.1 version, you may see the context info)

6. Try to change the context member, such time. Repeat the step 3 and 4. Check the value again. As you can see, besides the cube name, we can see the dimension member info as well. Here, you can know whether the context members you selected are really passed to the dashboard. (Don't forget to click the arrow to expand)

7. Well, we have known whether the context member are passed to dashboard or not. Next, let's take a look at the request sent to server by the dashboard. Is the correct MDX statement generated?. Open Network tab and click XMLA.

8. Then you will see the MDX statement. You can log on to BW and test the MDX statement by using t-code MDXTEST. (The MDX is within <Statement></Statement>.) If error happens when executing the mdx statement in BW, you may see error "The server has encountered an error" on the dashboard. By executing the MDX directly on BW, you can know why data is not correct.  Is the data generated by MDX itself already wrong or the dashboard displayed the data returned from server incorrectly?

After migrating from BPC 7.5 NW to BPC NW 10/10.1, some customers found BPC users can’t trigger BW process chain, especially when tasks to interact with BW are involved. In next sections, I’ll give more information about this change.

1. How does BPC trigger job? with which user?

In BPC 10/10.1, most data manager packages are triggered as background jobs. The program flow is like this:

The job is triggered with BPC system user,so you will find all BPC jobs are under BPC service user in SM37, as shown below:

Note: If you find BPC jobs are under specific user's name, you need to check the RFC setting and BPC global parameter RFC_DESTINATION.

2. Which user’s authorization will be checked in the background job?

The user who starts DM package in EPM Add-in will be checked. Job is created by BPC service user, but it doesn’t mean the authorization of this user is used inside the job. As the highlighted code shows: when the job is submitted, SY-UNAME is used instead of BPC Service user.

In BPC 7.5, BPC jobs are triggered by BPC service user, and the security check inside the job is also performed on BPC Service user. So, it is unnecessary to assign BW or other authorizations to BPC users in BPC 7.5, but it is not the same case in BPC 10/10.1.

3. What’s the purpose to specify user name in UJD_TEST_PACKAGE?

As shown in below figure, we could specify User ID when running UJD_TEST_PACKAGE, so what does that mean?

Let say we have two users in this case: ADMIN and TESTBPC. ADMIN logs on BW and starts to run UJD_TEST_PACKAGE, and he inputs TESTBPC in the User ID field and starts to run the package asynchronously.

The user specified here (TESTBPC) will be checked whether he/she has the authorization to run current package. If yes, the backend job will be triggered under SY-UNAME user (ADMIN) by BPC Service user.

So the user specified in UJD_TEST_PACKAGE is only used for security check before the job triggered.

After job starts, SY-UNAME will be checked.

4. For more information about the security design in BPC NW 10/10.1 (Standard Model), please refer to following notes:

• 1613125 - Planning and Consolidation 10.0 NW Security Design & Limits
• 1613620 - Security issue when loading data from infoprovider
• 1744312 - Not able to list InfoProviders in Data Manager Package “Load Transaction Data from BW InfoProvider UI” (Process Chain /CPMB/LOAD_INFOPROV_UI”)

In BPC 10.1, two different models are supported: standard and embedded. For Embedded model, Analysis for Office (AFO) could be used as reporting tool, but the place we need to pay attention is the data security setting. As we know, there are 3 layers data security setting for BPC embedded model:

1. BW analysis authorization
2. Environment  (option)
3. Data Access Profile (DAP)

The final scope end user could access is the intersection of layer 1 and layer 3. (refer to BPC 10.1 security guide for more detailed information).

By default only the layer 1 security (BW analysis authorization) will be checked when you open a query on BPC Embedded Model in AFO.

1. How does AFO use DAP of BPC Embedded model? and What type of setting is needed?

From AFO 2.0 version, user could set the planning model in workbook. This is the method to connect the workbook with BPC Embedded Environment. Only when this connection is setup, DAP defined in BPC Embedded Model could be checked during query.

Support for different version:

2. How to check it?

You could set break-point in the highlighted place in report LRSEC_CHECKSF03 as shown below. Only when the “Planning Model” is set,  BPC authorization defined in DAP will be checked.

Starting with the release of BPC 10.1 SP06, a new enhancement in BPC Business Process Flow (BPF) allows defining deadlines for BPF activities.  In the following sections, I will describe BPF deadline in more details.  It is assumed that you are already completely familiar with BPF.

1. Overview
   • Background information - Business Process Flow (BPF)
   • What is BPF deadline
   • How to define deadlines 
2. How to Calculate Deadlines
   • General Rules for Calculation
   • Use Cases
3. How to Modify Deadline When Creating Process Instance
   • Rules for modifying deadlines
   • Use Cases
4. Action after Expiration
   • What is "Action after Expiration" and how does it work
     • When action deadline is "Wait"
     • When action after deadline is "Close Activity"
   • Use Case

• Rules governing performer and reviewer activity status when activities are completed, rejected, reopened, suspended and resumed
• Use Case

1- Overview
Background information - Business Process Flow (BPF):

Business Process Flow (BPF) is a feature of BPC that can be used for organizing complex business processes into a sequence of related activities.  An activity is any BPC function that users can perform within BPC web client or Office.

You can define one or more BPF templates for your organization and within each BPF template define multiple related activities see the details. Furthermore, you can generate multiple instances of a BPF template, and for each activity assign a performer and optionally a reviewersee the details

What is BPF Deadline:

BPF deadline allows defining a time period for each activity to be completed.  It is optional and flexible and can be modified following certain rules.

The following are the general characteristics of BPF deadline

• The deadline calculation for each activity starts from the date and time a process instance is created see the details
• Each day is calculated as 24 hours from the start date and time
• Deadlines can be defined for both performer and reviewer
• Depending on how "Action after Expiration" option is defined an activity can stay open after it has passed the deadline or closed by the system.

How to Define BPF Deadline

The option for deadline is enabled when defining activities in a BPF template or during instantiation of a process. When enabled through BPF template it requires a non-zero value representing the number of days from the start of activity.

Defining BPF deadline through process template

2- How To Calculate deadlines:

In the following discussions I will refer to the information entered in the fields numbered 1 - 10

General Rules for Calculation:

A deadline is calculated by adding the number of days for all previous deadlines from 1 - N.

• Deadline for ActivityN Performer =  Deadline for Activity1 Performer + Deadline for Activity1 Reviewer +

Deadline for Activity2 Performer + Deadline for Activity2 Reviewer +

Deadline for ActivityN-1 Performer +Deadline for ActivityN-1 Reviewer

• Deadline for ActivityN Reviewer =  Deadline for ActivityN Performer + Deadline for ActivityN Reviewer
• A day is calculated as 24 hours from the time an activity is created when a process instance is created.

Deadline Calculation - Use Cases

Use Case 1

Use Case 2

3- How to Modify Deadlines When Creating Process Instances:

Deadlines can be modified during Process Instantiation

• On the last step "Set Timeline", select "Manual Start"
• Click on the Calendar Icon next to each date

The Rules for Modifying Deadline When Creating Process Instance:

• Deadline for Activity 1 performer <= Deadline for Activity 1 Reviewer <= Deadline for Activity 2 Performer

Deadline for Activity N-1 performer <= Deadline for Activity N-1 Reviewer <= Deadline for Activity N Performer

• Deadline for ActivityN Performer can be increased and it will change all subsequent deadlines accordingly
• Deadline for ActivityN Reviewer can be increased and it will change all subsequent deadlines accordingly

Modify Deadline - Use Case:

4- Action after Expiration

BPF activities can be defined with"Action after Expiration" either as "Close Activity" or "Wait" for both performer and reviewer.

What is "Action after Expiration" and how does it work

Use "Action after Expiration" to define what should be done with an activity that has passed its deadline.  The following are the possible outcomes.

1. "Action after Expiration" is "Close Activity" - When an activity is passed the deadline the system automatically sets the status to "Completed" and the timing for the next deadlines begins.
2. When "Action after Expiration" is "Wait" - When an activity is passed the deadline for performer - the activity will remain open with the last status while the deadline showing as expired.  The status of subsequent activities will show Pending.

The last status of an activity can be the initial status "Open - To Perform" or different depending on if any action was taken by the activity performer or reviewer

Action after Expiration - Use Case:

Use Case: Action after Expiration

Rules governing Performer and Reviewer activity status when activities are completed, rejected, reopned, suspended and resumed.

Activities can have different status depending on the actions performed by performer and reviewer. The last status of an activity for performer and reviewer will remain the same or changed automatically depending on the value of "Action after Expiration"

• The possible status for activities are:
  
  • Open  (a task is to be performed),
  • Submitted (a task has been performed submitted to be reviewed),
  • Completed (a task has been completed)
  • Rejected - (a task was rejected by reviewer, to be performed again)
  • Reopened
• When performer completes an activity, the calculation of deadline for reviewer starts
• When reviewer rejects an activity, the calculation of deadline for performer starts
• When activity is suspended the calculation of deadline is stopped and resumes after activity is resumed.

Use Case: rules governing performer and reviewer activity status:

As we are about to say good bye to FY 2015 and welcome FY 2016, I would like to    re-iterate EPM’s journey for Year 2015 and how EPM’s market share will change in future years. Based on EPM’s road map, I have I have tried to identify knowledge gap that EPM consultants will face.

2015 – Year that was

  In FY 2015, EPM space has been through a roller coaster ride. With advent of 10.1 Classic and Embedded Model, release of IBP (Simple Finance), BI-IP/PAK, SAP Clouds for Analytics and BW 7.5, EPM has come a long way. By Looking at the product timeline below, it is clearly visible that SAP has improved its release frequency throwing a lot on EPM consultants to catch up in a year.

With all these releases, SAP on one hand is addressing market demand but on the other hand, SAP is putting a lot of pressure on EPM consultants to get acquainted with. Here in this article, I call them as “Fields of Play (FOP)”.

Consultants needs to spend time learning these new FOP even if the requirement is not eminent. Some of them are closely related like BPC10.1, Analysis for Office, BW 7.5 etc. but there are others like Fiori, Predictive Analytics which are not related but may be required in near future. Similarly, EPM Addin and Analysis for office 2.1 may have some similarities but again AO is new for EPM consultants. BW 7.5 was introduced with much more advanced features including features like ADSO, Composite provider, Hadoop Integration etc.

In 2015, In addition to enhancements in Embedded BPC, SAP came up with sFIN 2.0 and IBP which opens up altogether a new avenue for EPM consultants. Since Simple Finance provides integrated business planning directly off of the same transnational database as ECC, enabling real-time planning and actual-plan comparison with drill-down to line item detail. This is probably, SAP’s biggest bet in decades. Quoting Mr. Hasso Platter "If this doesn’t work, we’re dead. Flat-out dead. It’s that simple". This makes lot of sense and one need not be Nostradamus to predict future of BPC. So what does it mean for EPM consultants? What are these new fields of play and the knowledge gap current EPM consultants have.

EPM Market Share- Current Vs Future

Let’s look at how the current EPM market is spread across. Based on some basic assumptions, I have put down EPM market share as below

Majority of SAP EPM market is concentrated around BPC classic as this is the most comprehensive product in the market addressing both planning, consolidation and reporting needs. However, market is slowly moving towards BPC 10.1 Embedded. Even though Embedded 10.1 is fairly new (Planning only), lot of traction is going on in this space. Based on current road map of SAP, BPC Embedded will have all features of BPC classic (including consolidation, business rules etc.) in FY 2016. We are already looking at some sap notes talking about the consolidation features in BPC 10.1 Embedded. SAP note 2218893and 2218894confirms this assumption. Based on these notes it looks like with next release BPC 10.1 Embedded will have basic consolidation features. This takes away the biggest disadvantage of BPC 10.1 Embedded w.r.t Classic.

Secondly, I have put IBP into early adaptors section because this where the future is. IBP has got huge potential as explained in many blogs. It’s needless to say that SAP is heavily investing in IBP and some point of time, BPC Embedded and IBP will converge.

Last, I have put Predictive analytics and BPC into innovators. A consolidated product with integrated features of predictive analytics is few years out but consultants needs to be prepared for these new technologies to have the “First Mover Advantage”. 

For years 2016-2017, the EPM market share will shift towards Embedded and sFIN 2.0 and trend will follow the same pattern going forward.

EPM Knowledge Gap

Based on predicted EPM market share, majority of EPM consultants needs to get trained in these technologies. Current knowledge gap looks as below:

Conclusion

To conclude, there are new Fields of Play that consultants needs to gain access to. With Embedded, IP, Bex, ABAP will come back into BPC design. sFIN 2.0 will force EPM consultants to get acquainted with ECC functionality to design and develop IBP solutions. This will also give opportunity to traditional ECC functional consultants to learn and implement IBP. Last, EPM consultants with knowledge of predictive, analytics will have definite edge over others. Analytics is next big thing.

Bibliography

1. http://www.businessinsider.com/sap-founder-hasso-plattner-if-this-doesnt-work-were-dead-2015-2
2. http://events.sap.com/teched-global/en/tracks?bc=5%2%0
3. https://www.asug.com/myasug

One of the most frequently asked questions from customers using BPC at the moment is which client tool is the best fit for BPC on HANA. In this article we will compare the various front-end tools that can be used in combination with SAP BPC in a simple way. We will do this by drawing a comparison between the SAP BPC Frontend tools: Analysis for Office (AO) and the EPM Add-in which both are used in Microsoft Office. We will conclude with the new SAP convergence client 2.2 which has been released inNovember 2015 and take a look  at what is to come with 2.3 in 2016.

Analysis Office vs. EPM Add-in  | It ​seemed a very easy task to list down the differences between the tools before we writing this article, but in practice it turned out to be quite a challenge to identify factors that determine the completeness of a tool. This is comparable to the discussion about  the exact distinction between Reporting and Analysis in SAP Frontend tools, and especially for Planning Applications like BPC NW, Integrated Planning and BPC on HANA 10.1. To have a clear picture of the tools, we started looking at what is shipped by default with Microsoft Office products of which everyone knows how these work, and what advanced users can do with it. We also know how powerful Excel is and how it is the tool of choice within Finance departments. Excel is of course ideal for calculations, pivot tables and focus on content rather than formatting/presentation and data integration. Major missing element of Excel is the ability to easily connect to SAP systems where all actual data is stored. For example, Excel doesn’t hold any integration with actuals versus plan data, making it very difficult to  have one centralized version (one version of the truth) and performance can be a problem if you have complex calculations of data retrievals.

Analysis for Office| What make Analysis for Office different from EPM Add-in?In the first place, AO requires a BusinessObjects Platform(if you want to deploy your reports on BO server) and EPM is a standalone client tool (Excel add-in). It also is the successor of BEx (Web) Analyzer and can be installed as Microsoft Excel plugin or can be used as a web version(OLAP). Analysis Office is the right tool for users with extensive analysis needs. It is particularly suited to access and analyze OLAP (Online Analytical Processing) sources. It offers slice-and-dice capabilities and supports use of hierarchies, for example a cost center hierarchy. It is a tool for analysts who know the data and are looking for answers by exploring the data. The dataset is also usually built by the IT organization and is often based on the specifications of the business analyst. AO works nicely for ad-hoc analysis-type of reporting without focusing on formatting and complex calculations (e.g. VLOOKUP’s and pivoting).

Analysis for OLAP | Functionality-wise Analysis for OLAP matches  Analysis for Office with the big difference that it runs in a browser. This often has a preference from an IT perspective because the roll-out and maintenance of the tool is much easier. However, the fact that it lacks integration with Excel makes Analysis for OLAP less popular with business analysts. Analysis for OLAP doesn’t have a future in SAP’s plans. It seems to be phased out in the future.

EPM Add-in | The Enterprise Performance Management or EPM Add-in for Microsoft was released for SAP EPM’s suite as depicted below. This client tool was built to harmonize different Microsoft Office based clients used within the SAP BusinessObjects and EPM portfolio. Previous tools like Extended Analyzer (acquired from Cartesis) used for BPC 7.X and EVDRE were migrated to EPM 10.0. The EPM tool contains huge improvements with Excel integration and provides features and functions for the business users to analyze and report. One of the features of EPM is the ‘Local Members’  which can be explained as ‘dynamic referencing formulas’. This feature is integrated in Excel  and can be created in EPM by the business users without any involvement of the IT organization. This increases the user adoption  of EPM. The business users are now in the driver’s seat and are able to create their   own reports, local formulas, input on data cells and reuse the look and feel by applying the standard EPM formatting sheet. EPM is not only used for BPC but it can also be used for the entire  EPM Portfolio. For example, Financial data (BOFC) can be combined with SAP Strategy Management (SSM) by joining data from different EPM data sources into one report.

One EPM client for BPC Standard and Embedded version | EPM has been released for two types of BPC on HANA versions: BPC ‘Standard’ and ‘Embedded ’. The Standard version is like a standalone version within SAP BW and it has a Consolidation engine in it, which is used for Financial Planning & Consolidation. With Embedded version BW on HANA is integrated and Master/Transaction data can be reused without any conversion or formatting. Embedded version can’t consolidate data but it’s the best for Planning, like Budget, Supply Chain Planning, Cost/Sales/Logistic Planning etc. Both versions work  in Excel but with different connections to their data sources.

Analysis Office 2.X : Convergence of AO and EPM Add-in| In September 2015 SAP announced a new client tool for EPM and AO called Analytics Office , which includes the EPM add-in and AO in one installation. The tools are just merged technically from an installation perspective and EPM/AO can be used independently from each other: there are two separate ribbons with each their specific functionality. If you are using AO reports- you have to logon in using the AO client and if you want to switch to EPM, an additional logon is required to access the EPM reports. Once you are logged in – the refresh function works across tools and can be used for all reports which are opened in the EPM/AO sessions. We don’t see any added value to move from EPM or AO to the new converged client if you just use one of these tools. From an IT perspective it makes scripting easier only having one script to rollout both tools in one client.

Analysis Office 2.2 has been released | The new Analysis Office 2.2 has been released in November 2015  with more integration and improvements. With the AO 2.2 version, EPM SP23 was taken as a reference for the EPM part. Analysis Office has been improved with more features like formatting and prompts. But is this version now ready to be used or just for piloting? Eventually you would expect that EPM and AO are merged into one single tool. What we heard explicitly  at SAP’s Strategy sessions is that both tools will be merged into one Office Client and that would be Analysis Office. Something we should expect to be delivered in 2016 but we are eagerly anticipating a new roadmap for Analysis Office 2. 4 and further.

Latest and greatest– Analysis Office 2.3 has not been released yet but we know already that AO 2.3 is planned for June 2016. What we know about the 2.3 version is not much more than that Analysis Office can handle local calculations similar as in EPM, which would be a big improvement. This means you can have ‘local member’ formulas in rows or columns and you can apply specific formatting to it. Another feature is the ‘work statuses’ (facilitates Data information about planning cycle such as data locking or submission management)  which was not supported in the previous versions. More and more reasons to switch from EPM to Analysis Office for BPC ‘Embedded’ version.

Wrap-up | We can clearly see SAP is investing in further development and enhancements of AO while EPM only has bug fixing as a priority. This brings us to conclude that within a few years EPM is nearing the end of its product lifecycle, since the introduction in 2011.

Thank you for reading this article and we would appreciate your feedback: analytics@just-bi.nl

References:

1. Magic Quadrant for Business Intelligence and Analytics Platforms, Q1; 2015
2. Analysis Office Roadmap Webcast Notes: Apr 24, 2015
3. BA270 TechEd 2015 Presentation Slides 20-24: Hands-On, Embedded Model in SAP BPC
4. The Forrester Wave™: Enterprise Business Intelligence Platforms, Q1 2015
5. BA261 TechEd 2015 Presentation Slides 9 – 19: Analytics Clients in Microsoft Office
6. Roadmap of Analysis Office: Dec 8, 2015

Good Day All,
           I would like to share my BPC 10.0 on HANA implementation experience which we have developed the business logic via HANA objects.
Our approach has two main advantages;

1. Overall significant decrease on development time
2. Huge performance increase

           The initial phase of the project was implemented in traditional way which was developing the business logic through optimizing the ABAP codes and parallel processes to maximize the performance and decrease the runtime process of packages. The runtime process was taking too much time due to huge amount of data.

          The 2nd phase is implemented with the similar concept and additional simulation logic to calculate results based on changed assumptions, on the fly master data creation and other functional logics specific to the client’s requirement. This phase we decided to change the approach of developing the business logic and calculations by using HANA objects.
The flow illustrated as below;

Performance increased by 20 to 100+ times.

In our calculation layer which is handled on HANA, we process all calculations, security check and model update. The approach to implement in HANA is more complicated. Nevertheless, when we compare between ABAP and HANA the package runtime was significantly reduced and performance increased by 20 to 100+ times.

My first BPC on HANA implementation was in 2012. I have implemented several projects using different ways but this was my first implementation fully utilised HANA Objects. I have faced many problems, errors, memory issues, cursor performance problems but all of them are fixed by using different approach on calculation logic with very late night hours :).

I had different results while using ROW and COLUMN type tables based on my scenario as below;
Test is done with a calculation that generates and inserts 26 million records into a table.

Sometimes i received error messages due to my queries and calculations;

and during testing i found a hidden cat in my package log

The day is 09.11.2015 and for all intents and purposes, it seems to be a fairly routine and run of the mill day. But on this inconspicuous day, was the release of SAP Netweaver 7.40 SPS 13. This SPS stack release comprises many new features to the BW platform and is considered a feature release. There has been posts detailing some of the new features and product road map updates, but I find it interesting that not that many people have picked up on or commented on the new feature, EmbeddedConsolidation.

Previously, it was fairly straight forward. If you wanted to do planning or use the embedded model. You were always limited to only planning, the consolidation model was only available on the BPC standard / Classic which guided your implementation approach, but the reason for my interest and blog post is to draw some attention to this new feature and capability with SAP BW SPS 13, SAP BPC Embedded Consolidation is now possible..

Reference Links - https://scn.sap.com/docs/DOC-58721

Having been involved with an implementation of SAP BPC Embedded Model at a large Financial Institution. I have come to appreciate the performance, flexibility and power of the BPC Embedded model. (Please refer to the reference section below to get links to the various posts outlining and detailing the difference between the two model types) . Having the ability of having both a planning and consolidation application that leverage off of the power and performance of PAK, I can say that I am pretty excited about the fact that organizations can now start to harmonize there planning and consolidation environments and leverage off the power of PAK.

I do however believe that customers will have to carefully consider and understand the drivers for deciding which models to use in their implementation. It will require careful consideration especially in light of the technical requirements and skills required for the implementation of the SAP BPC Embedded models.

I do believe that having both embedded models in the same namespace as SAP BW along with the flexibility that the it provides you, is pretty powerful motivation to consider the embedded consolidation model in itself. There is a multitude of scenarios in which having the planning and consolidations cubes in the same multi / composite provider will facilitate reporting and reduce much of the problems of moving data between models. I can remember scenario's in which having to write tedious script logic to move data between the different models and conversely how incredibly easy it was to see and move data across different models in the embedded model using FOX and as a result of using Multi / Composite providers in the data model design.

In addition, the ability to call SQL in FOX or SQL Exit CR are pretty compelling reasons in itself for choosing the embedded models in solving a lot of the limitations of the classic BPC models. I look forward to seeing more features and functionality being added to the embedded model, along with hearing some of the customer success stories of the new implementations of using the embedded consolidation model.

SAP Support Product Availability Matrix

Reference Links

SAP Notes -

2240919 - Release Note for Netweaver 7.40 SPS13

https://websmp130.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/spat/index.htm?sp1=SAPKW74013

http://scn.sap.com/docs/DOC-58899

With the release of SAP BW 7.50 late last year, you will soon notice that there are no CPMBPC / HANABPC Add-ons installed with your BPC 10.1 system. This was not a mistake but rather a design choice to simplify the SAP stack. Now the CPMBPC and HANABPC Add-ons have been merged into SAP BW 7.50. Therefore, a BPC 10.1 standard model will not require any additional Add-On installations. Please note: You will still need to buy a BPC 10.1 license. See slide 4 of SAP BPC 10.1, version for SAP NetWeaver Product & Product Strategy Update for more information.

Please review the following diagram:

It is key to understand that if you are using the BPC 10.1 standard model, an SAP Note (code correction) will now reference both SAP_BW 750 as well as the BPC 10.0 / BPC 10.1 CPMBPC / HANABPC Add-On versions (800 / 801 / 810) if the code correction applies to those specific versions.

For example, the validity of this Note 2271368 - Support filtering on property with size over 255 in Script Logic applies to BPC 10.0 (CPMBPC 800 and CPMBPC 801), BPC 10.1 standard on BW 7.40 (CPMBPC 810) and now BPC 10.1 standard on BW 7.50 (SAP_BW 750).

Currently there is no service pack (SP) mapping matrix between BPC 10.1 on BW 7.50 with BPC 10.1  on BW 7.40 because their release dates are not synchronized between NW 7.50 / NW 7.40. Here are some release dates for BPC 10.1 on BW 7.50  and BPC 10.1 on NW 7.40.

*Disclaimer: Be aware that the information contained in this schedule is subject to change. SAP does not guarantee the availability of an SP Stack delivery on the specified date. The delivery frequency of a product version may change during its lifecycle.

Reference Links:

• 2252082 - BPC 10.1 on SAP_BW 7.50: When upgrading to NetWeaver 750, After Component SAP_BW is Upgraded, CPMBPC and HANABPC Removed
• SAP BW 7.50 - Update
• SAP Support Package Stack Schedule
• Concepts compared: BPC 10.1 Standard and BPC Embedded
• SAP BW 7.5 ABAP Support Packages

Please let me know if you have any questions via this blog in the comments section.

Users may want to know where to find and download BPC and it's related components, here takes BPC 10.0 for Netweaver version as an example.

Part 1: How to download BPC

1. Logon to software download center: https://support.sap.com/swdc
2. Click “Installations and Upgrades” in left hand

    3. Click “A-Z”

    4. Click “B” as BPC starts with B

    5. Select “SAP BPC FOR SAP Net Weaver”

    6. Click “SBOP PC 10.0 FOR SAP NW”

    7. Click “Installation”

Part 2: How to download BPC related components

Steps are similar, just replace step2 as below:

2. Click “Support Packages and Patches” in left hand

Then after step 6, you will find all the related components and their available support packages.

This blog will provide a snapshot of the SAP BPC Embedded – Consolidation functionality, as SAP released BPC SP09 for NetWeaver BW 7.4 and NetWeaver BW7.5SP02.  SAP BPC Embedded is also integral part of SAP Integrated Business Planning (IBP), also known as SAP IBP for S4/HANA, which integrates financial planning, Sales planning, Manufacturing planning, Procurement planning etc.

The following consolidation components and functionality are enabled in 10.1 BPC embedded:

• Consolidation
• Journals
• Ownership management
• Dimension management
• Business rules
• Task Sequence
• Controls
• BPF Integration

The Consolidation functionality in BPC Embedded is same as the consolidation functionality in BPC Standard/Classic version.  The objects need to be created in BW and will be mapped in BPC including related “models” (Consolidation, Ownership and Rates), dimensions and dimension properties.

1. Environment:   The  Embedded Shell  consists of Consolidation and planning models.

2. Administration: The consolidation features which are enabled Rules, Business Process Flows   and Journals, which is similar to  BPC Standard/Classic version.

Modeling:To modify the consolidation model, need to set the references to InfoProviders/ Relatime infoCubes that exist in SAP Business Warehouse (BW) (Rates, Ownership, and Consolidation)

Modify the Model:

Mapping of Dimensions & Member Properties with   InfoObjects & attributes:  The configuration is similar to BPC10.1 Standard/Classic version functionality for Dimension type, Hierarchy, attributes

After Mapping, save and Validate Model:

Advance Settings: IncludesIntegration Mode, Parameters, Default Trading Partner

Integration Mode

Parameters:  For Example; Mapping of Fiscal Year period in BPC to Fiscal year Variant with compounding member in BW ; K1

Default Trading Partner:Enables, to assign the default trading partner.

Dimensions:  The Configuration to edit the dimension members, Hierarchies & View structure is Similar to 10.1 Standard/Classic version.

Business Rules: The Configuration is Similar to 10.1 Standard/Classic version.

Methods & Method Based Multipliers: : Configuration is Similar to  10.1 Standard/Classic version

Business Rules: Account based calculations, Currency translation, Intercompany bookings, eliminations & Adjustments, Carry forward configuration Same as 10.1 Standard/Classic version, Based on mapping of the members of infoObjects

Task Sequence:   The new feature task sequence is added , which needs to be configured based on configuration rules, on running the Execute button in consolidation monitor which simulate  the consolidation tasks in sequence which are already configured in the business rules.

Consolidation :The Configuration is Similar to 10.1 Standard/Classic version

SAP Business Objects Planning and Consolidation (SAP Business Objects EPM portfolio) is an application dedicated to financial processes. Owned by the business and designed for the end user, it is the target environment to support planning, consolidation and financial reporting, through unique functionalities like Business Process Flow and tight Microsoft Office integration.

Security Terminology

Following needs to be set up to enable authorization restriction:

• User:

End users of the application.  BPC users require an SAP BW named account with specific access.

• Tasks:

Specific application level access right/permissions.  E.g. Manage Environments, View Environments, Manage Security, etc.

• Task Profile:

A collection of granted tasks. A Task Profile determines what type of activities or tasks a user or team can perform in BPC.

• Data Access Profile:

A collection of read, writes, or denies member access rights to each dimension of the model.

• Team:

A group of users with a common task profile and data access profile.  A team can have a team lead who have special access rights to the Team’s folder

• Environment:

It is a shell or BPC client in which all configuration and data reside. There can be more than one environment

User Authorization

User’s Authorizations is determined by the team assigned.

Team

A Teamisa group of users and fairly equivalent to a SAP NetWeaver role. Task Profiles and Member Access Profiles are assigned to a Team.  A team can contain one or more task profile and member access profile. BPC has “Admin” team by default. Following are the features of team:

• Team can be added to user to enable the access
• The Manage Security task is required to modify, create, or delete Teams
• Any team member can be identified as a Team Lead, which provides management access to the Team’s Folder

Are you currently evaluating, implementing, or running SAP Business Planning and Consolidation (BPC) but also have S/4HANA Finance in your future roadmap?  Did you know that the building blocks for SAP BPC optimized for S/4HANA Finance are pre-delivered and completely different from your existing stand-alone SAP Business Warehouse (BW) and BPC environments?  To help SAP customers who want to implement BPC but are not yet ready for S/4HANA Finance, SAP has recently released an SAP note that will allow them to prepare their current environment for a more easy migration to S/4HANA Finance in the future.

To provide some additional context for those not familiar with S/4HANA Finance, it represents the next generation of SAP ERP financial and management accounting functionality by merging all pertinent transactional and analytical information into a single-source-of-truth table known as the Universal Journal.  Using S/4HANA Finance, customers can quickly evaluate the financial implications of business decisions with real-time analytics, forecasting, and simulation capabilities via a simplified user experience.

A key enabling technology within S/4HANA Finance is SAP Business Planning and Consolidation. SAP had already more tightly integrated BPC and BW via a modeling option known as “BPC Embedded” (distinct from the prior option known as “BPC Standard”).  Both BPC Embedded and BPC Standard are for standalone deployments. In contrast, BPC optimized for S/4HANA enhances BPC Embedded within S/4HANA itself via pre-packaged application content that read S/4HANA master data and transactional actuals in real-time.

Going a step further, with the recent release of SAP Note 2243472 in November 2015, it’s now possible to use the BPC optimized for S/4HANA building blocks (metadata known as “InfoObjects”) in your standalone BPC Embedded implementation.  By applying this SAP note, the risk of boxing in your solution from future migration to S/4HANA Finance is mitigated. In order to have the SAP note independently validated and tested, SAP collaborated with TruQua Enterprises, LLC an SAP-certified consultancy and an SAP-licensed software development partner.  TruQua not only validated the SAP note in its internal systems but also at one of its customers who will soon be going live with the solution. Validation activities included feedback on the migration methodology, areas needing clarification and the results of system tests for technical accuracy that all lead to the improvement of the SAP note.

For full details on how to optimize SAP Business Planning and Consolidation for S/4HANA Finance, you can access the complete note from SAP here: http://service.sap.com/sap/support/notes/2243472. You’ll find attached a detailed step-by-step guide of how to import the new InfoObjects and how to structure your transports for a future migration.

As part of its independent testing and validation, TruQua performed the following activities within TruQloud (TruQua’s cloud-based “Try-And-Decide” offering):

1. Followed the instructions in SAP note 2243472 importing S/4HANA InfoObjects into a standalone BPC Embedded 10.1 system.
2. Built and tested a custom BPC Embedded 10.1 planning application using the imported S/4HANA InfoObjects.
3. Transported the custom planning application into an S/4HANA Finance system (leaving behind the imported S/4HANA InfoObjects) to verify that migration of custom development was possible.
4. Further modified and customized the S/4HANA InfoObjects by adding new hierarchies and master data attributes and incorporated the changes into the custom planning application.
5. Ensured master data and hierarchy consistency across the landscape referenced within the custom planning application by maintaining master data and hierarchies within a separate SAP ERP system and loading them into the relevant S/4HANA InfoObject within the standalone BPC Embedded system.  For simulation and testing purposes, the assumption was made that the SAP ERP system used for master data maintenance would eventually become the S/4HANA system via migration.
6. Manually made the corresponding changes to S/4HANA InfoObjects (including master data and hierarchies) within the S/4HANA system directly to ensure master data consistency with the standalone BPC Embedded system.
7. Transported all the changes to the custom planning application in the standalone BPC Embedded system to the S/4HANA system.

Outside of TruQloud lab testing, TruQua has implemented, tested and validated the SAP note at one if its customers going live early this year on a stand-alone BPC Embedded system as part of a more extensive implementation and “real world” scenario.  Note that the S/4HANA migration activities will be part of a subsequent phase at that customer.

Any questions with regards to implementation and testing experience with the SAP note can be directed to info@truqua.com.

"The first round of testing of your new system is complete and it passed with flying colors.  You must be excited!" the consultant said proudly.

"Yes, we're pleased, but why isn't there a data-transformation-function*?" asks the customer.  "We've always relied on that critical function to run our business."
[*arbitrary example… insert your missing requirement here.]

"That function wasn't mentioned during our blueprinting workshops, so it wasn't included within the requirements document.   All the stakeholders agreed and signed-off on the documents before we began building the system, " defends the consultant.

"As the 'expert' shouldn't you have asked us if we needed it?  Didn't you notice that we use it now?" the customer asked.

"We were following the project guidelines.  That includes concentrating on a new future-state which leverages best practices and utilizes standards, as well as not dredging history regarding old ways of doing things.  Because the standards do not include that function as an option and since we didn’t conduct a review of your previous system to discover it, the function was not included in the new system. "

"Standards and best practices are good starting points, but exceptions should be anticipated in order to support some of our competitive differentiators… that's why we hired you and why we didn't implement the new system ourselves.  I understand that this is a joint process and you can't feasibly ask us every question possible during our workshops.  Likewise, we can't be expected to remember every need and requirement ourselves… particularly ones we naturally take for granted.

So, how could this have been avoided? "
- - - - - - - -

Does this story sound familiar or at least resonate?  This situation applies towards many types of system implementations.  However, it particularly applies to Enterprise Performance Management (EPM) implementations which includes SAP Business Planning and Consolidation (BPC) and SAP Integrated Business Planning (IBP) systems where the SAP ASAP or SAP Activate methodology is employed.

Over the past ten years on multiple occasions I've been tasked to rescue 'at risk' SAP EPM implementations much after the blueprint or design was complete.  While there are often multiple root causes contributing to the risky situations, one basic cause in particular was systemic across all of them: not conducting a proper current state analysis – the failure to adequately consider and understand the customers' existing system and how they are using it.

Blueprinting ERP Configurations vs. Designing EPM Custom Solutions

The SAP ASAP and SAP Activate methodologies were created primarily to guide Enterprise Resource Planning (ERP), ECC, S/4HANA implementations, in tactical and transactional areas such as production planning, purchasing, sales, distribution, inventory management, etc.  An underlying assumption of these methodologies is that on an industry-by-industry basis, these systems should be relatively similar to each other and can adopt a standard– recreating the wheel at each customer is not necessary.  As such, a 'best practices' approach is pursued, where a default system is used as a base, certain choices are agreed upon with the customer during a blueprinting, then the system is configured by populating templates, selecting various options and activating settings to fit the customer's needs.  Since the major difference between individual customers should mostly be their data and master data, those are the only real areas where a current state analysis is performed – the 'how' or 'why' regarding the current system is mostly disregarded in favor of the standardized solution's processes.

EPM systems cover strategic and analytical areas that differ from ERP, such as strategic planning, annual budgeting, quarterly forecasts, analysis, reporting and consolidations.  While two competing companies in the same industry perform their ERP functions similarly, the ways they analyze their performance and plan for the future vary significantly and change over time more frequently than in an ERP system.  Correspondingly, the EPM systems are typically very flexible with many tools, utilities and simplified scripting functions, that often do not require programming, to satisfy these different needs by allowing for the creation of a custom solution.  SAP does make available default standard 'business content' and Rapid Deployment Solutions (RDS) for EPM, however, in practice they are more typically used as sales demonstrations, learning examples, prototyping aids and for baseline testing.  They are rarely used as a base from which to build, because making modifications usually takes more time than building from scratch given the wide variances between customers.  Since those differences lie in the 'how' and 'why' customers conduct their strategic and analytical activities, the consultants' best opportunity to understand that is through a current state analysis which in turn informs the design.  As such, this is one of the more important exceptions to the SAP implementation methodologies that must be made for EPM.

Benefits of the Current State Analysis

Reviewing the current system and/or methods being replaced ensures the consulting team adequately understands how it is used, or not used.  This analysis helps define what does/does not work for the customer and explains the pros/cons and likes/dislikes about the existing system to ensure prior benefits are carried forward and limitations are avoided.  More importantly, it establishes a baseline of understanding and communication between the consulting team and the customer.  When new ideas and approaches are discussed, both parties share the same frame of reference.  When users require the new system to be as fast as the current one, but easier to use, their request will be better understood and the consultants’ follow-up questions will be more insightful.

These benefits cross both functional and technical lines.  Some consultants lead with their business, industry and functional experience.  They can leverage what they learn from why and how the current system operates, to recommend designs that will improve business outcomes and streamline the everyday decision making process.  Other consultants with a more technical approach are able to leverage their current state understanding to improve system efficiency and reduce manual steps.  Consultants with both functional and technical experience are able to push both the functional and technical envelopes even further in designing a solution that is guided by business benefits while still being technically feasible.  In all cases, having this common starting point perspective allows the consulting team to better anticipate needs, make better recommendations, ask more relevant and pertinent questions, and conduct more productive and smoother workshops, which ultimately will result in a better design with fewer errors and omissions.

Breaking against the SAP methodologies has its detractors.  Some believe that while learning the current system, the consulting team will become indoctrinated into the old ways of doing things and will not be able to think outside the box or consider a better process.  However, to a consulting team with a few engagements under their belt, the current system will be considered just one of the many they've already experienced.  Others cite time and costs.  Why pay consultants to analyze a system which the customer is already familiar and will be going away?  Based upon the above benefits, it is hard to argue you can afford not to.  In addition, the time and costs can be mitigated when there is useful preexisting system documentation available to give the consultants a jump start – as long as it is not relied upon exclusively.  Most detractors come from the ERP perspective, but once they understand the differences of EPM, they are typically swayed.

As described, there are many differences between ERP and EPM systems, the problems they solve and the solutions they provide.  The methodologies that guide how they are implemented must adequately reflect these differences.  Including a full current state analysis that addresses the 'how' and 'why' in EPM implementations is the first accommodation to the SAP methodologies necessary in order to implement EPM systems correctly the first time.

Please share your comments below... rate this post and share with others to spread the understanding.

• BPC is a full feature planning and consolidation tool based on BW, it requires its own BW namespace and its own cubes in its “classic” version. Version10.1 of BPC on HANA introduced the BPC “embedded” option, taking advantage of native BW cubes and allowing leveraging existing BW-IP logic.
• Previously S/OP (Sales & Operational) Planning tool transited into IBP. IBP is a new family of application in SCM under Hana whereas BPC belongs to analytic family.
• IBP uses source system tables as source data whereas BPC uses BW objects.Main difference in IBP is the direct access to Actual and Master Data tables via HANA views instead of data replication into BW persistence’s.
• IBP on Simple Finance is to replaceplanning functions from FI/CO which are not there anymore in Simple Finance
• Front-end Excel add-in (Analysis for Office) for IBP and EPM Add-in for BPC.

BPC along with IBP to improve corporate forecast accuracy:

Moreover, IBP can be integrated with BPC.   For example - IBP can take input from BPC for Annual Operation Plan (AOP), Monthly/Quarterly Finance Plan and Use this information for Demand/Supply/S&OP planning.

Then IBP can send output like mid and Long Term Plan, Constrained Collaborative Plan, Revenue and Profit Plans to BPC as a detailed starting point for financial planning in BPC.                         

                                   This integration brings the value by - Align financial plan with IBP inputs, Improve corporate forecast accuracy.

A process led by senior management that evaluates and revises time-phased projections for demand, supply, new product development, strategic projects and the resulting financial plans. This is done on a monthly basis, on a planned 24-month rolling horizon. It is a decision-making process that realigns the tactical plans for all business functions in all geographies to support the company’s business goals and targets.

A primary objective of IBP is to reach consensus on a single operating plan, to which executives of the management team hold themselves accountable, and allocates the critical resources of people, equipment, inventory, materials, time and money to most effectively satisfy customers in a profitable way.

1. IBP is primarily a supply chain focus of balancing demand, supply, and inventory.
2. Improved operational risk visibility and management
3. Gap identification and improved decision making
4. Easy, effective translation of aggregate plans to detail plans, and vice versa

Resources must be available and approved to execute all functional plans. Resource planning (manufacturing, operations, sales, marketing, product development, and financial) is a key element of S&OP/IBP.

• IBP and BPC both are Capable for all company functional plans which are aligned (product and portfolio management, demand management, supply management, and financial management). The process focuses on making decisions to keep plans aligned and agreeing on the tactics required to execute the plan (with a strong set of KPIs)

• BPC as atop down planning tool which considers many factors like inventory and sales. IBP is more of a bottom up planning solution focused on the inventory and its movements, through sales etc.

Take advantage of this opportunity to discuss the topic "BPC on HANA" with SAP Experts in a virtual round table. Bring your questions and doubts, and also feel free to share your experiences with other BPC users during the session.

This session will cover Business Planning and Consolidation for NetWeaver version.

Some important points:

• Only S-users can participate in this session (please provide your S-user in the registration)
• Session limited to 20 seats
• Concerning questions, it should not involving investigation of complex scenarios or deep analysis
• After the registration you will receive an invitation with SAP Connect link to join the session

When: Tuesday, June 14, 2016 from 4:00 PM to 5:00 PM (BRT)

Link for registration:

https://www.eventbrite.com.br/e/virtual-round-tables-bpc-on-hana-registration-25849731242

Please leave a comment below in case you have any question about this session.

Carlos Petry, John Leggio

Don't miss out the opportunity to acquire even more knowledge regarding an important topic on NetWeaver systems, focusing specifically on Business Planning and Consolidation.

This session will cover the following topics:

• SAP BPC-NW 10/10.1 transport architecture
• Basic configuration
• Transport and activation processes
• Essential Tables and parameters
• Comments on ChaRM
• Reading transport logs (checking the activation)

When: Tuesday, June 14, 2016 from 2:00 PM to 3:00 PM (BRT)

Link for registration:

https://service.education.sap.com/sap/bc/webdynpro/sap/zlso_esa_home?suser=I839719&hash=0E23F7062BD8FF2F0BD96DA278459632…

Please leave a comment below in case you have any question about this session.