Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
Showing results for 
Search instead for 
Did you mean: 
Active Contributor

As promised, I am following up my previous blog (HCM Processes & Forms: Gotchas, Bugs and Other Curiosities) with one on a more positive note. This time around instead of a list of “bugs and gotchas” peppered with my own little touch of sarcasm, I want to offer up some of the tips and tricks I discovered that I believe led to a successful HCM Processes & Forms (HCM P&F) project….and I am sure there will be some sarcasm in here too….for consistency of course. (ha-ha)  Of course, this is not the only way of doing things, but I hope some (if not all) will at least help others in planning and executing their HCM P&F projects. The following points are not necessarily to be considered as a project plan, however, it does somewhat follow a linear path: 


The “Learning Phase”….or “Project Prep-Prep”

    I would highly suggest building in some time into your project plan for some “learning time”. HCM P&F is new as of ECC6 and will most likely be completely new for your entire team. Even now, finding consultants with experience in HCM P&F is difficult at best (trust me, I have the recruiters’ emails to prove it! ha-ha) This “learning time” will impact almost every member of your team as well as others outside your team who might have some involvement (Portal, BASIS and Security). Even with a background in PCRs, learning HCM P&F took some time for me. I can not tell you how many times I read the help.SAP.com chapters, presentations, marketting material, etc. on HCM P&F from top to bottom until it all began to sink in. So what to do?  


Tip #1: Make use of a Sandbox!

    This was huge for us! By doing all of our initial work in a Sandbox environment, we were able to get the whole team up to speed….as well as make many mistakes and learn from them without doing any “damage”. This applied to everyone. First of all, the entire concept and architecture of HCM P&F will take some time to learn and get up to speed. There is a lot going on and a lot to learn about the interaction of the various pieces. At the least, your team should understand what the pieces of the framework are (Form Scenarios, ISR Scenarios, Process, Process Object, Workflow, etc.) and how they relate. Then, there are learning curves specific to each group involved in the project. Your BASIS folks will have much to learn in installing and configuring ADS as well as applying any support packages and/or Enhancement Packs you might need (I suggest having Enhancement Pack 2 for HR at least!...it adds a LOT of functionality to HCM P&F). For many BASIS folks, not only will Adobe and the ADS be a new concept for them, but Enhancement Packs will be completely new as well. What better place than the Sandbox to learn? During development in the Sandbox, your BASIS team can also monitor and tune as needed based on what they are seeing (odd things do occur!) Likewise, for your developers, Adobe Interactive forms and the HCM P&F generic services will be new to them. The concept of generic and enhanced generic services takes a bit of time to learn as well as get comfortable with developing. They have their own set of required methods each of which has very specific usage….and no, there is not much documentation or examples out there from SAP so it becomes a routine of trial and error to get up to speed. Next, your workflow resource(s) will have to learn what is delivered with HCM P&F, the limitations and workarounds needed for workflow and how workflow models the process. There is actually a lot that the standard tasks do for you and this often surprises workflow folks who might be use to doing it all themselves (for examples, writing custom BAPIs or ABAP classes to handle tasks). Lastly, for those doing configuration, they are somewhat the Ring Masters of this circus. Along with doing the configuration and learning the order of doing things, they will be pulling together the work from the other team members (workflow, developers, and forms). 


Tip #2: Let’s all do the Tutorial!

    I would highly suggest that along with reading and absorbing the help.sap.com documentation on HCM P&F, you also have your team members all do at least the first few chapters of the tutorial that SAP provides in the HCM P&F documentation. Not to fear, this tutorial will only take about a day to go through. I think what your team will learn will more than justify that time. This hands-on experience will help everyone understand how the pieces all work as well as what their fellow teammates will be doing. The tutorial walks you through a very basic 2-step process and is written so that even if you have no knowledge in some area, it steps you through it exactly. For example, you might not have any idea of how to do workflow at all, but if you simply follow the steps, it will walk you through it perfectly. You can do the whole tutorial, but really after the initial chapter or two, you are just enhancing the process you created. As a side benefit, your BASIS and Security teams can also monitor, check and correct any issues that might show up.


