Thamsanqa NdebeleModel obligations, not just sales
A prepaid driving lesson creates an outstanding service obligation. The system therefore needs to understand both the commercial transaction and the remaining service delivery.
One operating system.Multiple businesses.
Island Group operates businesses with very different operational models — from prepaid driving lessons to food production, inventory, fleet operations and finance.
The challenge was not simply to digitise each department.
It was to create a shared operational system that could give management control across the group without forcing every division into the same workflow.
- Client
- Island Group
- Sector
- Multi-Industry Operations
- Role
- Systems Architecture & Implementation
- Platform
- Custom Business Operating System
- 2,913
- Active Students
- 8,226
- Lessons Owed
- 40
- Vehicles Tracked
island-group-command-center
The Challenge
One group. Very different operational realities.
Island Group required management visibility across several businesses and operational units.
The driving school manages students, prepaid lessons, instructors, vehicles and branches.
Food and feed production operate around raw materials, production batches, yields and finished goods.
Central stores manage stock used by multiple divisions.
Fleet and logistics operations need vehicle, fuel and operational controls.
Finance needs visibility across the organisation.
These are not simply different screens in the same application. They are different operational models.
The architectural challenge was to create enough shared infrastructure for group-level control while allowing each division to operate according to its own business rules.
Driving School
- Student records
- Lesson balances
- Instructor activity
- Vehicle usage
- Branch operations
Manufacturing
- Production batches
- Raw materials
- Finished goods
- Yield tracking
Central Stores
- Stock levels
- Internal requisitions
- Asset-linked consumption
- Replenishment
Fleet & Logistics
- Vehicles
- Fuel
- Movement
- Operational costs
Finance
- Sales
- Receipts
- Branch cash-ups
- Reporting
Management
- Group visibility
- Branch comparisons
- Operational exceptions
- Decision support
The problem was not a lack of data. The problem was that operational information needed to become part of one coherent management system.
Discovery
Model the operation before designing the interface.
The system was designed around operational entities and events rather than simply reproducing the existing forms and registers used by each department.
The goal was not to build four unrelated applications.
Shared operational capabilities such as users, branches, stores, finance, assets and reporting needed to support division-specific workflows.
This allows management to move between group-level intelligence and the operational detail underneath it.
Group
- Driving School
- Foods
- Feeds
- Logistics
- Central Stores
- Finance
- Fleet
- Users & Permissions
- Reporting
Executive Intelligence
System Architecture
Shared operational core. Division-specific workflows.
01Management
- Executive Dashboard
- Group Reporting
- Branch Performance
- Financial Visibility
02Business Operations
- Driving School
- Food Production
- Feed Production
- Logistics
03Shared Operations
- Central Stores
- Fleet
- Workshop
- Sales
- Finance
04System Control
- Users
- Roles
- Permissions
- Branches
- Auditability
- Operational Statuses
Business architecture — operational layers, not infrastructure.
Workflow 01 — Driving School
Turning prepaid lessons into a controlled operational workflow.
A driving school has a deceptively complex operating model. Students can purchase lessons before consuming them.
Management therefore needs to understand not only revenue and bookings, but the organisation's outstanding obligation to deliver those lessons.
- Student
- Package / Purchase
- Lessons Owed
- Booking
- Instructor
- Vehicle
- Lesson Completion
- Remaining Balance
- 2,913
- Active Students
- 8,226
- Lessons Owed
“Lessons owed” is particularly important because it represents an operational obligation created by prepaid sales. A sale therefore cannot be treated as the end of the workflow — it creates future service delivery that management needs to see and control.
Group driving-school operations Branch-level operational visibility Lesson delivery and outstanding obligations
Workflow 02 — Production
Manufacturing requires events, not just inventory numbers.
Food and feed production require a different operational model. Instead of student balances, the important relationship becomes the movement of material through a recorded production event.
- Raw Material
- Production Batch
- Input Quantity
- Production Process
- Finished Output
- Yield
- Inventory
- 1,000 kg
- Batch Input
- 833 kg
- Batch Output
- 83%
- Recorded Efficiency
This is operational evidence captured by the system, not a claim that the software improved efficiency to 83%. The value is that production performance can be measured from recorded operational events.
Production batch tracking with input, output and efficiency visibility.
Workflow 03 — Central Stores
Shared inventory across the organisation.
Central stores support multiple operational divisions.
The system therefore needs to distinguish between simply knowing what is in stock and understanding where inventory is going.
- External Purchase
- Goods Received
- Central Store
- Internal Requisition
- Division / Branch / Asset
- Consumption
- 69
- Stock Items
- US$9,458.63
- Stock Value
- 1
- Low-Stock Item
These values reflect the store view recorded in the system at the time of capture.
Enterprise stores visibility across stock value, items and replenishment exceptions.
Workflow 04 — Fleet
Vehicles become operational assets, not just a list.
Vehicles support multiple areas of the organisation. The platform models vehicles as operational assets that can participate in workflows across divisions.
- Driving lessons
- Fuel consumption
- Logistics
- Maintenance
- Workshop activity
- Cost tracking
- 40
- Vehicles Tracked
Fleet operations and asset visibility
Management Visibility
Move from records to operational control.
The management layer is designed around questions rather than database tables.
- 01
How many lessons does the group still owe students?
- 02
What is happening at a specific branch today?
- 03
Which production batches are underperforming?
- 04
What stock requires attention?
- 05
What is happening with the vehicle fleet?
- 06
What cash has been reported by branches?
- 07
Where are operational exceptions appearing?
Executive dashboard Branch performance Branch cash-ups Cost analysis
Proof of Work
Inside the working system.
Group Operations — visibility across students, lessons and fleet. Branch Control — local visibility into students, lessons and revenue. Lesson Operations — booking and delivery workflows. Production — batch input, output and efficiency tracking. Central Stores — inventory value, item counts and stock exceptions. Fleet Operations — fuel capture linked to operational assets. Finance Operations — branch cash-up controls. Management Intelligence — cost analysis and reporting. Executive Visibility — group-level operational intelligence.
Systems Thinking
The decisions behind the interface.
Share infrastructure without forcing shared workflows
Food production and driving lessons cannot use the same operational process. But they can share organisational structures such as branches, users, assets, stores, finance and reporting.
Connect transactions to physical operations
Operational systems become more valuable when financial and administrative events connect to what happens in the real world — a lesson delivered, stock consumed, fuel issued or a production batch completed.
Design management views around questions
Management does not need another collection of tables. The system should surface obligations, exceptions, performance and operational state.
What this project demonstrates.
- 01Business process discovery
- 02Multi-division systems architecture
- 03Complex workflow modelling
- 04Role and permission design
- 05Operational data modelling
- 06Manufacturing workflows
- 07Inventory operations
- 08Service-delivery tracking
- 09Branch management
- 10Fleet operations
- 11Financial workflow integration
- 12Executive reporting
- 13Phased implementation
“The challenge wasn't building more screens. It was creating a coherent operational model underneath them.”
Responsibility
My role.
My work covered the translation of business operations into the system model — understanding workflows, defining modules, designing operational states and relationships, shaping management controls, and leading the implementation of the resulting platform.
- Business discovery
- Process mapping
- Requirements definition
- System architecture
- Workflow design
- Data modelling
- Interface direction
- AI-assisted implementation
- Testing and operational validation
- Client iteration
Technology
Implementation tools.
- React
- TypeScript / JavaScript
- Supabase
- PostgreSQL
- Tailwind
- AI-assisted development
- Web application architecture
Island Group demonstrates the kind of systems problem I am most interested in: not simply digitising an existing form, but understanding how an organisation actually operates and creating the software model that allows those operations to become visible, controlled and measurable.