ECM/EDM for organizations: questions about integration and archiving

Start by clarifying the problem, not product names

People often begin choosing an ECM/EDM with names: Directum, Docsvision, 1С:Документооборот. But if you don’t agree on goals first, it’s easy to buy a system that looks great in a demo but fails to solve daily issues in real work.

Describe the current situation without generalities. Where does a document live before signing: email, messenger, folders on a network drive, an Excel register? What exactly consumes time: searching, gathering approvals, meeting deadlines, preparing reports, or moving documents to the archive?

A practical trick: pick 2–3 key document types and trace their path from creation to storage. For example: a supplier contract, an invoice, an HR order, or a citizen’s appeal. You’ll often find the pain is not “document flow in general” but a specific bottleneck: versions lost, unclear status, or no quick way to find the final copy.

To capture the task, discuss these questions with your team and the integrator:

• What risks are unacceptable: leakage, tampering, version loss, missed deadlines?
• Who is responsible for the document at each step and where does responsibility get blurred?
• Which deadlines are critical and how should the system remind about them?
• What should a manager see in one click: statuses, overdue items, workload?
• How will we measure success in 3–6 months: search time, share of approvals without email, number of missed deadlines?

When goals and success signs are clear, comparing platforms is simpler: you verify how they support your real processes, not their promises.

Users, roles and daily scenarios: what must work every day

Projects usually fail not because the system lacks features, but because departments work differently. Agree in advance who actually needs the EDM and what people do daily: create documents, approve, sign, search the archive, prepare inspection reports.

Start with groups: leadership, accounting, legal, HR, IT, records, branches. For each group record roles, not job titles. One person often has two roles, for example “creator” and “approver”.

Ask practical questions:

• Who creates documents and who only reads or comments?
• How many approvers in a typical process and who substitutes absent approvers?
• Are external participants needed (contractors, partners, citizens) and what can they see?
• Which clients will people use: web, mobile, office workstations?
• Is a bilingual interface needed (for example Russian and Kazakh)?

Example: legal prepares a contract, accounting checks details, a manager approves, and a branch should see only the final version and only their contracts. If you don’t describe this in advance, access rights and routes will be set “by eye” and users will return to email and messengers.

Appoint an administrator (IT, records or a dedicated employee). This determines the speed of changes and control over access.

Approval routes: questions to resolve before configuration

Routes are often the source of conflicts after go-live: the system seems to “work incorrectly” when rules simply weren’t agreed. Describe 3–5 common processes and agree which steps are mandatory.

Start simple: which documents are approved daily (contracts, invoices, orders, purchase requests), who initiates, who checks and who signs. If there are dozens of processes, focus on those with the most delays and errors today.

Be honest about which processes can be adapted and which cannot. For example, regulations may require legal and security sign-off—those steps shouldn’t be skipped for convenience. Parallel approvals, however, are often more flexible.

Answer these before setup:

• Which 3–5 routes go first and what is a successful outcome (time, quality, no returns)?
• Which conditions affect the path: amount, counterparty, branch, document type, presence of attachments?
• Where is parallel approval needed and where strict sequence (e.g., finance after legal)?
• How are deadlines set: per-step deadlines, reminders, escalation to a manager on overdue?
• How does the approval history look: who approved and when, what comments were left, who can see this?

Example: a 2 million contract goes to legal, then CFO, then branch director; a 200 thousand contract only needs legal and the department head. If this rule is not fixed, employees will ask for manual approvals in messengers and the EDM loses its purpose.

Also clarify what counts as the final version: can the file be changed after approval, how are edits recorded and who can send the document back for revision.

Integrations: how to avoid manual entry and data splits

If the EDM lives separately from ERP, accounting and mail, staff will start copying data by hand. The result: different amounts in different places, lost attachments, and contract versions scattered across folders.

First list systems that require integration: typically ERP/accounting (invoices, contracts, counterparties), HR (staff, org chart), CRM (clients and deals), corporate mail and calendar.

Then specify which data is synchronized and where. Example: a contract card is created in ERP, while the EDM is used for approvals and stores the final signed file. Decide in advance which fields are bidirectional: number and date, amount, status, file links, approval participants.

Define the single source of truth. Reference data usually has one owner: counterparties in ERP, employees in HR, org structure in AD or HR. For documents decide where the original file is stored and where only metadata lives.

Ask the integrator:

• What events trigger exchange: card creation, status change, signing, closing?
• What happens on error: retry, queue, notification, log, reaction time?
• Who handles failures: IT, process owner, integrator, and how is this recorded?
• Network and security constraints: segments, VPN, service accounts, permissions?
• How is data quality controlled: duplicates, required fields, matching rules?

A good sign is when IT and the business discuss integrations together: data exchange is not just a “pipe” but daily working rules. If you need help defining architecture and security tasks, system integrators such as GSE.kz involve specialists before the pilot so you don’t hit constraints at the start.

