---

Catalog purchases are often sold as “faster orders” and “less paperwork.” But anyone who has ever rolled out an internal catalog in a public-sector organization (or a large university) knows the truth: technology is the smallest part. The real battle plays out between people—on three levels.

This article blends two real experiences introducing MARQUET into one story:

• Liberec Region: an internal office-supplies e-shop for the regional authority and its contributory organizations, including warehouse and distribution.
• Comenius University in Bratislava (UNIBA): an electronic catalog that reset ICT/IT procurement to be more flexible, transparent—and defensible under public-procurement rules.

---

Catalog-driven procurement is IN

In the most practical definition: an internal e-shop—the contracting authority’s “in-shop”—that holds items, prices, suppliers, rules, and roles: who may order, who approves, what can be bought automatically, and what writes into the process and how. (That’s exactly how practitioners in both stories described it.)

A note for managers: efficiency isn’t the goal. The goal is control plus comfort in one package—so users have no reason to bypass the process and procurement has both data and peace.

And yes, broadly speaking, digitalization of public procurement and e-procurement tools increase transparency and efficiency and reduce administrative burden—this is no longer an “opinion,” but a long-term direction at European and international levels. (OECD)

---

Two starting lines: Liberec vs. UNIBA

Liberec Region: a catalog for office supplies, warehouse, and distribution.

In Liberec, the task was to turn everyday office needs into a managed “commodity”: visibility, unified pricing, clear approvals—and to connect the catalog to the physical warehouse.

A practical detail from the field: before the in-shop, the warehouse functioned, but people didn’t know what was actually available. After go-live, users see quantities and know in advance what they’ll get at issue. A small thing that makes a massive difference day-to-day.

Another practical point: a wider circle of users. Once the process was simplified, the number of people allowed to order went up—and the feedback was (in their words) “mostly positive.”

UNIBA: the push came from inflexibility and legal caution.

At the university, the problem was different: long periods of framework agreements and, in practice, “one supplier for everything,” which in ICT/IT hurts quickly—on oversight, agility, and defensibility.

The turning point came when the topic was approached as a combination of:

• compliance with procurement rules (including consultations),
• effectiveness and real usability for the university,
• and a change in perspective after new leadership took office.

UNIBA also did one smart thing: they asked where it was already alive—consulting experiences from academia; for example, Masaryk University in Brno is far along in using catalogs. A fresh reminder of the rule: don’t reinvent the wheel when someone’s already spinning it. 😊

A catalog can be deployed quickly. Getting it adopted quickly almost never happens. Success takes persistence and change management: a clear plan for who leads, who the local ambassadors are, how feedback will be collected, and how rules will be adjusted after the first weeks. Without this, the catalog stays “somewhere in the system”—and people find their shortcuts anyway.

That’s why both organizations didn’t stop at “choosing a tool”; they tackled the process first.

---

How to think about implementation so it doesn’t fall apart after three months

Catalog solutions often present themselves as a “product.” In reality, they’re a process change that must rest on three things:

1. Process map and future state
   First name how the process runs today (request → approval → order → delivery/issue → control) and where delays, duplications, or gray zones arise. A process always has inputs, outputs, and linked activities—and until you name them, the system won’t invent them for you.
2. Roles, competencies, and rules of the game
   Requester/approver/buyer/admin aren’t “boxes.” They are safeguards that uphold enforceability and auditability. Without clear roles, your catalog becomes a pretty list everyone bends to their needs.
3. Data and long-term maintenance
   Rolling out a catalog is one thing. Keeping it alive is another: items, prices, availability, suppliers, assortment changes. Who owns the data, how often are they updated, and how is quality monitored—this is the real difference between a system that works and one people eventually bypass.

Only when this holds does it make sense to handle training, communication, and expanding the catalog to other categories.

---

Three levels of implementation

1) The user’s view: “I want to order it fast, correctly, and without awkwardness.”

Users don’t want a system. They want a result. Above all, two things: not to be slowed down and not to make a mistake that ends in a returned order or an embarrassing explanation.

What worked in both cases:

• photos and a clear catalog (for office supplies this is surprisingly important—no one wants to order “something similar”),
• clear availability info (critical in Liberec—warehouse and issue),
• as few steps as possible (or it becomes just another obligation).

And as a bonus: a satisfied internal customer is the best currency for procurement. When people see that the process saves time, reduces errors, and "gets it right the first time," they no longer feel the need to look for shortcuts. On the other hand, if the catalog is slow or confusing, shortcuts become a rational choice.

