VP, IT & Enterprise Applications at Graham Group Ltd
- Reasons for embarking on the switch to SAP (ETR: SAP) S/4HANA ERP (enterprise resource planning)
- Implementation process – S/4HANA roll-out, timeline and deployment method
- S/4HANA's strengths and weaknesses for customers
- RISE with SAP initiative and deploying S/4HANA in the public cloud
- Likelihood of customers taking on wider SAP products once using S/4HANA
Specialist (SP): We did the upgrade to 1709 of S/4. We were on ECC on HANA prior to that. We did what we’re referring to as a technical upgrade, so we did the back-end conversion and we’re still using SAP GUI to do a lot of the transactions and things like that. We have leveraged some of the Fiori applications but we’ll continue with that roll-out over the next couple of years.
SP: I’ll go back even further. Our implementation was in end of 2012, start of 2013, which was ECC 605 oncSQL server. We did a HANA Sidecar as a proof of concept just to test the technology, so that was for reporting, a year after, so it was in 2014 or 2015. Then we did an upgrade to Suite on HANA, which was essentially the same product just using a HANA database, and then from there, we looked at the S/4, and it was probably half a year planning and half a year to do the conversion to S/4 onto 1709 from our Suite on HANA implementation. That would have been in 2018, I think, when we did that.
SP: No, we’re entirely on S/4HANA. Like I said, the only piece, I guess, left to do is to do the front-end screens. We’re not leveraging all of the Fiori applications, we’re leveraging them piece by piece. That was part of our decision to do what we call the technical upgrade, was to have minimal impact to the business, and instead of trying to do a complete new user interface, we still use the SAP GUI screens for most of the
functions, and we’re rolling out the purchasing applications right now on the Fiori side.
SP: You’re right, it is our financial core, so AP, AR, GL, materials management for purchasing. We purchase in three different buckets, essentially. We’ve got what we call our overhead, which would be for our corporate functions of HR, IT, etc, we’ve got an equipment department that does a lot of purchasing for the fleet that we
manage, and then we’ve got our projects that do purchasing for the construction projects that they do. We’re also using the plant maintenance module for managing all of our equipment and fleet. We use the HR module and the payroll function as well. The other piece that we’re using lightly is the project systems. We do have a
construction application that we use separate from SAP and integrate it, all of the project information, but our record of cost or source of truth is SAP.
SP: It was a brief thought at that point. We were definitely committed to SAP. As I mentioned, our construction applications are integrated to SAP, so it was a very quick, “Are we still on the right path here?” and so it wasn’t much of an evaluation of other packages when we decided to do the upgrade.
Third Bridge (TB): Why wasn’t that much of a focus? Why did you have that commitment to SAP?
SP: To be honest with you, it just works really well. We’ve never had an outage, and I’m going to knock on wood here, never had any system challenges that way. The numbers always match up. They make sure that the core functionality, when you have a transaction flow through this system, all of the systems line up with the integration across the modules, so for us, it just meets the needs. The flexibility of the payroll solution is really key for what we need to do, especially in some of our construction environments where we’re dealing with union payrolls and things like that and lots of flexibility that we need for it to handle.
SP: There are a few factors I think that would lead people to either stay on a path. Like I said, the heavy investment to actually do an implementation, make sure you’ve got your business requirements and implement a solution, it’s not a small undertaking. To be honest with you, once it’s in there and it’s working really well, it’s hard to justify the cost just to change it out just because you want to if you’re not going to get much extra functionality by any competing product that’s out there. I think that’s a key piece of it.
The other thing that we really tried to do with ours, when we first did our implementation, there was a lot of customisation because we as construction people didn’t really understand SAP, our implementation partner at
the time didn’t maybe understand construction, and I think, after implementation, we realised that a lot of the terms, the way things are worded and things like that, there was core functionality that probably would have met our needs had we been more flexible in how we wanted a business process to work. We took a few years to
actually reduce the amount of customisation that we had to get back to as close to core as we could, which actually has helped us when it comes to doing upgrades, there’s a lot less rework you have to do every time.
Every time you do an upgrade, you’ve got to double and triple check all of your custom pieces, and the fact that we have less of those now makes it a lot easier.
SP: There were several factors. We want to stay current and being on the latest platform and making sure that we’re fully supported with the direction of SAP, so I think that’s one of the pieces. The other one though was just the simplification of the solution, which also gave us some performance that we need. We use the
resource-related billing for some of our cost reimbursable-type project work, and depending on the size of some of these projects, we could have over 100,000 line items that we need to generate onto invoices in a month.
The performance of that, just the shift from ECC, where it might have been an hour to process that, to Suite on HANA down to 15 minutes, we went from 15 minutes there to seconds on S/4HANA, so just the performance gain there was one of the biggest factors.
That and, like I said, the simplification, so the ability for
us to now access the tables, etc, to do reporting on top of it is just way easier than it was in the prior system.
TB: It seems you were drawn by the performance, the actual product itself, rather than being pushed by SAP talking about turning off maintenance for certain products in the future. Was it a more proactive decision on your behalf rather than a reaction to what SAP is doing?
SP: Yes, definitely. The performance, like I mentioned, was one of the key drivers. On some of our projects they have to produce a daily report to an owner to say, “Here’s the work that was completed yesterday,” and having that turnaround, like I said, into the seconds vs minutes or hours was definitely worth it. I think that push was definitely internal, for sure.
TB: Was it particularly difficult to get that through the C-level decision-making area? Was it particularly hard to sell the benefits of moving to S/4HANA and away from ECC?
SP: No, and the reason I say that is because we have a pretty strong alignment that our systems give us a competitive advantage. Having most or all of our projects using the same platform, using the same processes, is beneficial for us. We can have people move to different projects or different areas of our company and understand what they need to do. As far as that goes, we saw the S/4 upgrade as a core for, we’re
implementing a new construction solution in parallel, not in parallel, after, subsequent to the S/4 upgrade, to integrate into that core, and knowing that we were going to do that, we figured we needed to be on the current thing so we wouldn’t create more work for ourselves down the road. It was more of a roadmap conversation at the C-level that made sense and the buy-in was pretty simple.
SP: As part of the upgrade, there were a lot of really powerful tools that SAP provided to do a comparison of not necessarily a comparison of functionality, but more of a what’s the impact of the upgrade and what areas would you need to go look at and focus on.
For instance, if you had a lot of programs that did select off of tables, you had to go back and make sure you had an order-by clause and things like that, so your programming style, you’d have to change it. As far as the functionality goes, we met with SAP several times, so from their sales perspective, just showing the power of the functionality with the simplification, the analytic functions that you get as part of this, in addition to the transactional system.
I think there was a lot of excitement from our finance group especially, just on what they would be able to do when it came to a closing and being able to monitor the closing function vs having to do it all through email and checklists and things like that that people are managing on the side of their desks. From the functional side, it was definitely conversations with SAP, on the technical side, like I said, they provided tools that walked us through the effort and the things we needed to do.
SP: It’s both, for sure. That simplification that I mentioned on the HANA side and the way that things are stored and the performance gains that you get from that, coupled with the fact that now, on the front end, you can get real-time analytics. You can see things as they’re happening, essentially, vs the old style of waiting for batch processes to run and things like that. Just the simplification of the user interface, it’s a little bit more modern. You can hide the fields you don’t really need to show people, so you can simplify the screens even further beyond that. If you’ve been in any of the SAP GUI screens, you know that there could be 100s of fields there that maybe you only need 15 or 20, and people have to learn that, so training effort is also simplified.
You can get people up and running, onboard new people a lot better. There are definitely a lot of improvements from the user interface side, for sure.
SP: I think I did mention earlier that we tried to back out of a lot of our customisations to get back to a standard process. I’m guessing a lot of customers that you’re speaking out there, customers of SAP, have enhanced a bunch of solutions.
I know a few of my peers in other companies said that a lot of the customisation in their solutions was in the finance and the HR, and it’s just people wanting things a certain way because they were comfortable with how things had happened in the past.
If you just boiled it down to what problem were they really trying to solve, SAP probably solves it in a standard way, and you can get the same results, you just have to be comfortable with doing the steps in maybe a different order to get that result
vs trying to rework the whole thing to work the way you had it at your last company or whatever, for example.
If people stay close to that, the functionality is there. Like you said, you have to really question the what needs to be done, not how it needs to be done, and if people are true and honest to themselves about what that is and what outcome they’re expecting, and that’s what we found, is a lot of the standard way that SAP does things
gets you that result.
We’re really pushing back on our user base that’s used to having things a certain way and we’re saying, “We’ll get you that answer, but you’ll have to do it this way.” It’s painful at times, but definitely worth it, especially when it comes to staying on an upgrade path and being able to keep the product current.
SP: It’s actually all of those things that you just said. When you customise something and then there’s an upgrade, you have to test the core functionality, you have to test and probably make adjustments to your custom piece and then retest it vs just testing the standard process when there’s an upgrade and just making sure that the functionality is still the same way you expect it.
There are definitely savings there for time, effort,etc. The other thing, like I mentioned, is training. If you’re using a standard process, and let’s say you’re hiring
workers that have worked with SAP in the past and the company there was using a standard process, transfer of training comes built-in with people, so that’s another factor for sure.
SP: I think the scepticism would have been more on the business. Our department, like the IT department, was actually one of the key drivers of it, and it was a lot of lightbulb moments.
We’ve got a really strong team and they have researched SAP since we’ve gone in there, learned how things work, like I said, understood some of those terms. One of them was hold-back on a purchase order or a sub-contractor is the term we use,
SAP called it retainage.
Had we used the word retainage originally, there might have been a standard way to
implement it, but we ended up and built a custom process around that because our implementation partners didn’t understand what we were trying to say at the time. A lot of those lightbulb moments as we went through the early years there with our team and they’re like, “We could take this custom functionality out, give it back
to the users and tell them, ‘Just do it slightly differently,’ and away you go.”
I think they were open to that when they saw that they could get the result they were after, and I think most people are. There are a few people that get stuck on how it happens, but for the most part, people are receptive when it comes to that. I
think if there was resistance, it was more like, “It’s working for me. Don’t break it,” but when we showed them the value of why we would get back to that core functionality and the ability to, I think you touched on it a bit earlier there, is use that money and that effort to actually customise the pieces that really need to be special for what our business is, and there are a few of those places, but for the most part, your finance, your HR and your purchasing functions, they can be pretty standard.
TB: How quickly did those perceptions change about moving to a more standardised model, or is this still an ongoing issue, that back and forth between the business units who want customisation and the IT department that prefers a more standardised approach?
SP: I’m smiling a bit because it depends on the individuals usually. I don’t really want to pick on finance people, but once they have a way of doing things that’s repeatable and gets the results for them, they’re really reluctant to change it. Even if it is 10 or 15 extra steps and a lot of manual effort, once they know that it works, it takes a lot to convince them that, “If we just did it this way, we could take care of and automate the first half of this for you, you’d only have to do this little bit at the end here.” They definitely are sceptical about what that’s going to do to them, they’re resistant to change a bit at times, but usually the results are what will convince them. That and a lot of testing. We make sure that any changes we do we would test thoroughly
before we hand over to them to look at vs having them in on that process a bit earlier. Other groups definitely, “If you can make this easier and upgrades are easier, let’s do it,” so it depends on the individual, for the most part.
SP: We’re on-premise. We’re actually in the process of moving it to a cloud environment that we would manage, so really just leveraging a cloud provider for the servers and managing all of our environments that way, but we would still do all of the technical support of those environments.
SP: Partly, when we first did the implementation, most of our stuff was on-prem. I think cloud was fairly new and the stability wasn’t quite there when we first looked at it. The cost wasn’t there, for sure.
Connectivity, performance were the other key pieces. I mentioned earlier in the call about HANA Sidecar. We did that through a cloud provider, but the latency between that and the on-prem, getting the data there, reporting off of it, etc, the performance wasn’t quite there.
Now, we’re moving there because performance is there, price is there, you can have more flexibility in the environments, you can have a lot more control over turning things on and off when you’re not using them. Just being able to scale with our business. If we need more memory because we’ve got bigger projects, more transactions, then we can quickly do that without having to get technicians in. The other thing is if there are any hardware failures, it’s instantaneous, it’s moved over to new hardware, we don’t need to take care of that. I think just for stability now, the cloud makes way more sense.
SP: No, I don’t think we’ll ever be public, like public cloud with a shared container through SAP. We have no plans to move away from us managing it on cloud servers. That would be our state that we’re going to be in for the foreseeable future.
SP: We’re going to use the Microsoft Azure environment. That’s where we’re going to host all of our development, QA staging and production environments for S/4, eventually for our PI environments, our BW environment.
SP: No, the whole thing will be in Azure.
SP: Like I said, our hardware, it was due for a refresh. I think we were at five or six years. We were end of warranty on a lot of the hardware that we had on-prem, and we were at that crossroads. Like I said, price, performance, scaleability, availability, our guys don’t have to be here on weekends if a power supply fails or a hard drive fails or anything like that, it’s just way easier for us to manage this way and, to be honest, the cost is pretty much on par with what it would take for us to do it on-premise, if not slightly cheaper.
SP: No, it was definitely on our minds while we were in the midst of our hardware. We wouldn’t have done it until it was fully depreciated and we got the full value out of the hardware. From that perspective, it was really driven by, “We’re at the end of life of the hardware.” We did consider continuing on-premise, and like I said, cost-wise, I think it was almost on par, so it just made sense to actually make the leap now. We still have some of our other systems that’ll be on-prem that are connected to the S/4 environment for reporting and things like that that we will eventually move up to Azure as well.
The other piece to it is we don’t feel we need to do that with any urgency at this point because we were and are able to get the performance out of that reporting piece that I mentioned that maybe 5-10 years ago wouldn’t have been there.
SP: Yes. I think the ink isn’t quite dry on our Azure deal, and we’ll have everything moved over by the end of this year, so within two months, essentially. Our development environment is already in there, and I’m talking weeks after we signed this deal, so it’s so much easier and doesn’t take as much time to do those types of things these days. We’ve been very happy with the decision.
TB: It seems that once a customer of S/4HANA is live with it on-premise, shifting that S/4HANA environment into the cloud shouldn’t be too difficult.
SP: No, it definitely is not. It does take planning, there’s no question. With S/4, especially in our environment, you’ve got your landscape that you have to take care of, your BW, your PI, your core system, making sure all those connections and pieces are there. Once you have a plan of, “We can move this, then we can connect that, redo this,” as long as you plan it out properly, it’s actually not that difficult. We’ve got a really strong basis team and infrastructure team and they’re joined at the hip on this one and working well together, so I think that’s a key piece too, if you have the right people, it’s actually quite easy.
SP: 80% is not our experience when it comes to the performance of the cloud. We did benchmarking on both AWS and on Azure and found that those core reports, that billing functionality I was talking about earlier, they were all faster in the cloud environments than we could get on-prem with our existing environment. I would
say that the performance is there. I don’t think it’s less than.
The other thing I mentioned is if we needed more horsepower, it’s flip the switch and pay a little bit more if you like, but you can get that within minutes, not weeks of procuring hardware and installing it on racks and moving the environments over, etc.
It’s just a lot easier to scale, for sure.
SP: I’ll be honest, I have limited knowledge of what the offering is. What it seems like to me is that they’ll walk you through and get you into that managed cloud environment. Is that fair? Do you have that background on it?
TB: It’s where you just have one contract with SAP and all costs go into one subscription to SAP so it seems to be designed to create ease of deployment and transition into an S/4HANA in the cloud environment.
SP: I think if you were starting out with SAP and didn’t have a full team ready, available, a skilled team, that could do all of those parts and manage all that for you, then that might be appealing, for sure. With our environment, because we’ve got, like I said before, the construction solution, we’ve got our SAP, we have other
integrated pieces that when we try to do a test environment or anything like that that’s fully integrated and tests all of our integrations, it’s really a lot of effort to get those environments in sync from a data perspective so a project in one is the same as the project in the next, and the employees and all of the environments, etc, we wouldn’t be able to do the things we do as fast if it was in a fully managed environment like that. I think for us, personally, that wouldn’t be the best approach. I could see though if your business was running solely on SAP with maybe a few niche products that didn’t necessarily need to be kept in sync in a test environment,
then that would definitely be the way to go.
SP: SAP mentioned it, but that was about it. I didn’t have time to have a full dive-in with them on it. The other thing is, and our representatives here know, that our team is quite skilled, quite competent and selfsufficient. We did our own S/4 upgrade without a partner, so it is possible, so I think that’s maybe why they
didn’t push that conversation with us.
SP: I think some of the biggest hurdles that we had were with the simplification of the functionality. They had removed maybe a field or two here and there that we were using for certain functions, so there were a few of those instances where we had to look at it and go, “What are they proposing instead if they’ve removed that
functionality? What should we be doing?” There were a few of those head-scratching moments of, it may have been a custom piece of functionality, or we were using that piece of functionality in a custom fashion, we had to rework the process and find different ways and then, of course, retest a lot of that to make sure that we had
taken care of our business case.
There were several of those that probably took a little longer than we were
expecting, but not insurmountable. Then the other ones were where, with the simplification, they removed a lot of, what I’d call, summary tables or intermediate tables, and if we were leveraging those for some of our custom applications then we had to rework that. They did have what they called, I’m not going to get the term
correct, but like a virtual view, so they gave you the look of what the old table would have looked like as a view instead of a table into the core piece, but we found a lot of those the performance wasn’t very good on them.
The functionality was there, we could leverage it in the short term, but we had to rework some of that functionality just so we could get the performance out of it. Those are probably the biggest ones, just where
fields disappeared on us.
SP: Good clarification. On our implementation, our original one, yes, we had an implementation partner, we had consultants helping us through the stabilisation process of the first year or so, but our team built up the skill and knowledge from that point. I think our Suite on HANA upgrade, we did ourselves, which would have
been three or four years after our implementation, so since then we’ve done all of our own upgrades.
SP: Yes. We use the Business Technology Platform. We have a lot of craft labour for the construction projects, so they aren’t working on a computer system or anything like that, but we use the Business Technology Platform to have them register upon being hired and so that they can get in and get their pay stubs electronically. That’s a great use case for that. BearingPoint has a product called ETM.next, which is
equipment, tools and maintenance, built for construction companies or big rental shops that have construction or any type of equipment that they would rent to a customer, so we’re going to use that for our internal equipment group to rent our fleet out to our projects.
That’ll work off of the Business Technology Platform. With the RPA and Signavio, I’m curious about Signavio, I’ve seen a little bit of it, we just haven’t had time to dive into it, but I’m definitely interested in finding more about that and seeing if it can benefit us on the business process side. The RPA we’ve done a bit of experimenting with it, but nothing that we’ve rolled out to production, so just more R&D at this point.
TB: On the RPA [robotic process automation] side, is that specifically SAP’s own RPA offering there?
SP: Yes. It used to be SAP Cloud, but through the Business Technology Platform, that’s where we’ve done some experimenting, is within there, some of the tools that they have there, the RPA, some of the document management-type pieces, etc. A lot of it’s just R&D at this point.
TB: Why is it better to do that through the Business Technology Platform? Would you be able to build these connectors out yourself? What is the value-add?
SP: Could we build all that out ourselves? Yes, but then we’d have to build a platform for it, we’d have to figure out how to get people connected to it, and there’s a lot of that that the BTP just has built into it. The other, what I find interesting, piece is that you can enhance the functionality of S/4 and the core through industry partner solutions. ETM.next is one that I mentioned. There are a couple out there that are specific to the construction industry that we’re looking at as well. Allows you to have that custom piece that maybe you’re looking for to solve a very specific business problem, and it integrates into the core without impacting that upgrade path, like I mentioned before. It helps keep your core solution simple and pure and allows you to have that value-added functionality where you need it.
SP: Yes, absolutely, and in fact, we’ve used all of them, of the ones you just mentioned. We were using Ariba for sub-contractor pre-qualification. We’ve since moved from that. I don’t think that was a core piece of the functionality of their product there. We decided to do the purchasing piece using the Fiori in S/4, so it didn’t make sense to continue on that platform. We use Concur for expenses. We use SuccessFactors for our people management and we’ve got a roadmap there. We just implemented the recruiting and onboarding.
We’ll be looking at the learning, the skills and competencies and compensation as well as the Employee Central pieces of it, so that’ll be our HR platform going forward. You said is it more compelling? What we found is, early on, when SAP bought those products, the integrations weren’t there and you had to do a lot of that work yourself,
but a lot of it now is quite a seamless integration, which makes it appealing.
Your people are there, your cost objects, etc, to do any of your coding when it comes to concurrent expenses and things like that, and it’s integrated back into the core, so it just makes sense for that perspective.
SP: Yes, the one that we’re interested in, there are a couple, I guess, that we’re interested in, from a business planning perspective, because we’re a project-based organisation, looking at all of our construction projects, leads that we would hope turn into projects that we would do, we’ve looked at the PPM tool from SAP to help
us manage that and maybe give us some of that business planning. A business unit might say, “We think we can do this many projects. Here are the leads that are in the hopper,” so to speak, “and what we potentially think our market has on tap for us,” so there’s some potential with that solution.
The other one is the vendor invoice management for the back end of our purchasing process to help manage invoices and payables to our
vendors and suppliers.
SP: We did look at Workday just recently. We were using SuccessFactors for performance and succession, which was a little bit of functionality, but not so much that we couldn’t decide to go in a different direction if we found a compelling need to so.
With all of these things, it really boils down to a lot of times people will
come and say, “We should get this product. We should get that product,” we have to shift that thinking to, “What problem are we trying to solve?” What’s the best way to do it to manage the life cycle of an employee, for example? How do we get them on-boarded? How do we get them trained? How do we code time for them
on a project? How do we manage their certifications, if they’re a craftworker, to know that they have their first aid, their at-height training, etc? It’s looking at the whole solution to understand that you can take care of the entire employee life cycle vs, “This product maybe has a better interface for this one thing.”
If it’s not integrated to the whole flow in your entire system, then you’re going to end up doing a lot more work to make all those parts work together. I guess you sort of said the answer there in your question, integration really is
the key piece to it, and that was probably the biggest piece for us, is that we’ve got continuity of that employee record when it comes to SuccessFactors, for example.
SP: Absolutely. I think that if you’re not thinking from an integrated perspective, and even take our construction, from a lead to an estimate to execution on the project to handing over a 3D model of the solution with all of the quality and warranty information, etc, to our owner, that’s where we’re trying to get to. You want to be able to do as little work as possible to manage all of that and make it efficient, and having a
complete solution that’s fully integrated is the best way to do that.
SP: SAP is a really compelling way to go. If I was starting out today, even if I had a bit smaller company, I would probably look at it. If you have designs on being a bigger company, it’s definitely the way to go and start simple, because it can handle your business. It’ll take care of you. It has all the pieces that you need. You can add pieces on, like SuccessFactors, etc, when you get to a point that you need to do that.
We value our partnership with SAP. I’m actually on the EC&O advisory board which is looking at and helping grow the engineering, construction and operation space functionality that’s needed for our industry. It’s great because they’re actually willing to grow with us and help us solve the business problems we need to. Our investment is going to continue.
We will, like I mentioned, roll out the S/4 screens, the new user interface and the
functionality and gains that we’ll get from that, with each of our business units, so supply chain first, we’ll continue with finance and then HR with the SuccessFactors implementation. That’s a journey that we’re on there that’s going to be happening over the next 3-5 years. We’re going to continue down the road, for sure.
SP: Yes. I think the customer focus is there. I’m noticing that there’s definitely more of a partnership feel to the conversations that we’re having. “How do we help you in this area? Where are the areas most that we can help you?”
Even the subtle thing with me not knowing about RISE, it’s them understanding what we’re like as a customer and not pushing things on us just because it’s the trend of the year. I think there’s definitely a shift that I’ve noticed.