How to Streamline Shopping Digitally Without Losing Control

The procurement process is meant to protect the company from wasteful spending, not from operating efficiently. In practice, however, many organizations add yet more forms, approvals, and handoffs between teams to the process. Each of these elements may once have addressed a real risk. Over time, however, it becomes difficult to trace their original purpose, resulting in a lengthy cycle, work done via email and spreadsheets, and decisions made outside the official chain of command.

The point is not to replace control with freedom. A well-designed procurement process should simultaneously protect the budget, ensure competition, and give the business the time it needs to carry out the project. This is a task for people, procedures, and the system—not just one of these elements.

A good starting point is to distinguish between procurement policy and procedure. Policy sets the boundaries: who can enter into commitments, when competition is required, what information must be documented, and who can approve an exception. Procedure defines the sequence of steps. The boundaries are binding; the workflow can be designed and improved.

Let’s imagine purchasing a solution for a warehouse or production facility. The business is aware of the problem, but during discussions with potential suppliers, it clarifies the scope of integration, user requirements, and the billing method for the service. In the “tunnel” process, the successive stages are closed off: first, a full description of the need; then approval; followed by market research; another round of approval; and only then do discussions with suppliers take place. If new information comes to light, the matter either goes back to the beginning or is resolved informally.

The “field” model does not eliminate oversight. Instead, it allows certain tasks to be carried out in parallel: analyzing needs, mapping the market, and preparing contract terms by a single working group. Decisions regarding the budget, supplier selection, and exceptions remain at clearly defined checkpoints. At the same time, the workflow system can monitor access rights, ensure the completeness of documentation, and maintain a record of decisions.

The difference is significant. In the first approach, the organization primarily controls the sequence of steps. In the second, it controls risk and the evidence that the risk has been addressed. For simple, repetitive purchases, the sequence may be the least expensive solution. For a complex project in which knowledge is generated during discussions, the cost of the sequence may outweigh the benefits.

Before automating, it’s a good idea to conduct one final procurement process involving the business, procurement, finance, and compliance teams. The goal isn’t to evaluate people, but to see how the process actually works. The process map should include not only the steps visible in the system, but also waiting for decisions, clarifications via email, re-entering the same data, and exceptions handled outside the workflow.

It’s worth asking five simple questions:

1. How much time is spent working on a case, and how much time is spent waiting between stages?
2. What specific risk does each acceptance mitigate?
3. What information does the organization receive through this gateway?
4. What happens if the scope or terms of the purchase change along the way?
5. Does the system store a record of the decision, or does it just display the form?

The responses usually reveal where the problem lies. Often, the issue isn’t the number of approvals itself, but rather the lack of a designated owner, an ambiguous decision threshold, or a form that doesn’t forward data to the next stage. That’s when a digital workflow makes sense: it allows you to set a rule once, use the same data in multiple places, and automatically escalate only unusual cases.

A procurement system or an integrated ERP environment does not automatically generate savings. It does so only when it takes over actual control and administrative functions. Examples include: verifying the available budget, controlling access rights, comparing orders with contracts, requiring declarations of conflicts of interest, recording exceptions, and automatically reminding users of decision deadlines.

It’s also a way to better distribute responsibility. The person submitting a request doesn’t need to know the entire procedure if the system guides them through the required steps. The buyer doesn’t have to manually check every limit if the rules are defined in the workflow. A manager should not approve a complete set of documents simply because they cannot tell what constitutes a standard decision and what constitutes an exception. A role-based dashboard can highlight precisely those cases that require evaluation.

However, it is important not to digitize unnecessary workflows. Transferring five PDF forms to five screens does not simplify the process. A well-designed configuration eliminates redundancies, links customer data, contracts, budgets, and orders, and leaves an auditable record of who made a decision, when, and on what basis.

The best results are usually achieved by integrating the purchasing process with the data the company already has in its ERP system. A purchase requisition can immediately check the cost center and budget availability. The supplier selection process should utilize the current vendor record and the terms of the existing contract. The purchase order, delivery confirmation, and invoice should not require re-entering the same information.

