Categories
articles Business Central Business knowledge Dynamics 365/AX INLOGICA products Other Microsoft products Recommended

DIGITIZATION IN BUSINESS – Programmers: Pillar of the supplier-customer relationship | Marek Zasada

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.

Categories
articles Business Central Business knowledge Dynamics 365/AX INLOGICA products Other Microsoft products Recommended

New: Flexible payment for Copilot licenses!

Table of contents
Nowość: Elastyczne płatności za licencje Copilot!

Good news for Microsoft 365 Copilot users! From now on, you can enjoy an annual subscription, paying in monthly installments. This great solution gives you more flexibility and makes it easier to manage your budget.

Until now, the only option was to pay for the license in advance for the whole year. Now, you can choose the model that best suits your needs – enjoy Copilot’s advanced features while paying in convenient monthly installments.

What's worth knowing?

Don’t wait – use Copilot to streamline your processes and tailor payments to fit your capabilities! Contact our expert and learn more about this offer: https://inlogica.com/en/contact-us/

 

Categories
articles Business Central Business knowledge Dynamics 365/AX INLOGICA products Other Microsoft products Recommended

DIGITIZATION IN BUSINESS – Analysis vs. Workshop: Which solution to choose | Michal Paluszczak

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.

Categories
articles Business knowledge

Intra-community supply of goods (ITA)

Table of content
Wewnątrzwspólnotowa dostawa towarów WDT

The intra-community supply of goods (WDT) is a key element of international trade within the European Union. It is a transaction involving the movement of goods between EU member states in which both the seller and the buyer are VAT payers. You will learn what WDT is, its associated VAT rates, what elements a WDT invoice should contain, and how to correctly issue an intra-community invoice.

WDT, what is it?

Intra-community supply of goods (WDT) refers to the sale of goods between companies from different countries of the European Union. Under WDT, goods are shipped from one member state to another, and both parties are registered for VAT.

Characteristics of WDT:

WDT is an essential element of the unified EU market, eliminating tax barriers and promoting the free movement of goods between member countries.

WDT VAT rate

A preferential VAT rate of 0% is applied to the intra-community supply of goods, an essential incentive for entrepreneurs engaged in international trade. However, the possibility of using this rate is subject to the fulfillment of certain conditions.

Conditions for applying the 0% VAT rate in WDT:

Failure to meet these requirements may result in the VAT rate applying to the seller’s country.

Faktura WDT

WDT invoice

The WDT invoice is the essential accounting document that confirms the realization of an intra-community supply of goods. It should contain certain elements that tax law requires to fulfill its function in VAT settlements.

Elements that a WDT invoice should contain:

The WDT invoice also serves as evidence in case of a tax audit, so its correctness is crucial for tax settlements.

Intra-Community invoice

An intra-community invoice is a broader term that includes invoices issued for intra-community supply of goods (ICT) and intra-community acquisition (ITP). In both cases, the invoice must meet specific requirements, including details of the parties to the transaction and appropriate VAT designations.

What is the difference between a WDT invoice and an intra-community invoice?

The most important rules for intra-community invoices:

Intra-community supply of goods (ITA) is an integral part of the EU market, allowing the free movement of goods between member states. Key aspects such as the 0% VAT rate, a correctly issued WDT invoice, and documentation confirming the transaction’s execution are the foundation for the correct settlement of WDT. With compliance and proper preparation, entrepreneurs can enjoy the benefits of international trade within the EU.

Categories
articles Business knowledge

European TIN – how to check?

Table of content
NIP europejski - jak sprawdzić

The European TIN (VAT Identification Number) is a unique tax identifier assigned to companies doing business within the European Union. Verifying this number is crucial in international transactions to ensure correct VAT settlements and avoid tax irregularities. Below, you will find information on the European TIN, how to check it, and where to do it.

European TIN check - is it possible?

A European TIN check is possible and extremely important in international transactions. For companies making sales or purchases between European Union countries in so-called intra-community transactions, the correctness of the European TIN is crucial. By correctly verifying the VAT number, the entrepreneur can:

Verification of the European TIN is available to everyone, meaning businesses and individuals can check the correctness of the VAT number if they have access to it.