Tip #3: Learn from SAP

    Be sure to set up the example processes from SAP (called “Sample Processes” in configuration). These are not necessarily the most functional or useful processes, but you can make great use of them as examples for specific functionality. The “Transfer” (org change) sample for instance has some great code and configuration in it for showing how to populate a drop-down (in this case, it shows the positions for the manager you are transferring an employee to). Secondly, you can use the examples to make sure your installation is sound. The examples should at least run, so if they don’t, this is where you get BASIS and/or Security involved to figure out why you might not be seeing something correctly. For example, while testing our own custom processes, if we tried to run through our processes and had problems, we would then try to run one of the samples. If the sample came up, we knew right off, the problem was with our process (config or code). If the sample did not come up, we knew the problem was with something in the landscape (portal or backend).


Tip #4: Don't Forget the First Steps!

    Even if you don't use the sample processes from SAP, you still have some initial set up work to do under HCM P&F configuration in order to actually use it at all. This is largely setting up your process object (CASE Mgmt), number range(s) and workflow tasks. Most of these steps require you to copy objects from client 000, so you might need special access or need BASIS to handle this for you. Theses steps are all documented in the HCM P&F documentation in help.sap.com under the "sample processes" section. Not sure why it is put there when it is needed regardless, but hey, I don't pretend to understand German logic at times (ha-ha).


So while all this “learning” is going on, you might think this is holding up your project. Fear not! There is LOTS of other work to do that can be done in parallel. 


The “Setting the Scope and Business Involvement” Phase

    While everyone is getting up to speed on HCM P&F, ADS, Adobe Interactive Forms, etc., we can use this time to do a lot of the up front work required before we ever do the first bit of configuration or write the first line of code. To give you an idea, we had about 2 months for our team to do their “learning” in the Sandbox, and we used every bit of that time to take care of the following work: 


Tip #1: Pick your Process and Build from there in Phases

    I can not tell you how many times I hear from people saying “Well, we are about to do a 6 month HCM P&F project, and we are starting with hiring, termination, new position, and transfer.”. I always just chuckle to myself and politely say “Oh really….that’s nice.”…..but I don’t tell them that it’s also very, very difficult and not very realistic. Not only are you attempting to implement a whole new framework (from the technical landscape to the portal content to the security) but you are also doing completely new configuration and development. My suggestion is to pick your least complex process and initially aim for implementing that one. You could even do this first for a smaller, target group to mitigate risks. Choose your process carefully though. What constitutes “complex” is not only the process flow itself, but also, what data needs to be automated. For instance, maybe your “new position” process is quite basic with only a few steps. However, SAP does not provide any Org Mgmt. services at this time, so you would have to develop/code your own and that could make it more complex than another process. Also, a process containing “country specific” requirements will be more difficult than a more generic process (there are limitations with country specific fields for HCM P&F…only ONE country specific structure along with the generic, country independent structure is allowed for form scenarios/services). So, why just chose one process to begin with? Again, this will be your learning curve. After getting the landscape in place and getting your first process developed, configured and up and running, rolling out additional processes will be much easier (ie. your team will have much more experience at that time and the development cycle will be much shorter…even for a more complex process).


Tip #2: A Smart way to Design your Process   

    Now with your initial process(es) selected, we need to put on our “business side” glasses and layout what the process looks like. For us, it was easiest just to do a simple Visio flow chart. You want to work closely with the business (HR) at this point to help define this “business flow”. This will be fairly high level. What you are looking for are simply the “steps” in the process and “who” is involved in that step. This will help us further drill down and put this in HCM P&F terms in the following steps.   


    After the business helps you define this “business flow”, we now switch and put on our “HCM P&F” glasses. Based on what you are given as the “business flow”, you will now look at each step and decide (1) which ones are forms (2) which ones are automated tasks (ie. background) and (3) which ones will involve backend data updates. With these defined, we will also take our first pass at making the process more efficient either by combining steps, automating steps, removing unnecessary cycles or wait times, etc. At this point, we could say this is our initial HCM P&F “process flow”.     


    Next, we put on our “HCM P&F Workflow” glasses. Based on the limitations of HCM P&F in regards to workflow, we may need to enhance of “process flow”. This involves possibly splitting process steps into branches or changing the flow slightly in order to insure Process Object integrity (the Process Object can be thought of as our global data container for the process….or “how does it know what data is entered throughout the process”).   


    Lastly, we switch to our “HCM P&F Configuration” glasses. At this point, we are going to look at making our “process flow” even more efficient. Here, we are really going to walk through the process over and over and look for anyways we might be able to reduce complexity, possibly automate steps, etc. This will prepare our final “process flow”.


