Topic 5 : BUSINESS PROCESS DOCUMENT (Core HR Process)

[freesaphr]

Before we go SAP HR Configuration, Blue Print, SAP Navigation's, SAP HR Tables & T-Codes....


We will look at Core HR Business Process so that we can MAP Core HR to SAP HR.


Sub-Modules of HR

1. Personal Administrations
2. Organizational Management
3. Time Management
4. Payroll Management

And other Sub-modules like Benefits, Personal Development, ESS, Recruitment's, CATS...



PLEASE LOOK AT THE ATTACHMENT, CONTAINS : BUSINESS PROCESS DOCUMENT (Core HR Process)

[freesaphr]

Before SAP CONFIGURATION we need to understand the client Business Process/Requirements.

Functional Consultants will contract Clients Core- team and will gather all the requirements and starts mapping to SAP.

This is called AS - IS, TO - BE.

[freesaphr]

Functional consultant involves understanding the complete functionality of the system.

It involves detailed understanding of how the HR department is functioning because based on that only you would provide a solution to them.

Like suppose you are implementing SAP HR module for them then in the AS-IS and TO-BE phase, you need to prepare all the documents of the process flow (you can prepare them in word).

Like suppose you are implementing for PA then you need to identify how many personnel areas you need to make, how many subareas you will make, employee groups, subgroups, based on what you are classifying them? This all will come in the master data document which has to be approved from the client whoever he is .

Like if the current system is on mainframe or for some specific applications like for recruitment the system is on mainframes and the client wants to keep that system as well then interfaces need to be identified which will be there because you will have to upload the data to sap system using bdc.

Like this for every process there will be a document.

Even for actions like:

- Hiring
- Newly Hire
- Termination
- Transfer
- Layoff etc

You will have to see what all actions your client wants, like if there is an action transfer which is run for employee what all will be the reasons you will be configuring for that action. This will be told by the client which can come out after a series of meetings and after discussions you will have to come out with the document that these will be action types. These will be the action reasons, these will be the action codes for that. This will be in the TO BE process document.

After this phase is over complete configuration can be done.

Actually AS-IS process in summary involves :

1) Series of meeting with the client.

2) Gathering complete information about the existing system.

3) Preparation of the blue print documents describing the complete AS-IS process ,i mean the existing system.

4) Flow charts should be included in the as-is blue print process flow document describing the complete process.

5) After this is finished u have to give the TO-BE process structure that will be implemented in SAP.

6) After that there will be some things which cannot be implemented in SAP so the gaps are to be identified.

7) These gaps are to be documented in white paper for the client.

[freesaphr]

Some more on AS- IS


Symptoms: You are the implementation Project Manager for a consulting firm and you have a client that just selected an ERP system. You (the project manager) and your team start gathering requirements from end users through focus groups, workshops, sessions with SMEs, etc. After gathering information from end users you erroneously conclude that you have all the necessary information and requirements to successfully implement the “to be” software system. Since you believe you understand the “to be” system you neglect to document the “as is” system.



During UAT (User’s Acceptance Testing) you find out that the system does not meet end user’s expectations and the UAT participants cannot validate your implemented solution. Your client is dissatisfied with the proposed solution, and you are now challenged to prove that your implemented ERP solution is consistent with the client’s business needs, and requirements. Given clients’ complaints you are put in a position where you cannot explain how the proposed ERP solution meets or exceeds previous system functionality. The question now becomes how does the ERP system meet replaced system functionality if at all?


Suggestions: Determine if there are any existing documents in the form of functional specs, architecture diagrams, requirements or flow process diagrams that describe current system functionality. Work with the client and in particular programmers who designed the legacy systems to understand the nuances and high-risk areas of the system that will be replaced. Document from your findings your understanding of the current “as is” system and also specify how you will replace the “as is” functionality with the “to be” ERP system.



Draft test cases that specifically address how the replaced functionality will be verified within the ERP system and also allow the UAT members to peer-review the drafted test cases as they become available. Document any feedback from the UAT members for the drafted test cases and as time allows produce prototypes of the proposed solution to minimize the impact on the end users.

[freesaphr]

Mapping "AS-IN" to SAP called "TO-BE"

For that we do Configuration & Customization.

CONFIGURATION: we will configure the system to meet the needs of your business by using the existing data.

CUSTOMIZING: we will customise or adapt the system to your business requirements, which is the process of mapping SAP to your business process.


Configuration vs. Customization
When considering enterprise software of any type, it is important to understand the difference between configuration and customization.The crux of the difference is complexity. Configuration uses the inherent flexibility of the enterprise software to add fields, change field names,modify drop-down lists, or add ****ons. Configurations are made using powerful built-in tool sets. Customization involves code changes to create functionality that is not available through configuration.

Customization can be costly and can complicate future upgrades to the software because the code changes may not easily migrate to the new version.Wherever possible, governments should avoid customization by using configuration to meet their goals.Governments also should understand their vendor's particular terminology with regard to this issue since words like "modifications" or "extensions" often mean different things to different vendors.