Running ERP In-House: Lessons From a Six-Country ERP System Rollout

Most enterprise resource planning (ERP) projects are judged on whether they go live on time and on budget. Aissam Drai, ERP Head at the Middle East Broadcasting Centre (MBC), measures success differently. For him, the real work starts the day the system goes live, and it can run for years.

Aissam Drai runs Oracle Fusion across six countries and 38 legal entities at the largest broadcaster in the Middle East, with more than 25 integrated applications covering finance, procurement, human resources, and project and performance management. He arrived on a legacy system, led the migration to cloud, and chose to implement it in-house after two external attempts failed.

Across this episode of the Comparesoft ERP Podcast, he sets out a practical view of ERP selection, implementation, and adoption, shaped by years spent on both sides of the table.

From Consultant to Client: What a Dual View of ERP Reveals

Aissam began his career implementing ERP for other people. That perspective still shapes how he runs systems today.

“I started off my journey as an Oracle functional consultant. I was the person who would sit with a client and implement the software,” he explains. “Being on the implementation side gives you a different perspective from when you become the client, the person who owns the system after it goes live.”

The difference, he says, comes down to what each side is accountable for.

“When you’re a consultant, the company deals with you through a timesheet, the hours you bill and the scope you deliver. You try to close on time so you can move your resources to another project,” he says. “When you work for a company full-time, you’re there. If something goes wrong, people are going to come and chase you. So you have to make it work, because after go-live you’re not going anywhere.”

That gap, he argues, explains why so many ERP programmes struggle.

“In the industry, we have a high rate of ERP project failures,” Aissam continues. “It’s because we tend to focus more on the technology. But the technology is only a small portion of the success criteria of an ERP implementation.”

It also leaves him better equipped to scrutinise the vendors he now buys from.

“This is what equips us today to challenge any vendor that comes to work with us. We can ask the right questions to validate what they say,” he adds. “It’s not that vendors come with bad intentions, but sometimes they choose the easy way, which may not give you the best outcome once it’s running in production.”

How MBC Runs Oracle Fusion Across Six Countries

MBC’s setup is large, and deliberately not uniform.

“It’s what I’d call a big Oracle shop,” Aissam says. “We have the full scope of financials, procurement and supply chain, human capital management and payroll, project costing, and project portfolio management. It’s a multi-entity setup, with Oracle running across multiple countries in the region.”

Crucially, each country is configured to its own rules, not copied from a template.

“It’s not a copy-paste,” he explains. “Payroll in Saudi Arabia is different from payroll in Egypt, and different again from payroll in Jordan, because there are different labour laws governing things like social insurance.”

Payroll is where that complexity bites hardest. “Payroll is one of the most critical. If something is wrong with payroll, it cannot wait. People need to be paid on time,” he says.

He is candid that no ERP system removes complexity entirely. “I don’t think you can claim that at any point the complexity faded away completely. You’re trying to minimise it, but saying it’s gone entirely, I don’t think that’s realistic.”

Why MBC Moved From Legacy ERP to Cloud, One Step at a Time

Aissam joined when MBC was still running Oracle E-Business Suite (EBS), its legacy platform. The migration to Oracle Fusion, the cloud ERP system, was anything but a single leap.

“We had two options. Be a late adopter, after everyone else, or be an early adopter but go slowly,” he says. “Not Big Bang, all across, but slowly, building success stories as we went. The first thing we launched in Fusion was a single performance management module. We tested many things, because a vendor can claim a lot when selling software. Unless you do it yourself, with your own hands, you won’t uncover the complexity.”

Three problems with the legacy system drove the move:

• User interface. “The original Oracle interface was just awful. There were companies whose entire product was an interface you’d place on top of EBS, because the standard one was so poor.”
• Customisation. “EBS was an open book. You could customise almost anything,” he says, a freedom that later made upgrades far harder.
• Upgrades. “Upgrades were painful, because they were long, and because the customisation you accumulate makes them almost impossible. So there’s no return on your investment.”

The driver behind moving early was not technology. “It was mostly people related,” he says. “And by people, I mean two groups: my own team, and the users we serve.” Moving slowly bought time to bring both groups across, from EBS habits to Fusion thinking.

He is clear that the work is ongoing. “Even today on Fusion, I still cannot claim it’s a rosy picture. We’re still trying to stabilise things and get to a level where people are more or less satisfied.”

Choosing an ERP System: Why Process Comes Before Features

When it came to selection, MBC never seriously looked elsewhere. The scale of the estate made switching impractical, so the question was how to choose well within Oracle, not whether to leave it. If you are comparing and shortlisting ERP systems, Aissam’s warning is to resist starting with a feature list.

“Changing an ERP system is not easy,” he says. “Before you select, you really need to do a lot of housekeeping inside first, because once you’re in, it’s extremely difficult to get out. Functionalities are the last thing to look at.”

Having worked on both SAP and Oracle, Aissam also has a comparative sense of how differently the two platforms behave, particularly around customisation.

“I had a chance to work for a short period on SAP. When I asked about customisations, people would tell me, no, it’s impossible, you cannot do that,” he recalls. “Whereas in Oracle, it’s an open book. You could pretty much customise anything.”

