Category: Business knowledge

Marek Zasada: A programmer is not just a code slapper. Those visitors who came understood us and knew what we were about. It’s just essential to weave a particular narrative of this implementation.

Marek Mac: CTO of INLOGICA, almost 10 years of experience. Marek Zasada, hi.

Marek Zasada: Hi.

Marek Mac: Marek, we’ll talk to you today about the situation where programmers come in at the sales stage. You oversee the programming team at INLOGICA, and why does a salesperson show up with a programmer at a potential customer?

Marek Zasada: First, it’s essential to start building awareness about the customer’s business as soon as possible because the programmer is not just a code slapper. It’s not like he gets the documentation prepared and has to do a re-creation role. As programmers, we need to understand specific business processes; sometimes, we don’t have that experience from previous work. It is explained to us by people from the company or the consultant we go with, who specializes in a particular area, finance or warehouse, and the processes of how companies work that we need to understand. This is an added value to the programming profession; after a few years of experience, we know a lot about company processes, so this is an additional branch for personal development.

Marek Mac: At this stage, can companies invite a representative programmer or IT director when they know you are coming? I remember that this was only sometimes the case. When there were discussions about the selection or implementation of a system, the top employees of the modules in question were usually the top employees.

Marek Zasada: Yes. This is often the case.

When we announce that a technical person is coming, the other party also invites one. Then, we can talk about what already exists in the system.

Marek Mac: Please clarify what the integration will look like at this stage. Will red lights come on at the sales stage?

Marek Zasada: Yes. The issue of technology debt, which is already there, triggers the decision to implement a new ERP system. One such trigger is simply technology debt. You must run to something newer.

Marek Mac: What happens later after such a meeting?

Marek Zasada: It happened already in the meeting, which is essential. As I mentioned before, it’s a tandem of consultant and programmer. We discuss some company processes with the people at the meeting. It’s known that it depends on the company; often, it’s people from accounting because however ERP is mainly accounting. We talk about the first things: the difficulties in the current system, the ergonomics of the work that has yet to work so far, and the legal requirements that still need to be implemented or are done around or in another system. Another issue is that companies operate in a particular ecosystem, a collection of several software.

For example, invoices flow down from one system, courier integration is in another, and so on. It’s highly distributed, and at this point, we’re already in a position with key users to recognize the critical point in the company, the center of gravity, where we need to focus.

Marek Mac: You often hear we didn’t have this tandem with the previous implementation. This approach was different; now, it’s different. Customers see a specific difference, and quality follows.

Marek Zasada: Sometimes, I encounter a comment that customers felt listened to and understood. Looking at this tandem and listening has led to guests who have come to understand us, understand what is happening, and will already know how to manage this further.

Marek Mac: Years before, there was a perception that the first months were essentially programming work, which the client often didn’t see, and the invoice always saw and had to be paid. Do you think that at your stage, clients know how the work and implementation are going?

Marek Zasada: Yes. I always talk about it in the meeting; from my point of view, there must be partners on the client side to whom we can transfer knowledge. It’s a matter of specific capabilities and schemes or reconfiguring the systems at a basic level and certain technical limitations because that’s how it works, and that’s what you have to watch out for. Why is this important?

If we don’t transfer this knowledge, specific problems will keep coming back to us, and the customer may feel that he keeps paying, adding to this bag, and the problems keep recurring. Someone will eventually, for example, from the board of directors, come and say: “But what is the point here?” It is known that no one likes uncomfortable questions. This is one thing. The other thing for me as a programmer or a team with whom I enter such an implementation is to be stuck for a long time with one client on one project. This means that the knowledge gained from one implementation lasts for, say, a year or two, and we cannot transfer it to the next customer. We can’t take a step as an organization; the relationship in an ERP implementation should be symbiosis. One side and the other should benefit from it.

Marek Mac: Do you think it’s better to focus on one concept for this type of project, which is extensive implementations? I’ve often encountered situations where a company developed e-commerce and an external WMS parallel to an ERP implementation. I mean, all this communication. You guys have this approach—you show up initially with a development team; I assume your whole team communicates with the client. It cannot be easy with three different projects.

Marek Zasada: It is difficult, but my head is in it. How to set projects and priorities, plan the team or its development, or even hire the following people so that the transfer of knowledge is smooth, so that the entry threshold for the next person to take over the projects is acceptable, so that it happens within a specific time, and manage the client’s expectations. Sometimes, 2-3 large projects are grouped individually in our work. You need to be able to manage this and say we will do it, but you will have to wait a month or two because this is the situation now, and surprisingly, most often, clients accept it well. We must weave a particular narrative, a story of this implementation, even if it is a temporary stoppage or we hit a bad moment; nothing terrible happens if you talk.

Marek Mac: We are already in the middle of the implementation; the first months are behind us. As a programming department, what do you pay special attention to, and what should the customer be prepared for?

Marek Zasada: Certain events occur over a certain period, and many things must be put aside during system implementation. We approach it like this: we mark the critical processes and modifications to take off now and which issues can be addressed in the next step. I understand this can be cumbersome for the end user working on it. Once all the critical things are resolved, there is time for ergonomics. This time can be very long, even two years. I realize that someone may work in an unergonomic way initially for six months or a year before they get a solution from us.

That’s just the way it is. Business decisions must be made, and the sequence of activities must be followed. If we threw everything in at once, you wouldn’t know, for example, where to look for a problem if something stopped working.

Marek Mac: On the customer side, there is always data preparation. They often prepare it at the last minute, and things are different with that data. Do you get cases where the client prefers to pay more for you to prepare the data? Is this a good approach?

