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.
