Catalogue of Standard PC Configurations for Public Procurement: How to Prepare

Why create a catalog of standard configurations

A catalog of standard PC configurations for public procurement is useful when you want to buy computers predictably: with clear workplace classes, consistent compatibility requirements, and without rewriting documents every year. It shifts the conversation from disputes about specific models to discussion of tasks: office, engineering, classrooms, server room.

When the TOR is rewritten each time, the same problems usually recur. Past agreements are lost, wording differences appear by chance, and requirements begin to contradict each other: different interface versions, obsolete ports, mismatches in memory or storage. The predictable result: more clarifications and complaints, deadlines stretch, and procurement becomes more complicated than it should be.

A catalog helps align expectations between different roles. IT looks at support and compatibility, procurement at verifiability of requirements, lawyers at careful non-discriminatory wording, and users at convenience and adequate performance.

Another advantage is easier planning of updates. In a year you may change a CPU generation or storage type, but class logic and the set of requirements remain the same. This is especially important if you expect long-term support and a clear lifecycle for deliveries, including when working with a local PC manufacturer in Kazakhstan.

To keep the catalog viable for years, standardize a few things from the start: what workplace classes you have and their purpose, which parameters are minimal, what expansion and compatibility requirements you check at acceptance, how service and warranty are described, and which documents confirm compliance.

Once this base is fixed, updates become targeted and approvals take days, not weeks.

How the catalog fits with the TOR and annexes

For the catalog to work year after year, it's important to separate what is fixed in the TOR itself and what lives in an annex and can be updated without rewriting the main document.

In the main TOR text keep what rarely changes and is checked at acceptance. In the annex put what depends on the market and component generations.

A practical logic is:

• In the TOR text: procurement objective, delivery requirements (timelines, lots, completeness), acceptance conditions, warranty and service, documentation and labeling requirements.
• In the TOR text: rule for choosing configurations (for example: supplied PCs must correspond to one of the codes from Annex 1).
• In the annex: table of standard configurations with codes (PC-01, PC-02, etc.) and parameters.
• In the annex: allowable variants within one code (e.g., 2–3 levels by CPU or storage), if you permit them.

Functional requirements are better described by scenarios rather than brands: "office tasks with 10–15 browser tabs and video calls simultaneously", "work with a medical information system", "classroom with constraints on noise". Link these scenarios to codes from the catalog. This avoids brand ties while keeping a clear performance level.

To separate mandatory from desirable, follow a simple rule of language and structure. Phrase mandatory parameters as "must/not allowed", desirable as "recommended/preferred". In a table this is easy as a separate "Requirement status" column (mandatory or desirable) or by marking mandatory fields in the header.

Linking to lots and quantities is usually done with a short table in the TOR or a separate annex: for each lot indicate configuration code and quantity. For example:

• Lot 1: PC-01 (Office) — 120 units
• Lot 2: PC-03 (Classroom) — 30 units
• Lot 3: PC-05 (Workstation) — 10 units

This way the catalog remains stable, and in the TOR you change only the need (codes and quantities) and, if necessary, update the annex with component generations without altering procurement logic.

Catalog structure: PC classes and grouping logic

A strong catalog is built around employee tasks, not around specific models. Then it can be attached to the TOR year after year, changing only CPU generations, RAM sizes and storage types, without breaking the document's structure.

Start with clear classes by work scenario. Usually 5–8 profiles are enough to cover most requests without overloading procurement. For example:

• office PC (documents, mail, browser, electronic document flow)
• PC for accounting (1C, multiple windows, printing peripherals)
• operator/call-center workstation (simple tasks, reliability and headset requirements)
• engineering PC (CAD, 2D/3D, more memory, sometimes discrete graphics)
• workstation (heavy projects, computations, professional graphics)

To let the catalog survive generation changes, set some parameters as ranges and some as fixed. Ranges give suppliers freedom to select current components without downgrading class.

Commonly useful:

