Documentation from a compliance perspective – with Denis Glowicki

Interview: Denis Glowicki, Head of Finance at Wicke GmbH + Co. KG

Although it has long been a legal requirement, many companies have still not addressed the issue of process documentation. Yet this is not just a matter of avoiding serious consequences. Understanding one’s own processes brings a host of benefits. In an interview with Paul Liese, Denis Glowicki, Head of Finance at the Wicke GmbH + Co. KG, the topic of documentation from both a business and a compliance perspective.

Paul Liese: A very good morning to you all from Hamburg, from the „hsp TV Studio“. We’ve got another fascinating guest with us on the livestream: Denis Glowicki, who’ll be introducing himself in a moment. We’ll be discussing the topic of „documenting processes“, not from the perspective of a tax adviser, but rather from that of a business. Good morning, Denis.

Denis Glowicki: Good morning, Paul!

Paul Liese: Are you all right?

Denis Glowicki: Yes, I’m fine. It’s sunny and it’s Friday. Why on earth would I feel down?

Paul Liese: You’re right. Why don’t you introduce yourself briefly? Who are you? What do you do? And why are you in a position to contribute to the topic of „documenting processes“?

Denis Glowicki: My name is Denis Glowicki. I’m 45 years old. I’m currently working at Wicke GmbH & Co. KG. I’ve been there for quite a long time now – 12 years, in fact. We’re an industrial company that manufactures heavy-duty wheels and castors. And I’m in charge of the finance department. You’ve just mentioned the tax adviser’s perspective: I’ve done that too. I’ve had the opportunity to view the field of „finance, accounting and tax“ from various angles throughout my professional career. Twenty-three years ago, I started working at a tax office, where I spent several years in the field; I then passed my tax adviser’s qualification in my late twenties. I then spent six years working in tax consultancy and auditing. And now I’ve been with this industrial company for almost exactly 12 years, where I’m looking at things from a third-party perspective, so to speak, and examining the processes and tasks.

Paul Liese: So, does that mean the topic of „documenting and evaluating processes“ has been a constant theme for you throughout?

Denis Glowicki: Perhaps not all the time. At the start of your career, you’re not really aware that this is part of the job and just how important it is. But naturally, it has become more important as my responsibilities have grown. It’s an important and useful aspect of organising your work efficiently.

Paul Liese: What sort of processes are we actually talking about here – the ones you’ve documented?

Denis Glowicki: The ones we wrote down with the C4B team? It’s all evolved a bit. We actually only wanted to focus on the „Accounting and Controlling“ area. The problem is always knowing where to start. A process that begins, for example, with incoming or outgoing invoices isn’t complete in itself, so the processes we documented have also evolved somewhat. We’ve kept moving further back towards the source processes; where does the invoice actually come from? Is it a purchase order or a customer order? But we’ve also looked further back: what actually happens afterwards? What other specific aspects are there once a payment has been received or made? We’ve incorporated various special aspects there as well. So the whole thing has developed over time and become increasingly comprehensive.

Paul Liese: I was just about to say that. If you’ve started with incoming or outgoing invoices, the whole background to the process isn’t documented at all. That’s precisely when – and you’ve just written two blog articles on the subject – it makes sense to look at and document the entire chain to see where the potential for optimisation actually lies. Isn’t that the most exciting thing about documentation? Identifying the processes where changes can be made, and thereby generating optimisations?

Denis Glowicki: That’s exactly what companies do, too. It’s just that they often don’t do it themselves. What usually happens in a growing, successful company is this: in a 10-person company, everyone still has a rough idea of what everyone else is doing, and the boss, in principle, knows what his staff are up to. But when the company is successful and grows over time, the range of tasks becomes much more varied, new staff join, and it becomes difficult to keep track of everything. At a certain point, inefficiency sets in. And what do companies usually do then? They bring in management consultants, who actually spend more than half their time simply getting to grips with the processes.

