A few words to introduce yourself?
I’m Damien Delbende, I created a consulting agency for construction companies. We have two brands : Data Efficiency for large groups and Data4BTP for smaller SMEs because they don’t have exactly the same issues. Large groups want to exploit all the data that they already have and which is very bulky. SMEs want to know how to use tools adapted to their activity and closest to their field to digitalize their processes.
We are an agency of three people, our company is 3 years old, and the 3 of us now share project manager roles, data engineer, data analyst, data scientist. We gave me the role of UX designer. That consists of designing hand-crafted tools for us to offer. With Data4BTP for SMEs, we install software which already exist on the market most of the time, like Odoo for example for the CRM part, or Kizeo for all forms. But for example, on the costing part, we reached an empty spot there is no real suitable software for this complex task. So that’s the reason why we called you to help us design a tool really impactful and relevant for construction SMEs.
The costing part is a difficult subject. I started by that when I was at Bouygues fifteen years ago, Each construction site is always different. There are new materials, new designs, new configurations and the architects are having a blast. So, every time, the project must be studied to not miss a thing. So if you spend too much time to study the project to make sure the costing part is ok, you often spend money quickly because you don’t always earn money fast. And if you don’t study enough you have a risk of making a mistake. And then, at the time of construction, you’re having trouble because you discover that you forgot things.
So the costing part is a good balance between studying the project, but not too much either to not be too lost.
For SMEs it’s not easy to know how to manage this, to know how to treat the costing data because you must have a price database which is at the same time exhaustive, which corresponds well to their activity and which lives. Because every year, we still have price changes, product developments.
So the SWITCH solution that we developed with you, answers all that.
Can you tell us a bit more about SWITCH?
Digitalizing the costing activity is a large thing to do. First, we try to recover the client’s frame. For every offer we have to get them in a framework called the DPGF and so rather than typing it by hand, we found a system where this document is collected, we get the formatting and the data is entered directly in this framework. This process made us save about 2 hours on a quote.
Then, by talking with artificial intelligence, we try to do the mapping among those who asked and the price base. And it is also a time saver which can be estimated at three or four hours.
Then we check to validate everything that has been imported automatically. We make adjustments, we can refine the way the costing data is setup in terms of working force, of rate, of product, make variations. We can retrieve pieces of data that we had done in other contexts and then we send the data directly in the CRM who will format the quote, manage customer relations.
So with SWITCH, we really pushed the limit of the automation of the costing data and I think this will allow SMEs to respond to twice as many quotes in the same time.
Why did you choose R Shiny over another technology?
That’s a good question. I went to see our exchanges at the beginning of the project. We had a lot of questions and the argument you explained to me had guided me. You said « Ok, you can do with an other technology, but when you will have to maintain the app, you will need several skills, each will have their own code bits on the backend, frontend etc., and finally, it will be way more difficult than what you have done in Shiny where only one person who knows the code ». Shiny can hold the whole app together. This argument convinced me. As I knew Shiny, I knew it was possible.
But on the other hand, to go into production, it was still necessary to do things well. I had already made apps in Shiny and I’d hit some walls with packages disappearing, with slowness, with data that we did not recover. I know it was necessary to partner with someone who knew how to put into production an app on Shiny, so that’s the reason why I’ve asked you to work with me.
Also, the advantage is that I searched other competitors specialized in Shiny, for example Appsilon. He told me the entrance ticket is 25,000. And me, at my beginnings, I didn’t have planned everything. I knew it was a long-term project, really innovating, which will disrupt the market for SMEs. But I had no plan on specification and to invest 25,000 at the beginning. So, you adapted. You told me we will make progress with a small volume at the beginning to let you time to design things properly. Then, little by little, we accelerated, expanded the bandwidth with the contribution of Marc-Aurèle in particular. And that allowed the project to take off, and at the same time to keep up with my design pace because I changed it to be a side-project.
How did the collaboration go?
The Shiny’s expertise is really there, and I had it on another project. We had worked together, and I was amazed by the design aspect because he had managed to make a Shiny app, which is really in the customer’s colors with a special design. And it was very much appreciated.
There, in the case of the SWITCH project, it’s more the technical aspect because there are trees with R data.tree and shinytree, which we need to manipulate. And we want the data to be versatile, to be transformed in a management grid. So that means you have to be able to manipulate the tree. That’s the very technical part on which you have done really well. I am very satisfied.
The part where I felt a little bit more frustrated is sometimes, I don’t understand your technical choices too much. For example, why make a helper file with functions displayed in one place, then use Class R6 in another place, then make a source file in a third place? I discovered that. I trusted you, but it’s true that I didn’t understand it well enough why you made those choices. And maybe I just needed a little more explanation to help me understand. For exemple if I have maintenance to do, to stay on the path that you tried to put in your way of coding because Shiny can be coded in many different ways.
What is the future of the SWITCH project?
Well, now I need to sell it. In a month, I’ll install it at a customer’s. We will validate everything and do the field test. And then, if the customer likes it, we will launch it a little bit more massively, and then I will come back to you certainly for new features which will be requested.
For now, we will still offer it widely. We’ll offer it to some happy few. It will allow us to follow how they use it. If there are things to change, it will be the V2.0 that we will offer more broadly, maybe in a free version or with a trial. I don’t know, but it’s a strategy. Because, with our customers, we don’t install only the costing data app. We are installing a whole ecosystem with customer management, with also field data and a management portal to be able to manage construction site performance. And this makes a fourth brick that comes in to be able to coordinate and manage to recycle field data in the data. So, it is a whole ecosystem that we offer. That’s why it takes a little bit of time to settle down. And maybe people will only be interested just by the costing part. We will see.
Comments