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.
Example one-page summary for the board. Illustrative data.
An EZD-class system, e-government, invoice workflow under KSeF, a new process platform — each of these decisions costs hundreds of thousands of złoty 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.
| 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 |
| Change orders 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 |
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.
A kickoff workshop with leadership (the county head or CEO, the secretary, IT) and an inventory survey sent to departments and vendors.
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.
A draft A/B/C/D categorisation and a validation workshop with heads of department.
The report and the full set of documents; preparation for, and delivery of, a presentation session for the board (60–90 min).
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 |
A keep
B adapt
C phase out and replace
D fill the gap
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%).
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 40,000–80,000 zł.
Methodology → initiative charter → architecture review → tender clauses → risk register.
A standards catalogue, 20 contract clauses and an evaluation scorecard — you know what to ask before you sit down with a vendor.
The integration matrix with central systems as a ready starting point for every future integration project.
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.
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.
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.
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).
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.
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.
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.
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.