If you do this yourself, you can make it significantly more efficient and put it to good use. Of course, management consultants are important – there’s no question about that. An outside perspective is always valuable. But every company could map out its own processes and generate efficiency gains from them. That’s exactly what management consultants do, after all. They generate efficiency gains and eliminate „blind work“ – the inefficiencies that arise during growth when people no longer know what others are doing or what their actual responsibilities are. There are other areas too. You’re a software company, after all, and you have plenty of experience in this field. Even when implementing software, it’s very important to understand your processes. Because often you implement a piece of software and then realise: „Oh, I need a solution for that as well if I want to replace a particular piece of software.“ It’s the same principle there. Again, I need to understand my processes.

Documenting processes yourself

Paul Liese: Yes. You just raised the point that the company can document the processes itself. What skills must the person responsible for this have?

Denis Glowicki: First and foremost, she must be strong in the area of communication. After all, she has to look at the areas of work of individual staff members. And there are many different personalities there. There are staff members who are very open and willing to disclose the scope of their responsibilities. But there are also very different personalities. And sometimes there’s a bit of fear involved too. „What exactly does he want from me?“ It’s no different with management consultants when they come into the company and start assessing the processes. There’s always a certain underlying fear involved. „Why is he doing this? Why does he want to know that?“ That’s why you need strong communication skills and a certain amount of empathy, and of course you have to explain exactly why you’re doing this. You don’t want to take anything away; you want to improve efficiency. You really do need to be able to sell that idea effectively.

Paul Liese: Doesn’t it also take a huge dose of curiosity to want to find out how your colleagues in the organisation work, just so you can document it? After all, it’s not about the person doing the documenting immediately coming up with a whole host of improvements; they’re just supposed to record the current situation first, aren’t they?

Denis Glowicki: Of course, he’s supposed to capture the current state of affairs. I’m not sure whether a certain degree of curiosity is necessary. Perhaps a curiosity about how things actually fit together, how tasks ultimately come together again, and what purpose they actually serve. These are questions that not only the person carrying out the task should ask themselves, but every employee in the company needs to know why they’re being given tasks. If I don’t know the meaning and purpose of a task, but am merely a small cog in the whole process, then I need to understand the end result of that process so that I know what my role is within it. That is, after all, the so-called ‘meaningful work’ that one produces in this way. And only when I understand the purpose of a task can I also think about how to improve it. These things are, in fact, inextricably linked.

Paul Liese: Right. So you’ve now documented all these processes. What has been the outcome for you? You’ve identified areas for improvement and perhaps implemented them. But how is the documentation being put into practice within your organisation now?

Denis Glowicki: Well, we’ve started by creating a template. We can’t provide any documentation – just a template, because the processes are, to some extent, specific to each company. We’ve tried to map out the part that actually occurs in virtually every company. We’ve also tested this on two or three companies and can say that, under normal circumstances, we map between 70 % and 80 % of the processes that occur. The remaining 20 % to 30 % are simply very specific and vary from company to company.

But it’s always easier to tackle the task of documenting a process when I already have a template and a guide on how to go about it. After all, the initial hurdle to getting started is quite high. And even we in the team, when we were writing this down, had to start some process chains from scratch two or three times and keep tweaking them until we could say: „That makes sense. The way we’ve documented it is clear.“ And our aim is actually to overcome that initial hurdle by creating a template that people can use as a guide, work with, and then adapt to their own specific processes.

Paul Liese: For those who aren’t yet familiar with the context: we’re currently talking about the C4BManuals, which cover the accounts payable, accounts receivable and fixed assets processes. And I believe you’re currently working on the next topics as well, such as the annual accounts, for example. The question is: if I now receive these processes or this documentation, what can I do with them as a business owner? Or even as a tax adviser or auditor who has a client with whom they’d like to tackle this issue?

Denis Glowicki: He can use it as a template, but it’s also sometimes very important to compare. After all, it’s not a bad thing if I realise that a process runs differently for me than we’ve described. That might well serve a purpose. But as a company, you often don’t have anything to compare it with. How do others actually do it? We’ve now developed these modules you’ve just mentioned, based on the work of our group of six people who’ve compiled the information and discussed it at length. And, drawing on our collective experience, we’ve created model processes that we believe represent the optimal way to design a process. You can then compare these with your own processes and see why they differ, or whether they’re exactly as described. That’s the advantage of this approach.

Paul Liese: A very specific question: Can I use the processes you’ve documented there to draw up procedural documentation for my company?

