HR Vision Podcast #30 – Consulting ins and outs ft. Stephan Schoeman

Ivo:
Hey everyone and welcome to the HR Vision podcast. I'm your host, Ivo, and every week I'm going to have a conversation that matters about HR.

This week I have Stephan Schoeman with me. Welcome Stephan. How's it going?

Stephan:
Very well, thank you.

Ivo:
Thank you for being here. Stephan is based in the UK and he's an implementation consultant at FourVision. He has an etensive track record in HR technology. So this should be fun. Stephan, Are you ready? Excited?

Stephan:
Yes let's go!

Ivo:
OK. Alright, let's start by just getting to know you. Give us a little bit of an introduction about yourself. What you've been doing in this in this area?

Stephan:
So yeah, I'm originally from South Africa. I immigrated to the United Kingdom about seven years ago. So based, as you said in the UK at the moment, my career started on client side in human resources. So I was a human resource manager. Then through career progression, also moved into payroll. So I have an extensive experience in payroll as well.

Then through my various positions, got involved in implementation of HR and payroll systems and that's where the consulting started with. So I worked on quite a few implementation partners in South Africa, mainly on payroll. And then when I moved to the United Kingdom, I got involved in the human resources software implementation space. So I have been implementing Dynamics HR now for four and a half years.

Ivo:
OK. And that HR background, it was always something that you were looking for, it just came by chance? What happened there?

Stephan:
Yes. That was my career projection. So I studied a bachelor's degree with psychology and sociology as majors. In South Africa, we've got quite a legislated labor environment. So I also studied labor law. So I was practicing as a labor consultant and in the labor law space.

Ivo:
OK. And then your career naturally progressed to the HR technology part or the implementation part? Or was it something that you always preferred instead of a general HR list or something? How did that happen?

Stephan:
Through the various positions I held, I was heading up the HR department and then got involved in implementing HR and payroll systems. So no, when I started out, the idea of technology was never on the horizon. That was a bug that bit a bit later. There I was fascinated with the system side of things rather than just the day to day operational side.

Ivo:
Why is that? Can you identify what it is in technology then gets you that gets you excited? Like fixing processes, What is that?

Stephan:
I'm a very methodical person. And when you do a project implementation, the planning and the structure around projects. And yes, the satisfaction of giving a client a good solution to make their life easier is always a bonus.

Ivo:
OK, I see. Yeah. let's get to that. You've been a consultant for some time now in HR technology. I wanted to ask you, like, what does it mean for you to be a consultant? What do you think are the must haves and what gets you excited about it?

Stephan:
Yeah. So I think if we take it from an angle, what makes a good consultant: First of all, it's a communication. Obviously that is key for any project or any good consultant is to have good communication. In that I mean to know your subject matter. So to be an HR consultant, obviously you have to understand the HR environment, and I think that's probably what's where I have a distinct advantage is having been an HR practitioner before I became a consultant, I Understand the day-to-day working and the pinch points or the heartache that HR people normally suffer. Because they are not professional IT minded people. If I can say that way.

So it's a different way of communicating with human resources practitioners. It doesn't help you to throw a lot of of technical jargon or system language at that audience they don't respond to that because they it's they don't have a reference point when you start talking systems. So you have to understand their world and communicate to them in that.

So yes, talking processes. Understanding their day-to-day operations, how they actually function and then bringing their technology solution to that. And in saying that, it's also one of the things I find quite often is: because this audience is not very system oriented or IT minded, they would normally come to a project wanting a better system, but quite often you find that just want to replicate what they had because they don't know what's new, or they don't know the questions to ask you. "How can we improve the problems we had before?", so in that again, a good consultant will understand and start talking processes and understand what is it that you actually want to achieve. Let's not design your process to fit a system. You need to have the base practice processes in place and then we get a technology system that can facilitate those processes.

Ivo:
Yeah, I think like, that is indeed one of the... And a lot of consultants tell us that, adapting your communication to the audience that you're speaking to, right? And you will do that to a point where it was actually my next question. I know that one of the most common challenges for customers implementing new tools is actually it has to do with legacy systems, right?

They're to using the system way with a certain tool and they expect the new tool to work the same way because they are not IT minded like you said. So why do you think that is first of all? And how do you go about it to overcome that challenge?

Stephan:
Like I said, so quite often you find that the tool that they currently use is all they know. So they aren't in the space of working on across multiple systems or having experience with different HR solutions. So when they come to a project the way that they've been doing things is the only way they know how to.

So introducing a new system, it's again you approach it from: Let's step away from the buttons you click or the screens you look at. Let's look at your process. So when you look at recruitment, when you look at employee lifecycle, so the cradle to grave process, let's break that down in what do you actually do? Who are the teams that interact with each other? What is the communication that flows between the teams? And how do we based get or what is the best result that you wanted the end. Once they understand that process.

