Holding Administrative Platform
- Type
- Enterprise case study
- Employment context
- Former employment, delivered with teams
- Employer
- Tarım Kredi Teknoloji
- Period
- April 2023 – April 2026 (period of employment)
- My role
- Led product direction and delivery on the employer side: harmonising subsidiary needs, roadmap and module prioritisation, MVP scope, and coordination of the UAT, pilot and live stages.
- Domain
- Corporate Administration
- Team
- Designed, built and tested by the in-house software, analysis and testing teams, with requirements from administrative units across the group's companies.
- Evidence
- Figures are drafts awaiting approval. No screenshots or internal architecture details are shown.
Enterprise project undertaken during my employment. The platform is owned and operated by the respective organisation; my contribution is described below.
This is a case study of an enterprise administrative platform shared by the companies of a holding group, delivered through Gönenç Türkekul's former employment at Tarım Kredi Teknoloji. The platform brings document management, attendance, legislation, meetings, inventory and employee self-service into one place. The page explains why scattered tools were consolidated, how the needs of many companies were turned into one roadmap, what the team built and his specific role in product direction. The platform belongs to the group, not to him.
A group of many companies
The Tarım Kredi group includes 17 subsidiaries, each with its own administrative routines: documents, attendance, meetings, inventory and staff requests. The group's technology company, where I worked, builds and runs software that serves these companies. Administrative software is rarely visible from outside, but staff across the subsidiaries rely on it for routine work.
How administration worked before
Administrative processes were spread across different companies, tools, manual methods and separate applications. Each subsidiary could handle the same task in its own way, and the technology team had to maintain several applications that did similar jobs. That made consistency between companies hard to achieve and kept much routine administrative work manual.
The problem to solve
The group needed one platform that every subsidiary could use for routine administration, while still respecting real differences between companies. The challenge was less about building forms and more about agreeing what should be shared, what could vary and in which order modules should arrive. Staff in every subsidiary, and the teams supporting them, were affected.
What the platform covers
The team built a centralised enterprise platform with modules for document management, attendance, legislation, meetings, inventory and employee self-service. It also became a base for later products: the group's business process management platform was built on top of it. The state of individual modules and the internal architecture are not published here.
Capabilities in scope
- Document management
- Employee attendance
- Legislation tracking
- Meeting management
- Inventory
- Employee self-service
My role and the team's
The modules were designed, built and tested by the in-house software, analysis and testing teams, with requirements coming from administrative units in many companies. My part was to analyse and harmonise what the subsidiaries needed, turn that into one roadmap, and decide which modules and features came first, based on efficiency and shared value.
My part
- Analysing and harmonising needs across the subsidiaries
- Product vision, roadmap and module prioritisation
- MVP scope and phased transitions through UAT and pilot
- Requirements governance and prioritisation with senior management
The team’s part
- Module design, development and testing
- Requirements analysis and documentation
- Business input from administrative units in each company
- Support and maintenance
Trade-offs and constraints
Many companies sharing one platform means competing requests. We had to decide which needs were common enough to build once, which differences to support and which requests to defer. Requirements were gathered and documented to a shared standard so decisions could be traced. Phased delivery meant modules could reach users in stages instead of waiting for a complete suite.
Coverage and intended value
Figures from the sources
17
Group companies
~22,000
Users
Draft awaiting approval
- Documented coverage
- Used by 17 group companies and approximately 22,000 users, according to the published site and CV.
- Intended value
- one platform in place of distributed applications, more consistent administrative processes between companies, lower maintenance and development effort for the technology team, and less routine manual work for staff.
What I learned
A shared platform is a governance decision before it is a technical one. The hardest work was agreeing what all companies would share. I learned to make those agreements explicit early, with a clear owner for each requirement, because a common platform without common rules soon drifts back into separate tools.
.jpg){kind=link}
The case in four stages
- BeforeEach company handled administration with its own mix of tools, manual steps and separate applications.
- DecisionConsolidate routine administration into one shared platform, introduced module by module.
- SystemA central platform with modules for documents, attendance, legislation, meetings, inventory and self-service.
- ChangeCompanies share one administrative base, and later products such as the BPM platform build on it.
Drawn route of the case. The platform belongs to the organisation, so no screens are shown.
Technical, operational and managerial
Technical
The platform was built as a set of modules on a common base, so new administrative areas could be added without starting again. That base also carried later products, such as the business process management platform. The specific stack and integration details are not published here.
Operational
The modules cover routine work that every subsidiary has: managing documents, recording attendance, following legislation, organising meetings, tracking inventory and letting employees handle their own requests. Bringing these into one place lets the companies follow the same processes.
Managerial
This is where my role sat. Many companies brought different priorities, so I analysed and harmonised their needs, set a single roadmap and agreed priorities with senior management and subsidiary managers. Requirements were managed to one standard so that decisions stayed traceable.
Questions answered
Why consolidate distributed admin tools?
Separate tools for the same job mean different processes in each company, duplicated maintenance and little shared data. One platform lets a group define a process once, maintain one system and improve it for everyone. The trade-off is that companies must agree on shared rules.
How do different companies share one platform?
Through a common base with modules. Needs that all companies share are built once, and differences are handled within agreed limits. The detailed configuration model is not published here; the principle was to agree what is common before building.
How did the team manage competing requirements?
Needs from the subsidiaries were analysed and harmonised into one roadmap, prioritised by efficiency and shared value, and documented to a common standard. Priorities were agreed with senior management and subsidiary managers rather than decided request by request.
What was Gönenç Türkekul's role?
He led product direction on the employer side: harmonising subsidiary needs, setting the roadmap and module priorities, and coordinating phased delivery. The in-house software, analysis and testing teams built the platform, which belongs to the group.
Facing a similar change?
If your organisation is planning a change like this one, I am glad to talk it through.