Tip #3: Mock-Ups and Role Playing   

    With our “process flow” defined, we now will have a better idea at which points we will have actual Adobe Interactive Forms and what kinds of data might be required. For us, luckily, we were replacing a custom form based process, so we had some examples to work from. You can mock-up our forms quite easily and choose whichever medium you feel most comfortable with to convey your idea for the forms. You could do simple Word documents or web pages if you like. For us, we actually used transaction SFP (the Adobe Livecycle Designer) and made “dumb” Adobe forms. These were just local (“Y”) versions without fields binded to any data. This also had the added benefit of getting us more use to the Adobe form editor which is a very easy to use “drag-and-drop”, WYSIWYG application. As an added benefit of using SFP, we could select previously created mock-ups and simply copy them to create new ones to keep our forms consistent.    


    With all of our forms mocked-up, we actually went through another meeting where we “walked” through the process and actually used our mock-up forms in their steps. I mean we actually had people at the table playing each role in the process and handing off the forms accordingly! This might sound silly, but you would be amazed at what this did for us. From this, we were able to discover missing information/fields we needed as well as further identify where and what kind of possible generic services and user events we would need to provide functionality on our forms. Also, it helped further define “who” the approvers were on each step and identify any timing issues that might be a concern. Lastly, I believe an interesting side effect was that this little “acting exercise” kind of made us a closer team (ha-ha). 


Tip #4: Get their Signature and Involvement  

    With our “process flow” and form mock-ups in hand, we now went back to the business. We had a meeting comparing the “business flow” to our “process flow” and showing the form mock-ups. The outcome was that we wanted the business to “sign off” on our solution. I can hear all the stories now, and I can add plenty as well….we all know how “sign offs” tend to work (ha-ha). However, we did want some level of accountability. Why so formal? This is because changes to our “process flow” and/or forms could be quite a large bit of work down the road. This sets expectations for all involved. It is also a good way to initially get the business (HR) exposed to HCM P&F (they tend to get all excited too when they “see” how it will all work!).    


    Another outcome of this meeting should be to identify areas where the business themselves might be expected to provide content (yes, you might be assigning them some work!). This content will be such things as actual form text/wording, any process step “help” you wish to provide (this could be text on the form, or web pages attached to the process step via config) and possibly any images that need to be on the forms (logos, graphics, etc). 


The “Get Our House in Order” Planning

With the project actually set to begin….yes, with actual configuration and actual coding!!! Yea!.....we need to get everyone on the team on the same page. This portion of work can also occur in parallel with the two previous groups of work.   


Tip #1: Naming Standards are our friend  

    With so many pieces of configuration and development involved, it will greatly benefit you to define naming standards and strictly enforce these. I know….common sense, right? But you would be surprised. The key pieces you will need to define a naming for are:

  • Process ID
  • ISR Scenario (4 CHAR)
  • Form Scenario (32 CHAR)
  • Form Step (32 CHAR)
  • Form Step Description (60 CHAR)
  • Adobe Form ID (system generated….should keep it as generated)

    For us, we started with the ISR Scenario name. Since an ISR Scenario is tied to a Form Scenario, we wanted to names to somewhat be linked. Also since the ISR and Form Scenarios are part of the Process, we wanted the Process ID to convey the link to each as well. So, we first define a 2 character ID for our Process “prefix”. For example, “ZT” for our process ID “ZT_TRANSFER” might be our name. Now, we name our ISR Scenario using that ID plus two more numerics for the actual step in our process. For example, “ZT01” would be the ISR Scenario for our first process step. Now, we tie the naming of the form scenario by using the same two character process ID, the process step and process name so we have “ZT01_TRANSFER” for the first form scenario. Form Steps within a form scenario are named after the Form Scenario and then a suffix conveying their order. For example, we might have “ZT01_TRANSFER_A”, “ZT01_TRANSFER_B”, and “ZT01_TRANSFER_C” for three Form Steps within our Form Scenario. Now, simply from the naming of each component, we know what it’s corresponding pieces should be.    

   After defining our naming standard, we were able to very quickly document our entire configuration based on our “process flow” steps (via a nice Excel spreadsheet I came up with…ha-ha). From this spreadsheet, the entire team knew what the configuration would look like. For instance, this allowed our workflow person to go ahead and build the entire workflow because she knew the names of our Form Scenarios and Form Steps to use in her bindings. She did not have to wait for us to actually configure those and then tell her what they were.


