When an IT system implementation project is completed, companies face a critical decision: how to support and develop the system further—independently or with the help of external consultants (the vendor or integration partner)? Many companies opt for the former, driven by cost-efficiency, independence, and internal control, and choose to create internal Centers of Excellence (CoEs). But is this always the right move? When does it make sense to establish a CoE, and when does it not? 

The rise of low-code development—an approach that allows for building applications with minimal hand-coding—has fueled the trend of establishing in-house Centers of Excellence. The logic is clear: low-code platforms are designed to lower the entry barrier for managing complex systems and empower internal IT teams to make changes without relying on external developers.

The standard assumption is that after deployment, the client’s expert team is trained by the vendor and takes over support and development of the system. The CoE’s main responsibilities are to administer the platform, promote its capabilities internally, gather business requirements, improve existing modules, and develop new ones. Ideally, this leads to faster reaction times (e.g., for process updates or new reports) and reduced reliance on costly consultants.

However, technology is advancing. Modern systems now incorporate machine learning algorithms, mathematical optimizers, and other cutting-edge capabilities. And not all platforms follow the low-code principle. This brings us back to the core question: Is a Center of Excellence still relevant? And under what conditions?

“Help! The system can’t handle it anymore!”

We and our industry peers have often seen the following scenario: implementation is complete, management asks to create a CoE, employees get trained and certified, and take full ownership of the platform. Two or three years later, the client returns with an urgent plea to “save the business,” fix performance issues, and rework the system architecture—because the platform has become so slow and overloaded that further development is impossible.

Before revisiting the architecture, the first step is identifying why the system is underperforming.

Scenario 1: A complete lack of data hygiene. The platform is overwhelmed with disorganized directories—no numbering, no grouping, no searchable structure. All knowledge resides in the head of a single person, who, by default, has become the entire CoE while also juggling operational tasks.

Scenario 2: The system is bogged down by dozens of unused reports. The entire CoE team focuses only on creating reporting—something that should be handled by a BI system. As a result, a expensive IBP platform is utilized at only 30% of its potential. No new business modules were ever launched, despite original plans.

Scenario 3: The CoE tried to build a new module but failed to align its architecture with the existing structure, making the system unscalable across new branches or production sites.

From a manager’s perspective “on paper”, the company has:

• A trained and certified expert team
• Well-paid professionals
• A clear mandate for system performance and evolution

But in practice, users complain about slow response times, system downtime, and needing to work night shifts because the platform only runs smoothly outside business hours. No further development is taking place. From the outside, it’s unclear whether the issue is with the CoE team or the platform itself—so the company eventually turns to external consultants for help.

CoEs: Myths vs. Reality

Myth №1: A small team can continuously grow and improve the platform

Having 2–3 vendor-trained architects is necessary, but not sufficient. Mastering a system is like learning a foreign language: completing a training course isn’t the same as fluency. True expertise requires immersion, regular updates, access to expert networks, and continuous self-development.

In reality, once someone finishes a training programme, they get absorbed in daily tasks and stagnate. Without challenging tasks or expert guidance, they struggle to build new models or design architecture correctly. New module development requires not just an architect, but also a business analyst, project manager, integration specialist, data engineer, and data scientist—roles often missing from in-house CoEs.

As the company grows, the CoE may try to scale the solution, but due to improper configurations, the system becomes sluggish and inefficient.

Myth №2: CoE members can juggle their main duties with platform development

Managers often assume: “Since these specialists are expensive and not fully loaded, they can use their spare time to enhance the platform.” Or even worse: they assign CoE duties as extra work to existing business teams. For example: “Our demand planners already work with the system—let them support it too.” This logic doesn’t hold.

In practice, when CoE staff must balance platform development with day-to-day firefighting, operational tasks always take priority. One real-world example: due to poorly prepared master data, a major project launch was delayed—wasting millions.

Effective CoEs need full-time focus, and leadership should treat CoE investments as long-term strategic assets, not cost burdens.

Myth №3: CoEs save money on platform development

The cost of maintaining a CoE can easily run into hundreds of thousands of dollars annually. For instance, one internal system architect might cost 400 thousand dollars annually (including taxes and benefits). A team of three would total around 1,2 million—roughly the cost of outsourcing a full module implementation to an external integration partner.

Factor in “repair” costs—bug fixing, system cleanup, performance improvements, architectural redesign—and the numbers only grow. That makes each dashboard produced by the CoE almost literally “golden.”

Often, CoEs invent tasks to justify their existence, becoming reporting factories instead of gatekeepers of quality and efficiency. Rather than prioritizing and educating users on what’s feasible, they flood the system with unnecessary visuals and complexity.

Are there success stories?

Yes! One global FMCG brand, after implementing a business planning platform, created an internal CoE to support and enhance the platform’s functionality and replicate the model across other markets. The CoE, initially formed in one country, eventually supported business units worldwide—cutting deployment costs and timelines across regions.

Large tech-driven enterprises also benefit from CoEs, especially those with strong in-house IT expertise and a culture of continuous investment in their systems.

If a company is growing fast, expanding to new regions or countries, and willing to invest in full-time CoE teams, then establishing a CoE is a sound strategy.

But what about everyone else?

If massive growth and expansion aren’t on the horizon and in-house IT resources are limited, the value of creating a CoE becomes questionable. In such cases, it’s often more efficient to rely on a experienced integration partner for advanced and streamlined platform implementation. 

A balanced approach could be: use your planning platform for its core purposes—forecasts, budgets, resource planning, supply chain optimization, promo planning, etc.—and handle simpler tasks like data visualization using cost-effective tools like MS Power BI or Qlik Sense. Since reporting needs frequently change, rebuilding complex systems around them is rarely justified.

With this approach, basic system maintenance remains in-house, while external experts handle new implementations.

AI-Powered Platforms and the CoE Dilemma

As AI/ML-powered platforms become more common, the CoE question becomes even more complex. Supporting such systems autonomously requires not just platform expertise, but knowledge of adjacent disciplines—like programming languages used in machine learning and optimization, e.g., Python.

For instance, adding a new data-entry dashboard for a new production line is something a CoE member can probably handle. But adjusting a mathematical optimizer—the core of many AI-based platforms—is far more complex and will likely require vendor expertise. Full autonomy becomes unrealistic.

Key business processes take years to evolve and require long-term care. Automation—and especially intelligent automation—is not a one-time project. That’s why it’s more effective to develop the system in partnership with the vendor.

In an ideal setup, the vendor provides not only technical expertise but also methodological guidance—offering strategic advice, overseeing complex tasks, introducing new features and trends—while internal teams manage day-to-day operations.