• range: CPU class (not below a specified level), RAM size (not less than), SSD capacity (not less than), number of ports (not less than)
• fixed: form factor (SFF/MiniTower/all-in-one), TPM presence, network interface type, warranty and service requirements, noise limits (if critical)

Don't overdo ranges. Power supply and cooling are better specified by verifiable reliability and safety requirements, not by "anything goes."

A separate principle — do not mix system unit, monitor and software in one row. Treat the system unit (or all-in-one) as a separate base-line item. Add monitor, keyboard, mouse, headset, UPS and cables as independent items tied to a profile (e.g., "for Office profile"). OS and office suites are also easier as separate lines: this simplifies license changes and avoids disputes about editions.

If you procure from a local PC manufacturer in Kazakhstan, this structure usually simplifies things: you describe required task level and equivalence rules, and the supplier meets them with current components within allowed ranges.

Which fields to include in the configuration table

The table should be clear for both procurement officers and inspectors: what we buy, the minimum acceptable, and how to prove compliance. For a catalog used in public procurement, a few columns usually cover both TOR and acceptance:

• purpose and class (office, classroom, engineering, medical, etc.)
• key parameters and minimum values (brief, brand-free)
• tolerances and equivalence (where "not worse" is acceptable and where strict)
• compatibility and constraints (form factor, memory type, TPM presence, etc.)
• supporting documents (product passport, serial numbers, certificates, origin)

To keep components described consistently, create a wording template and stick to it.

CPU: indicate class and measurable minimums (for example, not less than a certain number of cores/threads, or not below a chosen performance level). If your software requires specific instruction sets or virtualization, state that too.

RAM: capacity, type (DDR4/DDR5), frequency as "not less than", number of slots and expandability.

Storage: type (NVMe or SATA SSD), capacity, encryption or endurance requirements if truly needed.

Graphics: "integrated sufficient" or "discrete with minimum video memory" and a clear level.

Network and ports: Ethernet (1G/2.5G), Wi‑Fi/Bluetooth if needed, minimum USB and video outputs.

Case and power: form factor, operational requirements (including noise if critical), reasonable power headroom.

Also include a support block: warranty length, how to request service, service network requirements, response and recovery times (e.g., "no more than N hours/days under contract"). Avoid promising things the supplier cannot document.

If origin and local content matter, add a separate field "Proof of origin/local content" and list which documents confirm it. In Kazakhstan this often affects preference eligibility, so formulations must be verifiable. As an example of a supplier that usually has such documents, consider GSE.kz: a domestic manufacturer since 2015 with ISO 9001, ISO 14001 and ISO 45001 certifications. In the TOR itself, leave requirements for documents, not brand mentions.

How to change component generations without rewriting the catalog

To keep the catalog usable for years, separate the permanent part (classes and purpose) from the variable part (component generations). Then updates are targeted rather than full rewrites.

A simple rule: a "generation" changes when you update key nodes that affect performance and market availability. Typically this is CPU (platform), RAM type and capacity, and SSD type and capacity. Replacing a case, keyboard or OS version is usually an adjustment to completeness, not a generation change.

What to keep unchanged

Keep selection logic stable, not model names. In the catalog fix:

• PC class (office, graphics, thin client, workstation, etc.)
• purpose and scenarios (documents, e-government services, CAD, training)
• minimal levels that do not depend on brand (for example, at least 16 GB RAM, SSD at least 512 GB, TPM 2.0 presence)
• interface and form-factor requirements (e.g., at least 1x HDMI, 1x DP, 6x USB, M.2 NVMe)

This lets you update hardware without changing configuration meaning.

How to update CPU/RAM/SSD without rewriting

A practical approach: one row per configuration, and generation is treated as an execution variant. In a "Generation" column indicate Gen1/Gen2, and update only CPU, RAM and SSD in a "Variable components" column.

Define equivalence on replacement by verifiable criteria: "not below performance level", "DDR4 to DDR5 allowed if minimum capacity preserved", "NVMe SSD not below specified class." For compatibility add short constraints: memory type, number of M.2 slots, power requirements.

