Most companies lack an up-to-date systems map, which describes the tools they use, how they interconnect, and which processes flow through them. Therefore, every technology project— e-commerce implementation , ERP replacement, new integration, order processing automation—begins with an audit of a portion of the architecture. The company knows in advance that this cost will arise and that the decision on the project itself will be delayed by the time of such an analysis. The second consequence is less visible: an audit conducted for a single project only shows that single portion, so the connections between the new system and the rest of the organization are only revealed during implementation. The most glaring symptom of this same deficiency is when a company discovers a tool it was unaware of. This article shows the cost of not having a systems map, what a systems audit should include, which doesn't need to be repeated for every project, and how to keep such a map up-to-date.
Why does every technology project start with an audit?
When we begin a conversation with a client about automation or a new B2B sales system , the first stage isn't implementation, but discovery: a workshop where we define what's currently happening, followed by a pre-implementation analysis where we plan how it should be. Only after this stage do we know exactly what we'll be doing, and only then does it make sense to discuss the scope and timing. We do this because companies typically lack a ready-made description of the current state—no one has a systems map at hand that would allow them to see what's implemented, what interacts with what, and where the data physically resides.
This becomes apparent from the very first meeting. Before we even begin to calculate anything, we ask if the company has a PIM system in place , if product information is centralized in the ERP, where prices come from, and where the order is placed. These aren't questions about preferences, but about architecture – without answers, any quote is a guess. In most conversations, answers need to be gathered, because some of the knowledge resides with the IT specialist, some with the logistics person, and some in the mind of the previous contractor.
The implication is simple and repeatable in every project: before a company begins automating anything, it must first audit the technology being automated. This audit costs time and money, and only then does the actual project begin.
How much does implementation cost when there is no systems map?
The cost is spread over several items, most of which do not appear on any list.
The time before the project starts. Pre-implementation analysis is the first stage of any major implementation, and its scope increases when the architectural picture is incomplete. In one project proposal, we increased the scope of this analysis after the workshops, as many of the client's needs were identified but not explored in depth – additional analytical hours were cheaper than entering the implementation with unfinished requirements. The company can perform some of this work in-house beforehand; we described this in the brief preparing the pre-implementation analysis.
Analyzing each integration individually. In another project, we planned two to three business days for a precise analysis of a single integration : where the logistics data comes from, where the order data is stored, where the prices are stored, and how they are correlated with a specific customer. One integration requires several days of work before the first line of code is created. With three or four integrations, that's a whole week in the schedule.
Risk buffer in valuation. When it's not known in advance what lies beyond the integration, a buffer for surprises must be added to the valuation. In this case, the company pays not for work, but for uncertainty – and the only way to reduce this buffer is to describe the architecture in advance. This same mechanism reduces the accuracy of the system's total cost of ownership calculation , because some items are simply not yet known.
A postponed decision about automation. This is the cost that's hardest to budget. A company that knows that any idea for automating quotes or inquiry processing will begin with a few weeks of research is less likely to even submit those ideas. The topic returns a quarter later, then a year later, while the process continues to be handled manually.
Paying for features that no one uses. For one client, we migrated the system from the Enterprise edition to the open source version because the company was only actually using some of the features it paid for in the license. We added the missing elements in a dedicated manner. This decision was only possible after someone had compared the license scope with what was actually being used—that is, created a fragment of this map.
What you don't see during implementation: the connections between the new system and the rest of the company
An audit conducted for a single project has one inherent flaw: it only shows the portion we're asking about. If we're implementing a new pricing management system, we'll describe prices, price lists, and everything directly adjacent to them. Unreported connections are left out of scope.
In practice, a new system in a trading company usually affects a much wider set:
- ERP – source of stocks, prices and sales documents,
- WMS or warehouse system, often with its own reservation logic,
- PIM and DAM – product data, photos and materials,
- OMS or marketplace order integrator,
- price and discount management system, if it works separately from ERP,
- marketing automation tools and mailing systems,
- analytics and reporting systems,
- document circulation and accounting systems,
- importers and scripts previously run for one supplier,
- accounts and integrations in external channels, including multi-store structures and on marketplaces.
Each of these items can have its own integration, its own synchronization schedule, and its own place where a given value is "true." When a new implementation changes one of these, the consequences for the others are revealed during the workflow, not during the planning phase. The schedule then shifts by a time that no one planned, because the scope expands to include something that wasn't known at the outset.
Extreme case: a tool that no one in the company knew about
In one of the projects we worked on, during onboarding, it was discovered that a product data importer had been running in the client's system for a long time, and the team was unaware of it. Someone on the previous contractor's end had activated it and failed to pass on this information. Some of the team admitted they had never seen this tool before, and those responsible for this area described their knowledge of their own infrastructure as if they were starting from scratch, despite having worked at the company for years.
This situation occurs less frequently than a standard pre-project audit and isn't a market phenomenon in itself. However, it's the starkest evidence of the same thing: if a company can run a tool for years without anyone even knowing about it, it has no point of reference for assessing its own architecture. And if there's no point of reference, there's no way to estimate the cost of other, less visible things—duplicated functions, unnecessarily maintained integrations, manual processes alongside a tool that can execute them.
The mechanism that leads to this is always similar. Someone solved a specific problem, launched the tool, and moved on. The knowledge that the tool existed and how to use it remained in their head, not in the documentation. When that person changes projects, departments, or employers, the knowledge disappears with it, leaving the company with a system that continues to function.
What does a systems audit that doesn't need to be repeated look like?
When auditing the e-commerce ecosystem for a dermocosmetics manufacturer, we began by examining the tools the company already uses and how they are interconnected, rather than asking what's missing. We verified the existing architecture, visualized the connections between systems, described the actual processes—from ordering, through ERP, to shipping—in BPMN diagrams, and documented what each system is actually used for.
The result of such an audit isn't a list of purchase recommendations. It's documentation of what the company already has. Only with this documentation can it be distinguished between a technology gap and a knowledge gap about its own infrastructure, which are two different problems with different solutions.
A complete systems map should include:
- a list of all systems and tools, including those deployed by previous contractors,
- the business owner and the technical person responsible for each of them,
- the version and licensing model of each system along with the scope that the company actually uses,
- integration list: what connects to what, in which direction and how often,
- indication of where each key data is created and where it is "real" – product, price, stock, order, customer,
- diagrams of the processes passing through these systems, in notation readable also for non-technical people,
- information about which functions are duplicated by more than one tool,
- a list of things that are operated manually even though there is a tool that can do it,
- known limitations and places where architecture requires workarounds,
- date of last verification of each entry.
This map has value beyond the audit itself. Without it, every subsequent project— switching a system to a different platform , combining the functions of two tools into one, optimizing warehouse, marketing, or order processing—must begin with a fragmented assessment of that single area. Once the map is ready and updated, such projects can begin immediately, and the estimate is more accurate because it's clear from the outset which connections will need to be rebuilt.
A project without a systems map and a project with a map
| Project stage | Without a systems map | With the current system map |
|---|---|---|
| Starting the conversation about the scope | First, recognize where the data comes from and what is implemented | A conversation starts with a decision, not with gathering facts. |
| Pre-implementation analysis | Full, also includes a description of the current state | Shortened, applies only to the planned change |
| Range | It grows as unknown connections emerge | Established from the start, changes come from decisions, not discoveries |
| Valuation | With a buffer for integration uncertainty | More accurate because the contact points are known |
| Schedule | It shifts by the time of recognition and surprises | Counted from the first day of implementation work |
| Another project | Recognition anew, on a different slice | Update the map with what has changed |
| The decision to automate | Postponed because it starts with the cost of recognition | Taken on the basis of what has already been described |
What doesn't a systems audit solve?
An audit describes the actual situation and ends there. It's important to know what not to expect from it.
It doesn't replace business decisions. The map will show that two tools duplicate functionality, but we can't decide which to abandon on our own—it depends on how the company sells and who uses what on a daily basis. Our role is to demonstrate the consequences of each option and work out a solution together with the client's team.
It doesn't replace pre-implementation analysis for a specific project. It shortens it because some of the work is already done, but planning the change is a separate step.
It doesn't sustain itself. A map that no one updates will, after a year, describe a company that no longer exists – and then we're back to square one.
It doesn't answer the question of whether a given tool is good. It shows whether it's being used and what it's connected to. Assessing whether it's worth replacing is a separate discussion, usually related to a specific project – just like when choosing a PIM system , where the outcome is determined by much more than just a list of features.
What can I do to prevent the map from becoming outdated after a year?
A one-time audit solves the problem temporarily. To prevent a new team member from having to rediscover the infrastructure from scratch a year later, a simple process is needed: someone in the company is responsible for ensuring that with each architectural change—a new tool, a new integration, a system replacement, a change of supplier—the roadmap and its documentation are updated, and information about the change is communicated to the team.
In practice, linking this update to the acceptance of work works well: the change is only closed when the description in the map matches what has been implemented. Then the update ceases to be a separate task for which there is never time.
Frequently Asked Questions
What's the difference between a systems audit and a pre-implementation analysis? A systems audit describes the current state of the entire architecture: what's implemented, how it's connected, and what it's used for. A pre-implementation analysis plans a specific change and is created for a single project. The audit is conducted once and updated, while the analysis is conducted before each implementation – with a ready-made map, it's shorter because it doesn't start with fact-gathering.
How long does a systems audit take? It depends on the number of systems and integrations. This benchmark is helpful for the scale of the analysis itself: a precise analysis of a single integration typically takes two to three business days. A company with multiple integrations and a single ERP requires a different amount of effort than a company selling through multiple channels simultaneously.
Does an audit make sense if implementation isn't planned for another year? Yes, and that's the best time. An audit conducted earlier doesn't impact the implementation schedule, and its effect shortens the subsequent pre-implementation analysis and allows for budget realignment before approval.
Who on the company's side needs to be involved? Typically, a person responsible for IT or e-commerce , someone from logistics and warehousing, someone from order processing, and someone familiar with the pricing process. Some knowledge is dispersed, and gathering it in one place is the proper content of an audit.
Does the audit end with a list of tools to purchase? No. It ends with documentation of what the company already has and how it works together. Purchase recommendations, if any, stem from this documentation and are a separate decision.
We have documentation from the previous contractor – is that enough? It can be a good starting point, but it usually describes what the vendor implemented, not what the company is using today. It's worth verifying it against the actual situation, especially in the sections regarding integration and data.
What to determine before the next implementation?
If your next technology project will begin with an architecture review anyway, it's worth consciously deciding whether this review should be fragmented and repeated, or comprehensive and completed once. The following list is the minimum you should have written down before you sit down to discuss the scope.
- Do you have a list of all the systems and tools your company uses – including those deployed by your previous supplier?
- Do you know how these systems are connected and which processes pass through them?
- For each key data item – product, price, stock, order – is it known in which system it is created?
- Do you know what scope of licenses you actually use?
- Is this knowledge stored in a place accessible to the entire team, not just in the head of one person?
- Is someone responsible for updating this documentation when something changes?
If the answer to most of the questions is "partially," the next project will begin the same way as the last. We describe the client's architecture at the start of larger consulting projects and also do this as a separate assignment – we've described the scope of our work on the services page , and collected examples of completed projects in case studies . If you simply want to see where to start in your own environment, schedule a consultation – a conversation about what you already have will suffice.
