The schedule of responsibilities defines which organisational unit of an authority is responsible for which task. It supplements the rules of procedure and is the basis for deputising rules, signing authority and records management.
In most administrations it is a text document. That is where the problem starts: responsibility is written out separately for every task, and every reorganisation forces a review of the whole document. The plan is correct on the day it is signed and increasingly no longer so afterwards.
Ordivis Platform turns that around: responsibility is not written, it is derived – from an assignment of product to organisational unit and from your maintained organisational structure.
Ownership – the A in the RACI system – comes from exactly one assignment: product to organisational unit. From it follows the responsibility for all processes of that product. An explicit entry on the individual process trumps this derivation; the exception stays possible without becoming the rule.
Responsibility (R), consultation (C) and information (I) conversely inherit downwards and can be assigned at product, specialist task or process level. Anyone defining a duty to consult for a whole product does not have to repeat it on every process.
In the list, the detail view and the PDF you can see where a statement comes from:
| Provenance | Meaning |
|---|---|
| explicit | maintained on the process – trumps every derivation |
| from the product | from the assignment product → organisational unit |
| from the product group | assigned one level higher in the product plan |
| from the parent unit | through the hierarchy of the organisational structure |
| from the specialist task | for responsibility, consultation and information |
| missing | no responsibility found – appears in the audit report |
The reason for this visibility is simple: an inherited entry must not look like a confirmed one. Otherwise nobody checks it any more – and a plan in which everything looks equally certain is more dangerous than one with visible gaps.
Units, posts with post identifiers, appointments with a share and a deputy, officer functions. Existing data can be imported via CSV.
An initial assignment evaluates the department proposal of the process catalogue and creates assignments wherever a unit of the same name exists – marked as a proposal until you confirm it.
Processes without ownership, duplicate ownership, products without a unit, units without a head, orphaned assignments – all before the plan is issued, not after.
The data state, a PDF and a SHA-256 checksum with the issue date and the author. The reference-date query reads the edition instead of reconstructing the state.
What changed between two states? The answer is a query, not a text-diff exercise in Word.
The org chart shows the structure – which unit hangs under which. The schedule of responsibilities distributes the tasks across that structure. Ordivis Platform generates both from the same data, which is why they cannot drift apart.
No. It becomes binding through issuance by your authority's management. The software supplies the basis, documents the data state and makes the edition citable – the issuance remains your administrative act.
You move units and reassign products. The plan follows. What used to be hundreds of individual edits is now a handful of changes to the org chart.
Yes. The plan can be extended with free entries per organisational unit – for whatever no catalogue product covers. These entries are marked as manual additions and are not lost when the plan is regenerated.