How do you check the European TIN?

The European TIN can be checked in a few simple steps using official tools provided by the European Union or national tax authorities. Here are instructions on how to check a European TIN:

It’s worth remembering that if the VIES system indicates that the VAT number is incorrect, it may mean that the counterparty is not registered for VAT in its country or that the number provided contains an error.

Jak sprawdzić NIP europejski

Where to check the European TIN?

If you are wondering where to check the European TIN, you have several options:

When is it a good idea to check the European TIN?

The European TIN check is essential in verifying contractors and ensuring the correctness of VAT settlements in international transactions. The verification process is quick and easy, thanks to the VIES system and other online tools. If you’re wondering how to verify a European TIN or where to do it, use official sources such as the VIES system. Correct verification is the key to operating safely and legally in the EU market.

Categories
articles Business knowledge

What is the DAC7 Directive, and to whom does it apply?

Table of content
Dyrektywa DAC7 czym jest i kogo obowiązuje

The DAC7 Directive, another update to the EU’s tax information exchange regulations, aims to tighten the European tax system and make it easier for national tax administrations to identify revenues generated through digital platforms. It introduces new reporting obligations for online platform operators and rules for automatically exchanging this data between EU member states. This gives EU tax authorities better tools to prevent tax avoidance and improve the efficiency of tax collection.

DAC7 - what is it?

DAC7 (Directive on Administrative Cooperation 7) is an EU regulation on administrative cooperation in taxation. It is the next installment of the DAC package of regulations (DAC1 to DAC6). Its key element is requiring digital platform operators to report on revenues generated by their users who engage in profit-making activities through these platforms.

Key objectives of the DAC Directive7:

The directive covers a wide range of activities, including the rental of real estate, the sale of goods, the provision of services, and the rental of transportation. Digital platform operators must report data on their users, such as revenue earned, type of activity, and identification data.

DAC7 effective as of when?

The Council of the European Union adopted the DAC7 directive in March 2021, and member states had until the end of 2022 to implement it into their national legislation. Reporting obligations for digital platform operators began on January 1, 2023.

Schedule of key dates:

The first DAC7 reports covered data for 2023 and had to be submitted to the relevant tax authorities by the end of January 2024.

DAC7 report - who does it apply to?

The DAC7 report applies to digital platform operators, both EU-based and non-EU-based, who enable users to generate revenue through their platforms. The directive applies to a wide range of activities, meaning that entities that will allow, among other things, must report:

Who is affected by the DAC7 report?

Kogo dotyczy DAC7

What data must be included in the DAC7 report?

What are the implications of DAC7?

With DAC7, tax administrations gain a tool to identify revenues generated in the digital economy, allowing them to enforce tax obligations more effectively. For platform operators, this means new administrative obligations; for users, it means greater transparency to tax authorities.

The DAC Directive 7 is the EU’s response to the growing role of the digital economy and the need to ensure fair taxation in this area. With the reporting obligation, digital platform operators become a key link in increasing tax transparency, and member states have a tool for more effective cooperation and information exchange. Implementing the DAC Directive 7 is a step towards a tight tax system and a level playing field for all market participants.

Categories
articles Business knowledge

VAT OSS – what is it?

Table of content
VAT OSS co to jest

The VAT OSS (One Stop Shop) system is a simplified VAT settlement mechanism that came into effect in the European Union on July 1, 2021. Its primary purpose is to make it easier for businesses to settle VAT on cross-border sales to end consumers in different EU member states. With VAT OSS, companies can avoid registering for VAT in every country they send goods or provide services.

VAT OSS, what is it?

VAT OSS (One Stop Shop) is a system that allows EU and non-EU entrepreneurs to simplify tax settlements related to distance sales. Under VAT OSS, a business can register in one member state and file a single VAT return covering sales to other EU countries.

Key features of VAT OSS:

VAT OSS is particularly useful for entrepreneurs engaged in e-commerce, digital services, and remote goods delivery.

OSS VAT - To whom does it apply?

VAT OSS applies to entrepreneurs who provide certain types of transactions to consumers in the EU. The main groups subject to the OSS VAT procedure include:

