Transformation Every Day
00:17:45 · Alexander Greb
[00:17:45] S2: a good point that you're saying, the confidence, because I quite often ask myself, yeah, when you are up to, for example, a public cloud implementation, yeah, and you say this is this kind the the most modern thing you can do at the moment. Yeah. Because the deployment model and, the way you you move there and so on, everything there is is cutting edge. And then you start with the DDA, and you have consultants sitting together with people manually, going with them through scope items. This is this is completely ridiculous. Sorry to say that. But but in a certain way, this is absolutely absurd, yeah, to talk on the one hand about latest technology and then still have these kinds of, manual processes which, take days and in the in the end could could be not only far quicker, but also in a certain way far more encouraging about the possibilities of technology we have today.
00:18:43 · Louis Schmidlin, Alexander Greb
[00:18:43] S0: Yeah, absolutely. And if you look at what kind of tools the consultants still work in, in these long Excel sheets, mapping scope items to required manually, and I think many that worked actually as a consultant can still remember how this manual mapping is working, have tons of workshop notes that lay around somewhere and not at all in order. If you look into the SharePoints, it's quite a mess. Often the customer come and actually present us their SharePoint and we're like, what are we doing with all of that? There is so much misinformation and it's so unstructured in the way they're working, but also how they go about the tooling, I think needs to change with how the market is evolving. And I think there is still a big discrepancy. And I understand the critics there that, you know, you have consultants that did it thirty, forty years in that way, but there still needs to be a way to actually bring them a new kind of way over to go about these tasks, and I think mapping scope items to requirements on Excel sheet is not the way to go about that. [00:19:57] S2: Absolutely. But then, of course, the question, what do you do differently?
00:20:04 · Louis Schmidlin
[00:20:04] S0: I think what you do differently is kind of two things. You enable the consultant at every step of the way that any sort of these manual tasks are being taken over by technology. And it's just about reviewing and seeing what, for example, AI is putting and is that actually right? Bring your industry expertise, your process expertise, etc. And then going over with the kind of customer relationship trust, present the most critical points, navigate these political differences, and these issues then can come up in this kind of huge transformation project or even in the smaller one, and then translating this input back into some sort of an AI that then can start working with that again and amend the results accordingly. And I think it's important that consultants don't need to learn another tool and a new methodology, etc, but they can just use the tools that work already in, let the AI go over it, understand it, and transform it in the right way, bring it in the output as the consultant already know, and through that lead them much more efficiently through these different stages of a transformation. And the point of that is that because you have these insights, you have this transparency, you can start thinking about processes in a much more greenfield way. You can actually say, okay, do you really run this process like this? Do you don't want to go here in a much cleaner way and try to impose this clean core mentality from the ground up in the end to have transformation project and processes that the customer actually understands, that are actually clean, and in the end that are delivered much more efficiently.
00:22:05 · Alexander Greb
[00:22:05] S2: Hi there. Quick break for a short message before we go right back to the episode. Enjoying the insights and stories on transformation every day? Want to make sure you never miss an episode packed with practical tips and best practices from the SAP world featuring conversations with some of the most interesting people in the SAP universe? Then hit that subscribe button on your favorite podcast platform, whether it is Apple, Spotify, or any other you use. And if our podcast brings you value, we would be incredibly grateful if you could leave us a five star review and share it with your friends and colleagues. Your support means the world to us. Thanks so much and happy listening. Yeah. In a certain way, for example, this means for a consultant that his work is actually changing. It's less about fighting with the system. It's more about being a classical consultant who really takes a customer by the hand and leads them then to, to to the new state of of a transformation, which is what we basically pray since years, which should be the way that we approach things, yeah, instead of, just, treating everything as a technical exercise. Know that technical exercise part will be done by agents or LLMs that you use within that case. You are then again responsible that, your customer works differently on Monday after the go live, or on Monday after the... You change something in the system, which is a fantastic thing, yeah, because it's, about to solve the big problem, that our whole industry is having since decades, which is, yeah, where is the value in that? Yeah. You are far more value focused after this than than before. But but give me give me a short walk through what what you're... What you are doing, what you're offering as a technology, as as a tool, as as how you enable, with what tooling the consultant to be basically the consultant of the future?
00:24:26 · Louis Schmidlin
[00:24:26] S0: Yeah, I think the first part is really about kind of capturing everything that the customer has, or maybe even yourself has already in sort of documentation, knowledge, integration, so you integrate into already the existing tool, into a Signavio or into a LeanIX, into a Calm, and bring all of the knowledge right in a platform that it can work with the reality of the customer. On the other side, you also connect to the actual system, so you connect to an ECC system, read out the custom code and give the consultant the possibility in natural language to see what is actually going on in a customer's legacy estate. What is custom, what is standard, how is everything built up, what is being used. Of course, the same side, you can also do process discovery on your transactional and event data where you can see, okay, how the processes end to end actually work at the moment for the customer. And through that, a lot of knowledge gaps are actually being produced. Because what you first need to understand as a consultant is not just what is in the code, but also why are they running a process like this? And I think there the right question needs to be asked, where are the inconsistency? What is not part of the code? Why are the enterprise customer uses them that way? And exactly these questions need to be written down and need to be asked by the consultant or by the technology itself, the right stakeholder to get a full picture of their assets and estate. And that all goes in kind of one place, which we call the single source of truth. And the single source of truth gives for all of these kinds of lines of businesses, the different requirements that are already existing, the different as is, or maybe they're already existing to be processes. It tells you what is the old system architecture, what is the new system architecture, and all of these deliverables the consultant can take and bring to the customer and say, is this right? Is this wrong? Do we need to amend something or out of our own experience? Maybe this process can be amended in that way. So it's really about technology, the consultant, and in the end the client working together.
00:26:43 · Louis Schmidlin
And as soon as this baseline is kind of given and the single source is populated and the conflicts have been resolved, you can start designing, you can start doing the difference between assets and to be processes and process comparison. And you can map these to be processes against the standard and tell them per requirement, is this now a fit? Is this a gap? Is this a fit with configuration? What are the different process steps? Or you can run it if it's a template rollout against different templates. And through that, you help the customer in much more efficient way design their future estate and how their processes actually need to run. And that is then the end of design, but design is not just enough. You also then need to execute and you need to help the consultants to execute much faster. So what are the right configuration steps? Where after the RISE with SAP framework do you make or how do you go about the different gaps? How can you use configuration agents to directly configure in the system? How do you bring custom code over to the new system? Everything proposed, because I think that's what AI is really great at, at proposing these options and letting the consultant making this decision. And that goes then as far as bringing it into a release management, the cutover plan, bringing it to go live, making sure that the test scripts are written, the feedback is being put back into the platform. And during this way, you will have a lot of, deliverables. You're gonna upload the 2B processes, you're gonna upload certain requirements directly to Cloud ALM, you write functional specification documents, technical specification documents, cutover plans, and all of these deliverables on the way that the consultant needs to document it right, to present it to the client, are being written with the help of AI and the consultant together.