Blogs

Why Onsite All the Time?

Why is it that firms are willing to outsource - both off-shore and near-shore – critical business processes yet they continue to insist on implementation teams being together onsite every week for months or years at a time? Many firms trust a business partner in some remote location to process their benefits and payroll, which are two complex and critical business functions. If people don't get paid, it's a safe bet they won't come to work – that is critical! Yet, when implementing systems such as SAP HR, firms insist on flying consultants from all over the country to a central location – week after week for months or years at a time. That's no longer a necessary or beneficial way of doing projects.

Software firms create big, complex systems with teams spread out over the globe. They have the project management methods and technology to make that work. Other products are designed, created and rolled-out by teams that are spread out over the globe. Companies have office staff working from home 2 or 3 days a week now. And aside from off-shoring some ABAP development, we don't see offsite work happening much if at all with SAP implementation projects. Why is that?

Familiarity

Many SAP consultants and project managers don't know any other way to do it. They have always relied on and sold the model of having everyone onsite together, in a big team-room, working all week (or maybe Monday-Thursday) face to face. If I can see you here in the team-room, I know you are working on something. If I can't see you, I don't know if you're working or not. And that is, I believe, one of the big reasons we still fly consultants in every week. Measuring work by walking around and seeing people at work is different from measuring the progress & delivery of tasks on a project plan.

We Will Lose Business

Another important reason we fly consultants in every week is that we're afraid that if we don't, someone else will, that they will gain the client's favor, and we will lose some business. The flip-side of that is the client will get only those consultants willing to travel every week, which isn't the same as getting the most qualified and appropriate resources for the project. Many experienced consultants no longer want or need to travel every week, yet their contributions are valuable. I believe many in the consulting profession don't want to really recognize this trade-off because it's uncomfortable to talk about.

Quality Will Suffer

Many successful firms have had geographically diverse teams working together for years. Even for the traditional office jobs such as those we find in HR, accounting and IT, some firms have had a lot of success letting employees work from home 2 or 3 days per week. If quality suffered or it was too expensive, they wouldn't continue doing it.

Technology

In the past few years there have been many advances in using technology to bring disparate team members together to work on projects. The big favorite? Microsoft Sharepoint – the all-pupose site for bringing teams together to work on projects. And new from SAP there is Streamwork – a site for collaborative work. Don't forget Skype and dozens of Instant Messaging systems. There is plenty of technology to help dispersed teams work well; perhaps the challenge here is to determine how best to use the technology.

Sustainability

Is this merely a buzzword? Or, do we take it seriously? How sustainable is it to fly consultants in every week, drive to an office, stay in a hotel, and fly back? A year of flying alone generates tons of CO2 emissions; round trip from Cincinnati to New York City for a year generates about 15 tons. SAP itself has made quite a commitment to sustainability, as have many of their customers and prospects. Will consulting firms join them in that endeavor, and if so, how?

Working for Balance

There are some definite advantages to working together onsite during certain phases of the project. Project Preparation and a good deal of Blueprinting are best done face-to-face. And even though working from disparate locations, it's still a team and having face-time is a critical part of team cohesion. Still, that is nowhere close to being onsite for the whole project. It's time for SAP implementation practices to catch-up with the distributed way that work can be done today.

Managing Expectations: Good, Fast & Cheap

I came across some wise words a few days ago; and as wise words will do, they have been spurring some thought:

'Good, fast, cheap - pick any two'

As a consultant it sounds a bit self-serving, I realize. Stepping outside the consulting world, the wisdom is apparent. Can you hire a plumber who is good, fast and cheap? Good and fast - yes. Fast and cheap - yes. Good and cheap - probably. But all three at the same time? How about cars? I think it holds true, on the whole, for that too. As a general rule, I do believe it applies to consulting.

Yet, I see examples every week where someone is expecting all three: good, fast and cheap. And I suppose one can expect and demand that, but the results won't be good. Take a look at the failed projects you know of - and there are a good number of them around - I suspect that they were demanding good, fast and cheap - and something had to give. They had cost overruns, or quality suffered, or they took longer to implement than planned.

