# IT Systems Inventory: 2–6 Weeks | Krogis

Źródło: https://krogis.pl/en/inwentaryzacja
Język: en
Opis: IT systems inventory: A/B/C/D categorisation, 16 documents and tools, 2–6 weeks to a board session, below the public-procurement threshold.

---

# Before you commit large sums to a rollout, *get a clear picture of what you already have.*

An inventory of IT systems is an orderly register of an organisation’s applications, contracts, integrations, processes and risks, finished with a single page for the board; it takes 2–6 weeks and falls below the public procurement threshold. An inventory of IT systems and architecture standards is the smallest, cheapest step on the whole digitalisation ladder — and the only one that gives the public office or the company, not the vendor, control over the direction for the next 10 years.

[Ask for a quote](https://krogis.pl/en/inwentaryzacja#kontakt) [See what you get](https://krogis.pl/en/inwentaryzacja#co-dostaniecie)

**Sheet 0** the organisation’s archive **Current state** before the inventory **Photo** illustrative

One-page summary for the board

**The organisation’s systems: state and recommendation** 6 of 14 systems

- Document workflowSecretariatdevelopment until 2029C
- Finance and accountingChief accountantno API for KSeFB
- HR and payrollHRup to dateA
- Customer serviceCustomer service departmentno integrationB
- Asset registerTechnical departmentup to dateA
- Invoice workflow under KSeFno ownergapD

**2** to keep **2** to adapt **1** to replace **1** gap

**Recommendation:** start with document workflow; handle KSeF by integrating the finance system rather than buying a new one.

Example one-page summary for the board. Illustrative data.

## Questions worth knowing the answer to.

I put them to boards, secretaries, county heads and company presidents before decisions on the next purchase are taken. If the answer to any of them is “we don’t know”, that is exactly where I can help.

1. **How many systems do we really have, who owns them and when does support end?**
2. **Which contracts are expiring and what will we do then?**
3. **Where do people retype data by hand or work in spreadsheets alongside the systems?**
4. **Which systems depend on one another, and what happens if one of them stops working?**
5. **Will the next purchase fit in with what we have, or create yet another island?**

**The cost of a mistake.** Buying without knowing what is already there means duplicated functions, missing integrations and a migration that repeats the mistakes of the old workflow. An advisor usually costs less than a single badly chosen technology, a single wrong vendor or a single trap in a contract.

## What you get out of it.

### Peace of mind

One page for the board and a full list of systems, contracts and risks: you know what you have and can show it to the council, the inspectors and the auditor.

### Better results

Further decisions and the budget rest on facts, not on whoever turns up with an offer.

### Fewer reefs and mistakes

You see dependence on vendors and end-of-support dates before they turn into a failure or an urgent purchase.

> “He drew attention to the need to put in order the information on existing solutions, their interdependencies and their limitations before the office takes further investment decisions.”

**Krzysztof Pijanowski**, Deputy Director of the Department of Digitalisation and the Information Society, Marshal’s Office of the Łódź Voivodeship (Urząd Marszałkowski Województwa Łódzkiego). [The full reference](https://krogis.pl/en/referencje#umwl)

## A set that would cost several times more if ordered separately, *included in the inventory.*

Built from scratch by an independent advisor, tailored to your organisation — not a template to fill in yourselves. Sixteen documents and tools in total, forming the foundation for digital transformation and for delivering a long-term IT strategy.

**Foundation · the full set of documents** 4 + 4 + 5 + 3 = 16 documents and tools

**The organisation’s systems: state and recommendation**

### Knowledge of the current state (4 documents)

### Show the list

- A one-page summary for the board: system state, A/B/C/D categories and a recommendation
- An inventory report — for presentation to the board, the Regional Audit Chamber (RIO), the Supreme Audit Office (NIK) and EU auditors
- A completed inventory spreadsheet (35 attributes per system plus A/B/C/D category)
- An integration matrix for central government systems (17 items, status, priority, risks)

**Contract clauses for the tender specification**

### Strategy and standards for the future (4 documents)

### Show the list

- A 10-year digitalisation strategy (regulation, architecture, AI, cybersecurity, a cautious approach to cloud, total cost)
- A catalogue of technical standards (APIs, authentication, data, documents, secure development, accessibility)
- 20 model contract clauses for the tender specification (open APIs, exit plan, source-code escrow, KSC/NIS 2/GDPR/AI Act)
- A policy on the responsible use of AI, compliant with the AI Act, with a register of AI uses in the organisation

**Risk register: heat map**

### Management tools for future projects (5 tools)

### Show the list

- A digital-initiative charter template (business case)
- An architecture-review scorecard template for the architecture committee
- An inventory methodology — for your own IT team to run future cycles
- A risk register (20 items, probability × severity scoring, a heat map)
- A change-management plan (organisational culture, user groups and their systems, adoption strategy, communication, training, metrics)

**Recommendation for the board**

*14* systems

*3* to replace

*2–6* weeks to a decision

### Communication and the board’s decision (3 items)

### Show the list

- Reference architecture diagrams
- A glossary of terms and abbreviations (~150 terms)
- A presentation for the board (12–15 slides) plus a 60–90-minute presentation session, included in the price

## Brief and focused, *with minimal demands on your office or company.*

1. Stage 1 **Start** A kickoff workshop with leadership (the county head or CEO, the secretary, IT) and an inventory survey sent to departments and vendors.
2. Stage 2 **Analysis** Document review, interviews with system owners (5–10 × 45–60 min), technical verification with IT. 1–3 days of meetings with process owners on site, the rest online.
3. Stage 3 **Categorisation** A draft A/B/C/D categorisation and a validation workshop with heads of department.
4. Stage 4 **Decision** The report and the full set of documents; preparation for, and delivery of, a presentation session for the board (60–90 min).

### Why you can trust me

- No commercial ties to vendors of line-of-business systems and platforms — an A/B/C/D assessment free of conflicts of interest.
- A confidentiality agreement before work starts, or confidentiality clauses in the main contract.
- All deliverables in an editable format, with a non-exclusive, perpetual licence for the organisation, including the right to modify them.
- Work with no access to residents’ or customers’ personal data; if access is needed, a separate data-processing agreement (GDPR Art. 28).

## The groundwork that comes before any rollout decision.

An EZD-class (electronic document management) system, an e-office, invoice workflow under KSeF (the national e-invoicing system), a new process platform — each of these decisions involves large sums and ties the organisation to a vendor for years. The inventory gives you objective knowledge of what you actually have, what state it’s in, and what’s missing, before that decision is made — so that you, not a vendor’s offer, define the direction.

## Three work streams, *one set of documents.*

- **Inventory of systems and line-of-business applications.** Every line-of-business system (finance, HR-payroll, EZD/EOD, taxes, surveying, education, social services, billing), process systems (invoice and contract workflow, public procurement, calls for applications), and infrastructure and security. For each: vendor, licence, cost, hosting, service contract, API openness, GDPR/KSC/WCAG compliance, AI readiness, risks — plus a map of integrations with central government systems and a map of dependencies between systems. We also identify where AI is already in use in the organisation, including in tools the management does not know about: for which tasks, with what data and who is responsible.
- **System categorisation using the A/B/C/D methodology.** Each system is assigned to one of four categories based on five weighted evaluation dimensions — see “Categorisation” below. The completed category matrix becomes a roadmap of actions for each system.
- **Architecture standards and strategic documentation.** A full set of documents carried straight into every future IT tender — strategy, technical standards, contract clauses, management tools. This lets the organisation mitigate risk and ensure that future investments comply with its adopted standards and its architecture and security guidelines.

## Before and after: who defines the requirements.

| Without an inventory | After the inventory |
| --- | --- |
| Tender specifications written around vendors’ offers. It is often the offers that end up defining the requirements. | Tender specifications written around actual needs — the client defines the requirements, the vendor meets them |
| Openness clauses and an exit plan left as “we might add them later” | 20 model architecture clauses, mandatory in every IT contract |
| Functionally overlapping systems — the organisation pays twice | You know exactly what the organisation has and where the gaps are — you buy only the capabilities you lack |
| Contract amendments for integrations missed in the specification, at the client’s expense | A catalogue of mandatory integrations with central systems in the specification from day one |
| KSC/NIS 2/GDPR/AI Act non-compliance risk only comes to light during an audit | Regulatory-compliance requirements written into the specification and enforced on the vendor |
| Vendor lock-in — years on, you can’t switch without losing data | Data-export clauses, an exit plan, source-code escrow — the client stays fully in control |
| No justification for a purchasing decision when auditors ask | Documented A/B/C/D categorisation and a justification for the decision |
| EU grant applications with no solid analytical base | Input for EU, KPO and national grant applications |

**The cost of a wrong decision:** an EZD-class system for a county office, a process platform or a comprehensive e-office platform is one of the largest IT purchases for years to come, and multi-year maintenance usually costs 2–3 times more than the purchase itself. The inventory costs the equivalent of a few percent of a typical single tender — the cheapest way to insure the quality of a purchasing decision.

## What you gain. *The documents are evidence, not the goal.*

- **Control over the direction** You, not a vendor, know what you have, what state it’s in and what’s missing.
- **Less money spent** Duplicate systems, expiring contracts and licences, and the real cost of maintenance all become visible.
- **Peace of mind during an audit** Documented due diligence: a written record of what you knew, what the options were and why you chose the one you did.
- **A faster start on the next project** Requirements, an integration matrix and contract clauses ready before the tender.

## Every system gets a clear category and a recommended action.

Hover over a row, or select it with Tab, to see an example.

| Cat. | Definition | Typical action |
| --- | --- | --- |
| A | Systems aligned with the target architecture, high maturityExample: an HR-payroll system with a current service contract and an open API. | Maintain, with controlled development |
| B | The right direction, needs adjustmentsExample: a finance system with no KSeF integration. | A modification plan, negotiation with the vendor |
| C | The system carries risk — outdated technology, end of support, vendor lock-in, no integrationExample: a document-workflow system whose vendor ends support next year. | A phase-out and replacement plan |
| D | A missing capability in the portfolio, needed over a 1–10-year horizonExample: cost-invoice workflow currently run through e-mail and a spreadsheet. | Prioritising rollouts, choosing a delivery model |

*20%* *25%* *20%* *20%* *15%*

The evaluation is based on 5 weighted dimensions: functionality and business value (20%), architecture and openness — APIs, integrations, standards, AI readiness (25%), security and compliance — KSC/NIS 2/GDPR/KRI/WCAG (20%), technology and vendor — how current it is, support, vendor lock-in (20%), economics and total cost of ownership (15%).

## Quote and terms.

Quote after a call

The price depends on the number of systems and departments. I set the exact price after a 30-minute call about the size of your organisation.

For comparison: the full set of strategic documents and standards, commissioned separately, would cost several times more.

- **Below the public-procurement threshold.** It can be commissioned without a procedure under the Public Procurement Law, following the organisation’s own internal rules.
- **A contract that hands over all deliverables.** All documents in an editable format, a non-exclusive, perpetual licence, the right to modify them.
- **A confidentiality agreement before the start**, and work with no access to personal data.
- **Material for grant applications.** The report and the strategy provide the analytical base for applications for EU funds, the KPO and national programmes.

## This isn’t a report destined for a drawer. *It’s the starting point for every project that follows.*

01

### A new initiative, e.g. an EZD-class system or invoice workflow.

Methodology → initiative charter → architecture review → tender clauses → risk register.

02

### The tender and vendor conversations.

A standards catalogue, 20 contract clauses and an evaluation scorecard — you know what to ask before you sit down with a vendor.

03

### Integrations.

The integration matrix with central systems as a ready starting point for every future integration project.

04

### Periodic inventory.

An update every 12–18 months, run either by your own IT team using the same methodology, or as an inventory update carried out by the advisor.

## The questions I’m asked most often about this service.

### How long does an IT systems inventory take?

Typically 2–6 weeks from contract signature to the presentation session for the board, depending on the number of systems. Only 1–3 days are on site, the rest is remote. A coordinating person on the organisation’s side spends about 10 hours in total.

### We have a deadline for the rollout. Won’t the inventory delay it?

No. It ends with requirements, contract clauses and an integration matrix — things you’d need to prepare before the tender anyway. It usually shortens tender preparation, since it replaces collecting vendor offers as the starting point.

### What is A/B/C/D categorisation?

It’s a method for evaluating every system across five weighted dimensions (functionality, architecture and openness, security and compliance, technology and vendor, economics and total cost), which ends with each system being assigned to one of four categories: A (keep), B (adapt), C (plan to replace) or D (a missing capability to plan for).

### Does the inventory cover residents’ or customers’ personal data?

No — the work happens at the level of systems, contracts and configuration, with no access to personal data processed within those systems. If such access were needed in a specific case, it would require a separate data-processing agreement under GDPR Art. 28.

### What happens to the inventory results afterwards?

They become the starting point for further work: a new project’s specification, preparation for vendor conversations, grant applications, and a periodic update run by your own IT team using the same methodology. This isn’t a report that ends up in a drawer.

### How is this different from a security audit or a KSC compliance audit?

A security audit checks compliance with a specific standard or regulation and ends with a list of non-conformities. The inventory gives a wider, business-level picture of the whole systems portfolio — costs, risks, gaps, direction — and translates straight into working documents for the decisions that follow, not just a list of fixes.

### Does the inventory cover contracts and licences?

Yes. The application register records, for every system, the owner, contract, licence, cost and end-of-support date. That shows which contracts are ending, where the organisation depends on a single vendor, and what maintenance really costs.

## Let’s start with a conversation *about scope and price for your organisation.*

[Write to: wojciech.kroczak@krogis.pl](mailto:wojciech.kroczak@krogis.pl?subject=IT%20inventory%20%E2%80%94%20a%20question%20about%20pricing) [Call: +48 516 401 658](tel:+48516401658)

- I reply within 2 working days
- First call: 30 minutes, no charge
- A quote within 2 working days of the call