Archive and storage: questions about retention, search and recovery

The archive often becomes where legal, security and auditors’ requirements surface. Lock these down before setup; otherwise you’ll later move documents and change rules.

Ask about retention and immutability

Decide which document types go to the archive automatically and which only after case closure. Clarify who sets retention and what the “start event” is (signing, registration, contract closure).

Check:

• Retention periods by document type and what happens afterward: deletion, extension, transfer to long-term storage.
• Whether immutable copies are required (WORM logic), edit prohibitions and version control rules.
• How actions are recorded: who changed a card, who downloaded a file, who approved.
• How to export for audits: document packages, registries, history.

Metadata, search and recovery

Define metadata: file classification, indexes, tags and relations between documents (contract, amendments, invoices). Fields should be filled from reference books and rules, not free text.

Check search: by requisites, full text, attachments, participants and change history.

Discuss backups and recovery: RPO/RTO, recovery tests, where copies are stored, and what happens on deletion or database failure. For a hospital or government body in Kazakhstan it’s often critical to restore the archive within hours, not days, and to prove a document hasn’t changed after signing.

Access rights and audit: what must be traceable

Rights break down mostly because rules weren’t agreed. Choose a model that matches your work: roles (legal, accounting, HR), org structure (departments), projects (teams and project folders), secrecy labels and confidentiality levels.

Clarify access granularity. Sometimes you must hide not the whole document but parts: attachments (passport scans), card fields (amount, personal data), or tabs with approval history. If the system can’t do that, you’ll need to change the process or accept the risk.

Define who grants rights and how often they’re reviewed. A practical approach: rights owners by area (HR, finance, procurement) and regular reviews on transfers and terminations.

Audit isn’t “for show” but for incident investigations and inspections. Minimum requirements to demand:

• who opened the document and when
• who downloaded or printed it
• who changed the card or file and what exactly
• who approved, rejected or signed it
• who granted or revoked rights

Discuss complex cases with examples. A manager is on vacation and a contract must be approved today: how does substitution work, who assigns the deputy, for how long, what happens to rights after that, and is there a log entry?

Incoming documents and scans: from paper to a manageable process

If you still have many paper letters, contracts and appeals, ask not only about “scanning” but about the full cycle: from receipt to response and finding a document a year later. Typically this is a chain of registration, scanning, OCR and routing.

Decide where a document first appears: registry, reception, shared e-mail, portal, courier. The system must record date and source and then indicate who owns the document and the response deadline.

Scanning, OCR and quality

Clarify device support (scanner, MFP), whether you need bulk scanning and OCR. Recognition errors break search and auto-population, so set quality requirements: for example 300 dpi, rules for stamps and signatures.

Agree formats: PDF/PDF-A for archive, TIFF for scans, JPEG/PNG for attachments, and office formats (DOCX, XLSX). Also clarify conversion and compression behavior.

Linking originals and electronic copies

Paper originals should have a clear anchor: barcode on the first page, case number, physical storage location (cabinet, archive, branch). Clarify electronic signatures: are they required at registration, during approval or only for final sign-off?

Five quick questions that reveal gaps:

• How does the system link a scan to the paper original and who marks it (barcode/sticker)?
• Can the system recognize a counterparty, contract number or ID from a scan and fill the card?
• What counts as an incoming item and which routes apply: letter, citizen appeal, act, invoice?
• How are response deadlines and executor changes handled if somebody is on vacation?
• Can you quickly assemble a full case package: letter, resolution, attachments, reply and reply versions?

Infrastructure and performance: what to ask IT and the integrator

Even a good system irritates users if search is slow, attachments take long to open or it “crashes” at peak times. Before choosing a platform agree expectations and responsibilities: your IT, the integrator or the infrastructure provider.

First block — deployment: on-premises, cloud or hybrid. Ask for an explanation using your specifics: data residency limits, local storage requirements, branches with poor internet and scaling needs. Clarify backup and recovery plans: acceptable downtime and data loss.

Next — speed and bottlenecks. Take typical actions and agree how they’ll be measured:

• Search by fields and full text — seconds for a database of N documents.
• Opening a card and viewing attachments (PDFs, scans, large files).
• Peak load — simultaneous users and operations during the busy hour.
• Where DB and files are stored — single or separate stores (active vs archive).
• How indexing, cache and permissions affect search.

Discuss operation: who updates the system, how compatibility is checked, monitoring and whom to contact on failures.

Don’t forget workstations and network: required PCs by role, scanners, inter-office channels, and how security policies (antivirus, USB restrictions, proxy) affect the client.

If you plan infra upgrades, estimate required servers and workstations in advance so you don’t hit a hardware bottleneck after the pilot.

Step-by-step implementation plan: from requirements to go-live

Start not with “Directum or 1С” but with an inventory of reality: which documents circulate, where they originate, who approves, where delays occur and what must end up in the archive.

