Page 1 of 3 123 LastLast
Results 1 to 10 of 23

Thread: Topic 5 : BUSINESS PROCESS DOCUMENT (Core HR Process)

  1. #1
    Administrator
    Join Date
    Jan 2009
    Posts
    5,562
    Rep Power
    10

    Topic 5 : BUSINESS PROCESS DOCUMENT (Core HR Process)

    Advertisement

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


    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)
    Attached Files Attached Files

  2. #2
    Administrator
    Join Date
    Jan 2009
    Posts
    5,562
    Rep Power
    10
    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.

  3. #3
    Administrator
    Join Date
    Jan 2009
    Posts
    5,562
    Rep Power
    10

    As- is

    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.

  4. #4
    Administrator
    Join Date
    Jan 2009
    Posts
    5,562
    Rep Power
    10

    Inadequate “as is” documentation


    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.


  5. #5
    Administrator
    Join Date
    Jan 2009
    Posts
    5,562
    Rep Power
    10

    To-be


    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.

  6. #6
    Administrator
    Join Date
    Jan 2009
    Posts
    5,562
    Rep Power
    10
    We do in SAP R/3

    We know that SAP R/3 is software, it particular it is client-server software. This means that the groups/layers

    that make up a R/3 System are designed to run simultaneously across several separate computer systems.

    When you install Microsoft Excel on your PC, each component of Excel (printing components, graphing components, word processing components, and etc.) is stored, managed, and processed via the hardware of your PC. When a company installs SAP’s software each component (or "layer” in R/3’s case) is stored, managed, and processed via the hardware of separate and specialized computer systems. Each of the various layers is capable of calling upon the specialty of any of the other installed layers in order to complete a given task.



    Those components/layers that are requesting services are called “clients”, those components/layers that are providing services are called “servers”. Thus the term - “client/server”.

  7. #7
    Administrator
    Join Date
    Jan 2009
    Posts
    5,562
    Rep Power
    10
    SAP is an ERP (Enterprise Resource Planning) module, ECC is the version of SAP, like 4.6, 4.6c and 4.7 in that series new version is ECC-6. Its known as Enterprise core component.


    The sole purpose of an R/3 system is to provide a suite of tightly integrated, large-scale business applications.
    The standard set of applications delivered with each R/3 system are the following:

    • PP (Production Planning)
    • MM (Materials Management)
    • SD (Sales and Distribution)
    • FI (Financial Accounting)
    • CO (Controlling)
    • AM (Fixed Assets Management)
    • PS (Project System)
    • WF (Workflow)
    • IS (Industry Solutions)
    • HR (Human Resources)
    • PM (Plant Maintenance)
    • QM (Quality Management)
    • CRM (Customer Relationship Management)

    These applications are called the functional areas, or application areas, or at times the functional modules of R/3. All of these terms are synonymous with each other.

    Traditionally, businesses assemble a suite of data processing applications by evaluating individual products and buying these separate products from multiple software vendors. Interfaces are then needed between them. For example, the materials management system will need links to the sales and distribution and to the financial systems, and the workflow system will need a feed from the HR system. A significant amount of IS time and money is spent in the implementation and maintenance of these interfaces.



    R/3 comes prepackaged with the core business applications needed by most large corporations. These applications coexist in one homogenous environment. They are designed from the ground up to run using a single database and one (very large) set of tables. Current production database sizes range from 12 gigabytes to near 3 terabytes. Around 8,000 database tables are shipped with the standard delivery R/3 product.

  8. #8
    Administrator
    Join Date
    Jan 2009
    Posts
    5,562
    Rep Power
    10
    Hello all

    Hope you are got some basic knowledge of SAP.

    What is SAP?
    What we has to?
    Where we need to configure?

    Basically How to start a project...

    So now we are going to start first configuration from TOMORROW ONWARDS.

    If you want to read more please do it today, from tomorrow onwards full screen shots, tables, navigation....

    Spend valuable time to read and practices..

  9. #9
    Administrator
    Join Date
    Jan 2009
    Posts
    5,562
    Rep Power
    10
    Hello all

    Hope you are got some basic knowledge of SAP.

    What is SAP?
    What we has do?
    Where we need to configure?

    Basically How to start a project...

    So now we are going to start first configuration from TOMORROW ONWARDS.

    If you want to read more please do it today, from tomorrow onwards full screen shots, tables, navigation....

    Spend valuable time to read and practices..

  10. #10
    Junior Member
    Join Date
    Feb 2009
    Posts
    12
    Rep Power
    0

    really helpfull....

    Hi,,

    the basic which is provided by you is really helpful. I learn a lot from it.

    I wann to ask one question that, is there any roll in project only for SAP tester?

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •