In many organisations everyone knows by heart how things work. That holds for exactly as long as it takes for someone to leave, for a new system to arrive, or for quotes to be requested from three suppliers at once — and then it turns out there are three different understandings of the same process inside the same house.
Analysis turns that knowledge into a document: what exists today, what has to exist tomorrow, on what basis anyone can say "accepted", and what the developer actually has to build. The same work covers both layers — business analysis ("what problem are we solving") and system analysis ("what the solution has to do").
Estonia's Auditor General, Janar Holm, put this in one sentence about state IT projects that holds just as well in the private sector: "In public-sector information-technology developments there is a significant risk that the client — the owner of the information system — does not itself picture precisely what it wants, and so the developer cannot understand what the client expects of it." (National Audit Office of Estonia annual report "#e-riik", 11 November 2019; our translation from Estonian.)
For us, analysis does not mean a thick specification before the first line of code. It means that the problem, the parties and the basis for acceptance are written down before anyone starts paying to build something whose content is still under dispute.
The decision to automate is usually made by picking a tool. The right order is the other way round: first you need to know which steps in the process repeat, what they cost in time and in errors, and which of them can be handed to a machine at all.
The pre-analysis answers four questions. Which steps of the process are rule-based and high-volume in their present form. Which of those depend on data that is already structured. What the change would do to people's work and to the controls. And what order the ranked list of candidates produces once both payback and risk are taken into account.
The deliverable is a ranked list of candidates together with the assumptions, and with the measures that later let you say whether the automation worked. The same document is a starting point for internal development and for a tender alike, because what is written down is the process, the data and the basis for acceptance, not a product name.
This work is part of the analysis and goes through the same interview as the process mapping. It does not need a project of its own.
Business, functional and non-functional requirements in one place: security, performance, availability, compliance.
Current and target state in BPMN, with bottlenecks, control points and the impact of the change.
User stories with Gherkin-style acceptance criteria — ready for the sprint backlog and test automation.
Architecture Decision Records: what was decided, why, which alternatives were considered, which trade-offs were made.
All deliverables are handed over in editable formats. PDF only means the next analyst starts from zero.
Security requirements are part of the requirements set, not a separate chapter at the end of the document. Who gets access to which data, what is sensitive, what is logged, how long data is kept, and what has to happen when something goes wrong — these questions go through the same interview in which the process itself is discussed. That way security does not first reach the table just before go-live, when changing it is expensive.
The founding analyst has 13+ years of system-analysis practice: an earlier career in banking, telecom, IT consulting and logistics (Swedbank, Telia, Nortal, Riverty, DPD Eesti, ERPLY — the founder's own employment history, not MentiSec client relationships). Qualification: BCS Foundation Certificate in Business Analysis. Working languages Estonian and English.
MentiSec's first won public procurement was business-analysis work for a public-sector institution. In the course of the work, system analysis was added to the original business-analysis scope. That is exactly the pattern our article Süsteemianalüüs vs ärianalüüs: mis vahe on ja kumba teil vaja on describes: two layers of the same chain, usually one and the same person, but two different deliverables.
And one number that always travels with its year: a PMI (Project Management Institute) in-depth report found that 47% of unsuccessful projects miss their goals because of poor requirements management (PMI Pulse of the Profession In-Depth Report: Requirements Management, 2014). It is a self-reported survey and by now more than ten years old — the more telling finding is the second one in the same study: in the weakest-performing organisations, more than half of projects fell short of their goals because of poor requirements management; in the strongest, 11%. That is a manageable variable, not an inevitability.
We write in Estonian first. The pieces below have not been translated yet and open in Estonian.
Each of these is a starting point; we settle its scope in conversation and fix it in a written offer. The steps can be taken separately, or one after another in a logical sequence.
An overview of how things work today, when the answer is spread across several people and several systems. A fixed-scope written deliverable that gives you a ranked list of next steps.
What it includes:
A narrower look at one change or one process, before development or a tender starts. Automation pre-analysis belongs here too.
What it includes:
A complete requirements set you can build from, procure from and accept against. This is the full scope of analysis in one deliverable.
What it includes:
An analyst in your team for an agreed number of days, when the work is continuous and priorities shift. Suits you when what you need is ongoing analysis capacity rather than a single document.
What it includes:
If you are not sure whether you need business analysis, system analysis or both, the answer is usually "both, but in different proportions" — and that can be settled in a single conversation. We reply within one working day, and the first discussion is free.
