Michal Paluszczak: It is excellent news that we will discuss finance. The second most common text on the client side is, “With us, everything is simple.” That’s not how it works at ERP. It’s as if it will never be possible.
Marek Mac: Again, in the studio, Michal Paluszczak, CEO of INLOGICA. Hi.
Michal Paluszczak: I liked it, so here I am again.
Marek Mac: Exactly, very good. We wanted to touch on a topic with you today: what is the approach to implementing Dynamics?
Michal Paluszczak: Do you want to touch on a complex topic of finance and precision?
Marek Mac: Yes, you are the person I can talk to about finance. It will be interesting because only some companies want to discuss it. What happens when a customer comes to you?
Michal Paluszczak: Before I answer this question, it is also excellent news that we are discussing finance. The most important thing is not to disappoint each other in the relationship with the client. We openly communicate financial issues and try on orders of magnitude because it is easy. Going back to your question, what happens when a customer comes in? One of the first questions: “How much will it cost?” I used to have a saying, but it has worn off, that between 100,000 and 100 million, depending on what we come up with for the project. We can estimate it only when the client comes in; they often can’t answer the basic questions for us to diagnose it.
Marek Mac: Clients often need to figure out what they want.
Michal Paluszczak: Yes, and what is their ecosystem? The second most common text on the customer side: “With us, everything is simple.” I know that at the customer’s place, it is simple. In his head, business and the world are all obvious and trivial. We have to understand it. When the customer comes, we must first define where he is. Does he fully understand how his business works? Does he have the processes of that business mapped out? Can he provide us with such a pill of knowledge so that we can look for analogies in historical projects, in what we are doing perhaps at the moment for another client or have done in the past? The first step is to understand each other, I would call it. We need to establish some level of understanding.
Marek Mac: I see it from the market: companies initially want an analysis done. This is justified. They want to know what it will look like. How do you guys approach this? Do you also do the analysis or have a slightly different approach?
Michal Paluszczak: Until recently, we have also done the analysis.
Marek Mac: Why don’t you guys do one?
Michal Paluszczak: Why don’t we do the analysis? It concerns the fact that analysis is such a sleepy word. Nothing comes out of it. What are we going to analyze there? We are not interested in analysis because “let’s deepen our knowledge of the customer.” That’s important, of course, but as an implementation company, we are interested in the processes we should take care of and reflect in the system. And we have been doing this for many years. Only recently, we found that the word analysis is a trap word. After the analysis, you may get, for example, a simple Excel spreadsheet with numbers that will say that for area X, we will spend so much time on this implementation, and for area So much. It will have value only when you step back from the analysis and see how you can work effectively with the customer through workshops, process mapping, and doing it with them. Analysis has been a sleepy word lately, and I’ve been trying to sensitize clients. Still, internally, the team has used this terminology for many years not to get caught in this trap that often occurs: “With us, it is easy.” It is necessary to deeply discover and see in this project what the customer does and what we should consider.
Marek Mac: And can we separate that? That is, we do both analysis and such workshops. The client chooses what he wants to use or both. But there is a little asterisk.
Michal Paluszczak: Yes. We can treat these as separate processes. On the other hand, I would like to speak and communicate for our clients coming to such a project, saying: “We need to implement a new ERP system, to launch a new system,” so that they come to us with the attitude that this will be a collaboration. Analysis has a hidden message: someone will come, listen to me, and then come back to me and present me with a finished solution.
It can’t be done that way in ERP. It never gave, and it doesn’t mainly provide now.
I’ll tell you why right away. From the beginning, we must involve the customer. This doesn’t mainly give because we work in Scrum and agile methodologies, so the contact with the customer, which will already be going on during the project, is quite intense. If, from the beginning, the customer comes with the attitude that people will come, listen to me, and magically create a system for me, it can only end poorly.
We had such an example in a recent implementation, where the comments from the client’s users were: “But it’s not ready yet, supposedly training, but it doesn’t work yet,” and so on. They pushed back the moment when the users would enter the system. They appeared very briefly before going live. You could say that the project was hanging by a thread because testing took place practically after the launch.
When we have this kind of workshop work, process mapping, and cooperation from the beginning, already at the analysis stage, when we start dressing this analysis in form, we will sit in front of Visio and start drawing these processes together. Not in such an analytical formula—the consultant comes, listens to the client, then comes back and tries to work it out again. It makes no sense at all.
We are now trying to shorten this path to implement a lot from the beginning with the client. This prepares the client for what will happen in the project. Let’s agree that with these initial analytics, the customer is aware, and then with the implementation itself, some customers are ready to join in at the right moment. Many customers with this approach took the attitude; we already discussed it during the analysis. We talked about it, and now it needs to be concreted. No. Specifics at the beginning. Let’s move that lever; let’s take that step.
Marek Mac: This is a good time for you because there will be no grinding. Often, clients must be made aware that after the analysis, we must detail it, and nothing comes out that nobody initially thought of.
Michal Paluszczak: Only when you see can you say that you feel something. We try very hard to encourage clients from the beginning so that it’s not a work on generalities, on large block areas.
Let’s sit down, draw, and then agree on what we will do in this system. At that point, my team can give reasonably reliable estimates of time and budget and how we will implement it.
Marek Mac: How do customers react to this approach of yours?
Michal Paluszczak: Surprisingly quite well.
Marek Mac: The workshop approach will be more expensive and longer.
Michal Paluszczak: A little bit.
Marek Mac: What if the customer says, after the workshop, ” This is a system not for us,” or you find that out?
Michal Paluszczak: Not this customer for this system.
Marek Mac: Yes.
Michal Paluszczak: The best information for the customer is that when they go to another partner, a provider of that system, they will have their processes objectively written down and cataloged.
This is work that customers often need more time to do internally, not coerced by a situation like an ERP implementation. When we say to ourselves, “Well, listen, it’s not for you after all,” I shouldn’t say that because Microsoft is a system for everyone. Everyone will undoubtedly buy-in, but if the customer says: “not for us, this budget,” ‘We need to find something cheaper’ or ‘from another shelf,’ that’s ok too. The stage of this workshop, the preliminary work, heavily intensive, in cooperation with the client, will undoubtedly result in the result, will be a process map, sensitive areas written down, and didascalies marked on charts, and this is the problem area that needs to be dealt with heavily, standardized or changed.
I can present you with an email under the title: With us, everything is simple versus practical. We have a simple business, simple orders, only sell and distribute, no fireworks, and such a chart. It looks okay, but the steps have a dozen at least. So, from simple – I buy and sell to actual what I do, there is a vast space to define.
Marek Mac: Can you determine how long such workshops can last and what they cost temporarily?
Michal Paluszczak: Yes, we can talk openly about finances; if we are talking about a company employing 20-30 people, implementation small, we have a company – distribution sales, we know that we need to talk to people in purchasing, sales, and warehouse. Let’s take it through the lens of people. We want to map these processes; let’s send an employee to each area for 2 days so that he can sit quietly in each department and discuss how these people work and the main processes; that is what I declaratively do. So that he can catch all these exceptions of this simple process, which is always simple in the customer’s mind, we have 2 days in each department, each consultant who goes and talks – 6 days in total. Employees must think about it, discuss what they’ve gathered, and catalog it.
If we add a day for each, we have day 9. Let’s give each of them one more day to refine this documentation. He started drawing with the client and created some graphs and processes. Let’s give him another day, such an extra day so that he can polish it more calmly.
Days 12 Summary meeting with presentation of results—each takes half a day, with the client in the overview.
How much did we get out? 13 and a half days x the rate we use- cost about 10 thousand euros- for the input work.
Marek Mac: This is a little. I remember a situation where clients came to us on the portal for analysis, how to approach, how to choose, and so on. We often try to suggest that they try to write out the processes themselves. And we have a record holder! It took 8 months. If one were to count it, it would be 8 months’ cost and so on.
Michal Paluszczak: It can take that long. If the company’s scale is such, we go into a corporate implementation, and the users will be 100, 200; we can analyze for many years. I talked about a simple scenario again: we can take an employee and think about how much he will be there; the cost of our work is the cost of the people we hire. There are no hidden costs; I’m not expertly calculating them. I have to consider humanly what time our people are. This is also an interesting topic because customers wonder where these costs, the rate, and where these volumes come from. We have to take an employee and send it to you, to the customer, he will spend a day there, 2, in such a variant, as I was telling you now, we have 3 days of such workshop work in the department. It seems a lot even. It can be done faster, but let’s give ourselves a buffer to fit in the time because it turns out that the first day went very precipitously, and we have to do a catch-up. It can always be done. The important thing is that these volumes don’t come out of nowhere. This is the work of these people. Microsoft is not the cheapest in implementing an ERP system. It is a very versatile system, but it requires a great deal of configuration to get off the ground to make it work.
If a customer’s company is multidimensional and needs an integrated system, the employees from those departments who come back must sit together and discuss it. This is another time. What impact are the warehouse movements going to have on sales? Are there specific requirements for holding stock heights or tracking a warehouse on the go? All these things matter.
These costs directly result from the people and the time they spend with the customer. You can imagine it on large blocks very quickly. As I said, in a large company, it could be weeks or months in the process spent with the customer, and then such a scenario where you say something takes six months is also possible.
Marek Mac: Are such workshops for everyone? Will there be situations where we should do a standard analysis?
Michal Paluszczak: workshops are for everyone.
I am fresh from the changes we are making internally, so I am enthusiastic about this approach. The passive-listening, inactive approach is going out strongly. It’s impossible to implement projects this way. We’ve had many stories of this kind, not involving the client at the right moment in the workshop or the joint work— it resonated very strongly later in the project when we realized the implementation.
The client needed to get used to it; he needed to understand our expectations and was pulled out of his work. That’s how he perceived it: we constantly wanted something from him. So, from the beginning, we engage him gently and say: listen, we work like this; we don’t work in a vacuum. I know such stories from clients who come to us and say: ‘We handed everything over to the company that implemented or is implementing it at our place, we need help, they disappeared, then they came back with something it doesn’t meet our expectations.’ It’s not the fault of the company that did it.
They can hold a grudge if the client doesn’t get involved or stay on top of it. Such situations happen when groups or employees in the client’s organization protect the rest from being too engaged in the implementation stage because their work is cut out for them. This is a mistake. We will test only after the launch to understand the system, its ergonomics, its design, where it clicks in the system, directly speaking, and how it’s structured visually even.
Every minute and hour spent by the customer at the stage of these workshops already during the implementation, from the very beginning, is essential; this does not happen in a vacuum; we talk about these processes, sometimes there are discussions, and there are questions: “what does it look like in the system right now, by example?” The consultant pulls out the computer, fires up the system, and says: this is how we can model it; this is how we did it on our demo or presentation. Is it ok for you? And this work must look like this. When I even talk about it, I hear an inner voice, and how could it look different? The approach to analysis in many of our implementations has been carried out in a lax manner. In retrospect, I don’t think that we did it right and directed the customer’s energy well in those implementations.
Marek Mac: The worst thing, in my opinion, is when you come across a customer who didn’t put a lot of thought into the traditional analysis, and during the implementation at the process, they say: “And yet this!”. It may not overturn the whole project, but it can add so many hours that problems arise.
Michal Paluszczak: Of course.
First, as I said during our first meeting, we need to know what we are contracting with the client for. All the words, risky wording: We talked about it, we mentioned it… Great, but what is the follow-up? It is known that analysis, even in this traditional approach, should end with a summary, a document.
We are betting heavily at the moment on deeper interaction from the very beginning. Implementation in collaboration, not implementation for the customer. It could be summed up in one sentence.
Marek Mac: You mentioned earlier that Microsoft implementation is not one of the cheapest. My question is: How much can it cost?
Michal Paluszczak: I understand. Is it between 100 thousand and 100 million?
Marek Mac: Yes.
Michal Paluszczak: The main reason is that the products are not the cheapest because they are universal. Microsoft Dynamics I version of Business Central and Finance & Operations is a system created by manufacturers worldwide.
It’s as if we scattered Lego blocks; we can assemble something from them. That’s the way this system works. We can put together a picture out of it for a tiny company, but with the tray of this system, we can create a system for a vast organization and take care of corporate processes. I will immediately answer the question of how much this can cost. 2-3 examples I can give you. The most important thing is to understand why this is so. It differs from Polish financial and accounting systems – when everything is ready – specific processes are modeled. Microsoft ‘u doesn’t care that in Poland, JPK is filed this way on the finance side or that the formal requirements are such and similar. He is universal. It has its localized packages, which require customization each time.
We recently discussed our model implementation in 5 days costs several thousand zlotys. Implementing such a system in a small organization can cost thousands of zlotys. In organizations with about 80-100 users, instead, we are already talking firmly about six zeros – it will probably be millions of zlotys. In the old days, when OnPrem reigned supreme, it was said that the value of the purchase of a license (one-time) was roughly equivalent to what the implementation would cost. And ideally, that implementation should still be multiplied by 1.5.
It used to cost 4,000 euros per user for a license. If you had 80 users, that is, it cost you 320 thousand Euros to buy a permit, then roughly 1.5 million you had to plan to invest in doing it for implementation companies like ours. Now that this barrier has changed, it’s hard to catch because there are subscriptions, so it’s slightly different.
Recently, at Business Central, we talked to a client with a relatively simple business. Without doing these workshops, we counted the cost of licenses: about 50 users. If I take the price of a monthly permit for Business Central, about 80 Euro x 50 users, that is 4 thousand per month x 1 year, about 50 thousand Euro in permits. I can only implement this for a maximum of 50 thousand euros.
That would be an abuse, but multiplying that x 1.5-I think we’re at parity in this case. Our business does project billing, invoices, sales, and purchases; we pin that down in the project module- a relatively repetitive and declaratively simple business. We’re about to move on to the workshop, so I’ll tell you at the next meeting whether, from this simple process, I collect cost invoices, invoice the customer, and bill the project. Will it be that simple or will I show you some big diagrams at the next meeting?
Mark Mac: You mentioned implementation in 5 days. We did a segment about that, and I know you already have one case described.
Michal Paluszczak: One case has already been completed in an auto repair shop; we can link it somewhere and show how it was done.
Marek Mac: Yes. Opinions were extreme and interesting after this episode. Some people knocked themselves on the head. We got comments: “How in five days? This is a marketing gimmick.” It turns out that it is not.
Michal Paluszczak: I keep inviting you to confront this proposal with your expectations; it has to resound: We have made assumptions and offer these as part of the implementation.
The advantage is that we can develop the Business Central system in our proposal. If elements do not suit the model customer, we can always change them. Indeed, these are additional costs and workload, but the question is one of scale.
If someone wants a model implementation for service companies to a few system users to be rewritten for a manufacturing company, then we have nothing to discuss. But if someone tells me that he still runs small sales from the warehouse in addition to the service, it will take at most 5 days. If we were to set up an adjunct warehouse, that would also be within those limits.
Marek Mac: It’s an intriguing entry into the world of ERP systems at little cost when the business owner has an excellent business idea to scale it.
Michal Paluszczak: That’s right. We know what the stakes are in the IT market. For a small company with 5-10 people, that’s your whole business; you can finance, account, sell, and purchase in a brilliant, scalable tool for the future—it’s easy.
It really can happen in 5 days. We refer you to the case, and I still encourage you to contact us and confront your business, preferably a service business, with our proposal.
Marek Mac: Michale, thank you very much for participating, and I hope to see you again. We’ll talk about the workshop next time.
Michal Paluszczak: We will talk about the workshop. Thanks.