And that also gets them thinking of what are we actually doing? Are we doing things just because our existing system forces us to first do step 1, then Step 2, would we rather have Step 2 then step one - because that would make our life easier? They as HR people don't normally done think about that, because they just do things because that is how they talked to do, because the system says click one then click two.

So when you take them out of that: forget your existing system. Let's talk about your process. That gets the cogs of thinking turning. So I think that as a good consultant, it's to have that ability to communicate and get the stakeholders to think that way. Let's talk process. Let's design your process or better document your process and refine your process and then we bring a system to that process to see how can the technology facilitate that.

Ivo:
OK. Interesting. That sounds like a good a good approach. Did you find throughout your career that this approach indeed has better results than just show the product, you click here, click there, and then and then you're done. Or do you also feel like not only you change that approach but also the customers just want that approach to be done then what they used to see like different screens, images and you click here, you click there.

Stephan:
With, well obviously when you introduce a new system, you have to demonstrate the capabilities of the system. But yeah, then in your requirements workshops where you actually do go into a deeper dive into what is it that the client actually wants out of the system. Again it's. Through experience that I learn you don't just focus on the system to say let's go from screen one to screen two, to screen three.

Again you do at a high level; this system that you looking at implementing is capable of... and again it's not getting sidetracked in a project by showing them too much, because most clients again have a scope of what they want. So a project comes with a scope. If you jump in and show the full system and spend days demonstrating all this functionality, the client can easily get sidetracked: "Oh yes, I like that. I like that. I like that." But that was not the aim of the project in the beginning. So you need to be mindful of that as well.

So yeah, I've definitely found in approaching projects it's you demonstrate the capabilities of the system at a high level and it's more introducing the new technologies' terminology. So obviously when you start implementing a new system, you're going to start using terms and jargon that refers to the new system. So it's what my approach is normally just to get the audience familiar with the new language that I'm going to use for the system, rather than restrict them to "let's look at building your system from screen to screen to screen."

Ivo:
So, OK I get it. All right. Uhm, that, that is. That is very interesting and very insightful. Is there any other challenges that you find common with implementations? Beside these difficulty to adapt to new to new systems, that you find interesting in your in your career with your experience?

Stephan: (13:00 TIME)
Yeah, probably. If you, as I said, my experience crosses from HR into payroll as well. So I've been involved in quite a few payroll integrations and implementations and what we find quite often on the payroll side is. OK. Their current system might push a lot of data to the payroll system as well. And when we as FourVisio,n 'cause, we've got quite a lot of experience in the world of payroll implementations or integrations as well.

What we find challenging is when we normally start asking clients: Why are you sending 16 fields of data to a payroll system, when you actually only need four or five. And those challenges, having clients then normally push back, because they don't understand - "but we needed it before. We integrated it before, why do you not wanting to integrate all this data?"

On the HR side as well, we often find the legacy systems have unique fields or they customized their previous system for to accommodate certain things, and within that system restraint they couldn't get the perfect solution so, but because they've been using their legacy systems normally for a while, they expect the new system to replicate those things.

So it's always that challenge. And to know when and how to ask those good questions: Always why - Give me a business justification why this needs to be this way. As I said as a good consultant, you should know your area. So we know what is required data in the HR world and in the payroll world and especially across different legislations, there's a lot of restriction or if we took GDPR or in Africa there's POPIA, in the US there's Sarbanes-Oxley. So there's a lot of restriction on privacy of data, and we are specialists in our field and familiar with those restrictions. So we will always challenge on a new implementation, in the best interest of the client, is when I challenge you why you're taking that.

It's not because I'm too lazy to do what needs to be, but it's normally we with our experience, now you could potentially have challenges in the future if you take this whole bunch of data and push it to another system. And if it's not required, you are making life more difficult than it needs to be. But clients are quite often hesitant to let go, because they used to have it before and want it again.

So that's always the give and take and the political game you need to play, but as a good consultant you don't just ask "why". Because I think it's stupid. That's not how you approach your client. You need to explain to them the intricacies of what they are trying to do, and where it could negatively impact them. And normally then they understand and appreciate that. I find that if you explain to clients properly what the negative implications could be, they are very receptive and appreciative of that. So they understand that and trust in you, that you do have their best interest at heart, and ultimately that is what we're trying to achieve. To give the give them the best solution, most secure, most robust, and obviously scalable.

So that you can grow with your systems, so that you don't repeat this painful process that you are going through at the moment, of implementing a new system in two years time because this new system that we implemented again fall short of giving you the best solution. So you want to throw it out the window again.

