Why IT Implementation Should Start with Process Analysis, Not System Configuration

An IT system implementation should not begin with configuration, choosing form fields or the first development tasks. It should begin with understanding the process: how the company works today, how it wants to work after implementation, what data is required, who makes decisions and which systems need to work together.

A system will not fix chaos if the process itself is not understood first. It may only make that chaos move faster.

This is one of the most important principles in IT projects. It applies both to companies purchasing software and to software houses, systems integrators and implementation teams. If the business need is not described properly and the requirements are not structured, the project quickly starts to rely on assumptions.

The client assumes that the implementation partner understands its process. The implementation partner assumes that the client knows exactly what it needs. End users expect something different from decision-makers. And once the system starts taking shape, it becomes clear that each party imagined the solution somewhat differently.

This is why business and systems analysis is neither an unnecessary stage nor a formality. It is a way to reduce project risk, costs and conflicts.

System configuration is not the beginning of an implementation

In many projects, the natural temptation is simple: start doing things immediately. Configure the system. Launch a module. Add users. Build an integration. Prepare a form. Create the first version and see what happens.

This approach may work for very simple implementations. But when a project involves several departments, many users, ERP integrations, document workflows, inventory, settlements, permissions or reporting, starting with configuration is risky.

Configuration answers the question: “How should we configure the system?”

Analysis answers the more important question: “What exactly should the system support, and why?”

If the second question is not asked early enough, the system may be configured correctly from a technical perspective but still fail to address the organisation’s actual needs.

A common mistake: asking about settings instead of the process

In IT projects, discussions often move to the system configuration level too quickly.

• Should this field be mandatory?
• What should the status be?
• Who should have access?
• Should we add a checkbox?
• Should the report use this filter or another one?

These are important questions, but they should result from the process. If we start with interface or configuration details, it is easy to miss the essential questions: why the user performs a particular activity, what decision needs to be made, what data will be required later and what should happen when an exception occurs.

For example, we might ask whether an overtime request form should contain a “project” field. But the more important question is whether overtime is accounted for against a project, budget or cost centre. If it is, the “project” field is no longer just part of a form. It becomes part of the accounting process, integration and reporting.

Similarly, in e-commerce we can ask whether the online store should retrieve inventory levels from the WMS. But first we need to establish which system is the source of truth for inventory, how reservations work, what happens during in-store sales and how out-of-stock situations are handled.

Without analysis, it is possible to configure the wrong thing correctly.

Why does a lack of analysis lead to conflicts?

Conflicts in IT projects rarely begin with bad intentions. They usually result from different interpretations of the same request.

The client says: “We need a module for handling requests.” The implementation partner understands this as a form, statuses and a list of cases. HR expects approval paths, limits, reports and compliance with organisational rules. The employee expects a simple screen and clear information about what is happening with the request. Management expects control, lower risk and greater efficiency.

Each of these perspectives is legitimate, but without analysis they are not translated into one coherent scope of work.

This is when statements such as these start to appear:

• “but this was supposed to work differently”,
• “we thought this was included as standard”,
• “the implementation partner did not anticipate this”,
• “the client did not tell us this was required”,
• “this requires an additional estimate”,
• “this was not included in the scope”.

Good analysis does not eliminate every risk, but it significantly reduces the number of such situations. It allows the process, exceptions, responsibilities, integrations and expected outcomes to be defined in advance.

What should be established before implementation?

Before configuration or development begins, at least a few fundamental elements should be clarified.

Business objective

The first question is why the project is being carried out. Is the goal to reduce manual work? Reduce errors? Speed up customer service? Improve control over the process? Structure data? Integrate systems?

Without a business objective, it is difficult to determine later whether the implementation has actually succeeded.

Current process

It is necessary to understand how the company works today. Even if the current process is far from ideal, it is worth documenting. This reveals manual activities, spreadsheets, workarounds, duplicate data entry and the points where errors arise.

Target process

The next step is to design how the process should work after implementation. Not as a list of features, but as a flow of activities: who starts the process, what they enter, who approves it, what data is validated, what happens next and when the process ends.

Systems involved in the process

An implementation rarely involves just one system. The process may include ERP, WMS, CRM, an online store, employee applications, project systems, reporting tools, accounting systems, payroll modules, integration platforms and APIs.

