Change can be hard. It doesn’t have to be hard, and it isn’t always hard, but from what I’ve seen and experienced in my consulting career it is often difficult for companies and people to really embrace change and make the most of it. How we do things tends to get linked too closely to why we do them.
Now, it can be said that not all change is good, and while that is true it is also true that this maxim is often used to resist changes in general. What I’m writing about are those times when change is needed for the common good - for the overall benefit of the firm or organization. Honestly, sometimes change that is good for the firm is difficult for individuals to accept. We can come up with all sorts of reasons not to change when the change impacts us and our work. I’ve seen all sorts of resistance to change in the SAP HCM projects I’ve worked on with clients - here are some useful examples.
One global firm had their authorizations setup so that users couldn’t see each other’s spool output. In an HR environment that is understandable - we don’t want other people to see the employee data we’re reporting or working with if they are not authorized to see it on their own. But, this also meant that users in the HR function couldn’t see what their teammates were working on - and when they were working together on a task or project, that really impeded their work. One user would run a report of employees, benefit plans or payroll wagetypes and their colleagues in the same job function couldn’t see the results. Each was authorized to see the same employee data so there wasn’t really an issue. But the company said this is their ‘global standard’ and nothing could be done. Resistance to change is sometimes cloaked in how compliance is implemented.
Another company had always separated the tasks for payroll calculation and payroll posting to accounting. When they implemented SAP, they kept that separation: the payroll group ran the gross to net, and the accounting group posted the results to FI. When there were issues in posting, as there are from time to time, the payroll group didn’t care because it’s not their job. The accounting group did care, but they couldn’t do anything to correct the employee data. They ended up with a reconciliation nightmare. In this case, resistance to changing who owned the work had a real impact on financial reporting.
There is more than one root to these problems. One root of these problems is that the SAP R3 software lets companies customize it so much that they can twist it around just enough to avoid changing. We can customize authorizations and we can program all sorts of work-arounds whether good or bad. Companies can end up literally recoding their bad or past practices into the SAP R3 system. And most often that inhibits the value they can derive from the software.
Another root of the problem is in differing interpretations of legal requirements. Sarbanes-Oxley is a great example, as are EU data privacy laws - many SAP clients are subject to them both yet the way companies implement them results in systems that function very different from one another. Similar to this are how companies interpret and apply local labor laws to the HCM software. I’ve seen very different applications of those laws - some more favorable or easily applied than others. One of the keys is how you ask the question of the internal legal team, and the another key is to review the impact of how you’ve implemented it. More than a few times I’ve seen legal teams say that the way their interpretation was implemented ended up with something they never intended, and then we refine it to something more pleasing both to them and the users.
When we are not willing to change how the work is done to better match how the system operates, we end up with suboptimal processes that destroy value. When we codify the old system’s features and weaknesses into the new SAP HCM system we hobble it from what it does naturally - and that destroys value. When we make the SAP R3 system conform to our mainframe mindset - relying on ‘overnight’ jobs and flat file processing for example - we destroy value. When we consultants don’t stay current on the newest features of the SAP software and cling to old methods then we destroy value our clients deserve to benefit from.
All of these problems depend on resistance to change. Firms benefit when people are flexible enough to change how something is done so that the same or better result is achieved. The problem is that time and human nature tend to weld together how we do things with what needs to be done.