Attila Koós — Lead Business Analyst

Case files

Case file / 01 — founder

From a post-it to a 14-year platform

STUDIOBP × Biohair franchise network · 2012 — present

Problem: An expanding franchise chain ran on isolated, island-like IT. The entire brief fit on one post-it: "show me revenue. warehouse. expenses." Salons had unreliable internet; staff had no time for training.
Approach: Discovery through leadership interviews and on-site shadowing in salons. Architecture built around the constraints: an offline-first thick client with an asymmetric sync model — production data flows up nightly, master data flows down at every start — eliminating data conflicts by design. The same channel doubles as the update pipeline. Two deliberately different interfaces: a radically simple salon floor UI and a full ribbon-based central console.
Outcome: A salon-management ERP — product master, revenue and expenses, invoicing, warehouse and central ordering, loyalty, training — that scaled from ~20 to ~50 salons and still runs today in 35, with 150–250 daily active users and thousands of guest transactions a day. The client relationship has been continuously live for 14 years.

35 salons live today150–250 daily usersoffline-first sync14-year retention

Live demo — the architecture decision InternetON

SALONserving guests

production data ↑ nightly master data ↓ at every start

HQprices · products · updates

Both channels open. Conflicts impossible by design — each side only writes what it owns.

The venture chapter

We spent 2012–2017 trying to scale the platform nationally. After nine months of negotiation, our funding round was scheduled for signature on the morning our investor's brokerage collapsed — the round never arrived. We regrouped on a smaller angel investment, reached verbal agreements with L'Oréal and Schwarzkopf on salon-level sell-out visibility (something the industry still struggles to see), and ultimately chose depth over scale. The product — and the client — stayed. The lesson stayed too: never build a critical path on a single funding source.

Case file / 02 — archaeology

Reading systems nobody documented

EPAM (Broadridge × UBS) · 2018–19 — and Vodafone · 2022

Problem: Two flavors of the same enterprise reality. At a global wealth-management program: a working monolith data platform had to move to microservices, but beyond user stories there was no documentation — only code. At Vodafone: a legacy network-infrastructure database (~500 tables, thousands of entities, stored procedures, custom ETL) had to be understood before it could be replaced.
Approach: As the sole BA in a 15-person squad, I built the analysis from the source itself — reading procedures, tracing data flows, leading discovery meetings in a client environment where the same question could not be asked twice. At Vodafone, structured deep-dive interviews with engineers reconstructed what the schemas alone couldn't tell: stakeholders, processes, data — in that order.
Outcome: At EPAM: several hundred procedures mapped and documented within a year, in parallel with new development — the analytical foundation of the migration. At Vodafone: the complete AS-IS picture with every data extraction interface identified, de-risking the replacement program before it began.

hundreds of procedures mapped~500 tables reconstructedsole BA / 15-person squad

-- proc RECALC_POSITION · no docs, no author, called nightly by JOB_47
UPDATE positions SET value = base_amt * fx_rate * adj
WHERE  batch_id IN (SELECT id FROM staging WHERE state = 'P');
-- ↑ the one line that explained three years of reporting drift
-- (illustrative reconstruction — the real ones are under NDA)

brush to excavate · double-click to clear

Case file / 03 — the uninvited proposal

The replatforming nobody asked for

KPMG — Marketplace VAT platform · 2019 — 2021

Problem: A monolith portal calculating EU VAT positions for thousands of Amazon EU sellers — 100,000+ transactions a month and growing. My brief was BAU development. But the day-to-day change requests kept hitting the same walls: the same bottlenecks, the same workarounds, the same data-access layer straining under load. Nobody had asked anyone to look at the pattern.
Approach: I ran a GAP analysis on my own initiative, built from the recurring BAU patterns — then put a full replatforming proposal on the table. Co-designed the modernization plan with the lead developers: critical business bottlenecks identified first, phased extraction of the most critical functions behind APIs, replacement of the underperforming data-access layer. Then I produced the complete backlog and roadmap to execute it.
Outcome: Proposed, designed and roadmapped — honestly stated: my engagement ended in an organizational restructure before I could see delivery begin, so the execution story belongs to those who came after. What this case proves is the part that can't be assigned: seeing the structural problem in the daily noise, and doing the architecture work nobody asked for. The same pattern I'd run at my own company — and would run again at MOL.

thousands of active sellers100,000+ transactions / monthself-initiated GAP analysisfull backlog + roadmap

Live demo — the pattern in the noise

root cause: data-access layer under load root cause: monolith coupling everything else TCK-4211 · timeout on monthly VAT recalculation (DE sellers) TCK-4198 · new country onboarding requires a code change TCK-4187 · duplicate rows after bulk transaction import TCK-4172 · date format wrong on seller dashboard TCK-4169 · deadlock during nightly batch run TCK-4155 · rate table update needs a full redeploy TCK-4149 · report export slow above 50k rows TCK-4140 · memory spike in the import job

Eight tickets, eight separate fixes. Business as usual — until you look at them together.

illustrative tickets — the pattern is the point

Case file / 04 — the common denominator

An admin platform, three vendors, one shared understanding

MOL Campus · 2023 — present

Problem: A brand-new headquarters with 10+ digital services — parking, smart lockers, signage, service booking — each with its own administration, running on 10+ integrated subsystems, delivered by three separate code vendors (frontend, backend, data). Specifications had to survive three different interpretations.
Approach: I designed the Campus Platform Admin UI — the umbrella application consolidating every service's administration into one interface — and grew from requirements into solution-architecture decisions: data models, storage structures, source selection, job scheduling for the central sensor data warehouse. To keep three vendors on one page, I built a specification method around working prototypes: AI-assisted drafting with strict human validation, clickable HTML prototypes instead of ambiguous documents, API schema analysis before development.
Outcome: The prototype-driven method became the common reference all three vendors work against — a click settles arguments that documents never will. Go-lives of business-critical systems delivered, including a role-management cutover affecting ~3,000 users, with readiness coordinated across every vendor and stakeholder. Lessons from each go-live now feed standing review and approval processes.

10+ subsystems integrated3,000 employees served3 vendors, one methodAI-augmented specs

Live demo — why prototypes win

4.2.1 The system shall provide role assignment functionality for authorized administrators, subject to the approval matrix defined in Annex C. 4.2.2 Upon assignment, the system shall validate persona eligibility against the access-control subsystem within the constraints established in section 3.7, provided that the validation service is available. 4.2.3 Where the persona is classified as visiting employee, parking entitlements shall be granted only where a valid host relationship exists (see 2.4.9), unless overridden per 5.1.2. 4.2.4 The system shall log all assignment events in accordance with the retention schedule (Annex F). 4.2.5 In the event of conflicting entitlements, the precedence rules of table 12 shall apply, except as noted in 4.2.5.1. 4.2.6 The reviewer shall confirm... — three vendors read this. Three interpretations came back.

I read systems nobody documented — and design what replaces them.

What I actually do

System archaeology

Data-deep analysis

Owner's mindset

The Excavation Method

The path

MOL Nyrt. — MOL Campus smart building program

Vodafone · Innoveo

KPMG — tax technology

EPAM — Broadridge × UBS wealth management

STUDIOBP.HU — co-founder

BMA Informatika — Fleet Administrator

Puchner Castle Hotel — Bikal

Case files

From a post-it to a 14-year platform

Reading systems nobody documented

The replatforming nobody asked for

An admin platform, three vendors, one shared understanding

Role management

Toolbox

Analysis & design

Technical

AI-augmented workflow

Delivery & coordination

Background

Education

Languages

Let's talk about the gap in your systems