Manpower Planning BPC Data Model

The BPC data model feeds from the SAP HR application which is uploaded through BI. The following diagram
represents the integrated data model with the integration of the transactional system and BI. This data model
also includes the BS derivation as it will be an integrated solution into the application in this project phase.
For the manpower planning process, the focus will be from the steps 1 to 4 of the diagram:

1. Data transfer from transactional systems to BW (transactional data and master data) as repository
of data for BPC

2. Upload of data to BPC in order to perform budgeting processes

3. Configuration of the Manpower budgeting process for all companies

4. Manpower budget is sent to the companies in order to build their budget

5. P&L and CAPEX Budget is entered into BPC by the AB Group of companies:

Other Expenses are entered into BPC manually by all companies using a common template
 Rest of P&L for all companies uploaded into BPC using current structures

CAPEX is uploaded via flat file to BPC following structures defined in step 5

6. Once P&L budget is in BPC for all companies, it is sent to the balance sheet to configure B/S budget:

Using common rules for all companies to derive B/S from P&L

Entering manual data for all lines that are not calculated from P&L/CAPEX (or uploaded via
flat file)

7. P&L and Balance Sheet budget for all companies is uploaded into the consolidation applications

8. Budget Consolidation process is performed (as per current process)

9. Budgeting Reporting is performed:

Consolidation reporting: Consolidated budget for B/S, P&L, CF, (as per current)

Operational budget reporting for P&L and B/S and Manpower in BPC

Operational budget reporting for companies not in BPC in their legacy systems

For the manpower planning application the following dimensions will be required :

Thanks for Sharing. Can i know more about the Employee dimension?

1. Is that a combination for Employee ID+Group?

 2. Is that a delimited data? Employee can be promoted or moved, so you can have
Same ID but a different group. Will this be a new member ID in Employee ?

3. Did the volume of Employee dimension cause any performance issue?

1. Yes, it is combination of all possible..

The employees information is the basis of all the calculations for manpower planning; therefore it is required
to upload the employees information. This information will be extracted from SAP HR and will be elaborated
in BW in order to update the employee information as master data and transactional data:

Employee Master Data This information will be stored in the dimension EMPLOYEE in BPC,
however due to the confidentiality of the information, only the following information will be
stored as Employee master Data, EMPID,BANDS( Group),GENDER, COSTCENTER etc.

Employee transactional data This data is the data required in order to make all the
calculations in BPC NW. This information will be associated to the employee only by the
ID. The required transactional data is the following, STIPEND,ALLOWANCES, BENEFITS etc.

2. This should be defined based on Assumptions( Band Change) and ID remains the same.. These
assumptions will be entered at the group level and will be distributed to All Group entities and cost
centres at the same time that the average calculations should be performed
3. There was absolutely no performance issues with Employee Dimension ( during my project
implementation & support), and I assume it depends on individual project scenarios.

We are planning for manpower planning for one of our telecom client which is having a company at
single location.
The parameters are as below :
1)Exchange wise revenue collection
2)Customer base (Employee to customer ration)
3)Technologies in each exchange ( Technologies like fixed line/mobile /ISP /other)
4)distance and time covered to reach customer for support
Existing grade wise manpower should be captured from ECC.
Performance rating of each existing employee must be also captured.
BPC should project the number of manpower required in each grade in each exchange.
Can you guide me to how to proceed for BPC modelling for such scenario?
Also would like to know how can we perform training planning for existing / new employee in BPC?
Currently they are doing using some questionnaire based on which they do the grading between 1 to
10 and depending upon that they decide the type of training to be made available for the employee?
BPC should capture the trainings provided to the employees till now, and also depending on his/her
performance, what training he should be appraised . Either he should go repeatation of the training
or some next level of training must be given?

there was a RDS (OHP - Operational Headcount Planning) from SAP which
provided almost all things for a common HCM planning. I have implemented this
several times for my customers. Nevertheless, the RDS has been removed from
SAP website due to many wrong implementations.
To implement a HCM planning you should consider a lot of things:
1. Whats the basis of data you want to use for? For myself, I used the standard
SAP PCP planning in R/3 to provide all data required for HCM planning. The
content itself delivers data structures which can be used in the HCM dataflow. It
even provides the transactional data via data collecting in PCP and pushes it to
the BW.
2. What features should your HCM planning include. As a best practice, I used a
top down approach to make guidelines for headcount, budget and fringe costs.
3. In a next step I implemented things like creating new positions, assigning
positions, terminating positions, promotions and so on (bottom up).
4. Implement a budget and FTE planning, which refers to the fringe costs from
top down planning and calculate the results automatically via script logic.
5. Implement things like education costs, unpaid leave and so on.
After all, simply create several reports based on the planning.
This is how I implement HCM plannings. Please consider that all is about your
data basis. With wrong data you get yourself in trouble creating a sufficient HCM
planning.
At the end, you can create a BAdI to retract data back to R/3.