Who is it up to today to find the right information in your company?

A client asks for a document. Someone asks in a chat what the latest version is. Another person remembers that there was a pending change. A third party has a different copy. The work stops until someone who knows the context appears.

This type of situation is usually treated as a personal problem. Often it is something deeper: the company has not converted information, responsibility and status into a shared system.

1. The symptom is not “we have too many files”

The amount of information is not necessarily the problem. Friction occurs when the organization cannot quickly and confidently answer basic questions:

• Where does a new request come in?
• Which record represents the real case?
• Who has the next step?
• What version is approved?
• What decision was made and why?
• What happens when information is missing?
• Who can resolve an exception?

If the answer depends on a specific person, the knowledge exists, but the system does not.

A core folder does not by itself create a core process.

2. The hidden cost of reconstructing context

Searching for information has a direct cost, but also an indirect one. One person interrupts another. The second abandons its task, reconstructs context, responds and then needs to concentrate again. Furthermore, the original case remains stopped.

The total cost may include:

• Search time.
• Internal interruptions.
• You wait.
• Rework due to using an incorrect version.
• Duplicate decisions.
• Transfer errors between areas.
• Dependence on key people.
• Difficulty incorporating new employees.

There is also a scalability cost. If each increase in volume requires more human coordination, the organization is not scaling the process; Friction is escalating.

3. Distinguish four problems that are often mixed

Scattered information

Relevant data lives in multiple tools with no clear rule as to which takes precedence.

Unstructured information

The data exists, but it cannot be easily related to the client, project, order, file or status.

Information without ownership

No one has explicit responsibility for its updating and quality.

Information without operational context

The information may be correct, but it does not explain what should happen next, who decides, or what exception exists.

Each problem requires a different intervention. Buying another tool without distinguishing them usually adds a fifth location for the same information.

4. Start with the business objects

A useful information architecture is designed around real business objects: customer, opportunity, contract, order, incident, project, asset, invoice, file, document or supplier.

For each object define:

The question is not “in which folder do we save this?”, but “what does this data represent within the process and what decisions depend on it?”

5. What it really means to have a source of truth

One source of truth does not mean that the entire company uses a single database. It means that for every important piece of information, there is a defined authority.

For example, the CRM can be the source of truth for a client's commercial status, the ERP for billing, and the document manager for signed contracts. The important thing is that there is no ambiguity about which system is in charge.

A source of truth needs four properties

• Authority: We know which system prevails.
• Current events: There is a rule to keep it up to date.
• Accessibility: Authorized people can consult it when they need it.
• Ownership: Someone is responsible for the quality of the data.

If any of the four are missing, trust is degraded.

6. Design synchronization rules, not indiscriminate copies

When several systems need the same data, it defines synchronization address and frequency. Not everyone should be able to edit it.

For example, if the customer's primary email is edited in CRM, other systems can receive a synchronized copy. Allowing each system to modify it independently creates conflicts.

For each shared field it is advisable to decide:

• Where it is created.
• Where can it be edited?
• Who validates it?
• What systems consume it.
• What happens if synchronization fails.

7. States convert information into operation

Saving data is not enough. A process needs to know what situation each case is in.

States should be observable and mutually understandable. “In progress” is often too ambiguous. Statuses such as “awaiting documentation,” “pending approval,” “ready to ship,” or “blocked by customer” contain more operational information.

A good state model allows us to answer:

• What can happen next.
• Who has responsibility?
• What condition allows progress.
• How long has it been standing?
• What cases require attention.

8. Make ownership explicit

A “team” task usually ends up being no one's task. For each case there must be a current owner or a clear assignment rule.

Ownership does not mean that one person does all the work. It means that someone is responsible for the case moving forward or being escalated.

It is also convenient to distinguish the data owner, the process owner and the technical person responsible for the system. They can be different people.

9. Record decisions, not every click

Useful traceability does not mean storing infinite noise. It records what allows us to reconstruct a relevant decision:

• Important status change.
• Approval or rejection.
• Modification of critical data.
• Responsible person who made the change.
• Moment of change.
• Reason when necessary.

This reduces memory dependency and makes it easier to investigate errors without turning the system into an unmanageable file.

10. Design access for necessity, not convenience

Good architecture makes information accessible to those who need it without making everything public. Define permissions by role, sensitivity and action.

There is a difference between being able to consult data, modify it, approve it or export it. Separating permissions reduces errors and helps maintain accountability.

11. Don't try to solve organization with semantic search

Search engines and AI can help locate scattered content, but they are not a substitute for data authority.

If there are two conflicting versions of a policy and neither is marked as current, an AI system can retrieve both. The problem is not the search capacity: it is the lack of government.

First resolve what information is valid, who maintains it, and what date or version matters. AI can then improve access, classification, extraction or summary.

12. Avoid duplicating information “just in case”

Manually copying data between sheets, CRM, email and documents creates operational debt. Each copy adds a new opportunity for divergence.

When possible, save the data once and reference its source. If a copy is required for performance or integration, define synchronization and error handling.

13. Design the flow of a request from start to finish

An information system must connect input, context, responsible party, decision and result.

1. The request enters through a defined channel.
2. It is registered with the minimum data.
3. It relates to the correct object.
4. Responsible is assigned.
5. The necessary information is validated.
6. The action is executed or approved.
7. The result is recorded.
8. The next step is activated.
9. Exceptions are escalated with context.

This journey makes visible where it is worth automating and where human judgment is needed.

14. Measure if the architecture really improves

Before the change, record a baseline. Then measure again.

The improvement should appear in the operation, not just in the new interface appearing neater.

15. A practical exercise to detect information debt

Select between five and ten recent cases that have generated doubts, delays or rework. For each one reconstruct:

• Tools used.
• Archives consulted.
• Messages sent.
• People who had to be asked.
• Duplicate data.
• Decisions without registration.
• You wait.
• Points where it was not clear who should act.

Then group the problems. If repeated patterns appear, you already have an initial map of operational debt.

16. How to prioritize improvements

Don't try to centralize everything at once. Prioritize the objects and flows that generate the most impact.

It starts where three factors coincide: high volume, high dependence on information and visible consequences when the data fails. First define source of truth and state; then integrate and automate.

Conclusion

Business information creates value when it allows you to decide and act. Having documents is not the same as having operational context.

A robust architecture makes it clear which object represents each piece of data, where the authorized version lives, who is responsible for its quality, what state each case is in, and what should happen next. That clarity reduces searching, interruptions, rework, and dependence on individual memory.

Only later does it make sense to add automation or AI. Technology can speed up a clear system; cannot decide for the organization what information is true.

To see how we analyze processes, data, and dependencies before designing a solution, see our method.