However, OSS VAT is not compulsory – entrepreneurs can decide whether to use this system or prefer classic VAT settlement in each EU country where they sell.

OSS VAT kogo obowiązuje

What does the OSS procedure consist of?

The OSS procedure is designed to make life simpler for entrepreneurs. It makes VAT settlement more transparent and convenient. The OSS procedure consists of several key steps:

Benefits of the OSS procedure:

VAT OSS is a modern tool for businesses operating in the EU that simplifies tax settlements and facilitates cross-border sales. It allows companies to focus on business growth instead of complicated administrative duties. When considering the OSS procedure, entrepreneurs should carefully analyze their needs and the benefits of this solution. VAT OSS is a response to the challenges of modern trade and an opportunity to simplify tax obligations.

Categories
articles Business knowledge

ROI with ERP – How do you calculate the return on investment?

Table of content

ERP (Enterprise Resource Planning) systems are a key tool for managing a company’s resources, enabling the integration of various business processes. An investment in ERP can bring significant benefits, but its cost is also substantial. To assess whether an ERP implementation is cost-effective, it is necessary to calculate the ROI or return on investment. In this article, we will explain ROI, how to calculate it and assess its value in the context of an ERP investment.

What is ROI?

ROI (Return on Investment) is a financial indicator that determines how much return an investment has brought about the costs incurred. It is one of the most popular methods of evaluating the effectiveness of projects, especially those requiring significant financial outlays, such as implementing an ERP system.

ROI measures whether an investment is financially beneficial and to what extent the expenses have been returned. Thanks to its simplicity of calculation, this indicator is widely used by both large corporations and smaller companies.

ROI - what does it inform about?

ROI informs about the profitability of the investment, which is particularly important for entrepreneurs planning to implement ERP. A positive ROI means the investment makes a profit, while a negative ROI indicates a loss.

In the context of ERP, ROI can indicate benefits such as:

The formula for ROI

The ROI formula is relatively simple:

ROI formula

The values in this formula include:

What kind of ROI is good?

Good ROI varies depending on the type of investment and the specific industry. In the case of ERP, achieving a positive ROI after just a few years after implementation can be considered a good result. In general:

The typical payback period for ERP systems is 2 to 5 years, and an ROI of 20-30% per year is often considered a good result.

How much does ERP cost?

ERP implementation costs can vary widely and depend on many factors, such as:

The cost of ERP for a small company can range from tens of thousands of zlotys to millions of zlotys for large corporations.

How to calculate the ROI of ERP?

Calculating ROI from ERP requires considering both the cost of the investment and the benefits the system brings to the company. The key steps are:

Determine the investment costs

The sum of all ERP-related expenses, including:

2. Identify the benefits

Benefits can be divided into:

4. Determine the payback period

Analyze how long the benefits achieved will outweigh the investment costs. For example:

The savings can offset the cost in the second year, and the ROI will be positive.

4. Consideration of additional factors

It is also worth considering intangible benefits, such as improved team morale, better interdepartmental cooperation, or increased compliance.

ROI is a key indicator that allows entrepreneurs to assess the profitability of investing in an ERP system. Calculating ROI requires considering all the costs associated with implementing and maintaining the system and the financial benefits it brings. A well-planned ERP implementation with a positive ROI improves a company’s operational efficiency and increases its competitiveness in the market.

Categories
articles Business knowledge

What is the debit note (accounting note), and how do you issue it?

Table of content
Nota obciążeniowa (księgowa) – co to jest, jak wystawić?

A debit note, also known as an accounting note, is an accounting document. Unlike invoices, it does not document the sale of goods or services but is used for billing in other cases, such as charging additional fees or charging a counterparty for costs related to a contract. In this article, we will explain what a debit note is, how to issue it, and its use in business and tax practice.

What is a debit note?

A debit note is an accounting document used for financial settlements between counterparties in situations that do not require an invoice. It is used when charging costs not directly related to the sale of goods or services. The note allows you to document additional financial receivables or liabilities formally.

When is a debit note used?

The debit note is used in situations such as:

How to issue a debit note?

Issuing a debit note does not require using a unique accounting program – it can be drawn up manually or in any word processor. However, the note must meet specific formal requirements.