Ivo:
Pretty insightful, OK, very cool. Yeah it's all about communication. Giving the right context, informing the customer, just always with their best interest in mind, right?

Stephan:
Yep. Let's say the listeners just, for an example, if you can give us like kind of a step by step process. Let's say someone listening in, they never experienced an implementation of a new system like Dynamics 365 HR. How do we go about that? do you set up a meeting to try to find out where are the stakeholders? What is the process of that implementation? If you can give us like an overview?

Ivo:
Yes. With most projects, I'm always hesitant to say all. With most projects, it normally starts with a presales. So a client would go to market with a set of requirements. There's normally a set of requirements that they lift from their existing system. So they will approach vendors with their requirements and look at new possible systems. There was normally a bidding process or from sales side an investigation. At a high level to see: Is our system fit for purpose for this client, and then if everything was followed through, by the time it reaches the consulting side, the project would normally have been agreed. They would have been a scope agreed.

By the time the implementation consultants get on board is the project is normally well it's project kick off. So we would then be introduced to the client, understanding who the stakeholders are, what the scope is, what they're trying to achieve with a project timeline. And then we as consultants go into the discovery or analysis phase. We will then have workshops with the different areas and again this a very generic explanation. So it would depend on the different modules within the HR application that were interested in the different processes.

At a very generic level, yes, you would have discovery workshops. Or every stream or area within the HR space that they're interested in looking at implementing your technology. During those workshops you, like I said, would introduce the new product, the capabilities, but then go into the deeper level of discovery of their processes: How they work, what they're trying to achieve, what their policies are. Or what their different contracts are. And just like Leave and Absence, you would discover the different leave plans they have, in how many countries they operate.

So that could be a one day workshop. It could be a week's discovery, depending on the size and intricacy of the various clients.

You normally translate then those discoveries or requirements into what we call a solution design. So we will then take that away as a consultant, and apply those requirements to the system, and give the client back a document explaining how we will meet your requirements through our technology or our software.

That then gets approved by the client and then we start configuring the system based on those solution documents. Then after you have configured the system, there is... FourVision has an approach in our projects to have a playback session. I would then demonstrate back to the client. How we have met these requirements within the system. Also the high level, we call them "show and tells". So how would you actually use the system, or hwo to execute the processes that you have given me or that you want the system to do. At a high level.

The client will then go into a testing phase. So there's normally user acceptance testing, where the client will test the system to see whether it actually does what they want it to do. Does it meet the requirements? Are there any gaps that they might not have told us that this a process that they need, or that we might have missed even through the solution design document. They might have been miscommunication or misinterpretation of a specific rule or a specific policy. So that is normally a hashed out during the user acceptance testing phase.

There could be a single cycle of user acceptance testing. There could be multiple depending on the size of the project, but during user acceptance you normally have resolved these issues. So if something comes up where configuration was missed or something should be changed, you fix that during the UAT. And have the client retest it to validate it. So normally as part of your UAT exit criteria you have a list of tick boxes to say: Yes it meets, yes it needs.

So you have a "go/no go" stage gate after UAT, to say yes we accept the system, it meets our requirements. Then you will go into a go-live preparation or go-live readiness. Where you then look at how do you. Get your legacy system data into your production system, ready to transition and start using the new system. As your new solution.

Having said that, there's a layer of functional consulting, that is normally the discovery, the configuration and assistance during testing. But there's multiple added layers to this project. Like I said, there's environment, so there's environment management. They could be solution architects, where you have multiple systems maybe integrating. For example, I mentioned the payroll. So if there's a payroll integration you would have solution architects also on the project where they need to ensure that the systems communicate with each other properly.

All of that forms part of the bigger project lifecycle.

Ivo:
Of course. You can always add complexity I guess, but I think for people to understandall the steps, I think you gave a great overview. I really think so.

Very cool, Stephan. Thank you so much. that's mostly what I had for you for you today. Is there anything that you would like to say as a major consultant for HR people out there that are still using those old, beautiful Excel files?

Stephan:
Excel is nice, but as you could see, my passion lies in having a decent solution. And there are decent solutions to make life easier. It may be daunting, normally HR people are not systems people. So when they hear new systems it sounds daunting, but in finding a good partner and implementation partner that have the skills to guide you through this process, there's definitely reward in having a good system. Like I can definitely promote Dynamics 365. I've been working at with it for quite a few years and we've had from small organizations with 50 employees to large organizations with over 20,000 employees, all shapes and sizes can find value in a system like Dynamics HR.

Ivo:
Perfect. I wouldn't say it's better. Alright Stephan, thank you so much for being here with us today. I hope you enjoyed it.

Stephan:
It was a pleasure. I hope I could add a little bit of value.

Ivo:
I think you did! Thank you so much. Have a good week guys, and we'll see you next time.