Programme governance · FLO Group · 2025 – 2026
18 initiatives through one gate, onto one platform
Back-office work in the group sat in separate tools, mostly manual and hard to trace.
In short
Situation: Approval, invoice, request and HR processes in four group companies and about 600 stores ran in different tools, mostly by hand and with little traceability. Every department had a digitalisation wish, and none had a route to getting it built. Decision: One internal platform, one way in. Every request matured in a written document before it reached a decision gate. Prototype before build, MVP before full scope. Integrations sat behind interfaces, and an AI-agent layer took over the steps that repeat. Result: 18 initiatives delivered on one platform, across HR, finance, procurement, logistics, store operations, marketing, employee experience and PLM. About 1,500 users in four companies. Approval time fell from ~5 days to ~1 day, ~3,000 requests a month run through the platform, and 12 paper forms were retired. My role: Product owner on the IT side: request maturation, scope freeze, prototype alignment, phasing, integration design.
- My role
- Product owner · IT
- Period
- 2025 – 2026
- Scale
- 4 companies · ~600 stores · ~1,500 users
- Key figure
- 18 initiatives · 8 business areas
Situation and complexity
The group digitalisation programme runs on the group's internal platform for back-office processes. When I took over product ownership, there was no shortage of demand: HR, finance, procurement, logistics, store operations, marketing and others all had digitalisation requests. They arrived as wishes, with no scope, no data owner and no agreed definition of done.
The cost was large, and invisible. Expense forms, shipping requests, travel approvals and exit interviews lived in email threads and spreadsheets. It was hard to tell how long an approval took, because no system recorded it.
- Recognition system
- Exit feedback
- Salary advance & instalments
- Performance / OKR
- Gamification for store teams
- Expense & invoice forms
- Energy invoices (AI reading)
- Brand invoice settlement
- Business expense advances
- Overseas payments
- Freight invoices
- Procurement platform
- Corporate shipping platform
- Store camera analytics
- Campaign management
- Travel & off-site assignments
- Approval flows
- PLM and accounting integration
SAP · SuccessFactors · internal employee apps · supplier portal · Power BI · OCR/AI · AI cameras
The programme started where transaction volume was highest, in finance and logistics. The HR initiatives were handled together because every one of them connects to the same employee data.
Options on the table
- Buy a workflow suite and configure everything
Rejected for the core. The group's processes, with four companies, Turkish tax rules and SAP cost centres, would not fit a generic suite without heavy customisation. That customisation would have become the real product anyway.
- Build each request as its own project
Rejected. Eighteen separate projects would have meant eighteen integrations with SAP and SuccessFactors, and eighteen ways to log in.
- One platform, one governance model, many initiativesChosen
Identity, integrations and the approval engine are shared, and there is one way for a request to become a product.
The decision and how it was organised
- 01 · RequestA business unit writes its needFree form; no scope yet.
- 02 · MaturationRequest-maturation documentBusiness problem, scope boundary, integrations, open questions, acceptance criteria.
- 03 · Decision gatePrioritised as a business requestImmature requests go back; nothing enters the queue early.
- 04 · PrototypeVersioned prototypeDozens of screen versions before any code is written.
- 05 · MVPMost valuable slice goes liveThe rest is written into named phases.
- 06 · Next releasesIntegration and scaleExternal systems behind adapters; reporting; AI steps where they pay off.
The programme rested on a single path for every request. A business unit wrote down its need, and the need became a request-maturation document: the business problem, the scope boundary, the integrations, the open questions, the acceptance criteria. Only then did it reach the decision gate, where it was prioritised as a business request. An immature request went back and never entered the development queue.
After the gate, the discussion moved from slides to a versioned prototype. A screen could go through dozens of versions before it was built. That is cheap; the same changes after build are not. The first release took the most valuable slice and the rest went into named phases, so nothing was forgotten and nothing bloated the MVP.
Integrations were designed as interfaces. In the corporate shipping platform the carrier sat behind an adapter, so a new carrier contract never meant a new platform. The store-camera initiative did the same with the camera vendor, placing it behind an event layer so that the notification logic does not depend on it.
Last came a layer of autonomous AI agents that carried the repetitive steps of a process all the way through, from opening a request to routing the approval and reporting on it. I presented this layer at TRAI Meet-Up #102 in February 2026 under the title “End-to-end enterprise processes with autonomous AI agents”.
One example from the programme is the corporate shipping platform. Stores, warehouses and head-office departments needed one way to request, approve and track corporate shipments, including those to supplier addresses. Nineteen business rules were written and approved before development started. The design had three roles and one approval flow, with the carrier connected through an adapter. Invoice reconciliation, the most requested feature, was held back from the first release because it needed data owners who did not yet exist. Leaving it out let the platform go live earlier.
Result
Figures are approximate; process times were measured per initiative.
Public record: Talk: TRAI Meet-Up #102, 18 February 2026
What went wrong, what I learned
Intent: Take every initiative through the same gate at the same speed.
What went wrong: In one initiative, the business rules and the technical specification described the approval chain differently, and the differences surfaced later than they should have. Closing them one by one cost time.
What changed afterwards: A contradiction list became a precondition for the decision gate instead of something found after it. The maturation document also began asking who owns the data before anything was built.