This is different from maximizing or economizing; we should all strive to do good work, without wasting time, that is of high quality. The point is that these three factors are all related. When maximizing the three goes over the edge into compromising one or more of them, then we are really getting what we asked for.

Looking at SAP HR for Higher Education

When SAP created the HR module most of their customers were in manufacturing. Over the years they adapted the HR module to fit a broader range of customers, and the past few years they have been expanding it for Higher Education customers. That expansion is still happening, and there are still some rough spots in what SAP delivers – and doesn't deliver – for Higher Education HR. Here are a few things to be aware of when taking a look at SAP HR for use in universities:


Concurrent Employment: Also known as CE. This relatively new functionality allows a employee in the HR system to have multiple work assignments, each with its own rate of pay, employee type, and so on. This is a great piece of functionality, but it does have some technical and practical implications. First, each assignment an employee has must be in the same pay frequency. So when there is a (biweekly/non-exempt) staff person who is also a part-time faculty (exempt/monthly) it requires new ways of thinking about pay frequency, for example. In this case, you end up paying a part-time faculty a fixed amount on a biweekly basis, or a full monthly amount on the last payroll of the month. For some customers it's a real mind-twist to make biweekly, exempt faculty payments. It would be easier to pay everyone biweekly, but that is not likely to happen (if you do it, please let me know!).

And how do you identify the main assignment, and when it changes? If there are two assignments in different employee groups, which one is used for determining benefits eligibility? What do you do – and how do you know – when that changes? The system handles all that just fine, but getting the business policy, process and change management worked out can require some significant effort.

When recruiting, you might fill a position with a new person, or by adding a new assignment to an existing person – figuring that out in the recruiting process gets complicated. Many universities use a non-SAP recruitment software, making this even more complicated.

Concurrent Employment has received some bad marks from some consultants the past few years. Like any new functionality SAP releases, it is rough the first few years and the first few implementations. However, CE does work fine now if you know how to work with it. It's stable and being released in more countries. If someone is telling you to avoid CE or that it has all kinds of issues, I would bet they haven't spent much time with it or they don't understand how to work with it.

Position Management: The position creation, budgeting and approval processes are much more complicated due to some Civil Service requirements as well as Position Budgeting and Control (PBC) practices. Setting up PBC is not all that complicated, technically, but adjusting business practices to how it works can require a lot of change.

Multiple Employee Groups: Many companies have distinct employee groups to manage – executives, staff and workers, for example. With universities, the groups are faculty, staff, students and non-employees – each has its own requirements and some specific processes. Recruiting, hiring and on-boarding varies a lot among those groups, for example.

System Integration: In Higher Education there are several enhancements that need to be done on top of the delivered SAP functionality to tighten up integration among HR, Financial Accounting (FI), Funds Management (FM) and Grants Management (GM). It is critical that what gets entered can be paid and charged without errors and within compliance (particularly for GM). The standard SAP integration really doesn't provide enough in this area.

Workflows: In standard SAP workflows we talk about the 'chief' of an org unit initiating and approving most of the items. In Public Sector and Higher Education, the chief of an org unit may not be the one to initiate a process; a Grant Principal Investigator (PI) might initiate or approve a workflow but is not a chief, or a department head might be the chief but their business administrator initiates workflows. Custom workflows and Org Management relationships will be needed to handle those cases.

Payroll: Integration with FI, FM and GM gets complex – fringe benefits calculations and expense allocations to funds and grants need special attention because the functionality SAP does deliver in those areas is pretty thin. This usually ends up being a combination of custom payroll calculation rules and custom payroll functions.

Deferred pay is not something that is really built-in to SAP HR or Payroll. There are a couple ways of getting it setup, and since it is not an 'out of the box' scenario it requires some time to analyze and design.

Summer: Managing the time between academic years can be challenging – do you make faculty 'inactive' and then reappoint them when they return? How does summer pay fit in with benefits and grants? Will HR initiate all that or will that be done via self-service in the departments?

Terminations: Knowing when to terminate (or, 'separate' for a friendlier term) part-time faculty and students can be challenging – how do you know when they simply stop working for a while, vs they left the university? Reporting can be done, but it is not always straightforward, particularly when an employee has multiple assignments.