Marek Zasada: Yes, we get such things, and they happen too often. Why? Data has a context, a background. The person who works on it knows that background. If I go there, I must ask about specific things anyway because I may need help understanding everything. There are cases like this: “Here is access to the database; see for yourself; if you recognize yourself, then let me know and prepare.” This often leads to a crush, consisting of the customer thinking we know everything about him. The answer appears: “But we’ve already given you everything you don’t understand?”. Unfortunately, this is not the case; since the customer owns his business, he knows best what he is doing. Since he decided to implement ERP, his company has been good. He has to sell us this story about how he works, what he needs this data for, and at what frequency.

Marek Mac: I’ve often encountered situations where a company deciding on a new ERP system in a previous solution needed to have the system described. There were no instructions, which was the norm for those years, say 5-10 years ago. Nobody cared about it, whether in the code itself – SQL, or in the databases, triggers, or custom things on the databases – not described. Do you encounter such situations? I ask that clients are sensitized that you have extra work to do, not a little.

Marek Zasada: This involves additional work. I tried to catch this early on to include it in the original estimates in budgeting, even though it’s difficult to budget. Fortunately, in the technologies that Microsoft works in, it insists on a specific best practice to make this code self-descriptive and self-describing, and indeed, quite a few companies adhere to this, so analyzing this code is okay. There are situations where the company didn’t expect so much development, especially if it’s from abroad and the code is written with a comment in Russian or Italian.

Someone didn’t adjust to the fact that someday it might be international, and that’s when things get interesting.

Marek Mac: Do you get customers who used a family solution, that is, a colleague’s colleague wrote some software that works? Do such people show up at your meetings? I have a conviction that these are difficult conversations. If there is one software person or two, it can be troublesome to transfer this knowledge.

Marek Zasada: Such situations happen, although I don’t remember it being a big problem.

Instead, it is collaboration. It stems from the realization that this software is already several years old, and replacing it with something more efficient would be helpful. This person wants to develop and see something newer. It happens to me that people who have implemented an older version of ERP call me and ask because they know that I am in touch with the latest version: “And how is it solved in the latest version?” They start thinking and wondering: “Do we need to develop what we have or go in the direction of migrating to newer versions of ERP because that will solve all the problems in the future.”

Marek Mac: When we are past the implementation stage, what is your role as a software department? You mentioned ergonomics, of course. How does customer contact continue? Is it a typical service, or does each customer have their contact person, or do they contact you as a programming department?

Marek Zasada: Yes, we have a ticket system; the customer submits a ticket to us and becomes one of many, but we keep the relationship. It’s all the time the people who were at the implementation. They contact those people directly if they are available and have knowledge of that implementation, which is very important. We manage this in such a way that both parties are satisfied.

Generally, such support lasts for many years. We rely on long-term relationships. I am also comfortable with such relationships. Such a client is predictable. For us, this cooperation is simply a model. We also want to be comfortable in our work.

Issues related to legal changes require adjustment, so a trusted supplier is a good partner for developing this system under new circumstances.

Marek Mac: Nowadays, we have such times that we all rely on soft skills. We used not to have that.

When we arrived as implementers, I remember hearing, ” The IT guy has arrived.” Now, we treat our industry as business consultants, and that’s capital.

From an experience perspective, what has been the biggest challenge in your work?

Marek Zasada: It took me a long time to understand specific jargon. When I was a beginner programmer, especially during the first six months, other people could speak to me in Korean, and I understood the same thing.

Building awareness and relationships within myself that are in the system. Recognizing the technical side of the system, how it works, and understanding the fundamental processes and laws that govern themselves in the system. This is an organic collaboration, usually with a consultant. It’s the programmer’s job to draw out the knowledge from the consultant to tell the whole story of how the client’s business works, maybe give a comparison of how we did it at another client and how it differs, to build a sense of the overall process and the business point of the change. That was the most challenging part and took the longest time. I also teach this to all the developers who come to our company. This period can last quietly for two years. He is on the right track if he still doesn’t understand something during this time. We are there to help him.

Marek Mac: What are clients’ most common questions in their first meetings?

Marek Zasada: The questions directed to me are not directly technical, programming questions. My role boils down to capability projection, integration, and system maintenance. They ask how we work and deliver modifications.

If someone has not been exposed, they may not know that we do certain things in the test environment first. I ask key users to study it carefully to avoid experimenting directly on production. This is a collaborative projection. If there is someone from the IT department, questions arise about experience and integration. Sometimes, they ask about the specific systems and solutions the company plans to integrate with and whether we have the competence. This is looking for a partner who has the skills.

If a technical person is present in the meeting, technical issues are discussed; if not, the project is projected to be run.

Marek Mac: Regarding the ticket system you mentioned, wouldn’t customers prefer to call? For them, it’s more convenient and faster. Today, even though we have a ticket system, which is run so that the customer describes a problem so that it is recorded, not a phone call of 5-10 minutes: “Please correct this, do this.” What does that look like now?

Marek Zasada: We are accepting if the customer calls. The ticket system is not just for the customer but also us. If it’s an issue to be solved for 10-15 minutes over the phone, or there was a phone call, the first of many, I set up that task for the customer.

Then, the customer will have information that I have noted. After such a call, I leave a note in the ticker about what we have planned, agreed on, or need a meeting. We manage the tickets for the client.

Marek Mac: Okay, Mark, thank you very much. We will have another opportunity to talk in the future.

Marek Zasada: Thank you.

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.