If you buy from a local manufacturer in Kazakhstan, it is practical to request a letter of compatibility and equivalence against your criteria. This is logical when the manufacturer controls assembly and testing.

Versioning and change management

A catalog lives beyond a single procurement cycle, so manage it with version control. Minimum: version number and approval date (for example, v2.3 from 2026-02-15). Put these on the cover of the PDF and in the table header.

Keep a short change log to avoid disputes about why a configuration or class changed. Place it on the first page or as a separate sheet in the table. Three to five lines per version are usually enough. Record not only "what changed" but also "why": switch to a new platform, end of SSD supply, security requirements.

How to store sources and final versions

One format for work, another for procurement: source — an editable spreadsheet (Excel/Google Sheets); publish — an immutable PDF for the TOR annex.

A convenient storage scheme:

• folder "Catalog_Standard_PCs" with subfolders by year or version
• in each version: source spreadsheet, PDF for the TOR annex, "Change_Log" file (if not inside the table)
• unified file naming, e.g.: "Catalog_PCs_v2.3_2026-02-15"

Who approves and how often to review

Assign a catalog owner (often IT or digitalization department) and at least two approvers: procurement and the profile customer (e.g., education or healthcare). In public procurement this reduces the risk of requirements that are hard to prove or deliver.

Review usually happens annually and ad hoc when market or requirement changes are significant. When updating generations, change only variable fields and record reasons in the log. Avoid altering class structure and selection logic unless necessary.

Example entry: "v2.3: Office PC — CPU updated from 12th to 13th gen; reason: end of supply and alignment by performance within the series." If local content matters, note that updates do not affect required supporting documents.

Step-by-step: how to assemble a catalog in 1–2 weeks

If the goal is to assemble a catalog in 1–2 weeks, start not with hardware but with how people work. Where are simple office tasks, heavy spreadsheets, medical systems, dual-monitor needs, silence requirements or 24/7 operation.

A typical working pace: appoint a responsible person, gather a small group (IT, procurement, legal, 1–2 department reps) and follow fixed steps.

1. Collect real scenarios and consolidate them into 4–6 profiles. Each profile needs 3–5 typical tasks and 1–2 constraints (noise, space, 24/7).

2. For each profile set minimums and tolerances for key nodes: CPU (class/level), RAM (capacity with margin), storage (type and minimum), graphics (integrated or discrete), interfaces, form factor, warranty and service.

3. Format the table as a TOR annex and immediately write equivalence rules. Phrase them through measurable parameters and "not worse", not by part numbers.

4. Check procurement and legal clarity: ensure there are no hidden requirements favoring one supplier, no contradictions between points, and that compliance can be unambiguously verified by documents.

5. Prepare an annual update cycle: who proposes changes, who approves, how to record versions, and what can change without rebuilding structure.

A quick guideline: if the catalog lists an "Office PC" with 16 GB RAM and an SSD of at least 512 GB, next year you update platform details as needed and refine variable components while leaving profile, scenarios and verification rules unchanged.

If you buy from local manufacturers in Kazakhstan, check in advance which characteristics are confirmed by passports and certificates. This simplifies acceptance and reduces dispute risk.

Common mistakes and pitfalls when creating a catalog

The most common problem is writing the catalog as if a specific model is already chosen. For public procurement this is risky: overly precise wording easily becomes a hidden restriction on competition, and updating generations later is inconvenient.

Mistakes that are expensive to fix later

Frequent issues include:

• listing brands, exact part numbers, unique connectors or sizes without real need
• mixing mandatory and desirable parameters in one table row
• inconsistencies between the annex and the TOR text (table says one thing, document another)
• lack of clear equivalence rules when changing generations
• ignoring the service part, especially for branch networks

How to prepare in advance

Separate "must" (minimum for the task) and "allowed/recommended" (what improves but does not block procurement). For generation changes use neutral wording: not "CPU X" but "not below performance level Y + required feature compatibility."

