Opti.Cast: An interview with Alexander Himmelmann from Ecovis KSO
Don’t be put off by process documentation, as it can lead to long-overdue and highly profitable improvements – says Alexander Himmelmann, process consultant at ECOVIS KSO.
Paul Liese: Hello, Alexander.
Alexander Himmelmann: Hello, Paul.
Paul Liese: Thank you very much for giving us the chance to have a quick chat with you about process documentation. Why don’t you tell us how long you’ve been doing this, what your background is, where you’re from, and what you did before this?.
Alexander Himmelmann: I joined the team in May 2019. Before becoming a member of the process documentation team, I completed my business studies degree in Financial Management and Controlling whilst working at a consultancy specialising in turnaround and restructuring. I started out there as a junior career adviser. I worked with clients to develop process optimisation strategies and found the topic of procedural documentation in real-world client contexts particularly fascinating. Yes, that’s why I’m here.
Paul Liese: And did it turn out just as you’d imagined?
Alexander Himmelmann: Yes, definitely. What’s exciting about this is working on the individual areas of procedural documentation with clients – whether it’s data protection, IT process documentation or optimising process mapping in collaboration with clients to ensure they are GoBD-compliant and secure, whilst minimising potential vulnerabilities. That’s exciting and exactly what I’d imagined it would be. And it’s definitely still exciting to see what the future holds in this regard.
Paul Liese: What are your expectations for the future? Where do you think the issue of process documentation will stand in 12 months’ time, both here in the team and in Germany in general?
Alexander Himmelmann: Generally speaking, I strongly believe that, in the context of digitalisation, the issue of documenting processes will become increasingly important, so that we can understand what the technology, the computers and the robots actually do, who operates them, how they work, how one can intervene in the individual processes, and where the interfaces lie. With the help of this documentation, these issues do indeed become transparent to the client themselves to some extent. In our department, I believe we can continue to drive this issue forward, establish it collaboratively with our clients, and – through this documentation and our external perspective on the processes – work together with clients to realise potential for becoming simply better, more efficient and also safer.
Paul Liese: And what’s your experience been? Do the clients you’ve been working with over the last 12 months see it the same way, or is it just a matter of fulfilling their obligations?
Alexander Himmelmann: It depends. There are clients who, of course, see this as a necessary evil in order to comply with yet another regulation. But there are also clients who are very grateful to simply let the consultant take a look at these processes and, through this external perspective, determine whether they work or not, and whether things can be optimised. In some cases, this is the very first time clients have really thought through their processes and the company’s IT structure; by identifying areas for improvement, we can collectively achieve a better outcome.
„It’s more efficient. It’s quicker.“
Paul Liese: What has been your top experience over the past year when it comes to process documentation?
Alexander Himmelmann: What pleased me most was when, after we’d drafted procedural documentation together with a client and discussed the results in the final meeting, he conveyed to me exactly the feeling I’ve just described: „Hey, that’s really made a difference. We’ve been able to adapt the processes in practice. It’s more efficient. It’s quicker. And we’re looking forward to working together in the future.“ I thought that was really lovely feedback, and I was personally very pleased to hear it.
Paul Liese: That was what motivated me to say: „I’ve made the right decision regarding the role, the job and the future responsibilities of the post“.
Alexander Himmelmann: Yes, well, on the subject of „future topics“: with such a wide variety of documentation retrieval taxonomies, the scope is naturally extremely broad, and it simply never gets boring because the structure at the client’s site is different every time. No two projects are alike. What more could one ask for? To see new approaches, new processes and new possibilities every time; to understand them, develop them further and, in some cases, learn from them. As a young person, that’s all you could wish for.
Paul Liese: Okay, so would you recommend that other young people get involved in this field?
Alexander Himmelmann: Definitely yes. At the outset, you have to shake off that slightly dull aftertaste that you initially associate with the subject of procedural documentation. It might well turn out to be a bit boring. It might be a bit mind-numbing. You have to move beyond that and realise the full scope of the issues covered in process documentation – that there’s an incredible amount of potential for consultancy work to be tapped into – from the data protection policy through to the company’s IT infrastructure, potential for obsolescence, opportunities for rapid improvement, the software in use, the process flows, and whether or not they comply with GoBD. Given this wide range of topics that you cover, develop together with clients, discuss and collate, it never gets boring.