That openness can look like an advantage when you are choosing a system. In practice, it cut both ways for MBC. The freedom to customise everything is exactly what later made Oracle upgrades long and, at times, almost impossible, eroding the return on the investment. It is a reminder that what you select is a way of working you will live with for years, not just a list of features.

The Case for Implementing ERP In-House

MBC’s most distinctive decision was to run its implementations itself. It was not the original plan.

“Initially, management decided the implementation would go to an implementer. We tried two implementers, and it didn’t work,” Aissam recalls. “On the third attempt, we took it in-house. The whole transformation, from one country to the next, was done by our own team.”

The logic rests on something an external partner rarely has: deep knowledge of the business.

“No one can claim they know your business better than the people inside the company,” he says. “An implementer knows the system very well, but in the world of ERP it’s not one size fits all. You really need to understand the business.”

He is careful not to present this as a universal answer. “This model may not be right for every organisation, because it’s costly. Building internal expertise takes people, and it takes time.”

Where it fits, though, the cost case can be stark. “In certain implementations, we were quoted a million, a million and a half, just for a number of entities,” he says. “Compare that with the payroll cost of twenty or thirty consultants, and the difference is massive.”

Convincing management to back the in-house route, after two failed attempts, came down to proof rather than persuasion.

“Before we called the implementers, we picked one small entity, Jordan, and rolled it out. We wanted to make it a success story,” Aissam explains. “When the implementers failed, we approached management and said, let us do it. We didn’t get the go-ahead for everything, only the next small one. Then the next. We were building momentum, showing one implementation after another that this would only succeed with us.”

Why ERP Implementation Really Begins at Go-Live

For Aissam, a smooth launch is not the finish line, it is the evidence that the groundwork held.
“Usually, once you go live, you start hearing about problems,” he says. “The success here was that it was so smooth people couldn’t believe we’d been through an implementation. There were issues, but the speed and quality of fixing them gave people confidence.”

Sustaining that after go-live depends on two things in particular. The first is discipline, a habit Fusion forces in a way the legacy system never did.

“In Fusion, the upgrade is pushed through by Oracle. You agree a schedule, and whether you want it or not, it’s coming,” he says. “You have four upgrades a year. If you don’t test properly, something is going to break.”

The second is business knowledge, which he protected by blending old and new. “We brought in younger consultants with a Fusion background and made the two work together,” he says. “The seniors who knew the business stayed senior, but to my surprise they adopted Fusion too, because of the daily interaction with those new consultants.”

Driving ERP Adoption and Tackling Shadow Systems With Agentic AI

A stable system that no one uses, Aissam argues, has failed. So when people slip into spreadsheets and workarounds, his team’s first move is curiosity, not blame.

“We try to understand what made them go for a shadow system. The first reaction in many ERP teams is to be upset. But there’s usually a reason,” he says. “If you put yourself in the user’s shoes, the process is sometimes cumbersome. You go through so many screens to get one thing done. Someone who logs in once a week won’t remember which screen to use. Open an Excel sheet, and it’s one sheet. They can do everything there.”

This is where AI is starting to earn its place, framed firmly as support rather than replacement. “AI is a new addition for us, mainly for automation,” he says. “The aim is not to remove the user, but to take away the pressure of dealing with multiple screens to do something simple.”

He gives a concrete example from requisitions. “Someone enters requisitions from a pile of paper, line after line, sometimes over several days. If we scan it, the AI fetches the information and pushes it into the screens, and the human only checks it’s right and clicks a button,” he explains. “That helps adoption tremendously. If a system is not used, you have not served the purpose.”

On where AI agents are heading, he keeps a person firmly in control, and reaches for an analogy. “It’s like a self-driving cab. The cab can’t move without you. You need to be inside for it to start moving,” he says. “The human’s role is to supervise what the agent does. For many years to come, the human in the loop will be very important.”

An ERP Leader’s Advice on Selection, Implementation and Adoption

Asked what a first-time ERP buyer should get right, Aissam offers four points:

1. Agree your processes, not just document them. “It’s not enough to have your process documented. Your process needs to be agreed. Take procure to pay. It starts in procurement and finishes in finance. Those two departments have to sit together and agree. If you don’t, it becomes a conflict during the implementation, and an implementation can’t afford that.”
2. Keep enough expertise in-house. “You need at least the minimum viable number of people, even one or two, who have full knowledge of your process and some knowledge of the application. Without that in-house expertise, you’re at the mercy of the vendor.”
3. Respect data migration. “Data is usually a nightmare during implementations, and people underestimate it. At least do your due diligence: know your data, know who owns it, know the problems with it.”
4. Fund change management early. “Change management is very important, and it’s usually not given the importance it needs. When you talk to the board about it, they’re not always willing to give extra budget. Sometimes it’s so important you need to start it, and data migration, before you even begin the implementation.”

The Mistake That Taught Him the Most

Asked for a memorable mistake, Aissam returns to the early days, and to a lesson about how people really make decisions.

“Getting sign-off was always difficult. I thought it was because, when we gathered requirements, we added our own advice on top,” he says. “So we tried letting users tell us exactly what they wanted, word for word, with no changes. We expected the sign-off the next day. It still didn’t come. What people tell you and what they see once you build it are rarely the same picture. People sign off on what’s in front of them, not the requirements document.”