Keep a single source of truth: if configurations are described in the catalog, there should be no other numbers or conditions in the TOR text. Also document support: is 24/7 needed, where must service be provided, response and repair times, and when warranty starts. For distributed organizations in Kazakhstan, requiring a service network and clear procedures helps; manufacturers and integrators that can document their support, including GSE.kz, usually meet this need.

Short checklist before publishing the TOR

Before attaching the catalog, review it as a document that will be read without you: procurement, legal, supplier and technical support. Anywhere the document requires an "oral explanation" is where disputes will arise.

Quick pass checklist:

• each profile has a clear purpose and measurable parameters (scenarios + numbers)
• tolerances and equivalence rules exist
• the catalog has version, date and responsible person
• warranty and service requirements are written unambiguously (term, format, response times, service location, warranty start)
• the catalog does not contradict the main TOR and is readable without explanation

A practical test: give the document to a colleague not involved in its preparation and ask them to explain in 10 minutes the difference between two adjacent profiles. If they hesitate, suppliers will interpret it inconsistently too.

If local manufacturing matters, ensure this requirement is correctly reflected and proven by documents rather than hints in the description. This reduces complaints and speeds up acceptance.

Example: how an organization uses the catalog for two consecutive years

A district hospital prepares procurement: computers for reception (many identical workplaces), for doctors (higher requirements) and several powerful PCs for functional diagnostics. Instead of creating requirements anew, they use the catalog as an annex to the TOR.

The catalog already contains profiles with clear names and purposes. In the TOR the hospital chooses profiles and states quantities; configuration details are in the annex.

First-year distribution might look like:

• Profile A: "Reception" — 22 units
• Profile B: "Doctor" — 14 units
• Profile C: "Diagnostics" — 3 units

The TOR fixes delivery and acceptance conditions; the catalog defines configurations. This is convenient because reception and doctors have different small requirements: compactness and low noise in one case, dual monitors or extra RAM in another.

A year later the hospital runs a similar procurement. The catalog structure does not change: same profiles, fields and compatibility requirements. Only component generations are updated where permitted by rules:

• CPU: new generation while keeping performance class
• SSD: update speed/capacity while keeping form factor
• RAM: migrate to a newer type if the platform changes
• video outputs: update for new monitors without changing profile

To avoid disrupting regional deliveries, the hospital adds service requirements that do not depend on generation: delivery time to the district, onsite or field support, warranty replacement rules, availability of spare parts. It is easier to work with a supplier who can document support and a service network, including local manufacturers and integrators such as GSE.kz (24/7 support and regional service).

In year two it looks like a directory update rather than rewriting documents: fewer errors, easier approvals, procurement comparable in quality.

Next steps: how to implement and maintain the catalog

Start with an inventory: what PCs are already deployed, what typical tasks employees perform (documents, accounting, EDM, graphics, classrooms), and which constraints matter (desk space, noise, TPM, OS, peripheral compatibility). Based on this choose 4–7 profiles and lock them in one document so the catalog becomes a stable annex rather than a one-off tender table.

To keep the catalog alive, appoint owners and a simple review cycle. Tie updates to the procurement calendar: change component generations and statuses (current/replacing), while keeping classes and service requirements stable.

A practical annual schedule:

• January–February: collect IT and user feedback on bottlenecks
• March: check component availability and delivery times
• April: update CPU, SSD, RAM platforms and related parameters
• May: agreement with procurement and security, finalize catalog version
• June: use version N in TOR projects for the next period

If the team lacks time or there are contentious issues (local content, warranty scheme, software compatibility, standard OS images), involve a manufacturer or systems integrator for a quick applicability check. In Kazakhstan, practical experience from GSE.kz as a domestic manufacturer and integrator can help: request profile, service and generation-replacement risk checks. This makes the catalog feasible for delivery and support.

Adopt a rule: any changes only via a new version and a short recorded reason. This preserves continuity, speeds approvals and makes it easier to explain requirement logic.