Paul Liese: You’re now using software to some extent to produce the process documentation. And as a young person, you always want to work with trendy software and cutting-edge technology. Do you feel comfortable with the software you use, and do you enjoy working with it? Or is it more a case of: „I’d rather have the conversation and record it; software is a necessary evil for making it all happen“?
Alexander Himmelmann: No, for me, the software is very important at that moment. It consistently provides me with a structure for my day-to-day work. It also enables me to ensure consistent quality. I don’t forget anything. It doesn’t have to be Hipp’s software. For me, it just needs to work when I need it and help me achieve the result as efficiently as possible, whilst adding value for the customer. I find that working with the software provider goes really well. On the rare occasion that I have a question or something isn’t working exactly as I’d like it to, I always have a point of contact who helps me straight away. It works really well.
Paul Liese: Thank you very much. Do you have any questions for me, or for us? Or is there anything you’d like to share?
Alexander Himmelmann: Yes. As a curious person, I’ve asked myself, for example: on 28 November, the GoBD and procedural documentation were published in the 2019 version. How quickly can you actually implement any adjustments and taxonomy queries into the taxonomy, and how quickly will I actually see this live on my system?
Paul Liese: We can now do this very quickly because we have a newly developed taxonomy generator in our software and no longer have to do this using complex Excel spreadsheets, which we then have to convert into XBRL – the technology behind the taxonomy. So it’s now very quick. Of course, we’re dependent on always releasing new software versions via online updates. That means it can sometimes take a little while. And in last year’s GoBD, there was actually only one significant change in the marginal note on procedural documentation: the reference to revisioning and versioning. That was the only sentence that changed slightly. And in release 20.1, which will be published in the spring, we will finally provide the function that allows me to compare versions of procedural documentation side by side. The software will then generate a table showing: in the first column, what was in the procedural documentation for 2019; in the second column, what was in the 2020 version. And if you look back from the perspective of 2022/2023, you’ll still see the following year in the third column, and so on. And you can always see how things have evolved over the years, so that as an auditor you don’t have to read 200 pages for every year, but simply read the 100 pages from the first year plus the changes from subsequent years. This is a feature that we’ll be rolling out relatively quickly. Of course, we have certain development cycles and the process of rolling out the software, which always slows things down a bit, but I think we’re very quick in this regard. At least that’s what we’re repeatedly told, and I believe this also came from your team – that you receive information and new features very quickly.
Alexander Himmelmann: Yes, thank you very much. A second question that I’m really keen to ask: do you think that, at some point, the software will allow us to generate procedural documentation at the touch of a button? In other words, will the client – for example, as we’re doing right now in an interview – provide information that can then be processed automatically within this system? We’re often asked this: why does it involve so much effort? Isn’t there a ‘one-click’ solution for you? For us, that’s not the case at the moment. Do you think we might move in that direction at some point?
„Every business is unique.“
Paul Liese: I don’t think so. Because every company is very unique and no two are alike. Why don’t you take a moment to look back at last year’s projects and see if you found a client who was exactly the same as another one.
Alexander Himmelmann: Definitely not.
Paul Liese: We see it exactly the same way. And the second point is: if a client were expected to document things themselves, they’d already be doing so. And I believe that external input – having a consultant take a look at things without being constrained by operational blind spots, without that fixed focus on processes, and breaking through that operational blindness with an outside perspective – is important. For that reason, I believe that the topic of procedural documentation will always remain a consultancy service. Creating it for the first time is certainly labour-intensive; it requires more energy and time. Maintaining it over the years will become increasingly efficient and quicker once a sensible system has been established. And quite seriously: most companies haven’t actually documented their processes. They’ve got them in their heads. And as I realised this week, when I was asked to draft some process documentation for a larger company: we very quickly identified that if one employee were to leave, a particular area of the business would grind to a halt. So we asked: „Where is it documented what this employee does?“ The reply was: „We haven’t done that.“ You can see just how important this employee suddenly becomes.
Alexander Himmelmann: The Dangerous Classic.
Paul Liese: Exactly. And that’s where it comes in, and the process documentation also helps the company, for example, to minimise this risk. So, from my point of view, it’s always a consultancy service.
Alexander Himmelmann: Then we’re in agreement on that.
Paul Liese: Yes, definitely. We’ve also found that using our software makes it possible to create process documentation efficiently, even the very first time round. It’s not a cumbersome task that has to take up 20, 30 or 40 consultant days; rather, it can be tackled very efficiently and further developed over the years. So, in my view, this fear along the lines of „OK, I’ve got a consultancy project lasting 100 days“ is a misconception, and that’s where our software helps to minimise the effort involved in creating the documentation.
Right, and now we’d like to let you know that Alexander would like to take part in *Jungle Camp* next year.
Alexander Himmelmann: Exactly.
Paul Liese: We’ll submit the application in good time. I think the video is enough to demonstrate your resilience and your communication skills.
Alexander Himmelmann: Exactly, so RTL, if you’re watching this: you can give me a call. The number’s right down there. And then I’ll really make it happen.






