Data integration between departments: the challenge is not to have more information, but to make it circulate (“consume THE data”)

There is a fairly common scene in companies that have been digitalizing over the past few years. In a meeting, someone asks for an apparently simple piece of data. It could be the sales forecast for a product, the margin of a project, the expected delivery date of an order, or the volume purchased from a specific supplier. Sales responds with one figure. Finance has another. Operations checks their application and gets a third.

This doesn't necessarily mean that any of the three are wrong. It's possible they are all working with correct information, but extracted at different times, calculated with different criteria, or coming from systems that barely communicate with each other.

The paradox is interesting. We have never had so much data available, yet many organizations still spend a considerable amount of time locating it, checking it, moving it from one application to another, and, above all, agreeing on which version they should use.

To a large extent, this is where the problem of data integration between departments begins. data integration between departments.

For years, business digitalization has been built primarily out of necessity. Sales needed a CRM and implemented it. Finance and administration worked with the ERP. Production incorporated MES, SCADA systems, and other industrial tools. Marketing added automation and analytics platforms. Procurement developed its own procedures, and maintenance did the same with theirs.

Each decision could be perfectly justified. The problem appears later when all these systems have to behave as part of the same company.

A digitalized company can also be full of islands.

Information silos rarely appear because someone decided to create them. They are usually a consequence of growth.

Companies incorporate technology to solve specific problems and, over time, accumulate applications, databases, SaaS platforms, departmental tools, and in-house developments. Some integrate with each other; others do not. And among all these, there appears a layer that almost never shows up in architecture diagrams: people.

It’s the Excel sheet someone prepares every Friday after downloading information from the ERP. The CSV that is exported from the CRM to cross-reference with another file. The email sent to another department to ask if an order is still blocked. Or the shared sheet that ends up becoming, without anyone expressly deciding it, a critical piece of a business process.

IBM uses the concept of a data silo to refer precisely to information that remains isolated within certain systems, departments, or business units and is difficult to share with the rest of the organization. data silo to refer precisely to information that remains isolated within certain systems, departments, or business units and is difficult to share with the rest of the organization.

But the true cost of the silo is not only in where the data is stored. It is in everything that has to be done to compensate for its isolation.

And that work can often go quite unnoticed.

One person spends fifteen minutes preparing a report. Another manually checks if the numbers match. Someone enters information into an application that was already recorded in another. Another employee calls production before responding to a customer because they can't directly check the status of their order.

Individually they are small tasks. Multiplied by departments, employees, and working days, they stop being so.

When the problem is not finding the data, but knowing which one is the right one.

One of the clearest symptoms of a fragmented architecture appears when a simple question needs an explanation before it can be answered.

“It depends on which report you look at.”

“In the ERP it shows one thing, but we use our Excel.”

“The sales data is not yet updated.”

“Production has another figure.”

These phrases will be familiar in many organizations.

Sometimes the problem is purely technical, but other times it has to do with something more difficult to solve: each department understands the data from its own perspective.

Think about something as seemingly basic as an “active customer.” For the sales team, it could be a company with an open opportunity. For finance, someone who has received an invoice in the last twelve months. Marketing might include contacts who regularly interact with the company even if they have not yet made a purchase.

Who is right?

Probably everyone, within their context.

That's why integrating information doesn't just involve getting two databases to communicate. It also requires agreeing on what the data means, who is responsible for maintaining it, and which source should be considered valid when discrepancies exist.

This part of the work is less visible than an API or a dashboard, but it usually determines the success of the project.

Integration starts in the process, not in the technology.

Faced with a fragmented environment, it's easy to start by making an inventory of applications. ERP, CRM, MES, maintenance tools, financial software, marketing platforms, cloud solutions…

It is necessary information, although there is another question that usually provides more value at the beginning: what path does information take when something important happens in the company? what path does information take when something important happens in the company?

Let's imagine sales closes a significant order.

The opportunity has been managed in the CRM, but from that moment, other systems and departments come into play. Availability, planning, procurement, and production capacity must be checked. Later, warehouse, logistics, and invoicing will intervene. If an issue arises during manufacturing that delays delivery, that information can be very relevant to the salesperson responsible for maintaining the customer relationship.

On paper, we are talking about a single order. Technologically, it may have passed through five or six different applications.

When systems are well integrated, much of that journey happens without the user being particularly aware of it. When they are not, emails, calls, spreadsheets, and manual checks appear.

That's why it makes sense to design the integration following business processes, not just the software map.