Agree on a single “dictionary” of fields: number, counterparty, contract, cost item, project, retention. If departments call the same fields by different names, search, reports and integrations will constantly diverge.

A typical scheme:

• Describe 3–5 key processes and their documents, assign owners.
• Agree reference books and mandatory fields; define the source of truth.
• List integrations (mail, ERP, accounting, HR, e-signature, scanning) and assign owners.
• Build a prototype for 1–2 processes and run them with real cases.
• Run a pilot with one group, train users and roll out step by step with a schedule and metrics.

A mature project shows pilot success criteria in advance. Examples: “a contract goes through approvals in 3 days instead of 10”, “no manual entry of counterparties”, “a document is found in the archive within a minute”.

Common mistakes when choosing Directum, Docsvision, 1С and similar systems

The most common issue is a beautiful demo process that fails in real life. In demos everyone approves in three steps, while real work has returns, replacements, urgent edits and parallel branches.

Typical mistake — describe only the ideal route and forget exceptions. What happens if legal returns a contract for revision while the creator has already sent a new version? Where is the previous version stored? Who sees edits? Can you block approval of an outdated file?

Often access rights are postponed “for later”. As a result rights are fixed by hand, shared folders “for everyone” appear and audit becomes formal. Better to agree principles up front: roles, confidentiality levels, contractor access and temporary substitutions.

Reference books are another pain. If owners aren’t assigned (who is responsible for counterparties, departments, contracts, nomenclature), duplicates quickly arise: “TОО Romashka”, “Romashka TOO”, “Romashka LLP”. Integrations fail and reports diverge.

Archive and retention are also remembered only at migration time. Decide in advance: what to migrate, what to leave in the old system, which metadata are mandatory, how to search, how to recover and who accesses the archive.

Short checklist before signing the implementation contract and go-live

Before signing, document key points in writing. This saves weeks of approvals and reduces the risk that the system will “sort of work” but not solve daily tasks.

Start with initial processes — not the entire flow but 3–5 concrete scenarios: contracts, incoming mail, requests, memos. Each process must have a business owner who makes decisions and confirms results.

Then check integrations: where reference data and fields come from (counterparties, departments, contracts, invoices), who is responsible for data quality and what to treat as the source of truth when values differ.

Agree archive rules before start: retention by type, search requirements, export format, backups and recovery procedures.

Attach to the contract:

• List of initial processes and owners, plus responsibility boundaries between integrator and customer.
• Integration map: data sources, exchange frequency and post-launch support owners.
• Archive: retention, search, backups, recovery and availability checks.
• Roles, access matrix and action audit (who viewed, changed, approved, exported).
• Support and SLA: hours, channels, response times, infrastructure and monitoring requirements.

Include a pilot with acceptance criteria: approval times, share of manual entry, correctness of rights, and successful restore from backup.

Example scenario: approving a contract without losing versions

A purchasing contract is prepared by the initiator, then reviewed by legal, finance and a manager. In practice the file goes by email: one edits in Word, another adds comments, a third sends the “final” version, and after a week nobody knows which version is correct or who delayed approval.

In an EDM this is solved with a single document card that stores the contract file, versions, statuses and the list of approvers. The route is predefined: who approves, in which order, deadlines and what counts as “approved”. If someone misses a deadline the system records the delay and notifies those responsible.

Edits are preserved: a new revision becomes the next version and the history shows who changed the file, who left comments and where the document got stuck.

At pilot stage check not the UI polish but practice:

• is there integration with the accounting system to avoid manual entry of counterparties and amounts?
• do access rights work: initiator sees their items, legal sees required contracts, others are restricted?
• can you quickly find a contract by number, amount, counterparty and status?
• is a full version and action history preserved?

A normal pilot outcome: fewer manual forwards, fewer errors in requisites, clear deadlines and transparent responsibility.

Next steps: how to evaluate and prepare for implementation

To have a focused discussion with an integrator, pick 15–20 questions from this memo and run a workshop with IT, records, legal, security and 1–2 managers who frequently approve documents.

Ask to demonstrate processes not on demo cards but on your real documents. Bring a typical contract, a memo and an incoming letter: it’s important to see versions, comments, deadlines, search and archive behavior with real data.

To avoid endless debates, fix the project scope in advance:

• which integrations are included (mail, AD, 1C/ERP, e-signature, scanning)
• what we do with the archive and storage (retention, formats, recovery)
• whether old folders/network drives will be migrated and quality rules
• training and support after go-live
• pilot success metrics (approval time, share of manual entry)

Also check infrastructure: are current servers, disks and backups sufficient, and how will the project handle user and attachment growth in 1–2 years?

If you need a single contractor to handle system integration and pick infrastructure for load (servers, workstations, support), integrators like GSE.kz (gse.kz) typically cover this scope, especially when security and supply-chain transparency matter.