The group runs companies in different segments, and each type of business needs a system to manage it. The number of systems grew with the number of businesses.
The group wanted to stop hopping between systems
A holding that runs businesses in unrelated segments replaced several tools doing the same job, including a dedicated HR tool, with one system where purchasing and a full hire-to-exit HR flow already run, and where the stated goal is a single panel that shows directors the whole group.
A holding that manages companies in different segments, and needed a layer they could share.
By the IT manager's description, it includes resellers of a global brewer, clinics, radio stations and festival sound trucks, with about four hundred people across all of them. Each business needs software for what it does; all of them hire, buy, pay and report.
Multi-business holding
1990Year the group began, in printing, from its published material
~400People across the group's businesses
1.5 yearsHow long the group had been using the system at the time of the interview
Several segmentsBeverage resellers, clinics, radio stations and festival sound trucks, by the IT manager's description
~400People across the group's businesses
1.5 yearsHow long the group had been using the system at the time of the interview
4Resellers of a global brewer inside the group
2Modules the interview describes in detail: purchasing and HR
“We wanted to reduce the number of systems and try to centralise as much information as possible, so the board would have more effective decision power, with a panel where they could see the whole group. See all the movement of the group in the same panel. I don't want to have to move from system to system to collect information.”
Wilbert CastroIT Manager, in the recorded interview
BeforeAfter
- Several tools doing the same job across the businessesOne system with a module for each function and sector
- Moving between systems to collect group informationOne place to read information, with a group-wide panel as the stated goal
- A dedicated HR-flow tool, separate from the restAn HR flow from candidate registration to dismissal, inside the same system
- Documents, evaluation, interview and medical exam handled in separate stepsOne flow that carries each step and feeds a database of the state of every hire
- A purchasing flow without notices or alertsA purchasing flow with notices, emails and alerts to suppliers and the team
What was not replaced. The vertical systems for each type of business stayed, by the IT manager's own account of why the group runs so many systems. The businesses and their operations stayed. Email stayed as the channel for notices. The IT manager says the group has "practically an ERP" running inside the system; that is his characterisation of how much the system now covers, and it is not a claim that the group retired any particular ERP, which the interview does not say.
The bottleneck was operational, not commercial
The group is a holding that manages companies in different segments. By the IT manager's description, it includes resellers of a global brewer, clinics, radio stations and festival sound trucks, with about four hundred people across all of them. Some resellers are larger than others, and so are some clinics. The group's own published material shows a company that began in printing in 1990 and has added lines of business over three decades.
A holding like this has a structural cost. Each business needs software for what it does: a beverage reseller, a clinic and a radio station do not share a core system. But all of them hire, buy, pay and report, and when every business does that in its own tool, the group has no way to see across them. The group the IT manager describes ran many systems for that reason, and each new business added more.
That is why the bottleneck was operational and not commercial. The businesses were running. What the group lacked was a shared layer for the processes every business has, and a view across all of them. The idea started with one of the directors, who wanted a tool that unified the group and centralised its information, as the company's main tool.
The group wanted to stop hopping between systems
“We wanted to reduce the number of systems and try to centralise as much information as possible, so the board would have more effective decision power, with a panel where they could see the whole group. See all the movement of the group in the same panel. I don't want to have to move from system to system to collect information.”
The IT manager's concern was not only the vertical systems but the duplication around them: two, three, four, five, six or seven tools doing the same role. The group already used a dedicated tool for its HR flow, and it did not want a second or third tool for a job one system could do.
To know how the group was doing, someone moved from one system to the next and put the picture together. A director who wanted to see the whole group had no single place to look.
The pattern: the group's structure, many unlike businesses under one owner, produced a pile of tools by design. Nothing was broken. But every tool that did a job another already did was a place where information could be out of step with the rest of the group.
Item by item, what did each job before and what does it today
“Our idea when we brought in HR was to do it from the start, from the employee's admission to the dismissal process. We send a link for the person to do the registration and send documents, and then it follows the whole flow of interview, documents, medical exam, and all of it feeds a database so we know how each flow is going.”
| What did this before | What does it today |
|---|---|
| Several tools doing the same job across the businesses | One system with a module for each function and sector |
| Moving between systems to collect group information | One place to read information, with a group-wide panel as the stated goal |
| A dedicated HR-flow tool, separate from the rest | An HR flow from candidate registration to dismissal, inside the same system |
| Documents, evaluation, interview and medical exam handled in separate steps | One flow that carries each step and feeds a database of the state of every hire |
| A purchasing flow without notices or alerts | A purchasing flow with notices, emails and alerts to suppliers and the team |
What was not replaced. The vertical systems for each type of business stayed, by the IT manager's own account of why the group runs so many systems. The businesses and their operations stayed. Email stayed as the channel for notices. The IT manager says the group has "practically an ERP" running inside the system; that is his characterisation of how much the system now covers, and it is not a claim that the group retired any particular ERP, which the interview does not say.
The chain, end to end, for one hire
- 1HR opens the hire and sends the candidate a linkPerson
A person has to start the hire.
- 2The candidate fills in registration and sends documents through the linkExternal
The candidate does this once, outside the company.
- 3The data lands in the database, so the state of each hire is visibleAutomatic
Registration arrives once.
- 4Internal evaluation and interviewPerson
The system cannot know a candidate is right for the job.
- 5Document check and medical examPerson
People and outside parties do this; the system cannot perform a medical exam.
- 6Admission is completed and the record stays in the databaseAutomatic
Every later step reads the same record.
- 7At exit, the dismissal process runs in the same flowPerson
A person has to run the exit.
- 8The database shows the state of each flow across the groupAutomatic
The picture is the same records the operation writes.
The hard links are 1, 4 and 5. The system cannot know a candidate is right for the job, run an interview or perform a medical exam; people and outside parties do. What the design removed is the passing of the same person's data between tools: registration and documents arrive once, through the link, and every later step reads them. The IT manager's own summary is that HR was the most complex module in the system, because it has many variables, and the purchasing flow was the first to go in.
The directors' panel is the aim, not a finished result
The IT manager says it twice and qualifies it both times. What he commits to is that centralisation improved a great deal. No before or after figure is given, and this write-up does not use the percentage.
The IT manager says the purchasing module is not finished after a year and a half, and says that is the team's doing: they keep finding things to improve for the supplier and for themselves. He presents the system's ability to absorb these changes as a quality. It also means the purchasing flow described here is the current state of something still moving.
The interview says what the group wanted to see in one panel and that the system has been taking on more of the group's processes. It does not say the panel is finished, so this write-up treats it as the direction, not the result.
Hires per month, time to hire, supplier lead times and cost of the systems retired are not in the source.
| Indicator | Result | Where it comes from |
|---|---|---|
| Information centralisation | Described by the IT manager as improved "a thousand percent", then immediately as "I know it improved a lot" | Recorded interview; a figure of speech, not a measurement |
| Number of systems | The goal was to reduce them and to eliminate tools by redrawing them inside the system; no count before or after | Recorded interview |
| HR | A flow from candidate registration to dismissal, with status in one database | Recorded interview; described as the most complex module |
| Purchasing | The first module in; still being improved after 1.5 years, by the team's choice, with alerts and emails for suppliers | Recorded interview |
| Group-wide panel | The stated goal for directors; the interview does not describe a finished panel | Recorded interview |
What this case does not measure
All descriptions and both quotes come from the IT manager in a recorded interview. No process was independently observed.
Not one number in the interview measures an effect: no hours, cost, hire time, error rate or count of systems retired. The only percentage is a figure of speech.
Several passages were reconstructed from context. The speaker's name is taken as transcribed and was not confirmed against a public source, and the brand of the beverage resellers is transcribed in a garbled form and left unnamed.
The IT manager counts four beverage resellers and mentions clinics; the group's published material lists five beverage distributors and does not list clinics. The two may describe different moments or different groupings, and neither is reconciled here.
The IT manager calls the tool fairly empty at the start, says the team develops on top of it and designs the modules inside it. Jestor now builds and maintains the system on the customer's behalf; those passages are not used as evidence.
The interview is from the first year and a half of use, and the group's own account is that the work continues. What it describes is progress, not a finished state.
A multi-business group has two layers, and only one of them can be shared
| Indicator | Number | Source |
|---|---|---|
| Apps in use at the average company | 101, passing 100 for the first time after years of roughly flat growth | Okta, Businesses at Work 2025, March 2025 |
| Apps in use at the average company, a different count | 305 | Zylo, 2026 SaaS Management Index |
| Average cost per hire, nonexecutive roles | USD 5,475 | SHRM 2025 Benchmarking Report, as cited by a secondary site; not checked against the primary report |
| Median time to fill, nonexecutive roles | 39 calendar days | SHRM 2026 data brief, same secondary site |
The first is the vertical software each business needs for what it does. The second is the horizontal layer every business has: purchasing, hiring, exits, reporting. The group in this case kept the first and went after the second, which is where the same job was done in several tools.
A hire needs the candidate's data, documents, an evaluation, an interview and a medical exam, several of which sit with outside parties. At the benchmark cost per hire, the collection and re-collection of the same data across tools is a cost with a figure attached. A flow that collects it once, through a link, and lets every later step read it removes the repeat.
Okta counts 101 apps per company and Zylo counts 305, depending on what is counted and where. Both agree that the number is in the hundreds or near it, which is the useful point. Neither says what a particular group runs; its own inventory is the number to plan on.
The system is built to fit, and responsibility for it stays with us
The group already had a dedicated tool for HR when it began, and it knew what that was like: a good tool doing one job, next to others doing theirs. What it did not want was a second, third or fourth tool for a job one system could do. The question a bespoke system has to answer is what happens in year two: a group-wide system nobody can change when a new business joins, or a module nobody can extend when a process changes, becomes one more tool in three years, with a login.
One builder owns each request from start to finish, and one is always in execution.
A new flow, a new automation or a new report comes in through the same channel, without becoming a new project.
If what was built is not right, it is rebuilt. Unlimited revisions within the subscription.
Seats are never the billing unit, which matters when HR, purchasing, each business's managers and the directors all touch the same operation.
People learn to use their app the way they learn any app, by opening it. Building, configuring and maintaining stays on our side.
Full export at any time, by CSV and API. SOC 2 compliant, no exit fee. Pause in one click and the systems keep running.
Methodology and sources
The before-and-after descriptions and both quotes come from a recorded interview with the group's IT manager, used through its machine-generated transcript. Quotes were cleaned of transcription noise without changing their content. The account is the group's own and was not audited. Passages describing the group building on the platform itself were not used as evidence.
Segments, history and the count of beverage distributors from the group's own published material. Headcount from the interview, as the IT manager's estimate. The 400-person figure is the IT manager's, given as "I believe", with no method stated. The four-reseller count is his; the group's published material lists five beverage distributors, and the difference is not reconciled. The 1.5 years and the two modules described in detail are from the interview.
Okta, Businesses at Work 2025 (March 2025). Zylo, 2026 SaaS Management Index. SHRM benchmarks as cited by a secondary site in 2026, not checked against the primary reports.
The "thousand percent" figure is not used as a result. No hours saved, cost saved, hire time or count of retired systems is claimed, because none was given. The finished state of the directors' panel is not claimed, because the interview does not describe it.