The important thing is not being able to assert that the CRM is connected to the ERP. The important thing is knowing what happens after a salesperson changes the status of an opportunity and what people, systems, and decisions depend on that change.

Integrating data does not mean bringing everything to the same place.

Another common confusion is equating integration with centralization.

Centralization can be part of the solution, but it is not always the goal.

An organization can use a Data Warehouse to consolidate information intended for reporting and analysis. It can work with a Data Lake when it needs to store large volumes of diverse nature information. It can resort to lakehouse architectures or adopt distributed approaches, such as a data mesh, when its organizational and technological reality advises so. data mesh, when its organizational and technological reality advises so.

At the same time, many integration needs are resolved by having two systems exchange the necessary information through APIs, middleware, connectors, or event-based architectures.

Not all data has to end up in a large central database.

They also do not need to move at the same speed.

An alarm from a production line may need to propagate almost in real-time. A consolidated report of certain financial metrics might be updated overnight. The modification of a master product data will require specific controls before being propagated to other systems.

This difference matters because sometimes technically very ambitious architectures are designed to solve problems that were much simpler.

Good integration is not necessarily the one that moves more data. It is the one that brings the necessary information to the right place, with the frequency that the process truly requires.

Excel is not always the enemy.

In any conversation about business integration, Excel inevitably comes up, usually as an example of something that should disappear.

The reality is a bit more nuanced.

Spreadsheets remain extraordinarily useful for analyzing information, creating scenarios, making quick calculations, or addressing immediate needs. The problem begins when they become the invisible infrastructure that holds together processes that should be integrated.

There is a significant difference between using Excel to analyze a data set and depending on a file that someone has to manually update every morning for another department to work.

In this second case, a dependency appears that is often fragile. What happens if that person is on vacation? What happens if a column changes format? How do we know who modified a data point? Are we sure everyone is using the latest version?

It's not about eliminating tools known to users. It's about identifying when a temporary solution has ended up occupying too important a place within a process.

These kinds of situations usually offer good candidates for initiating an integration project: they are recognizable problems, have a daily impact, and their improvements are relatively easy to perceive.

From moving data to sharing context

There is a significant difference between having access to information and understanding what is happening.

A sales manager may know that an order has been delayed. But it will probably be much more useful to know why, how long the delay is expected to last, and if it affects only that order or several customers.

Finance may know the cost of an incident, but to interpret it correctly, it will need to relate it to operational information. Purchasing may have the order history of a supplier, although its analysis will be much more interesting if they also know about incidents, actual delivery times, or related quality issues.

The most valuable integration comes when it allows for relating information that was previously analyzed separately.

This is where data ceases to be the property of a specific application and begins to explain complete processes.

In industrial organizations, this perspective is especially relevant because some of the information is born outside traditional corporate systems. Machines, sensors, PLCs, SCADA, MES, and other operational technologies generate data that can provide context to decisions made by planning, maintenance, quality, purchasing, or management.

Connecting IT and OT opens up many possibilities, but also requires careful design of what information should cross that boundary and how.

When data starts circulating, security matters even more.

Eliminating silos does not mean eliminating controls.

The more systems are connected, the more important it is to accurately establish which users and applications can access each information, what they can do with it, and how that activity is recorded.

APIs need authentication and authorization mechanisms. Communications must be protected. Identities and credentials require proper management. Certain data needs additional controls for regulatory, contractual, or simply business sensitivity reasons.

In IT/OT environments, the issue deserves even more attention. An integration designed to provide visibility into production should not accidentally become an unnecessary access route into industrial systems.

For that reason, integration and cybersecurity should be considered parts of the same design from the start.

Adding controls after building all the connections is usually much more complicated than incorporating them from the initial architecture.

Data quality quickly becomes a business issue.

Many projects discover as soon as they start connecting applications that the data was not as clean as it seemed.

While each department works within its own system, certain inconsistencies can remain hidden. When the information begins to cross, duplicate clients appear, references written in different ways, incomplete fields, incompatible nomenclatures, or records that have not been updated for years.

Integration makes these problems visible, but does not create them.

In fact, it can be an opportunity to start solving them.

That requires defining responsibilities. Someone must decide which application is the reference source for certain data. It is necessary to establish who can modify them, what validations must be fulfilled, and how exceptions are managed.

At this point, data governance emerges, a concept that sometimes sounds excessively theoretical until two departments need to decide which of their two figures should be used by the steering committee.

Then it ceases to be theory.

