With this fifteenth episode of SME Banking Conversations, I continue the series of inspiring interviews on SME Banking, digital transformation, and people making innovations happen in the industry!
The recording of this episode took place in July in Kraków (Poland) at Comarch Innovation Space.
We talked with Karol Leszczyński, Product Development Manager at Comarch Factoring Platform (one of the leading tech providers here in the CEE region), and Katarzyna Matias, Product Development Director at mFactoring (one of the leading factoring companies in Poland) about the transitioning from old factoring systems to new ones, complexities of such transition and discussed practical insights to optimize the process for factors and its customers.
You can listen to my conversation with Karol and Katarzyna here:
And read full conversation below:
Olena Gryniuk: Karol and Katarzyna, I’m very glad we’re recording this conversation here at Comarch Innovation Space. Karol, thank you once again for hosting us here! It’s been laud on the Polish market about your cooperation. I’m really glad that I have this opportunity to ask you both about that in detail.
Karol Leszczyński: It’s always a pleasure to have you here.
Katarzyna Matias: Yeah. And thank you Olena and, Karol, it’s nice to share our experience with you.
OG: Comarch Factoring Platform is a cloud-based platform, and we all know, and we do see that here in the CEE region, financial companies are moving their operations to the cloud. Katarzyna, my first question to you was it the key factor in your decision to choose Comarch as your technical partner and provider for a new factoring platform, or were there other reasons behind your shift or your decision to shift to a new factoring system?
Katarzyna Matias: Thank you, Olena. That’s a good question to begin with. So, why Comarch, and, why we wanted to change our system? First of all, we wanted to meet our clients’ expectations. We also observed the Polish factoring market and decided we needed to change the logic of the system based on balance to the one-based pay invoice settlement. Of course, the fact that Comarch factoring platform is a cloud-based system is an advantage, but it wasn’t a key factor in our decision. When choosing the new provider, we needed to factor in a few aspects. Such as, to what extent our requirements were covered; time of implementation; infrastructure; methodology of working on projects; and last but not least, the price. So, taking it all into consideration, we chose Comarch.
OG: I know that before signing the agreement you had functional workshops between mFactoring and Comarch teams, and I think that this is extremely important. I’m not sure whether other tech providers are doing this on the market. Karol, is it your usual way of doing things? Katarzyna, how did you like the experience?
Karol Leszczyński: I think it’s becoming more and more popular in our industry right now. It means that after signing an LOI, and a letter of intent, we prepared our workshops during which we went through the system, block by block, to show all the functionalities, how the system works, and how Kasia mentioned logic works. We provide a separate implementation team for those workshops. We wanted to be sure that our developers and our programmers are still in the production of our platform and a separate implementation team helps our clients understand the system.
Katarzyna Matias: We had some time limitations in that project. We knew that negotiations leading to signing a contract would be time-consuming. It was our mutual idea to do these functional workshops in the meantime, and we liked this idea. As Karol mentioned we decided to cooperate, having only the letter of intent signed. And I think that the willingness of both parties to cooperate gave us this flexibility in that project. We started functional workshops with daily meetings. We took all our requests for proposal points to see whether we were on the same page and whether we understood each other well.
Well, we divided this document into sections to select our must-have requirements for go-life and the others nice-to-have for a later phase. During that meeting, we focused on each functionality one by one and delved into details to see whether the system worked exactly as we expected or if it should be developed further.
Karol Leszczyński: It’s like Kasia mentioned that it’s all about flexibility because we divided our implementation into, for instance, three phases. And we decided that these particular functionalities must be implemented in phase one. We can wait with other functionalities for phase two, etc. So, I think flexibility is a keyword here.
OG: How many people were engaged in that project from your side as Comarch and from your side as mFactoring?
Karol Leszczyński: After the workshop stage, we work with six separate development teams that are combined with programmers, analytics, and of course, project managers and Scrum Masters. Each separate team works on two weeks’ sprints on separate functionalities. So, after two weeks we provide our clients with the improvement of some functionalities or new functionalities. So basically, it was six teams, with five-six people in each team.
Katarzyna Matias: Yeah. And I think that at our company, at mFactoring, it wouldn’t be an exaggeration to say that there were times when half of the people were involved in the project, especially during these functional workshops and during tests. And of course, we had a proper project team with a project manager product owner, and representatives of each department. But, while they were working on the project, other people had to take on their duties, so, they were indirectly involved also in that project. It was a very intense time for all of us.
OG: How exactly did those teams cooperate within or at the development stage and after the implementation?
Karol Leszczyński: We are cooperating on a daily basis. That means that our both teams, from the Comarch side and mFactoring side, are speaking on a daily basis. Each day we have a call during which we discuss the implementation that we made yesterday. And the plans for the next day. Maybe we have some questions about some functionalities, and maybe mFactoring has some questions for us. So, as I said close cooperation on a daily basis is very important here.
Katarzyna Matias: During the implementation, as we bought the product from the shelf, we agreed to develop only our must-have requirements for the MVP version for go-live. So, the rest we left for later phases. This is important to mention that Comarch works on agile methodology in their projects. So, we were able to see the development and the results of development every two weeks and then test it and approve it. This is very useful, also right now, after the implementation, because, getting to know the system better with some of the requirements we agreed on at the very beginning to the others we needed, but we didn’t know about this because in the early stage we couldn’t recognize this as we hadn’t known the system back then. Comarch’s approach is to work with quarterly releases. So right now, we are working like this, we are planning the backlog and all the development for each quarter. Then we receive the features to test, we approve it, and we implement it into the system with quarterly packages.
Karol Leszczyński: In our case, as Kasia mentioned, we have a quarterly release. So, we have four releases during the year, when we are providing software, new software functionalities, or some improvement of our system.
OG: Katarzyna, I’d like to ask you about customers’ migration, because this is the main pain point in the process of changing the systems. So, how did you do it in your organization? Was it a Big Bang approach, when you migrated all the customers simultaneously, or you did do it step-by-step?
Katarzyna Matias: After going live, we decided to implement all the new clients into our new system. So, a new system was introduced to them from day zero. With the existing portfolio of clients with decided to take this step-by-step approach. The reason for that was that we have a big client portfolio, and also, together with changing the system, we decided to refresh our documentation to make it more client-oriented. So, we needed the time to have our clients become familiar with the latest version, and to sign it. I have to say that there are positive sides to that kind of approach. We could get to know the system better and prepare our clients properly for migration. And of course, after migration, we had the space, and it was convenient for us to have time to answer clients’ questions. But now having that experience, I have to admit that it was a tedious process and, if changing the system for the next time I would recommend the Big Bang approach.
Karol Leszczyński: Of course, there are pros and cons of both approaches. In this case, when we are migrating clients step by step after, for instance, 30 % of client migration, we are able also to see the feedback of those clients. We must remember that when we are changing a system to the new one our clients can’t expect that it will be a copy of the old one. So, clients also need to learn how the new system works. This feedback after one month, for instance, is also very important. In the Big Bang approach, the clients ended up on Friday with the old system, and they woke up on Monday with the new one. All the data migrated. That’s the main difference between these approaches.
OG: How long did it take from the moment of the signing of the agreement about the cooperation till the go-live moment?
Katarzyna Matias: Starting from signing the letter of intent to go live it took us about nine months. So, I think this is pretty surprising and impressive.
OG: What’s the first feedback of the customers? And employees?
Katarzyna Matias: The first feedback from our new clients was very positive. But we were impatient to hear from the migrated clients, those who changed the system. This feedback was also very positive. Clients especially appreciate the front end, which is very intuitive and user-friendly. The client can manage by themselves the system, they can manage their users, create their own reports, and create the file formats for their needs. So, we really think that it’s something very good for our clients. Of course, we are conducting a Net Promoter Score survey among our clients regularly. And one of the questions there is about the system. We ask clients about cooperation and the new system. There is a plan to listen to the client’s voices and to develop and change the system together with them according to their needs. And this was our priority from the beginning, to satisfy our clients. Regarding our internal clients and our employees, I have to say that there is some work to be done. We have some challenges, especially in operations, to improve in payment matching process, for example, and to reduce the number of clicks required in the system. This is what is before us.
Karol Leszczyński: It’s worth mentioning that when we are preparing the system in the case of the front office, we ask the end users at the end of the day, about their opinion, about what we should improve in our system. As Kasia mentioned NPS survey is very important for us as well. In the case of the back office, there is a little bit different story because in this case, we are asking factor’s employees to show us when we can and where we can improve our system. We use our Comarch user experience laboratory, and I think the result is very impressive.
OG: Now when you have this project let’s say behind you, the system is implemented, are there things that you think you could have done differently? Both of you.
Karol Leszczyński: In my opinion, the thing that I would change was the timeframe, because nine months is, of course, impressive, it’s very good for both organizations, but we both were a little bit tired because of the speed.
Katarzyna Matias: I agree, with the pace of the project, because we were really working hard to make it happen. I mentioned about migration. And also, I think that I would give more attention to tests. Just so we could have tested the system better and know it better before we started to work with it. That’s from me.
OG: Okay. What are your plans for the future?
Karol Leszczyński: That’s a very good question. I’m a very big enthusiast of creating our roadmap, about creating our future with our clients. We also want to be very transparent in this case. That means that we are creating our roadmaps for two years ahead. That means that now in 2024 we are planning very carefully our work, our new functionalities, and the improvement of our functionalities. When we think about 2025, we ask our clients about their needs, and what they would like to have in our system, and we are trying to figure it out with our product owners, and our development team to meet the client expectations.
OG: Thank you very much for this conversation!