Tip #2: Pick your Poison….er uh….Scripting Language  

    For your Adobe Interactive Forms, you will need to decide up front which path you wish to take for developing scripts within the form. Using a mix within a form or using one on one form but another on other forms will be very confusing to your developers. With Adobe, your choices are FormCalc, which is Adobe’s proprietary language, or JavaScript. We chose JavaScript because we were most experienced with it and because or forms were going to be largely web based (you see FormCalc much more in standalone Adobe forms).


Tip #3: Let’s Build Some Black Boxes  

    At this point, we should know many of the Generic Services we will need to develop and what they need to do. It helps greatly to go ahead and define what the names of the services will be, the names of their “operations” and the name of the parameters to pass. This allows us to know what configuration will be needed, what will be passed to the service and the expected result. Talking through this often leads to further identification of missing services, operations or parameters.


Tip #4: A Common Toolbox   

    Make sure everyone on the team has correct Adobe Reader version installed, Adobe LiveCylce Designer version and ISR controls library. These are all local, client installations. This will make it much easier for the team to help each other in finding and resolving issues during development. It also will help keep you from spending time chasing down issues that are not directly related to your process development. For instance, one person on our team kept sending emails to BASIS that they “couldn’t see the forms” yet another team member could. Turns out, they had never installed the correct Adobe Reader on their own machine. This took some time away from work for both BASIS and several of us to catch which could have been avoided had the user installed the correct Reader initially (and yes, there was an email at the beginning of the project telling everyone to do so….ha-ha). 


The “Doing Work” Phase

Yes…that time has come! Actually doing something in the system…. configuration, coding and form development.  


Tip #1: Building an Efficient Project Team   

Again, assuming we are trying to implement an initial, single process, I found that this project team worked best for us. To give you some background, we were implementing a “Termination” process for around 4,500 employees across 9 countries.

  • 1 HCM P&F Configuration Expert/ Adobe Form Developer: This might seem like an odd combination but often the person doing configuration will need to add/delete fields from the form as well and this cuts down time dramatically if they can do both. Adobe form development is very straight forward, so someone with only a functional/configuration background should not be afraid of jumping in and doing this work as well.
  • 2 ABAP developers: Why 2? This is because you will have lots of generic services to develop and possible several BAPIs/Classes for workflow as well. Splitting this work based on complexity and work load helps overall. Also, you have the benefit of each developer learning from the other as they develop services.
  • 1 Workflow specialist: This person will work off of the “process flow” that was developed as well as the configuration of the Form Scenarios and Steps. This person may also develop some “utility” or “testing” workflows which will be discussed later. The brunt of their work was not really the workflow template development itself, but more in building the “approver determination” logic and related code.
  • 1 Portal Content and UWL Specialist: This person will set up the necessary portal roles (MSS, HR Admin, etc) as well as handled any needed UWL configuration for our process related task steps.
  • 1 Project Manager/Functional Expert: This person was our expert in “how the business works” as well as our liaison to the business itself. They provided us with any business process information we needed as well as information about the “actions” involved in our process. Since this person served as our link to the business itself, they also acted as Project Manager as well to insure that we were on track, not held up waiting for responses from the business, meeting the business’ expectations, etc.

 Other resources that were only involved as needed included Security (portal and backend) and BASIS.


Trick #1: Make Workflow Approver Determination Simple (initiator)  

   When first building your workflow, make sure the “next approver” is always set to the initiator. In this way, the person testing the process will get all the work items for each step of the process in their UWL. This makes it much easier to test and insure that at first the workflow is flowing correctly. It also gives you time to further develop your true “approver determination” logic.