This is not an argument for fully automating every decision. The system should distinguish between a standard transaction and a case requiring expert judgment. A purchase from a catalog at an approved supplier can follow a streamlined process with budget control. The purchase of a specialized service, an IT solution, or a project with a variable scope should allow for business assessment, market analysis, and review of contract terms. This classification is more important than the number of screens in the application.

A transparent process also helps suppliers. They know what data they need to provide, who is responsible for the next step, and where to report a change. The procurement team, meanwhile, gains a single, unified view of the situation, rather than having to piece together the decision history from email, a shared drive, and instant messages.

In a mature workflow, exceptions do not disappear. They are identified, classified, and handled differently from standard requests. It’s worth defining at least their basic types: urgent purchase, sole supplier, change in contract scope, budget overrun, and deviation from an approved category or contract. For each type, the following should be clearly defined: the decision-maker, the required justification, the necessary documents, and the response deadline.

This approach reduces the temptation to circumvent the process. A user who sees a clear path forward for an unusual case is less likely to seek a solution outside the system. The organization, in turn, receives the data it needs to improve its rules. If the same exception occurs regularly, it may no longer be an exception but rather a sign that the policy, framework agreement, or directory configuration needs to be changed.

In the discussion about faster procurement, it’s easy to create a false dichotomy: either full formalization or relying on the team’s intuition. Research on public procurement shows that broad discretion without adequate competition can lead to higher prices and poorer contractor selection. This is an important cautionary note for private organizations as well: speeding up the process cannot involve bypassing procurement policies or skipping the comparison of bids.

At the same time, contract rigidity and workflow rigidity are two different issues. If the scope of the implementation will be determined gradually, it’s worth establishing in advance how changes will be managed: who defines them, what impact they have on the budget and schedule, when they require renegotiation, and how they are documented. This is safer than pretending that the requirements won’t change after the contract is signed.

In the public sector, the Public Procurement Law sets additional limits. Parallel work does not allow for shortening statutory deadlines or circumventing the required competitive bidding process. However, it is possible to streamline the preparation of the procurement process, the sharing of information, and the documentation of decisions. Each legal exception should be assessed and documented separately, rather than buried within a general workflow.

It is best to launch the new process as a pilot in a single procurement category or for a single type of project. The same limits, competition rules, and documentation requirements should be maintained, with only the work organization and system support being changed. This allows you to compare the results without attributing benefits to the technology that it did not actually generate.

The key metrics are simple: total time from submission to decision, wait time, team hours, number of valid bids received, number and type of variances, and quality of documentation. For larger projects, it’s worth adding the cost of delay as indicated by the business owner, the number of contract changes, and the delivery outcome. Shorter deadlines alone do not guarantee success if competition declines along the way, the number of exceptions increases, or the decision trail disappears.

After the pilot phase, the team should review the results together and decide which rules can be extended to other categories and which ones need to be adjusted. This cycle is safer than a large-scale process redesign project based solely on workshops. It allows you to verify whether the new system actually reduces wait times and administrative work while maintaining data quality, competition, and decision-making accountability.

This approach is consistent with the logic of our proprietary decision-making model, ProcuraCost 2.1.

The model compares the same purchasing need fulfilled through two acceptable paths: a formal, sequential path and an adaptive path, both of which comply with the same conditions. It takes into account working time, administration, the cost of delay, the quality of supplier selection, formal contract amendments, life-cycle value, and the risk of circumvention. The result is not a one-size-fits-all answer for every company. It shows which data needs to be collected in order to make an informed choice about how to organize work.

The most mature organizations do not choose a single metaphor for all purchases. For routine, repeatable orders, they build a short, predictable pipeline with automated rule enforcement. For projects with a high degree of uncertainty, they create a framework: they define roles, decision points, and evidence of control, but allow the team to learn and work in parallel.

In both cases, the technology is intended to serve the same purpose: to ensure transparency, reduce administrative work, and enable data-driven management. A good workflow does not replace thinking. It allows people to devote their thinking to decisions that truly require knowledge and responsibility.