Elements of a debit note:

Jak wystawić notę obciążeniową?

Debit note - sample

Below is a sample sample of a debit note:

DEBIT NOTE NO. 01/11/2024

Date of issue: 04.11.2024

Issuer: XYZ Sp. z o.o., ul. Przykładowa 1, 00-001 Warsaw, NIP: 123-456-78-90

Recipient: ABC S.A., 10 Testowa Street, 00-002 Kraków, NIP: 987-654-32-10

Description: Charge for untimely implementation of the agreement by paragraph 10 of the contract no. 123/2024 dated 01.01.2024.

Amount: 5,000.00 PLN

Signature:

[Name of issuer].

Is the debit note an expense?

A debit note is not a document confirming a cost within the meaning of tax regulations. However, if it meets the criteria for a deductible expense, it may become the basis for accounting for costs in certain situations.

When is a debit note a cost?

When is a debit note a tax expense?

A debit note must meet the requirements of the Corporate Income Tax Act (CIT) or the Personal Income Tax Act (PIT) to be considered a tax expense.

Examples of situations in which a note can be a tax expense:

Remember that the debit note must be appropriately documented and by the regulations.

Debit note vs. invoice - application

A debit note differs from an invoice in that it does not document the sale of goods or services. It is also not an accounting document required for VAT settlement. A debit note is used in situations where an invoice would be an inappropriate accounting tool.

Examples of differences:

Correction of a debit note - what should be kept in mind?

Correction of a debit note may be necessary in case of errors in the amount, counterparty data, or other document elements. In the case of a correction, a new document that refers to the original note should be issued.

What should a note correction contain?

A debit note is a valuable tool in financial settlements between counterparties in situations that do not require an invoice. Its proper drafting allows the formal documentation of additional receivables or costs. Although the note does not report transactions subject to VAT, it can be considered a tax expense if it meets certain conditions. Entrepreneurs should remember to draft and make correct notes to avoid billing problems.

Categories
articles Business knowledge

Direct and indirect costs – definition, examples, differences

Table of content
Koszty bezpośrednie i pośrednie – definicja, przykłady, różnice

Costs are an integral part of any business activity. They are divided into various categories that help manage the company’s finances and determine its profitability. Direct and indirect costs are of particular importance. Understanding these concepts and properly distinguishing between them is crucial in managing a company’s finances and in tax settlements such as CIT. In this article, we will discuss the definitions, examples, and differences between these categories of costs and their role in tax accounting.

Direct and indirect costs are two basic types of costs that differ in how they are attributed to a specific activity, product, or service. Direct costs can be linked to a particular project or product, while indirect costs are more difficult to attribute because they relate to the general operation of the company.

Distinguishing between these costs is essential in budget planning, profitability analysis, and tax preparation.

What are direct and indirect costs?

Indirect costs - examples

Indirect costs are related to the company’s maintenance and involve general resources not assigned to a specific project or product. Examples of such expenses include:

Direct costs - examples

Direct costs are related to specific operating activities of the company and are easily attributed to individual products or services. Examples of direct costs are:

Koszty pośrednie i bezpośrednie – różnice

Indirect and direct costs - differences

Direct costs can be clearly attributed to a specific product, service, or project. Indirect costs are not connected to a single product—they are related to the company’s general operation.

Examples of costs:

Impact on the price of the product

Direct costs directly affect the calculation of a product’s unit price. Indirect costs, on the other hand, are included in the company’s overall budget and can be accounted for through the adopted cost allocation methods.

Application in management

Distinguishing between direct and indirect costs allows the company to control the profitability of individual projects better and identify areas for optimization.

Direct and indirect costs in CIT accounting

In the context of corporate income tax (CIT), allocating costs to direct or indirect categories is crucial. Here are the main principles:

Summary

Direct and indirect costs are key expense categories in any business. Direct costs are easily attributed to a specific product or service, while indirect costs relate to the company’s overall operation. Understanding the differences between the two is essential for effective financial management and proper tax accounting, especially in the context of CIT. Correctly assigning costs to the appropriate categories allows a company to analyze profitability more accurately and comply with tax regulations.