Your CIO shows up with a list of 23 different tools, each purchased by a separate department. Procurement has its ERP, finance has its accounting software, operations has its tracking system, and customer service has its CRM platform. Nothing talks to each other. The same data gets re-entered three times between initial request and final delivery. Nobody decided to create this chaos, but everyone suffers from it.
The problem is not technical. It is an architectural decision problem: you carved up your information system along the org chart, not along your operational flows. As a result, each tool stops at its department boundary, and every business process crosses several tools that cannot communicate.
Here is how to shift from a silo logic to a process-based architecture without throwing everything away.
How IT fragments: nobody decides, each department buys
The scenario always starts the same way. Procurement realizes Excel is no longer cutting it, so they consult three vendors and choose a procurement ERP. Two months later, finance discovers that the procurement ERP does not send them data in the right format, so they buy their own accounting software. Meanwhile, operations launch an RFP for a service request management system because they receive information five days late.
Each decision is rational at the local level, but nobody sees that a single business process (for example, purchase-invoice-payment) now crosses four separate tools. Technical boundaries follow hierarchical boundaries, and every transition from one department to another becomes a friction point: manual CSV export, partial re-entry, unavoidable delay.
What creates the chaos is not the lack of technical standardization. It is the lack of process mapping. If you do not know which business flows cross which departments, you cannot know whether a tool is relevant or whether it adds another isolated link.
The measurable symptom: how many times the same data gets re-entered between process input and output
Here is a simple test to diagnose a siloed architecture. Take an end-to-end business process (service purchase, customer request handling, supplier payment), and count how many times a single piece of information (customer reference, pre-tax amount, delivery date) must be re-entered or copy-pasted from one tool to another.
If the answer is zero, your IT system is already structured by process. If the answer is two, you are at the average for large organizations in Morocco. If the answer is four or more, you are in an advanced fragmentation situation.
Re-entry is not just an operational irritant. It is an indicator of weak architectural coupling: each department owns its own copy of the truth, and nobody knows which version is correct. When a dispute arises (wrong payment date, contested quantity), you have to reconstruct the chain manually, and each tool tells a different version.
Measuring re-entry frequency gives you two numbers: the number of inter-tool transitions in a process, and the number of transitions without automated API. If you have a high ratio, you know that every new software layer added by a department expands the problem rather than solving it.
Carving by process: the process x department matrix to build before any vendor consultation
The fix is not to impose a single vendor or merge IT budgets. It is to force process mapping before any purchase decision. Concretely, you build a two-axis matrix: in rows, your end-to-end business processes (purchase-invoice-payment, request-approval-execution, entry-processing-archiving), and in columns, your operational departments (procurement, finance, operations, customer service).
Each cell in the matrix indicates which department intervenes at which process stage. For example, for the purchase-invoice-payment process:
- Procurement: request, supplier selection
- Operations: technical validation, receipt
- Finance: accounting entry, payment
Once the matrix is built, you immediately see that a tool purchased by procurement alone will never cover the full process, because this process crosses three departments. The tool must therefore either be multi-department (a shared ERP), or communicate automatically with the tools of the other two departments (via API), or be replaced by a solution that covers the end-to-end flow.
This matrix becomes your decision filter. Before any vendor consultation, ask: which process does this new tool address? Which departments cross this process? If the tool covers only one cell of the matrix, it will create an additional silo, unless automatic integration with adjacent cells is planned from the start.
Three processes that always cross the organization: purchase-invoice-payment, request-approval-execution, entry-processing-archiving
Certain processes appear in almost all organizations, regardless of sector or size. Mapping three is usually enough to reveal 80% of inter-department frictions.
Purchase-invoice-payment: from initial purchase request (an operational service) to actual payment (finance), through budget validation, supplier selection, receipt, and accounting entry. This process often crosses four or five departments. If each stage uses a different tool without API, you get payment cycles of 45 days instead of 15, simply because of inter-system propagation time.
Request-approval-execution: every organization receives requests (customers, employees, partners), validates them (compliance, budget, priority), then executes them (delivery, intervention, payment). This flow always crosses at least three services. If the request arrives in a CRM system, validation happens in a shared Excel sheet, and execution is managed in an operational ERP, the process accumulates unavoidable delays at each boundary.
Entry-processing-archiving: any received data (invoice, contract, request) follows an identical cycle. It is entered once, processed by several services, then archived for audit or litigation. If each service uses its own reference system, you do not know where the reference version is. Result: in case of audit or dispute, you lose two days reconstructing the complete file.
By mapping these three processes via the process x department matrix, you immediately know where your structural frictions are, and which tool or integration should be priority.
When one tool per department remains legitimate (and the test to know)
Not all tools should be shared. Some processes are strictly intra-department, and in that case, a dedicated tool is not only legitimate but preferable.
Here is the test: trace the complete end-to-end process. If all process stages (from entry to exit) occur within a single department, without handoff to another, then a department-specific tool is justified. For example, route planning software for internal logistics, or a technical design tool for an engineering department.
However, if the process crosses several departments, even partially, the tool must either cover all stages, or expose an API to allow subsequent stages to retrieve data automatically. The criterion is flow continuity: if a human has to copy-paste data from one tool to another, or if a weekly CSV export is necessary to move to the next stage, it is a silo, not a legitimate specialization.
The simple rule: if the data leaves the tool to continue its business journey, that tool must speak automatically with the next one. If the data never leaves the tool, it can remain isolated.
What the matrix changes in your RFP: a scope, not a list of modules
Traditional RFPs look like shopping lists: 47 mandatory features, 23 desirable features, each scored out of 5 points. Vendors check all boxes, then implement one module per department, and you end up with the same silo as before, but within a single software suite.
With the process x department matrix, the RFP changes nature. You no longer ask "do you cover procurement management, accounting, and operational tracking?". You ask "how does your solution handle the purchase-invoice-payment process end-to-end, without re-entry, across the three departments involved?".
Concretely, this means:
- Specifying inter-department transitions as functional requirements (example: "budget validation in finance must automatically trigger notification to the requesting service, without manual export")
- Requesting a full flow demonstration, not isolated modules (show us a purchase journey, from initial request to actual payment, in your platform)
- Evaluating vendors on the number of manual re-entries needed to complete an end-to-end process, not on the number of available modules
The shift is that you buy an operational scope (an entire process), not a collection of features. If a vendor cannot cover the full process, they must prove that their tool integrates with existing tools from other departments, via API, without CSV export or copy-paste.
Sequencing: which process to start with, and on what criterion
You cannot restructure the entire IT system at once. You must choose a first process to make fluid, then iterate. Here are three criteria to decide where to start.
Criterion 1: frequency. Which process repeats most often? If you process 200 purchase requests per month and only 10 customer disputes, start with the purchase-invoice-payment process. Each optimization will have immediate impact on teams' daily operations.
Criterion 2: friction cost. Which process generates the most delay or error due to fragmentation? If your supplier payment cycles reach 60 days while contracts specify 30, and this delay comes from re-entry between finance and procurement, that is a clear signal. Measure the time spent on re-entry, export, manual reconciliation, then multiply by annual frequency.
Criterion 3: business value. Which process has the most direct impact on your revenue or operational capacity? A fluid customer invoicing process reduces your DSO (Days Sales Outstanding) and improves cash flow. A faster service request processing reduces customer dissatisfaction and contractual penalties.
Apply these three criteria to your processes mapped in the matrix. The process that combines high frequency, significant friction cost, and direct business impact becomes your priority. Start with this one, implement a solution that covers the end-to-end flow, then move to the next.
The frequent mistake is starting with the most complex or most "strategic" process. Start with the one that generates the most repetitive re-entries and affects the most people, because you will have visible ROI within weeks, and you will have built an internal reference for what follows.
FAQ
Can we keep existing tools and just add APIs between them?
Yes, if the tools expose standardized APIs (REST, GraphQL) and you have a team capable of maintaining these integrations. The risk is that each tool update can break integration with others, and you spend more time maintaining connectors than improving processes. The rule: if you have fewer than five tools and they all expose documented APIs, integration is feasible. Beyond five tools or if some are closed software suites, it is better to replace with a unified platform on priority processes.
How do you convince departments to give up their dedicated tool?
Do not ask them to give up their tool. Ask them to measure how many times they re-enter data that comes from another service, and how much time they spend reconciling conflicting versions. Then show them the process x department matrix and have them calculate the annual cost of these frictions. When a department sees it spends 15 days per month exporting, importing, and cleaning data, it accepts more easily a solution that reduces this time to zero, even if it loses some local control.
Should we wait to have mapped all processes before launching a project?
No. Map the three basic cross-functional processes (purchase-invoice-payment, request-approval-execution, entry-processing-archiving), identify the one generating the most friction, and launch a pilot project on this one only. Once this process is fluid, you will have a reference model and before-after metrics that will facilitate mapping and optimization of other processes. The sequential approach (one process at a time) reduces risk and generates tangible results faster than a global overhaul project.
What is IT's role in this restructuring?
IT becomes guardian of the matrix. It refuses any tool purchase that does not specify which process it addresses and how it integrates with tools from adjacent departments in that process. It imposes a simple rule: before any vendor consultation, the requesting department must fill in the concerned process row in the matrix and identify which other departments are involved. If the proposed tool covers only one cell, IT requires either a documented integration API or justification proving this process is strictly intra-department.
How long does it take to shift from a siloed architecture to a process-based architecture?
It depends on the number of priority processes and your current IT size. For an organization of 200 to 500 people, restructuring a first critical process (purchase-invoice-payment, for example) typically takes 4 to 6 months, from initial mapping to full deployment. If you sequence correctly (one process at a time), you get measurable results every semester, and you avoid multi-year transformation projects that often fail midway. The goal is not to redo everything at once, but to progressively reduce the number of re-entries until reaching zero on the most frequent processes.
Need help mapping your business processes and structuring your IT system? ClaroDigi supports Moroccan companies in their digital transformation, from initial audit to implementation. We also perform complete IT audits to identify your operational frictions and prioritize your investments, as well as system integration projects to streamline your processes. If you are developing custom business applications, we help you design them around your operational flows, not around your org chart.