A university is a world with thousands of employees and a number of faculties. It is a place where it is simply not possible to have "one training for all." A communication chain and support at local points must be established. And that's what happened: communication went through management and faculty secretaries as natural ambassadors of change. Not to "check off the training," but to let users know that they can rely on someone close to them. Again, a win-win situation. 👍

User comfort is not a "nice to have." It is a prevention against "rational" circumvention of the rules.

2) Influencer's perspective: "I need it to be sustainable, enforceable, and not disrupt my process."

The influencer is typically procurement, contract manager, economics, IT, internal methodologist. They don't just deal with the "order," but the entire ecosystem—and especially the question of whether it will still work in six months' time when prices, suppliers, or organizational structures change.

It therefore addresses:

• who approves what and why (and what limits make sense),
• what the roles will look like: customer/approver/buyer/administrator,
• how data (items, prices, suppliers) will be entered into the catalog and who will maintain it.

The Liberec Region had a nice "bureaucratic" approach (which is good): the process was based on internal guidelines and limits – who has what authority and when other approvers need to get involved. This is key for implementing the catalog, because without approval, the catalog is just a nice list.

At UNIBA, it became clear once again that influencers must keep an eye on two levels at the same time:

• legislative clarity,
• and practical applicability (because a process that is perfect on paper but which no one uses is… well, perfect on paper).

And one more thing that is often underestimated in practice: auditability. Not in the sense of "keeping everything nice and tidy in the system," but so that it is possible to trace at any time who placed the order, who approved it, why it was purchased in this particular way, and according to what rules. This is where the role of purchasing as the "architect of rules" comes into play. It not only monitors the process, but also sets it up so that it is sustainable, auditable, and usable in everyday operations.

Purchasing is no longer reactive. It is becoming proactive. It shapes reality and processes. It innovates.

3) The decision-maker's perspective: "I want to manage risk, have control, and see that it makes economic sense."

The decision-maker (board, office management, rector's office, secretary, CFO, etc.) does not want to deal with the brand of the system. They want to be sure that:

• the organization will not operate outside the rules,
• there will be control over who orders what,
• and the investment will pay off in terms of time, capacity, and reduced chaos.

Here is an interesting similarity between the two stories: decision-making is not about "functionalities." It is about the fact that the current situation is no longer tolerable.

At UNIBA, it was inflexibility and poor overview. At Liberec, it was the need to take a long-term commodity (office supplies) to the next level – with a larger number of users and an overview of the warehouse.

And by the way: even European materials on e-procurement repeatedly mention savings and impacts in administration and process (not just "cheaper prices"). (EUR-Lex)

Management lesson: decision-makers buy certainty. In-shop only gives them that when the process is built from the bottom up, i.e., so that it can be used.

---

What follows? Four lessons for practice

1) Don’t start with the system. Start with the commodity that hurts most.

Both organizations targeted commodities that are:

• repetitive,
• high-volume,
• administratively annoying,
• and standardizable (office, ICT).

2) Users need a reason to use the catalog.

The reason isn’t a “directive.” The reason is comfort:

• I can find it, pick it, order it;
• I know what will arrive/what’s in stock;
• and I’m not afraid someone will bounce it for a formal error.

3) Influencers need process ownership, or you’ll be piloting forever.

Roles, approvals, catalog management, data upkeep—these need named owners and accountability. UNIBA had this clearly set, which sped things up.

4) Communication in a large organization isn’t “sending an email.”

With thousands of employees, communication is a network: faculty secretaries, unit heads, local champions. Without them, your catalog turns into a legend like “it’s somewhere out there.”

---

Conclusion: an in-shop isn’t about procurement—it’s about disciplined rollout

A catalog isn’t an IT project. It’s a discipline project—and a test of whether procurement leads the organization or just puts out fires. When implemented well, the catalog becomes boring. And that’s a compliment.

A boring catalog means:

• the user orders what they need without unnecessary loops;
• the influencer holds the process and has data on the table;
• and the decision-maker rests easy knowing the organization isn’t behaving like a lunatic where everyone buys their own way.

If you’re looking for romance here, it’s this: procurement finally stops living off operations and starts managing. That’s why these case studies are worth reading.

---

Inspired by the show #PROEBIZWebináře, guests: #MartinaŠťastná, #MartinDufala, #JanaRemenová