ECM Development: Where Document Flow Breaks
Document flow doesn't break at the implementation stage — it breaks at scale: while there are only a dozen approvals per week, everything holds together on email and shared folders. As soon as the flow grows, the same bottlenecks surface.
Document versions diverge — the lawyer has "final_2", the finance person has "final_2_edits", and no one knows which one went to the counterparty. Approval stalls because it's unclear who has the document and how long it's been sitting there.
Document tracking is done manually, and the audit of actions boils down to "someone must have changed this."
The cost of such a regime is measurable: hours spent reconciling revisions, repeated rounds of approval, missed deadlines on contracts, and a complete absence of traces — when investigating an incident, it's impossible to reconstruct who changed the terms and when.
This isn't a problem of employee discipline, but the absence of a system where a document has a single current state, and every action has an author and a timestamp.
ECM development closes these gaps at the data model level, not through policies. A document is stored as an object with a version history, the approval route is defined by rules rather than emails, and the audit log records every opening, edit, and signature. Let's break down how this is structured and what exactly each bottleneck is addressed by.
What an implemented document management system delivers
The effect of implementation is measured not by the number of digitized pages, but by how much shorter the path from document to signature has become.
Before the system, a typical approval of a contract or an internal memo stretches over days: the letter travels along the chain, someone is on vacation, a version of edits gets lost in email, and the cycle starts over.
After implementation, the route is built once and then executed automatically — approval time is cut severalfold, and participants see the current version and status at any moment, without "reminder" calls.
A single registry eliminates the main class of failures — loss of versions and working with the wrong file. Every document exists in one place, with a change history, the author of each edit, and links to related materials: a contract, an invoice, an incoming letter.
Traceability becomes end-to-end — for any document you can see who, when, and what was changed, who approved it, and on what basis. This is what used to be collected manually and surfaced only during audits.
Access roles separate areas of responsibility without unnecessary bureaucracy: an ordinary employee sees their own documents, a department head sees their own block, and security services and legal teams see what they need per regulations.
Permissions are configured by document types and route stages, so confidential information does not leak, and working materials are not blocked by excessive restrictions.
The archive stops being a dumping ground and becomes a working tool: documents are stored by retention periods, automatically moved to the archive upon completion of their lifecycle, and found by search in seconds — by metadata, counterparty, date, or content.
In sum, this delivers a predictable cycle: a document is not lost, approval does not stall, and an inspection or audit does not turn into a frantic paper-gathering exercise.
Ways to Organize Document Workflow: A Comparison
The choice between an off-the-shelf product, platform configuration, and custom development is not a matter of taste, but a question of how much your processes differ from typical ones.
An off-the-shelf solution covers standard document workflow through speed of launch, but its approval and role logic is defined by the vendor: if you have multiple legal entities with cross-approvals or industry-specific requirements, you start adapting processes to the product rather than the other way around.
Configuring an existing platform is a compromise: the core already works, and you describe routes, permissions, forms, and rules through configuration.
This is faster than development, but it hits the platform's ceiling: a non-standard scenario that isn't in the data model will have to be either worked around or extended with code, and every core update requires verifying those customizations.
Custom development is justified when document workflow is a competitive advantage rather than hygiene. Then the data model, routes, and integrations are designed around your regulations, and the system doesn't resist process changes.
| Option | When it fits | Limitations |
|---|---|---|
| Off-the-shelf solution | Typical processes, need a quick start, small IT footprint | Logic defined by the vendor, deep customization is expensive, vendor dependency |
| Platform configuration | Processes close to typical, existing core and licenses | Data model ceiling, customizations complicate updates, some scenarios require workarounds |
| Custom development | Unique regulations, complex roles, critical integrations | Longer launch, requires an in-house support team, higher documentation requirements |
The key criterion is not company size, but the share of non-standard routes and the number of external systems the document must exchange data with.
The more integrations with accounting systems, archives, and external counterparties, the higher the chance that an off-the-shelf product will require middleware, and configuration will hit the core's limitations.
How we run a project: ECM development stages
A project starts not with code, but with a process audit: we analyze how a document actually travels across departments — who initiates it, who approves it, where it gets stuck, which approval branches exist only "on paper." The output is a map of routes with roles, deadlines, and the points where control is needed. This is the key artifact: if the scheme is wrong, no configuration will save it.
- Process audit. Interviews with the people doing the work, review of current regulations and the "gray" workarounds people use instead of official procedures.
- Route scheme design. Approvals, parallel and sequential branches, returns for revision, escalation on overdue, role-based access rights.
- Configuration. Reference data, document templates, numbering, routes, notifications, integrations with email and directory systems.
- Acceptance checks on real documents. We run through real contracts and requests, not test stubs: the full cycle from creation to archive, including rejections and returns.
- Training and handover. We show administrators how to change a route and reference data without a developer, and we document the regulations.
What we check before handover
We separately run through the scenarios that break systems most often: approval when an employee is absent, withdrawal of a document from the middle of a route, resubmission after rejection, rights to view someone else's document. Each such path must end predictably — with no "stuck" tasks in anyone's list.
Handover
We deliver the configured system, documentation on routes and roles, and instructions for administrators and users. After handover, routes can be changed by the internal team — without contacting us for every change in regulations.
What the customer receives after implementation
Implementation is considered complete not at the moment of launch, but when the customer's team can independently change routes, add roles, and connect new systems without us.
That is why we hand over not a "working portal," but a package that allows the system to be developed further and transferred to another contractor.
- Approval route configuration — exportable process schemas: branching by amount and document type, parallel and sequential stages, deadlines, escalations, automatic assignment of approvers based on the org structure. Routes are described declaratively; editing an approval flow does not require rewriting code.
- Access matrix — a "role → object → action" table with levels: read, edit, approve, administer. We separately document the visibility rules for attachments and the delegation of rights during an employee's absence.
- Integration modules — adapters to the accounting system, HR system, email, and file storage: reference data synchronization, status export, notifications. Each module includes an exchange log and retry on connection failure.
- Support regulations — the procedure for releasing changes, backup and recovery verification, incident response, and planned maintenance windows.
- Instructions for users and administrators — role-based scenarios: how to create and approve a document, how to restore a deleted item, how to add a new employee and grant them rights.
- Architecture diagram and integration map — what is connected to what, where data is stored, which external services are critical for operation.
- Acceptance protocol with test scenarios — a list of checks performed on the customer's real data, with results for each item.
We transfer the package to the customer's repository along with the change history: it is clear what changed and when in routes and rights. Describe your approval workflow — we will get back to you with an estimate and a handover plan.
Case: cutting the approval cycle by two-thirds
The client is a manufacturing holding with a distributed structure: four sites, its own legal and financial department, and a flow of contracts — supply, contracting, lease, supplementary agreements.
Before implementation, approval went through email: the lawyer received a file, made edits in track changes, sent it back, and the initiator merged versions manually.
A full round took 9 business days, and at every step the history was lost — who approved which specific revision and when.
What we changed
We deployed an electronic document management system based on an ECM platform with a configurable approval route.
The contract card pulls details from counterparty directories rather than from manual entry: the initiator selects the contract type and the party — the fields are populated automatically.
The route is built by rules: the amount and type determine whether the document goes to financial control and whether a lawyer's sign-off is needed based on the template or on non-standard terms.
Parallel approval replaced sequential approval: the lawyer, the finance specialist, and the department head receive the task simultaneously rather than waiting for each other.
Edits are recorded as versions in a single card — there is no longer any need to merge files manually, and the system keeps track of which revision was sent for signature.
Metrics before and after
| Indicator | Before | After |
|---|---|---|
| Contract approval cycle | 9 days | 3 days |
| Share of manual entry of details | 100% | 20% |
| Lost document versions | regularly | 0 |
Cutting the cycle delivered more than just speed: a whole class of errors disappeared, where an outdated revision went for signature and disputed edits surfaced only after approval.
Automating routes and directories removed the routine from the lawyers — they focus on terms rather than on forwarding files.
How ECM differs from BPM and what to choose
ECM and BPM solve different problems, although in practice they are constantly confused. ECM is document management: storage, versioning, access rights, search, retention periods, approval routes around the document itself.
BPM is business process management: the sequence of steps, performer roles, branches, timers, deadline control at each stage. A document in BPM may be just one of the process objects, while in ECM a process is just one way to handle a document.
The difference shows up at the starting point. If the pain is that contracts get lost, versions get mixed up, and approvals happen over email — you need ECM: a single repository, document cards, role-based rights, search by attributes and full text, automatic versioning.
If the pain is that a request goes through seven approvers and it's unclear who it's stuck with — you need BPM: a process diagram, statuses, escalations, analytics on bottlenecks.
In practice, most tasks are hybrid. A contract lives as a document (versions, signatures, archive), but its path is a process with branches: up to a certain amount one manager approves it, above that — the legal department and finance are added.
That's why mature systems don't pit ECM and BPM against each other, but build a single core: a document repository over which a process engine runs, with rights and routes inherited from the document card.
The choice starts not with technology but with an inventory: what comes first — the object of storage or the sequence of actions. If there are many processes and they change often, BPM becomes the core, and documents are connected as attachments and templates.
If order in documents comes first, ECM becomes the core, and processes describe typical approval routes. A hybrid system is justified when both circuits change regularly and cannot be split across different products without losing traceability.
The key sign that it's time to build a hybrid: end-to-end requirements appear — for a document you need to see the history of all actions, and for a process you need to see all related files and versions.
Then a single data model is cheaper than two disconnected systems that are synchronized manually. We start with a process map and a document registry, and only then choose the core architecture — that way the solution doesn't have to be redone a year later.
Common technical doubts before starting
Before starting, almost every team asks the same set of questions: what to do with an already deployed system, where to put the paper archive, and whether anything needs to be added for the industry. Below are answers to the point, without generalities.
We already have a deployed system. Will we have to throw it away?
No. We start with an assessment: we look at the data schema, reference data, approval routes, access rights, and the volume accumulated. Then we build a migration plan — what is transferred as is, what is moved into the new model, and what is archived read-only.
We migrate in stages, with backward compatibility during the transition, so people work in familiar cards while the restructuring is underway. Rollback is possible at every step: the old contour remains available until the new one is confirmed on the live flow.
What should we do with the paper archive — scan everything?
Scanning everything indiscriminately is usually unnecessary and expensive.
First we divide the holdings: documents with an active retention period and legal force are digitized in full, with recognition and linking to cards; the reference and closed archive is left in the inventory — a register with address-based storage is enough for it.
This way the volume of scanning drops severalfold, while a document can still be found within minutes.
Is customization needed for our industry?
Almost always — yes, but targeted. Industry specifics sit in three places: approval routes, the composition of the card, and access rules.
These are configured on standard mechanisms, and we write code only where non-standard logic is needed — calculations, checks, exports to industry systems.
Integration with the accounting contour, the HR block, and external services goes through documented interfaces, so that platform updates do not break the connections.
How are security and access segregation ensured?
Access is built by roles and departments, down to an individual field in the card: an employee sees only their own area, a manager sees their own block, and the audit logs every opening and edit.
Electronic signature, action logs, and channel encryption cover the security service's requirements. Rights are checked at the implementation stage, not after launch.
Describe your situation — what is already in place, the volume of the archive, and where logic is lacking. We will come back with an estimate and a work plan.
Let's discuss your document management task
To make the conversation substantive rather than "tell us about ECM in general," it's enough to describe the current process: who creates which documents, what approvals they go through, where time is currently lost, and at which steps they most often get sent back for revision.
If there's an accounting system, email, or network folders around which document management revolves, name them — the integration scheme and the scope of data migration depend on this.
In response, you'll get not general words but a working plan: an approval routing scheme, the composition of reference data and roles, a list of integrations, implementation phases, and a timeline estimate.
We'll separately show what will be included in the pilot — usually one or two real processes with a limited group of employees, to validate routing logic and access rights before scaling to the entire company.
- Analysis of the current process: route map, participants, bottlenecks, document volume per month.
- Solution design: roles and rights, statuses, templates, numbering and storage rules.
- Integration plan with the accounting system, email, and file storage.
- Pilot composition: which processes and departments go first, how we measure the result.
- Work phases with timeline estimates for each and acceptance checkpoints.
- Infrastructure requirements and deployment options — at your site or on dedicated capacity.
- Plan for migrating existing documents and training employees.
- Post-launch support terms: updates, enhancements, user support.
Describe the task in whatever form is convenient — a short email, a process diagram, or a list of requirements. We'll come back with an estimate, a work plan, and a pilot proposal so you can evaluate the approach on a real process rather than a presentation.