Artificial intelligence has made a problem that already existed more evident.

The adoption of artificial intelligence is putting a lot of pressure on business data architectures.

In recent years, we have seen demonstrations capable of querying corporate documentation, analyzing information, detecting patterns, or answering questions about the business in natural language. The temptation is to imagine that it is enough to add an AI layer over existing systems.

But one question remains inevitable: on which data will it work?

If commercial information is in a CRM, part of the history remains in spreadsheets, operations are managed from another application, and industrial data remains disconnected, artificial intelligence will inherit that fragmentation.

The MuleSoft Connectivity Benchmark 2025, based on responses from 1,050 IT leaders of business organizations, showed that 95% found difficulties in integrating data between systems. According to the same study, organizations had, on average, only 29% of their applications connected.

The figure helps put into context a reality that is sometimes overshadowed by the enthusiasm around AI: before building certain intelligent capabilities, there is much integration work that remains pending.

The quality of an AI-generated response depends, among other things, on the quality and context of the information available. An AI with access to five contradictory versions of the same data does not solve the problem. It may simply respond faster using the wrong version.

The client also notices when departments do not communicate with each other.

Information silos are not only an internal issue.

A customer does not think about the CRM, ERP, or support application. For them, there is only one company.

That is why it is especially frustrating to have to explain an issue again that was already communicated the day before, receive different delivery dates depending on who you talk to, or discover that administration is unaware of a condition agreed upon with the sales team.

From the inside, we can understand why it happens: they are different departments working with different tools.

From the outside, that explanation matters very little.

Proper integration helps build a more consistent view of the customer relationship. It does not mean that any employee must access all the information, but that each person can have the context they need to perform their job correctly.

In many cases, an apparently technical improvement ends up having a direct effect on the customer experience.

It is not always necessary to change systems that already work.

One of the biggest obstacles to integration is thinking that it will be necessary to replace half of the company's technological infrastructure.

Sometimes it will be appropriate to do so, but many other times it will not.

There are applications with ten or fifteen years of life that continue to correctly perform a critical function. Replacing them solely because they were not designed with current architectures in mind can be expensive, complex, and, in certain industrial environments, risky.

In these cases, integration layers can be built around existing systems using APIs, middleware, connectors, or specific developments.

Modernization does not have to occur all at once.

It can begin by connecting two systems that today require duplicated information. Continue integrating operational data with a corporate platform. Then automate certain exchanges or build a common analytical layer.

Advancing progressively also allows us to see if each integration is really solving a problem before addressing the next one.

Where to start?

Probably not with technology.

A quite useful exercise is to seat people from different departments around a table and choose a specific process. It can be from the entry of an order to its billing, incident management, supplier registration, or production planning.

Then it's enough to follow the information.

Who enters the first data? Where? Who needs it again? Is it copied manually? Does someone transform it before sending it? Are there different versions? Are there moments when a person waits for confirmation from another department that, technically, they could consult?

Opportunities usually start to appear quite quickly.

With that map, it becomes much easier to analyze which systems are involved, what interfaces they offer, where APIs or specific developments are needed, what information should be synchronized, and what security requirements must be respected.

It also helps to prioritize.

Because a company with twenty applications could probably imagine hundreds of possible integrations. That does not mean they should build them all.

It makes more sense to start where fragmentation is generating errors, delays, manual tasks, or lack of visibility over relevant processes.

A connected organization is not an organization with more technology.

Data integration usually ends up in the hands of technology departments, but its effects go far beyond.

When information circulates correctly, some conversations change. Commercial can consult operational situations without constantly calling production. Finance has more context to interpret certain deviations. Operations can incorporate commercial forecasts into their planning. Management stops spending part of a meeting discussing which figure is correct and can dedicate that time to deciding what to do with it.

That does not happen simply by installing a platform.

It requires architecture, integration, security, governance, and, in many cases, specific software development to cover what standard solutions do not solve.

In Motum Technologies, this type of project is precisely approached from this combination of disciplines. Integration can involve IT/OT infrastructure, connectivity, software development and APIs, cybersecurity, cloud environments, and managed services that allow those architectures to remain available and monitored.

It is an especially important view when integration affects critical processes. An API that connects two business systems stops being just a piece of software when dozens of operations depend on it working every day.

Perhaps that is why the conversation about data integration should start less with technology and more with a fairly simple question: how many times a day does a person in our company have to search, copy, verify, or request information that the organization already possesses?

The answer usually gives a pretty close idea of the path still left to travel.