Trick #2: Make Utility Workflows

    Create a few simple one step and two step workflows to use to test small portions of your process. You can simply change the binding on the workflow task to a different Form Scenario and Form Step to test smaller parts of your process while the larger process is still being developed. This speeds up development dramatically! If you don’t wish to create smaller subsets (trick#3) and “wrapper” processes (trick#4), you can still accomplish a similar outcome by using the “utility” workflow in your overall process. You would just change it’s assigned workflow to your smaller, “utility” workflow to call up the Form Scenario and Steps you assigned in the binding. This allows you to “jump” to specific steps in your process to test without going through the entire process flow.


Trick #3: Split Process into Small Chunks (subsets)

    This works in conjunction with Trick#2 above. Pick smaller parts of your overall process that can be tested. You can quickly build a small “wrapper” Process to test this subset, and then merge your findings back into the larger, overall process. For us, we had a fairly complex Termination process. By splitting it into smaller portions to unit test and then incorporating those back into the overall process, it allowed team members to work on different areas.


Trick #4: Make a "generic" process to use as a "test wrapper"

    Again, this works in conjunction with Trick #2 and 3 above. You can quickly create a “stub” or “wrapper” process to test smaller portions of your process. Also, by making it generic, you simply copy over the Form Scenarios and Steps from your larger, overall process and use those. This is great when developing and testing Generic Services for instance. Once the testing and configuration in your “generic” process is worked out, you can then make those changes back over in your main process.


Trick #5: Build forms without "brains"

    When you initially create your Adobe Interactive Forms, do not add any of the “bells and whistles”. This also includes not defining any backend services for your Form Scenarios and Steps other than simple “reads” from the standard services (SAP_PA and SAP_PT). If form field values are need, simply hard code them with default values in configuration and later change this. In this way, you will be able to test your process flow and insure you are getting the correct forms along each step without running into errors or issues that might be associated with incorrect form scripts or backend services. Once you stabilize the actual process flow, you can then focus on adding form scripts, user events and backend services.


Trick #6: Create skeletons and test services as "black box"

    Your Generic Services will be a coordinated effort between your developer who creates them and your HCM P&F configurator who uses them. We want to insure that neither holds the other up. Since we already defined what our services, operations and parameters “should” be (ie. in our design phase), the easiest way to start is for the developer to create the skeleton of the services, their operations and their parameters. The developer will have to create the service as well as provide some initial coding in the “get operations” and “get service fields” methods. In this way, the configurator can “see” these in their configuration drop-downs although they don’t actually do anything. Now, with the configurator able to add the services into configuration, the developer can then code the actual logic into their operations. At this point, it is best if the developer tests their own methods as “black boxes”. They can insure that their own operations are working as intended based on the parameters agreed upon. If not, they may need to enhance the design and communicate these changes back to the HCM P&F configurator. Once they have proven their operations work as intended, then the configurator can test and verify that their mapping to these operations works as well.


Trick #7: Ease into your Actions

    At the end of the day, you will want your process to mimic a backend action. For example, our Termination process should in fact be the same as a backend HR termination “action”. What we need in HCM P&F from a configuration stand point is to know all the infotype updates/deletes/delimits/etc. that are needed for the “action” and just as importantly, the order these need to occur in. Also, if these “actions” are somewhat “dynamic”, we will need to know that as well to model these in configuration through the use of “rules” if possible. An “action” can be quite complex. Therefore, the first thing we want to do is to “ease” into our action. By “ease”, I mean when we define our backend service for our form scenario which will actually make our changes, we should start first with only 1 or 2 of the infotypes in the action (for example, our “action” might go through 10 or so infotypes). From this, we will find out which fields we might be missing (these get reported as errors when testing the form). After sorting that out, we can then add another 1 or 2 infotypes and continue as before and “ease” into building up to the full “action”. This helps tremendously instead of trying to configure all the infotypes of an “action” at once and hoping it all works. You will end up “chasing your tail” and getting quite frustrated trying to determine which infotype is failing and where more information might be needed. Also, by defining it this way, you might discover you need some new "utility" generic services at this point. For instance, we found places where we need “utility” services to help determine some date fields for some of our infotypes based on the values of previous fields.



Now with each piece working, you simply put the blocks together and add "real routing" to workflow. You should have your working process at this point and can hopefully get in to your “testing and training phase” of your project. That means a successful “go live” is not far off, right? Before you know it….Viola! You are done……Time to start adding all those other processes now! (ha-ha)

Labels in this area