All postsJournal · post 10 / 10
No jargon

Key points

  1. EZD is the records office, not the whole workflow

    It handles correspondence and case files – the largest, but not the only, part of a public authority's documents.

  2. Many workflows run alongside it

    Recruitment, leave requests, training, business trips, and materials for board and council meetings.

  3. A process platform is a workshop

    It lets you build new workflows quickly and refine them just as fast.

  4. The change only really begins after go-live

    The first version of a process reveals what can still be simplified.

Zdjęcia ilustracyjne

Short answer: EZD is a document workflow, but not the whole one. A system of the EZD class (electronic document and case management system) handles correspondence and cases: incoming letters, registering correspondents, opening cases, routing, replies, delivery and archiving. This is the largest part of a public authority's work, but alongside it run many other workflows: applications for recruitment and the entire recruitment procedure, leave and training requests, business trips, draft resolutions of the executive board and materials for board meetings or council sessions. EZD, by design, does not create or manage these documents. To cover them all, you need a process platform on which further workflows can be quickly built and refined.

This post is for secretaries and senior officials who, when asked about document workflow, answer: "We have one – after all, we work in EZD."

What an EZD-class system actually does

If we were looking for a comparison with the corporate world, an EZD-class system is closest to a CRM system, only for public administration. It has a register of correspondents – residents, businesses and institutions. It has intake channels: the registry desk, ePUAP, e-Doręczenia (Polish e-Delivery), email. It lets you register a letter, open a case, assign it to a department, carry out the relevant actions, prepare and send a reply, and finally pass the documentation to the archive.

That is a great deal, and it forms the foundation of a public authority's work. Most documents follow exactly this route, because handling cases is what a public authority does above all. That is why implementing an EZD-class system matters and is not something worth postponing.

But this is a workflow for correspondence and cases, run according to the records-management rules. It is not a workflow for every document created within a public authority.

Analogy for the board

EZD is like a records office with an excellent register: it knows what came in, who received it, what case it became, and what reply was sent. But a public authority also has an HR officer running recruitment, a council office compiling materials for sessions, and an organisational department collecting training requests. Each of them has its own documents and its own approval paths. The records office does not manage these, even if it sometimes registers them.

Documents that live outside EZD

Once you start listing the document workflows in a typical public authority, the list grows quickly. There are applications for vacant posts and the entire recruitment procedure, with the announcement, candidate assessment and the record. There are leave requests and other HR documents. There are training requests, with a supervisor's approval and a budget check. There are business trips for staff and for councillors, with expense settlements. There are draft board resolutions with their supporting documents, draft meeting agendas and the entire handling of board meetings, alongside the handling of council sessions. And finally there are cost documents, which I wrote about in the post on invoice workflow in the world of KSeF.

Each of these documents has its own path: who prepares it, who checks it, who amends it, who approves it, and which system its data ends up in. Today these paths often run on paper, in email, or in spreadsheets. Some are handled by domain-specific systems, for example HR systems or council-support systems, but these are rarely connected to one another.

What a process platform is

Document workflow in the full sense means being able to handle any process, not just correspondence. That is what process platforms are for, also known as workflow systems or BPM systems. They allow a process to be defined in two ways. The first is a predetermined path: a request goes to the supervisor, then to HR, then for approval. The second is a path that people shape as they go, passing a document to one another for review, revision and approval, while preserving successive versions.

What matters most, however, is what happens outside the human steps. A process platform automates supporting tasks: it generates a finished PDF document from the request data, transfers data into HR or finance-and-accounting systems, tracks deadlines, and sends reminders about outstanding approvals. In doing so, it must keep data consistent across systems, so that the same employee, counterparty or budget line does not end up with a different version in each place.

EZD and a process platform do not compete with one another. EZD manages cases and correspondence, the platform manages the remaining workflows, and when a document from an internal workflow becomes part of a case, it is passed to EZD through integration.

Why speed of change matters

When choosing a platform, it is tempting to focus only on how quickly the first application can be built. It is equally important how easily it can later be changed and released as a new version. Only once a process goes live in electronic form do people see what can be simplified: a step that adds nothing, a field nobody reads, an approval that can be merged with another.

If every such amendment requires a commission to the vendor and weeks of waiting, the process freezes in its first version. If it can be introduced quickly and safely, with version history preserved, the process matures alongside the organisation.

Transformation, not procurement

This is what digital transformation actually means: changing the way the organisation works. We consider which activities the work truly requires, which of them a system can perform, which are worth delegating to artificial intelligence, and which documents can be generated rather than written. Buying a system is merely a tool for this change.

All of this, however, must work day to day: it needs an owner, safeguards, backups, and clear rules on who may change processes and how. That is why, before selecting tools, it is worth having a strategy and target architecture that defines which system is responsible for what and how systems exchange data.

Where to start

A good first step is a list of the document workflows in the authority beyond correspondence and cases. For each one: who takes part in it, how many times a year it recurs, where it currently lives (paper, email, a spreadsheet, a domain-specific system) and which systems its data ends up in. Such a list shows which workflows are the most frequent and most burdensome, and therefore which ones are worth tackling first. An inventory of systems and processes helps in preparing it.

Is EZD a document workflow?
Yes, but it is a workflow for correspondence and cases, run according to the records-management rules. It does not cover every document in the authority, for example the recruitment procedure, leave and training requests, or the preparation of materials for board meetings.
Could extending EZD replace a process platform?
Some workflows can be handled in EZD, but an EZD-class system is designed around cases and the records-management rules. Internal workflows, with their own forms, approvals and integrations with domain-specific systems, are usually easier and cheaper to build on a process platform connected to EZD.
What is a process platform?
It is a system in which processes are defined: forms, approval paths, rules, deadlines and connections to other systems. A single platform can support many workflows – for example leave, training, business trips or the handling of board meetings – and they can be changed without writing a new system from scratch.
Which workflow should we start with?
With one that recurs frequently, involves many people, and currently costs a great deal of supporting work, such as re-entering data or collecting signatures. Leave requests, training requests and business trips tend to work well as a starting point, because they involve every employee.
Would you like to see which document workflows in your authority are worth moving into a system first? Let's start with a needs analysis →

Let’s talk about your situation — specifically, not in general terms.