Since the move to accrual accounting, administrations have planned and steered through products. The work itself follows processes – with a trigger, steps, an outcome and a legal basis. The schedule of responsibilities is meant to connect the two worlds and is in practice out of date on the day it is signed. Ordivis Platform puts the product plan, the process catalogue and your organisational structure into one system – and derives the schedule of responsibilities from them.
The administration keeps its range of services in the product plan and its responsibilities in the schedule of responsibilities. What it does, is in neither of them.
The product plan answers what money is spent on – it is an instrument of budget control and was never meant to describe work. The schedule of responsibilities answers who is responsible; it is created as a text document, issued as an annex to the rules of procedure, and ages from the first reorganisation onwards. And the process – what actually happens – is at best recorded in a third tool that is connected to neither of the two.
The consequences are familiar: responsibilities nobody can evidence any more. Onboarding that consists of hearsay. Deputising rules that cannot be found when someone falls ill. And with every reorganisation the same manual work, because responsibility was maintained hundreds of times individually instead of once.
No rollout project, no Excel import, no external consultancy just to get started. The municipal product plan and the process catalogue are shipped and searchable from the first start.
| What | Scope | Note |
|---|---|---|
| Main areas | 6 | the top level of the municipal product plan |
| Product areas | 16 | 13 of them carry processes |
| Product groups | 41 | |
| Products | 148 | the level at which ownership is assigned |
| specialist tasks | 462 | the link between product and process |
| Administrative processes | 5,019 | 4,518 core, 445 support, 56 management processes |
| with a legal basis | 5,019 | every process names its norm |
| with a LeiKa reference | 4,389 | a link to the administrative service catalogue |
| Administrative levels | 3 | municipality/city (1,718), municipal association (2,925), state (376) |
That is the point at which the two orders meet: there is no process in the catalogue that points into nothing. The reverse does not hold – 13 of the 16 product areas carry processes; sports funding, economy and tourism, and central financial services are not covered in the process catalogue. We write that down because it is true.
The catalogue is a reference and creates no configuration items. Only adoption creates a business process in your inventory – for the processes your administration actually carries out. Adoption is repeatable, shows a preview beforehand and creates nothing twice.
The reason is practical: 5,019 processes as records would be 5,019 numbers, audit lines and search hits for material that a single municipality to a considerable extent never carries out. A catalogue that makes search unusable helps nobody.
Three bands – management, core, support – with tiles and counts, by click all the way to the process list. Filtering is by administrative level and process type; the level is preset to municipality/city, because without a filter there would be 5,019 processes and thus no map.
Source: material of the KGSt (the German municipal association for administrative management), licensed under CC BY 3.0 DE. The source note appears in the product wherever catalogue data becomes visible.
Not an org chart to look at, but the structure the schedule of responsibilities rests on.
Departments, divisions, offices, sections, staff units and municipal enterprises – create, change, move, delete. When moving, a cycle check prevents upside-down trees; only what no longer carries anything is deleted.
With the post identifier as it appears in the schedule, and the post size in full-time equivalents. Exactly one post per unit is the head – as a post, not as a person field.
With a share and a validity. Two people at 50 % each are two appointments; the total may not exceed 100 %. Deputies do not count towards it – they apply during absence.
Information security, data protection, fire safety, equal opportunity officers – with assignment and deputy in one entry. Explicitly separated from software permissions and crisis team roles.
Drawn from the same data, exportable as PNG for the manual, the notice board and reports. No second place to maintain that drifts apart.
A flat table, one line per post – the form in which an administration keeps its organisation anyway. The export is at the same time the import template: download it, extend it in Excel, play it back.
A person reference on the record cannot represent what is everyday reality in an administration: a vacant, a shared or a covered head role. The head role is therefore a post with a marker, and whoever holds it is an appointment with a share and a period. A change in the head of department changes the appointment – not the schedule of responsibilities.
A dissolved post and an ended appointment are ended as of a reference date, not removed. Older editions of the schedule of responsibilities therefore stay readable – and a responsibility from three years ago can still be evidenced.
It is not written but derived from the product assignment and the organisational structure – and every statement shows where it comes from.
You assign a product to a unit. That establishes ownership for all processes of that product. When the head of department changes, the org chart is touched – not every individual process.
An explicit entry on the process takes precedence over the derivation. The exception stays possible without becoming maintenance work for everything else.
In the list, the detail view and the PDF you can see whether a responsibility is inherited or maintained. An inherited entry must not look like a confirmed one – otherwise nobody checks it any more.
These inherit downwards instead and can be assigned at product, specialist task or process level. Ownership stays untouched by this: it comes from exactly one source.
Processes without ownership, duplicate ownership, products without a unit, units without a head, orphaned assignments. A plan that names its own gaps is worth more than one that looks complete.
An edition freezes the data state, the PDF and its SHA-256 checksum, with the issue date and the author. The reference-date query reads the edition instead of reconstructing the state – and two editions can be compared.
The OZG implementation catalogue orders administrative services not by authority but by the situation in which people and businesses need them: 18 topic fields, 54 life and business situations, 575 services. It is thus the outside view of exactly the administration that the product plan and the process catalogue describe from within – and in Ordivis Platform both sides are connected.
The executing level is stated in the LeiKa typology – and at one decisive point it does not distinguish further: for many services the value reads „state or municipality“, because state law decides per federal state who executes. Ordivis Platform shows exactly that instead of deriving a municipal responsibility from it. The filter „only what concerns us“ therefore hides only what demonstrably concerns another level.
And: „not yet assessed“ is a state of its own, not maturity level 0. Counting a statement that was not made as „information only“ would make the digitalisation status look systematically better than it is.
Part of our maxim is to name the limits before you find them in operation.
The product plan structures the range of services for budget control – it answers what money is spent on. The process catalogue describes how the service is delivered: trigger, steps, outcome, legal basis. Both describe the same administration from two angles; Ordivis Platform brings them together.
No. The catalogue creates no configuration items. Only adoption creates a business process in the inventory – repeatable, with a preview, without duplication.
From the material of the KGSt, licensed under Creative Commons Attribution 3.0 Germany (CC BY 3.0 DE). The source note is stored as a date on the catalogue state instead of hard-wired into the program – a new catalogue state brings its own note with it.
Because otherwise every change in the head of department triggers hundreds of individual edits. One assignment of product to unit carries all processes of that product; the explicit entry on the process remains possible as an exception.
Yes, via CSV with one line per post. The export delivers exactly the columns the import expects. A preview before writing, rejected lines are reported instead of swallowed, a second run changes nothing.
No – but they share the data. The business process is the same configuration item that emergency management, the ISMS and the record of processing refer to. Describe the process once and you have it everywhere.
We show you the Organisation area on real data – the catalogue, the organisational structure and a generated schedule of responsibilities, in a video call.
Arrange a demo