Denis Glowicki: Not the whole thing, but that is part of it. The process description is, after all, part of the Procedural documentation – and I think it’s also the most difficult to create. I’ve just tried to explain that. The barrier to entry is relatively high. I can use this as a template. I can’t simply implement it one-to-one into my procedural documentation, as that documentation is meant to reflect the real-world situation within the company. But I can use it as a great aid in that regard.

Paul Liese: These process descriptions you’ve provided do, of course, describe the process or the task itself. What’s missing from the context, though, is: what software do I use to do this? Who is responsible for it? What other issues are involved? In other words, when I’m looking at the processes and documenting them, and also using your template as a guide to see how others do it, how I do it, and what could be improved, I automatically – at least that’s been my experience in such projects – always to the points regarding everything I need to be able to implement a process step. And when I then add that to the documentation, the „by-product“ is procedural documentation, but in reality I have an organisational and process handbook for my company that documents exactly who does what, when, with whom and using which tools.

Denis Glowicki: There are, of course, different perspectives on this. Management itself wants to see how the processes within the company are running. I’ve just been talking about the possible uses. From an employee’s perspective, it’s very important to see which processes one’s tasks are actually integrated into, and what the purpose of the sub-process one is currently working on is. Where is this actually heading? What am I actually contributing to?

That is what makes the work meaningful. And that is absolutely vital for keeping motivation high, for
Identifying areas for improvement within the company. After all, having external consultants review processes often reveals that there is scope for improvement, potential for cost savings and opportunities to boost efficiency. It’s rather like a ‘clean-up’ exercise that I then carry out myself, and for which I usually end up paying a relatively high price. If you make this a way of life and do it yourself at regular intervals, it’s not only cheaper, but you no longer need these clean-up exercises. You’re constantly tapping into the potential for savings and improvements. That’s the idea.

Realising potential for savings and improvements

Paul Liese: Exactly. We actually took up that idea when we first got in touch last year – that we want to, and will, provide a web application, which we’re already developing, through which the processes documented within the company will be made available to the individual roles or employees in the company, who will then be able to see: „What is my step in the process? Where is my name linked to my role? What happens during my step, or before or after it? Why am I doing this in the first place? Why is it important that I do this?“

And I think another important function in the area we’re looking at is that, if I – let’s say as Paul Liese – am currently involved in the procurement process and am supposed to request quotes from suppliers, I can also influence the process documentation by saying: „I work on this stage of the process every day. I’ve got a suggestion or an idea here as to how we could do things differently, perhaps to improve such and such.’. And that’s exactly what, at least in my experience, doesn’t happen very often in companies. Somewhere, a brilliant quality management manual is written, along with excellent process documentation, which then ends up in some nice cupboard, but over time it fades into obscurity because knowledge of how the processes in the company should actually work is lost again, and then at some point we end up back at that clean-up exercise you mentioned.

But if I bring this to life and actively keep it in the minds of everyone involved who is caught up in the processes, making it easy for them to read, comment on, optimise and be allowed to work on improving it – surely nothing better could happen in process documentation, could it?

Denis Glowicki: That’s why I think this idea of switching to a web application is so important. Not just for the person recording the processes, so they can take it with them on a tablet or whatever, but also so that staff have access to it. Because only when staff have efficient access to it from anywhere can they work with it effectively and then immediately enter their changes and so on. I think that’s an excellent idea. You can integrate images and so on. That makes it easier to put into practice and really make it work. I know you’re working on it at the moment, and I’m really looking forward to seeing what it’ll look like and what new features will be added. I think having a readily portable version of it will really help take things forward.

Paul Liese: We’re convinced of that too. At the moment, we’ve now finalised – as we call it at C4B – the Professional Licence, which allows you to start using the templates we’ve provided to review and document your own processes. And whilst companies may be using your templates to assess, „how do we work, how does this compare to the template, and what can we take away from this or do better“, we’re now developing the web application so that it will be available shortly, enabling the first process chains to be rolled out across the organisation, so that we can then gather feedback to see what the process owner actually thinks. Is this just wishful thinking, or is it actually feasible?

Denis Glowicki: And why might things work differently from what’s set out in our process chains and our templates? Why do I do things differently in my company? Does that make sense? Are there reasons for it? Or should we consider incorporating these ideas there as well? What we’ve also incorporated isn’t just the processes themselves, but also – and this is very important – the internal control system; it contains tips. Where is it particularly important to carry out checks? And we’ve also included digitalisation tips to provide further guidance in that area.