Those are some of the more obvious points to be aware of when looking at SAP HR for Higher Education. Though there are some gaps and challenges, the product definitely does work. As SAP releases more enhancements for Higher Education, and as the customer base grows, we won't be talking about 'special' requirements for Higher Education.

Why SAP HR/Payroll Projects Fail

Two SAP HR/Payroll project failures have been in the news recently - Queensland Health and Marin County. That reminded me of a couple earlier failures that were reported in the news - LA Unified School District and State of California. Now, one can argue if these are really failures; employees are getting paid in three of the four cases after intense work to get things corrected. I count it a failure if a project gets public press time for not working out, and all four of these qualify on that measure.

On the one hand, I am puzzled by these failures. SAP HR/Payroll has been implemented thousands of times, at many firms that are larger and more complex. On the other hand, I'm not surprised at all. Successful SAP HR/Payroll projects are complex and require a lot of detailed work. And it is very interesting that all four of these examples are in public sector organizations. For-profit and private-sector implementations have, I'm sure, failed now and then. But the last one I remember is at Hershey Foods in 2002. Is this a public sector problem, a consulting problem, a software problem?

SAP HR/Payroll has been implemented at other public sector organizations - universities, cities, Federal agencies, school districts, and so on. The first one I know of went live in 1998 and is still going strong.

Although the SAP HR/Payroll software has certainly had its growing pains, it does work. It's not the easiest or most intuitive software around, yet it does work for thousands of SAP customers around the world.

In my opinion, project failures start and end with the consulting firm. We can say all we want to about customers not doing their fair share or not being ready for or agreeable to change. We can point to software defects and shortcomings, which are real. However, if consultants 'give professional advice' then it is our responsibility to call attention to issues that affect our client's success. If the software has critical errors or functional gaps, then maybe that software isn't right, or ready, for our client. If our client isn't ready for the amount of change that a new software package will bring to their organization, then maybe the scope of the change needs to be narrowed to what can be handled. If our client is not willing to pay for qualified and experienced implementation resources - or we are not willing to staff the project with such resources - then perhaps expectations need to be managed to line up with capabilities.

One of the biggest obstacles for implementation projects, regardless of the software package or industry, is the conflict between the consulting firm's goals for giving good advice vs. making a profit. There are tensions between those two: when the good advice is to cut scope, spend more on implementation resources, or invest more in change management then it is likely that profit will decrease.

Most times, experienced consulting firms know how to plan a project so that they can both provide good advice and make a profit. However, as the four cases mentioned at the beginning illustrate, that is not always the case.

Wrinkles with Enhancement Packs

SAP's Enhancement Packs (EHP) are great for releasing new functionality to customers. They can install and fairly-conveniently switch-on only the additional functions they want. SAP is taking Enhancement Pack 5 into ramp-up now, and it promises to deliver some good new HR functionality. However, there is one annoying detail that keeps me from getting too happy about SAP's EHP delivery.

EHP's require the system to be at a certain base Support Pack (SP) Stack, which corresponds to an SAP ERP SP Stack (take a look at note 1064635 for details). In other words, to install an EHP you might have to apply regular SP's to get up to a required level. SP's - and their HR cousin the HRSP - are changes to core SAP ERP functionality; you can't switch them on and off. Installing ERP SP's and HRSP's requires extensive testing and change management. It's like a mini-upgrade since it affects core functions. And so that puts a big wrinkle in the EHP story: you might have some unavoidable core changes to iron out when installing your EHP.

I really like the idea of Enhancement Packs, and having developed a fair amount of software in my lifetime I can understand why they would require the base system to be at a certain SP level. It all makes sense, but it's often challenging to manage that at the customer's end of things. The quality of SP's and HRSP's is getting better, but still, every year when customers apply them I hear of a few surprises: something that worked fine for years is now broken or works differently; last year there was a syntax error in the ABAP code at one customer site; and functional changes get delivered but are found nowhere in the notes or documentation. Those who have been using SAP HR for a few years have come to expect and plan for this, but that doesn't change the fact that it requires a significant amount of effort.

So when planning your EHP strategy, be sure to consider the change management and testing effort that might be required going to a newer SP/HRSP level.

Syndicate content

Copyright © 2001-2010 by Insight Consulting Partners - Contact Information