I have been ignoring this blog for the past few months with no good excuse beyond being over-extended on consulting projects. Now that I’m starting in on co-authoring a book on SAP HCM Processes and Forms with Justin Morgalis I can now ignore this space with a clear conscience. Feel free to do the same!
I will be back one of these days with more crack insights for my myriad fans.
This is the first in a series of blogs designed to help non-technical SAP HR users understand a few semi-technical tricks.
Introduction
In my travels, I have seen a lot of savvy functional people stuck when trying to finish something critical. The reason? There is an error that simply shouldn’t be there–after double-checked their configuration, there’s nothing strange about the employee record, yet the error persists. What’s a functional person to do? Typical answer: pull in a developer to sit side-by-side to figure out what’s going on “under the hood”. The only problem is that the developers are all busy working on other tasks. So, they wait.
My objective in this series of blogs is to introduce a few tools that functional people can use to begin to find their way around “under the hood”. Maybe we can reduce the number of times you have to involve the development team.
Warning!
A word of caution: you may find the empowerment so intoxicating that you move down the “slippery slope” until one day you know how to program. Consider this blog the “gateway drug” to the dark work of ABAP programming. Ok, you’ve been warned. That’s a ways off today though. We’re just trying to take some small steps to help with troubleshooting.
A Caveat
Some of the steps below require some transactions that you may or may not have authorization to. It’s usually more likely you can get access to these in your development environment. If they won’t give you the access you need, you should. Fight the fight to break down those walls.
Sequence of Steps
The logical steps that should be followed for troubleshooting will vary from issue-to-issue, and with experience the developer will be able to make these judgments for themselves. However, the steps in this guide are meant to go from specific information to more general sources.
#1- Check for runtime errors via transaction ST22
The Application Errors is available for analysis whenever a user encounters an error/exception that is unhandled. Application errors are very inelegant to the user: if the user is viewing from the windows GUI, they will see a shortened version of the application that is visible via ST22. If you’re seeing something in the web, you’ll also see something very technical in nature. The good news is that ST22 errors are actually very rich in information. If we can get past our initial trauma at looking at something that looks so overwhelming we can actually fish around and often see the source of our issue.
2. View the results screen and look for the user that might have experienced the error. If a “promising” entry is found, double-click.
3. The runtime error detail contains a lot of data—much of which will not be useful to non-technical users. However, there are a few key items to check:
“What Happened” provides a high-level play-by-play of where the error took place
“Error Analysis” describes the error in greater detail. This is usually the best information found in the runtime transaction.
Further down, you will see an extract of the source code in the program. The arrows indicate the spot in the source code where the error occurred. By looking at this the cause of the error can sometimes be readily apparent even to non-technical users.
“Chosen Variables”- This section looks intimidating at first, but for simple variables, the thing to be aware of is that the value can be found. For example, in the following view, you can see that the ID field does not have a value. This was the actual cause of the error.
Wrap-Up
Hopefully from the above example you can see anyone willing to overcome technophobia can readily find some answers by looking in the basic error log. In the next posting we will look in another error log that is gaining prominence, the application log.
“Silos can’t interoperate unless the technology does”
-Carly Fiorina
Over my time consulting in SAP HR I’ve noticed more than a few companies whose business teams have regarded the SAP support group as the:
“Can we do that? Maybe, Just Give Us Several Months and We’ll Let You Know“ team.
Businesses users are often made to beg to bring on-line new functionality–even if it’s provided by SAP. I believe that unresponsiveness of in-house teams is one of the key drivers of the current SAAS movement. Tell the business no often enough and they’ll say “You can’t do it? Fine! We’ll just go to the web and find someone who will.” The result is often that companies end up with a core HR system delivered by SAP and a patchwork of solutions for everything from recruiting to succession planning–just what the companies were trying to avoid by putting in the ERP in the first place!
Today I’d like to focus on a couple of the key barriers to responsiveness from in-house teams.
Barrier #1-HRIT Teams Are Measured By Failures Only
Let’s face it: HRIT managers are often judged less by the amount of value their solutions are adding and more on whether there have been any “incidents”. The natural consequence is that if you’re an HRIT manager, you want to avoid risk. What’s the easiest way to do this? Just don’t place the item in question in service at all. The reality is that while business cases are almost always used to justify the initial investment in the software, often there is not the same type of calculation for the long term support. This eliminates the incentive for the support team to stretch to bring in additional functionality.
The solution comes back to the old adage: what gets measured gets done. Calculate ROI on your HRIT investment on an ongoing basis. HRIT managers should be rewarded when they are able to deploy new solutions or enhance existing ones.
Barrier #2-The Wall Between Functional and Development Resources
But beyond just saying “no”, I believe there is another key cause of in-house inefficiency at SAP clients. It is the gulf that too often exists between the functional and technical disciplines: the functional group handles the table entries but does not speak the technical “language”. The technical team does not understand the functional requirements well enough to complete the work adequately. A couple of tell-tale signs of this gulf:
Bridging this gulf is imperative if we want to ensure that our production support environments are nimble enough to meet changing business requirements and rapidly deploy new solutions. The question is how to bridge? At the risk of being simplistic, I believe that there are two alternatives: (1) making the technical team more fluent on functional capabilities and business requirements (2) make the functional team more fluent in programming.
I believe that both of the above alternatives have merit. However, my experience with clients of all sizes and industries makes me believe that teaching programming concepts to functional resources is an avenue that is completely under-exploited. Here are my reasons why I would recommend teaching technical concepts to functional resources rather than vice-versa:
A couple of caveats here:
Of course many organizations are set up with walls built between functional and development groups. The model I am suggesting requires that the walls be shortened to allow some passage. As a community I believe that this type of change is not simply a suggestion: becoming more responsive is absolutely necessary. The alternative? The alternative is to give the business further impetus to decide to tell the “Several Months team” to hit the showers.
Next Up
Now that I’ve explained a bit of the “why” the functional groups should learn ABAP, my next blog will focus on “how”.
One of my favorite books from the past ten years is Moneyball by John Lewis.
Lewis chronicles the remarkable success of a baseball team (The Oakland Athletics) on a shoestring budget under General Manager Billy Beane. Under Beane’s watch the Athletics have consistently out-performed teams that with double or triple the payroll of the Athletics. Despite only having a conventional general manager’s background (former player), Beane decided to take a radical approach to player selection and development, informed by a new breed of baseball statistical analysis called sabremetrics. Instead of following the established dogma of relying on film assessments and scout intuition to determine the makeup of his team, he instead turned his organization upside-down by hiring a few bright Ivy League graduates. These “kids” performed detailed regression statistical analysis of player performance, both within the organization and without. Together they asked and answered a few simple questions:
Answering step 1 above required true intellectual horsepower. They drew upon the work of a new breed of statisticians who were analyzing new and innovative data points. In the final analysis they came up with a simple hypothesis: baseball teams were grossly underpaying for players who knew how to get on base through the decidedly unsexy method of taking a walk. Beane took this discrepancy and began amassing less expensive players who were good at taking walks. The result was amazing: the A’s won several division titles with hitting lineups that were so devoid of marquee names that their levels of performance seemed like an anomaly to the rest of baseball–except that they kept performing year after year.
It’s my belief that HR suffers from a greater level of undiscovered insights than baseball. As mentioned previously, employees are the most expensive and most pivotal resources for any organization. Yet true analysis of how their performance impacts the organization is seldom undertaken in a serious, analytical manner the way that Beane did with his baseball team. Companies who undertake this analysis can take actions such as investing in recruiting sources that yield the best, most tenurable employees.
these insights and take action on them will have an edge on their peers. \
It is at this point I should bring up the biggest argument I hear against focus on measurement in HR:
“But Brandon, so much of what we do in HR is not quantifiable. ”
Maybe true. A little. But also completely a cop-out.
We have a great number of data points at our disposal: employee tenure, performance ratings, potential ratings, turnover values, capability assessments, demographic data, application sources–to name a few. With the advent of social networking, we have even more elements to add to the discussion: number of links with top performers, number of networked friends, etc. Many companies also now have integrated talent management platforms with normalized data that make the analysis possible.
Let’s face it. People who make the argument above aren’t saying:
“But Brandon, so much of what we do in HR is not quantifiable. We been poring over reams of data for years and that is the conclusion we have reached.”
They are saying:
“But Brandon, so much of what we do in HR is not quantifiable. I take this as a foregone conclusion so I’m not even going to try.”
Or even:
“But Brandon, so much of what we do in HR is not quantifiable. Even if it was, I was not good with numbers in school, which is why I am in HR in the first place.”
Whatever the reason, the personnel insights continue to remain locked away, waiting for the right analysis to come along and set them free. Fortunately, the new generation of thinkers are beginning to point the way forward. The unquestioned pioneer in this field is Jac Fitz-Enz. He has been working for years in developing predictive metrics such as time to full capability and cost of turnover. Once the value in the data is laid bare, more boards will begin ensuring collection and analysis will take place. HR leaders will be expected to report on the ROI of the human capital–and those incapable of doing so will find other employment.
HR’s “Moneyball” moment will come, hopefully soon.
I began my career many years ago as a CPA, mainly because it was one of the few majors that guaranteed a job upon graduation. I did a double-major in accounting and finance to keep my options open. Taking both sets of classes gave me a unique vantage point on how each added value to organizations. Accounting is regimented and is meant to ensure that organizations record their books consistently with one another, following a predefined set of rules. Finance draws on accounting for information, but it has a different objective. Using finance we discover how to most efficiently deploy financial capital within organizations: do we incur debt for growth? issue stock? both?
Having these two disciplines conceptually distinct from one another provides a tremendous benefit: it allows the focus on compliance to be distinct from the focus on strategic planning. Everyone knows the role that a CFO is to play within an organization, and everyone knows what a Controller does. With this clarity comes credibility and the mandate to fulfill their respective responsibilities.
As I work with HR organizations, I am convinced that we could benefit from the same distinctions. Too often the mission of HR becomes muddled: are we primarily here to avoid lawsuits, or are we here to invest in our people? The answer of course is both, but where compliance and strategy are distinct in finance, in HR they seem to be inextricably joined. Why?
I think the time has come to separate HR into two disciplines–compliance and strategy. The compliance team would be responsible for tracking regulations, instituting policies, and ensuring compliance with them. The HR strategy team can focus on human capital allocation the same way a CFO does with the financial capital–invest in training? mentoring? top performer turnover avoidance? Some organizations have begun to do this on their own, but our industry itself needs to do more to make the distinction clear and educate the rest of the business. The distinction bring clarity of purpose and the appropriate mandates to carry out responsibilities.
I suppose I should lay my agenda bare here: by splitting off compliance into a separate discipline, we free up talented HR professionals to focus on increasing human capital effectiveness. Additionally, if the rest of the business understands this as the primary HR mandate, the clarity of purpose will enable the rest of the business (and most importantly the executive team) to more readily see the potential benefits of pursuing effective human capital strategies.
The other essential ingredient to increasing organizational buy-in to HR efforts? Producing measurable results that show how HR programs are (or are not) providing value. That’s the subject of my next blog. Stay tuned.
I believe in HR. I really do. I’ve worked in HR tech with forward-thinking people for well over a decade now. I’ve seen first-hand very smart people trying to advance our profession.
Why?
I see enhancing processes focused on people: an enterprise’s most expensive, essential, and volatile asset …as essential to any forward-thinking business. Developing people to make them more productive– making sure you retain the best of them– has an immense ROI.
The Disconnect
If you talk to the average business person and get their impressions on the discipline of HR, you don’t get an homage to the cutting-edge people in HR trying to transform their businesses in new and exciting ways. Instead you’ll often get one of the following responses :
Bridging The Perception Gap …Or Real One?
Hearing those undertones have the effect of making us want to lash out. You don’t talk smack about my family without me coming to the rescue. How dare you? Don’t you see how HR keeps the business on track? The problem is, they are often perfectly justified in their derision. HR people can often end up playing the part of an irrelevant policy monger who contribute to the success of a business about as much as a substitute teacher helps in the learning process–kind of helpful, but mostly irrelevant. The archetype for this view is Toby the HR guy in the TV series The Office. However, unlike many of the characters on The Office, the humor of Toby owes not to outrageous behavior but because he serves as a ready target for the derision that business people feel toward HR. He’s funny because he resonates.
Toby, are you a caricature or a mirror?
Looking Ahead
That may be the present, but what about the future? I think that the time may be right for the revolution in HR. Cutting edge thinkers have been advocating radical change in HR for a long time. A confluence of factors: technological advancements, demographic trends, and a modulating of the old way of thinking make change possible, but not inevitable. Over the next few weeks I will be highlighting some of the key barriers I’ve witnessed and how they can be overcome. My purpose is not to incite a revolution. I barely have enough clout to influence my own family on where we go to eat. My objective is simply add my voice to those already out there calling for change. Stay tuned.
In my thoroughly scientific analysis consisting of assorted conversations, the one tool most under-utilized by SAP HR people is Twitter. Most people I talk to don’t get it. Why, they ask, should they sign up for a service that allows them to find out who designed Lady Gaga’s meat dress? The name itself sounds trite. Clearly this silly little service does not deserve the attention of time-starved, information-overloaded business people, right?
In my personal experience, I’ve found that Twitter has become my go-to place for actionable, relevant information. The 140-character length limit requires the messenger to really focus their thoughts. Jarret Pazahanick has done a great job explaining some of the merits of Twitter in some of his blog work (see the links to Jarret’s content below), but considering that many of you still are not convinced, I thought I would add my voice to the chorus. This blog will focus on the top 5 myths/misconceptions on Twitter:
Myth #1- Twitter only exists so that celebrities can tell you what they had for dinner.
False. There are a lot of people who tweet out a lot of really good information on a variety of subjects. For example if you follow some of the key people in SAP HR, you would have found out the following in the past couple of months before just about anyone else:
1. SAP was delaying EHP5
2. The year-end support packs were set to be delivered 10/14
3. SAP is delivering a W-2 solution was set to
4. SAP added in more ESS functionality during the time of delay in EHP5
Myth #2-If I get an account I have to tweet
False. In fact, most people never tweet. The challenge here is that we think of Twitter as an alternative to Facebook. It’s not. Twitter is more similar to an RSS feed than anything else. It you want to tweet, great, but I find I read much more than I write.
Myth #3- I need the permission of the person to follow them (ala Facebook)
In Twitter I can follow whoever I want. I don’t need the person’s permission. Another great feature on Twitter is that I can see who others are following. So, for example, if I am interested in what Steve Bogner has to say, I can look to see who he’s following and choose to follow some of the same people too.
Myth #4- I need to be on my computer to use Twitter
Twitter’s short format (160 character maximum) is ideally suited for your smartphone. I can’t tell you how many times I’ve been in a checkout line, pulled out my iPhone and skimmed all of the latest news on Twitter. It’s the perfect on-the-go medium. All of the major smartform players (iPhone, Android, Windows Mobile, and Palm) have a number of twitter apps to choose from.
Myth #5- Twitter users are better lovers.
Ok, actually this one is true.
Read More About It
As promised, here are links to a couple of great articles from Jarret Pazahanick. These will tell you how to get on the bandwagon.:
One skill that is completely under-appreciated is the ability to write an effective SAP customer message. It often is the difference between getting a critical issue corrected by SAP or being stuck on your own. Below is a summary of tips on writing effective customer messages:
Be Courteous…
The support representatives on the other end from you are people. Begin your messages with “Greetings” and “Regards” as you would correspondences with anyone else. Frame your descriptions in a diplomatic tone.
…But Describe Your Issue As An Error
SAP support does not handle product “suggestions”. If they get the sense that you are asking for a new feature, they will shut down the requests. Therefore, whatever it is that you are asking about should be described as something that is not working as designed.
Be Thorough
The more precise you are, the easier it is for the support representative to understand the problem. You want to limit the number of follow up questions from the person who is on the other end. Also, by describing the issue well, you also let the support person know that you are knowledgeable and so your request should be taken seriously.
Always Include Screen Shots
A picture is worth a thousand words and aids in diagnosis
Re-Read Before Sending
Make sure it’s clear how you’re describing the issue
Include Your Support Pack Levels
This can save you a round of questions from the support representative.
Lastly…Keep You Cool
Sometimes things that seem obvious from the outside are not so apparent to the representative. If you get a ‘no’ and it’s a gray area, you may be better off accepting the ‘no’ and going on. I have heard from people within SAP that discourteous, unknowledgeable people are less likely to have their issues resolved. Being seen as obstinate on one issue may work against you on the next one.
Special Thanks
Luke Marson, Emeritus
Quick SAP transport quiz:
Let’s say I have a table with a configuration with 3 settings–a, b, c. The initial state of the table is blank.
I first save to setting a to transport #1001
I come back later and change the setting to b but I save to transport #1002
Lastly, I come back again and save the table with a value of c and save to #1003
I then release the transports and direct the basis team to move the transports to my QA environment in the order #1001, #1003, and lastly #1002 .
What value will be transported? (Read to the end of the blog for the answer)
When I went through SAP HR training many, many moons ago, I recall being impressed with the thoroughness of the curriculum. My training was several weeks in length and went through SAP HR soup-to-nuts.
However, I remember being distinctly shocked on my first assignment when I was tasked with updating some configuration and then being asked to place my changes something called a transport. Back then, the most common use of the term “transport” was a minivan from Pontiac. Wasn’t sure what to do!
My point is that functional resources are often given precious little guidance on the nature of transports.
The objective of this blog is to clear up a single misconception about transports. It’s a misconception that I held for a long time myself. It was not until I was able to play “junior basis dude” on an internal system that I fully understood how the alchemy of transports actually works. A quick summary:
Armed with a better understanding of how transports work, let’s revisit the quiz from before. As we learned, what gets written to the transport is the table’s current value at the time of release. Since the transports were all released at the same time, they will all have the same value–C. Therefore, this is the value that gets transported regardless of transport order.
Hope you’ve enjoyed this blog. Follow me on Twitter @brandontoombs to find out what ridiculously entertaining subject I tackle next.
The objective of this weblog is to alert you, dear reader, to the way that the new approval process functions in Enterprise Compensation Management (ECM) in Enhancement Pack 4 (EHP4). Judging by some of the beta-testing errors we have run into on our project, I’m guessing that not many companies have made the plunge yet. This blog will help you plan your path to the new functionality.
What’s changed (in a nutshell)
Before EHP4, the approval process for compensation planning was handled at the individual employee level. As of EHP4, The compensation approval process is now handled at the org unit level.
Why the change?
Compensation approval is often handled at the higher echelons of the organization. Thus the approver may need to occur thousands of employees at one time. Before EHP4, when the approver got ready to “do their thing”, the approval meant viewing and processing thousands of employees at once, which –surprise– caused the approver’s MSS view to grind to a halt. Many a functional analyst was called in to their boss’s-boss’s-boss’s office to help close out the merit process, hoping that their career wasn’t getting closed out at the same time.
So What’s The Catch?
Before EHP4, the Compensation Process Infotype (referred to hereafter by its number “IT759″), was the hub of the ECM process. With EHP4 a new control table (t791adm_process) tracks the approval based on the organizational unit. When the approver approves the compensation planning, the status of individual employees’ 759′s is no longer changed to “Approved”. When it comes time for activation of the planned change, instead of checking for a status of “Approved” on IT759, the business logic checks the control table to see whether the employee’s org unit is approved.
Key Gotchas
That’s all for now. Thanks for indulging me on my first blog. If you enjoyed, follow me on Twitter at @brandontoombs and I’ll let you know when I have more to share. I can also be reached at btoombs@toombsconsulting.com
Special Thanks
Jack Khoury, Cap Gemini