It should be clearly defined which system is responsible for what.

Data and sources of truth

This is one of the most important areas. It must be established where data originates and where it is maintained as the authoritative source. Products, prices, inventory levels, employees, projects, documents, statuses and settlements cannot have several equally authoritative versions of the truth.

User roles and permissions

The system should know who can submit a request, who can approve it, who can modify it, who can view a report, who can change a status and who has access to sensitive data.

Exceptions

Describing only the standard process flow is not enough. Cancellations, rejections, missing data, validation errors, corrections, returns, repeated approvals and unusual situations also need to be defined.

Exceptions often determine whether a system will actually be useful.

Integrations

If data is to move between systems, the integration direction, trigger point, data scope, responsibility for errors and method of confirming operations need to be established.

For REST APIs, it is useful to describe at least example endpoints, data structures, response statuses and error messages.

Reporting

Reports should not be an afterthought designed at the end of the project. If the organisation wants to control the process, it needs to establish in advance what data should be reported and at which stage of the process that data is created.

Testing

Tests should result from the process. Scenarios need to cover the standard flow as well as exceptions: rejection, integration errors, missing data, inconsistent statuses, corrections or returning to an earlier stage.

Responsibility after go-live

Finally, it is necessary to establish who maintains the configuration, manages reference data, handles errors, receives support requests and decides on changes to the process.

An implementation does not end on the day the system goes live.

Analysis helps the organisation buying the solution

For the organisation purchasing the solution, analysis is a way to structure its own needs before placing an order.

This is particularly important when an organisation wants to purchase software, a system module, an integration or a custom extension. Without prior analysis, the request often describes the expected outcome only in general terms. The implementation partner then has to interpret the client’s intentions, increasing the risk of misunderstandings.

A well-prepared analysis allows the organisation to:

• define the scope of the order more accurately,
• compare offers from implementation partners,
• reduce the risk of underestimation,
• avoid costly changes during the project,
• control acceptance of the delivered work more effectively,
• show decision-makers exactly what is going to be implemented,
• ensure that the system supports the process rather than merely looking correct on screen.

For management and decision-makers, analysis is a risk-management tool. It makes it possible to see whether the project has a clearly defined objective, scope, responsibilities and method for verifying the outcome.

Analysis helps the software house

Analysis is equally important on the implementation partner’s side. A software house or systems integrator often receives only a general description of the client’s need. The client understands its business but may not be able to describe it in terms of system requirements.

In this situation, an analyst can help the implementation partner structure the problem before delivery begins. This reduces the risk of incorrect estimates, limits scope changes and makes it easier to plan the team’s work.

For a software house, good analysis means:

• fewer assumptions,
• clearer tasks for the delivery team,
• better planning of project stages,
• lower risk of conflict with the client,
• more specific acceptance criteria,
• a stronger basis for estimation,
• fewer situations where “this was supposed to work differently”.

In practice, analysis is the bridge between the language of business and the language of delivery.

Example 1: integrating sales, warehouse, WMS, ERP and e-commerce

A good example is a trading company that uses an online store, physical retail, WMS, ERP and a sales integration platform.

At a high level, the need may sound simple: “we want to integrate our systems”.

But the analysis needs to answer much more specific questions:

• where the order is created,
• when stock is reserved,
• which system is the source of truth for inventory,
• where the sales document is created,
• how the WMS communicates fulfilment status,
• how returns in a physical store are handled,
• how in-store sales affect online product availability,
• how multiple warehouses are synchronised,
• what happens when stock is unavailable.

Without these decisions, integration may only make the disorder move faster. The systems will begin exchanging data, but it will still be unclear which data is authoritative and who is responsible for each stage of the process.

Example 2: HR processes, employee requests and ERP integration

The second example is an employee application supporting HR processes: overtime requests, travel expense processing, manager approvals, HR verification and transferring data to the ERP system.

At the business level, the requirement might simply be: “we need to handle employee requests”.

The analysis must nevertheless establish:

• who submits the request,
• what data is required,
• who approves it,
• what statuses are used,
• what data is transferred to the ERP system,
• how the request is linked to time records,
• how validation errors are handled,
• what REST API is required,
• what an example JSON payload exchanged between systems looks like,
• what the employee, manager and HR team can see.

