Key points
Zdjęcia ilustracyjne
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.
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.