Paul Liese: I have a very specific question for you regarding ICS: if I haven’t documented my processes, how can I set up an ICS?

Denis Glowicki: That’s quite difficult.

Paul Liese: That’s actually impossible, isn’t it?

Denis Glowicki: Yes, in principle that means I’d have to know every employee’s responsibilities. Then I’d have the process steps in my head, but once a company reaches a certain size, that no longer works. And the absence of an internal control system means I run the risk of encountering risks or even losing money – in whatever way, whether through external factors, our own staff, or mistakes. Anyone who doesn’t have one needs to be aware of this.

Paul Liese: Yes. Well, I’m always talking about this GoBD pyramid. The GoBD stipulates that, as an entrepreneur, I should have procedural documentation and I should also have an internal control system. That means, as you’ve just said, I have to document my processes; then I can apply my internal control system to those processes and identify which risks are associated with which process steps. And right at the very top of this pyramid is the Text Compliance Management System (TCMS). And once I’ve fulfilled the requirements of the two lower levels, it actually makes sense to build this on top of them and to be able to justify clearly why I do or do not identify certain risks within the TCMS.

Denis Glowicki: This will be more or less integrated into the actual ICS; as you just said, it will be added on top. The entire framework is formed by the actual ICS – or many areas within the standard scope of the ICS – and tax compliance will be added on top of that. However, many factors from other areas of the internal control system are already factored in. Ensuring that tax payments are made on time, and that all payments within this area are made on time, should be integrated in this way. Therefore, a robust underlying framework is necessary so that, ultimately, I do indeed have this text compliance management system in place.

Paul Liese: So, no matter which direction I approach it from – whether I work my way down from the top, starting with the text compliance management system, or work my way up from the bottom, starting with the documentation of processes – I always have to document it somewhere at the end so that I can achieve the other objective. That’s why it’s important for companies to engage with their processes, document them and then be able to derive the other elements from them. Because I think that, even though we’re currently more focused on business continuity in this crisis situation, the issue will resurface and gain momentum – that’s my personal view. This will ensure that companies are properly positioned – particularly when it comes to their future credit situation – to demonstrate that they are adhering to compliance rules.

Denis Glowicki: To conclude, I’d just like to add that there’s never a ‘right’ time to get started. It’s difficult when you’ve got a lot on your plate. It might also be difficult in the current situation. You should just give it a go. You should specifically assign this task to someone who actually enjoys recording this sort of thing. We touched briefly on the skills required earlier. But at some point, I’ll have to get this off the ground and get to grips with it.

And it’s all the easier – as I’ve tried to explain today – when you can see the benefits to be gained from it. There are requirements to have procedural documentation in place, but what’s important is that you also recognise the benefits for yourself and can work out the cost savings that explain why you should do it. That makes it easier to get started. No matter what stage you’re at right now – whether things are difficult, as they are at the moment, or whether you’ve got a lot on your plate and are kept fully occupied. It’s simply a matter of putting it into practice, in good times and bad. Only then does it make sense.

Looking at process documentation from different perspectives

Paul Liese: I think there are always more exciting things to do than documenting things when you’re right at the start. But once you’ve got started, you realise that it can be really enjoyable, because you simply gain insights that you wouldn’t otherwise have had.

Denis Glowicki: And when the next software migration comes around, you’ll be glad you did this, and you’ll be able to get these projects out of the way more quickly. It’s also very important that process documentation is viewed from different perspectives: from a management perspective and from the company’s perspective. This can then be used to great advantage for staff integration and for improvement processes or suggestions for improvement that come from staff. It ensures that the potential is fully realised.

Paul Liese: Yes, so all that’s left for us both to say is: „Let’s get started!“ Right?

Denis Glowicki: Yes, let’s get started then. The whole C4B team is keen to see what feedback we’ll receive from the initial roll-outs and implementations. The coming weeks are certainly set to be an exciting time.

Paul Liese: Thank you very much for your time. I hope you have a lovely Friday and a great weekend. And stay well!

Denis Glowicki: Yes, Paul. See you soon!