Only then can the implementation partner build a system that is not merely a form, but a practical tool supporting the actual process.

Example 3: sales, accounting and e-commerce platforms

The same principle applies to small and medium-sized e-commerce businesses. A company may use an online store platform, a sales integration platform, ERP or accounting software, courier services, marketplaces and payment tools.

At first glance, this may seem to be a matter of configuring the sales integration platform. In practice, several questions need to be answered:

• which sales channels should be supported,
• where product data is maintained,
• where prices are maintained,
• where inventory information comes from,
• where invoices should be created,
• how receipts are handled,
• how data is transferred to accounting,
• how returns are handled,
• how statuses are automated,
• which activities should be automatic and which require user control.

Even with popular off-the-shelf tools, the main challenge is rarely clicking the right option in the administration panel. The challenge is deciding beforehand how the company actually wants to work.

What should analysis deliver?

The outcome of an analysis should not be a document created simply so that “documentation exists”. Good analysis should be useful to every party involved in the project.

For the business, it should clearly show how the process will work. For the implementation partner, it should describe requirements and integrations. For decision-makers, it should reduce risk and help control scope. For end users, it should lead to a system that is understandable and supports their daily work.

In practice, the outputs of an analysis may include:

• a description of the current process,
• a description of the target process,
• process flow diagrams,
• functional requirements,
• non-functional requirements,
• a list of roles and permissions,
• object statuses,
• validation rules,
• integration descriptions,
• example API endpoints,
• example JSON structures,
• test scenarios,
• acceptance criteria,
• a backlog of tasks for the delivery team,
• implementation recommendations.

These are materials that genuinely help move a project forward.

Analysis does not slow down a project. It reduces waste

A common argument against analysis is: “we don’t have time, we need to start implementing”.

In practice, skipping analysis does not remove analytical work. It merely postpones it until later — during configuration, development, testing or even production.

The analysis then happens at the most expensive possible moment: the team is already working, deadlines are approaching, the budget is being consumed and every change creates additional tension.

A well-conducted analysis at the beginning of a project may appear to be an additional cost. In reality, it often reduces the cost of later changes, corrections, disputes and delays.

Many implementation problems arise not because the system was impossible to build, but because nobody established clearly enough what was supposed to be built.

The role of LISNET

At LISNET, I support companies and IT teams where requirements, processes and data flows need to be structured before implementation.

I can take on different roles depending on the needs of the project.

For an organisation purchasing a solution, I can help describe the business need before discussions with an implementation partner begin. This makes it easier to prepare an enquiry, compare offers and control the project scope.

For a software house or systems integrator, I can support the pre-implementation analysis stage: speak with the client, structure requirements, create diagrams, document processes, prepare API examples and translate business decisions into tasks that can be delivered by the technical team.

Within an implementation project, I can help take the client from a general business need to a concrete model of processes, integrations and requirements.

The objective is always the same: reduce assumptions and increase the likelihood that the system will address the organisation’s real needs.

When is it worth involving an analyst?

It is particularly useful to involve an analyst when:

• the project involves several departments,
• more than one system participates in the process,
• integration with ERP, WMS, CRM, an online store or accounting system is required,
• the business knows what it needs but has not documented it,
• the implementation partner needs structured requirements,
• different interpretations of the scope are emerging,
• there is a risk of conflict between the client and the implementation partner,
• the project requires a REST API or data exchange between systems,
• diagrams, statuses, rules and test scenarios are required,
• decision-makers want to reduce the risk of additional costs and delays.

The earlier this work is done, the greater the chance that the implementation will progress smoothly.

Summary

An IT implementation should start with process analysis, not system configuration. This is particularly important when a project involves many users, several systems, integrations, reporting, settlements or non-standard business processes.

Analysis makes it possible to define the objective, describe the current and target processes, establish roles, data, exceptions, integrations and acceptance criteria. As a result, the organisation knows what it is buying and the implementation partner knows what it needs to deliver.

A system can be an excellent tool, but only when it supports a well-understood process. If the process has not been defined, the implementation begins with assumptions. And assumptions in IT projects very often cost more than analysis carried out at the beginning.