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.
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.
- 2–6 wks
- from contract signature to the board session
- Quote
- after a 30-minute call, depending on the number of systems
- 16
- documents and tools delivered
One-page summary for the board
The organisation’s systems: state and recommendation6 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 keep2 to adapt1 to replace1 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.
- How many systems do we really have, who owns them and when does support end?
- Which contracts are expiring and what will we do then?
- Where do people retype data by hand or work in spreadsheets alongside the systems?
- Which systems depend on one another, and what happens if one of them stops working?
- 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.
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.”
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 documents4 + 4 + 5 + 3 = 16 documents and tools
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)
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
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)
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.
- Stage 1Start
A kickoff workshop with leadership (the county head or CEO, the secretary, IT) and an inventory survey sent to departments and vendors.
- Stage 2Analysis
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.
- Stage 3Categorisation
A draft A/B/C/D categorisation and a validation workshop with heads of department.
- Stage 4Decision
The report and the full set of documents; preparation for, and delivery of, a presentation session for the board (60–90 min).
- 2–6 wks
- from contract signature to the board session
- 1–3 days
- on site; the rest is remote
- ~10 hrs
- in total from the coordinator on your side
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.
- An EZD-class systempublic offices, an announced obligation, with the deadline pushed back to 2029 at the earliest
- You get: a map of document workflow and integrations, migration requirements and contract clauses. Risk: designing the digital system to mirror analogue procedures.
- KSeF and invoice workflowpublic offices and companies
- You get: an integration matrix for the finance system, and an integration option set against a new-system option, with 5-year costs. Risk: yet another application silo and double data entry.
- KSC / NIS 2cybersecurity law: obligations and penalties for the board
- You get: a systems register and a register of 20 weighted risks with a heat map. Risk: liability for failing to manage risk, with no documents to show that you did.
- Regional Audit Chamber (RIO), Supreme Audit Office (NIK), supervisory boardat any time
- You get: documented A/B/C/D categorisation and a justification for every purchasing decision. Risk: a charge of mismanagement or of decisions taken without grounds.
- Budget and fundingdraft budget, grant applications
- You get: IT spending split into obligation and investment, the cost of doing nothing, input for applications for EU funds, the KPO (National Recovery Plan) and national programmes. Risk: failing to account for the total cost of ownership.
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 directionYou, not a vendor, know what you have, what state it’s in and what’s missing.
- Less money spentDuplicate systems, expiring contracts and licences, and the real cost of maintenance all become visible.
- Peace of mind during an auditDocumented 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 projectRequirements, 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 |
A keep
- HR and payroll
- Website
B adapt
- Finance system
- Fixed-asset register
- File server
C phase out and replace
- Unsupported document workflow
- Contract register in a spreadsheet
- In-house warehouse software
D fill the gap
- Cost-invoice workflow
- Access register
- Customer and supplier portal
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.
A new initiative, e.g. an EZD-class system or invoice workflow.
Methodology → initiative charter → architecture review → tender clauses → risk register.
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.
Integrations.
The integration matrix with central systems as a ready starting point for every future integration project.
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
Call: +48 516 401 658
- I reply within 2 working days
- First call: 30 minutes, no charge
- A quote within 2 working days of the call