1. Purpose

Turn complete, accurate financial data into timely management information that shows how IKON is performing and where action is required.

2. One-year finished state

• Finance owns the complete reporting cycle from source data to a consistent management pack.
• Leadership can see P&L performance, EBITDA, project profitability, work in progress and stock value without waiting weeks.
• Cost centres are visible and assigned to the relevant leaders.
• Weekly and monthly reporting rhythms are defined, repeatable and trusted.

3. Current reality

• IKON does not yet have reliable click-of-a-button visibility of weekly performance, WIP, stock and profit by project.
• Financial information is spread across invoices, Zoho, Bizman Tools, EVA and existing finance processes.
• Finance still carries temporary work outside the future engine.

4. Problems & constraints

• Reporting is delayed by fragmented data and manual preparation.
• Information must be reconciled across systems.
• A report cannot be trusted if transactions, stock, WIP or project allocation are incomplete.

5. What must be resolved

• Define the minimum weekly and monthly management pack.
• Decide the central financial package and cost-centre structure.
• Define source, cut-off, reconciliation and approval rules for material numbers.
• Establish reporting lead-time and data-quality baselines.

6. Operating model

Capture at source → validate and reconcile → allocate to project and cost centre → close period → produce management pack → review exceptions → assign action → improve source data.

7. Capabilities & training

• Management accounting and financial interpretation.
• Reconciliations, close and variance analysis.
• WIP and stock accounting.
• Project profitability analysis.
• Data quality and commercial communication.

8. Roles & accountability

One accountable Finance owner is required for management-information integrity and delivery. Department leaders remain accountable for operational data and spending within their cost centres. Final Seats follow engine approval.

9. Systems, tools & documents

• Central financial package, still to be confirmed.
• EVA, Zoho and Bizman Tools where relevant.
• Weekly flash report and monthly management pack.
• Close checklist, reconciliations and variance commentary.
• Controlled chart of accounts and reporting definitions.

10. Standards

• One version of the financial truth.
• Every material number has a source, definition, cut-off and reconciliation.
• Reports separate fact, estimate and unresolved variance.
• Errors are corrected at source.

11. Measurables

• Time from period end to trusted pack.
• Unreconciled items and material exceptions.
• Availability of P&L, EBITDA, WIP, stock and project-profit views.
• Report corrections after issue.

12. Dependencies

• Operations supplies accurate stock, production, dispatch and WIP movements.
• Technical hands over complete product and BOM logic.
• Client Development supplies accurate sales and order data.
• Creditors and Costing supply clean transaction and project data.

13. Risks

• Automating incomplete or incorrect data.
• Treating system output as accurate without checks.
• Finance becoming the manual clean-up department for every engine.
• Building reports before agreeing definitions and ownership.

14. Immediate priorities

• Map required management numbers to source and current reliability.
• Define the proposed management pack for leadership challenge.
• Establish reporting and close baselines.
• Remove remaining non-Finance work through trained handovers.

1. Purpose

Protect IKON’s cash and relationships through controlled customer collections, supplier payments, reconciliations and cash visibility.

2. One-year finished state

• Customer invoices, receipts, ageing and collection actions are current and visible.
• Supplier invoices are captured, allocated and reconciled before payment preparation.
• Finance prepares complete debtor and creditor control packs, with final releases separately approved.
• Short-term cash requirements, overdue accounts, disputes and exceptions are visible early.

3. Current reality

• Meegan is expected to own debtors and creditors from start to finish up to final payment release.
• Creditor preparation already exists, but central capture and cost-centre allocation still need development.
• Debtor, creditor and cash information is not yet integrated into the desired weekly management view.

4. Problems & constraints

• Late invoicing or weak follow-up can delay cash collection.
• Missing supplier evidence or incorrect allocation weakens control.
• Unclear handoffs can create overdue accounts, duplicate work and cash surprises.
• Preparation, approval and release boundaries require clarity.

5. What must be resolved

• Approve end-to-end debtor and creditor workflows.
• Define collection cadence, escalation and credit-control rules.
• Define payment authority, evidence and exception rules.
• Define supplier and customer master-data controls and cash forecasting rhythm.

6. Operating model

Raise and verify customer invoice → monitor receipt and ageing → follow up and escalate → receive and validate supplier invoice → allocate and reconcile → compile payment pack → approve and release → update cash view → resolve exceptions.

7. Capabilities & training

• Debtor collection and customer-account reconciliation.
• Creditor processing and supplier reconciliation.
• Cash-flow forecasting and working-capital control.
• Fraud awareness, VAT and supporting-document checks.
• Professional dispute and exception management.

8. Roles & accountability

Finance owns debtor and creditor controls, collection visibility, reconciliations and payment-pack preparation. Sales and Operations supply accurate billing triggers and evidence. Final payment release remains separately controlled. Seats follow approval.

9. Systems, tools & documents

• Customer and supplier masters in the central finance package.
• Invoice, receipt, ageing and collection registers.
• Supplier invoice intake, reconciliations and payment pack.
• Cash forecast, approval matrix and exception register.
• Bank-detail verification and audit evidence.

10. Standards

• Invoices are raised promptly from approved commercial evidence.
• Overdue customer accounts receive consistent follow-up and escalation.
• No supplier payment without valid evidence and approval.
• Bank-detail changes are independently verified.
• Debtor, creditor and bank positions reconcile to the financial truth.

11. Measurables

• Debtor ageing and overdue value.
• Collection actions completed and disputes unresolved.
• Invoices awaiting capture or allocation.
• Unreconciled creditor and bank items.
• Cash forecast accuracy and off-cycle payments.

12. Dependencies

• Client Development supplies accurate commercial terms and collection support.
• Operations confirms billing, delivery and receipt events.
• Data & Analytics consumes reconciled working-capital information.
• Systems preserve evidence, workflow and audit history.

13. Risks

• Revenue is recorded but cash is not collected.
• Supplier fraud or incorrect bank details.
• Late capture creates surprise cash requirements.
• Over-control delays supply or damages customer relationships.
• Disputes remain unresolved because ownership is unclear.

14. Immediate priorities

• Map debtor and creditor processes end to end.
• Baseline ageing, disputes, unreconciled items and off-cycle payments.
• Define collection and payment escalation rules.
• Confirm cash-forecast and master-data controls.

1. Purpose

Build and govern the connected systems, automation and AI capability that makes Finance faster, more accurate, auditable and scalable.

2. One-year finished state

• A clear systems architecture defines the role of the finance package, EVA, Zoho, Bizman Tools and connected data.
• Finance owns system oversight, controls and financial audits without becoming the developer of technical product logic.
• Priority repetitive administration is automated safely using AI or workflow automation.
• System changes are scoped, tested, trained, launched and audited through a controlled process.
• Capacity exists to champion AI and systems without weakening core Finance delivery.

3. Current reality

• EVA implementation is consuming material time and the first launch will not complete the full programme.
• Further phases include machine integrations, tablets, sensors, barcoding and installation processes.
• Meegan is willing to oversee systems but does not want responsibility for inventing technical product calculations.
• AI was explicitly identified as a way to remove repetitive work, but learning time, accuracy and capacity are constraints.

4. Problems & constraints

• Software projects have not always been broken into sufficiently clear phases and milestones.
• Finance can receive incomplete technical logic and then be expected to resolve it.
• Multiple systems can create duplicate data, weak ownership and inconsistent truth.
• AI can produce inaccurate work if controls, training and review are weak.
• One person cannot simultaneously perform Finance, EVA audits, software oversight and AI championing without capacity design.

5. What must be resolved

• Approve the target systems architecture and system of record for each data type.
• Define Technical-to-Finance handover requirements for product and costing logic.
• Define ownership of development, implementation, administration, audit and support.
• Define AI-use controls, approval boundaries and priority use cases.
• Decide capacity or Seats required to deliver the systems responsibility.

6. Operating model

Identify business problem → simplify process → define owner and requirements → receive technical logic where required → configure or develop → test known cases → approve → train → launch → audit accuracy and adoption → improve.

7. Capabilities & training

• Financial-systems administration and process mapping.
• Software project scoping, testing and implementation oversight.
• Data integration, audit trails and access control.
• AI prompting, workflow design and human verification.
• Change management, training and adoption measurement.

8. Roles & accountability

Finance requires one accountable owner for systems governance, financial data integrity, automation and AI enablement. Technical owns physical product logic. System developers build to approved requirements. Users own correct execution. Final Seats and capacity follow engine approval.

9. Systems, tools & documents

• Central financial package, still to be selected or confirmed.
• EVA, Zoho and Bizman Tools.
• Integration map and system-of-record register.
• Requirements brief, test script, known-case library and sign-off checklist.
• Access matrix, change log, audit schedule and training records.
• AI use-case register, review controls and automation exception log.

10. Standards

• Simplify the process before automating it.
• No system change launches without defined ownership, testing, sign-off and training.
• Technical logic is handed over complete, documented and teachable.
• AI output affecting money, people or commitments is verified by an accountable human.
• Access follows role need and changes promptly when people join, move or leave.
• System output is audited against real evidence.

11. Measurables

• System implementation milestones on or off track.
• Data exceptions and audit failures by system.
• Manual hours removed through approved automation.
• AI workflows in use and exceptions found.
• User adoption, training completion and support demand.
• Duplicate capture or reconciliation effort.

12. Dependencies

• Technical supplies validated product and formula logic.
• Operations and Client Development define user requirements and execute source processes.
• Data & Analytics defines required outputs and control definitions.
• External developers and vendors deliver approved technical work.
• HR & Office Administration supports access and training controls.

13. Risks

• Automating a broken or unclear process.
• AI creates plausible but incorrect financial work.
• System development becomes dependent on one individual.
• EVA phases continue without clear scope, milestones and Definition of Done.
• Integrations create multiple versions of the truth.
• Finance becomes responsible for technical product design.

14. Immediate priorities

• Map the current systems architecture and data ownership.
• Define EVA phases still required after initial launch.
• Create the Technical-to-Finance logic handover standard.
• Identify a small set of safe, high-value AI automation use cases.
• Baseline manual effort, system exceptions and required capacity.

1. Purpose

Create confidence in IKON’s product and project economics by controlling costing logic, auditing actual cost and exposing margin variance.

2. One-year finished state

• Finance can explain approved cost logic without depending on informal technical knowledge.
• New and changed products arrive from Technical with a complete documented costing handover.
• Expected versus actual project cost and profitability are visible.
• BOM, material, labour, overhead and consumption assumptions are reviewed when variance appears.

3. Current reality

• Technical calculation questions have reached Finance without a complete formal handover.
• EVA development is exposing the boundary between technical definition and financial audit.
• Technical defines physical logic, then Finance understands, controls and audits the financial result.
• Project profit is not yet visible at the desired speed.

4. Problems & constraints

• Finance cannot audit a cost it does not understand.
• Costing formulas can be handed over half-built.
• Incorrect silicone, hardware, labour or material logic can silently erode margin.
• Actual usage, stock and WIP data may not support reliable variance.

5. What must be resolved

• Approve the Technical-to-Finance costing handover pack.
• Define the boundary between technical logic and financial control.
• Define standard cost, actual cost and variance-review methods.
• Prioritise products and projects for validation.

6. Operating model

Technical defines validated physical logic → formal handover and training → Finance controls financial logic → implement in system → test known cases → monitor expected versus actual → investigate variance → correct at source.

7. Capabilities & training

• Product-cost architecture and BOM interpretation.
• Material, labour and overhead costing.
• Project accounting and margin analysis.
• Formula auditing and controlled test cases.
• Cross-engine variance investigation.

8. Roles & accountability

Technical owns the physical truth. Finance owns financial costing control after complete handover and must understand the calculation it audits. Operations owns actual usage evidence. Final Seats follow approval.

9. Systems, tools & documents

• EVA and Bizman Tools costing logic.
• Approved BOM and calculation-logic handover pack.
• Standard-cost sheets and formula register.
• Known-case test library.
• Expected-versus-actual report and variance register.

10. Standards

• No costing logic enters use without documented technical handover and financial validation.
• Finance understands the mathematics it audits.
• Product changes trigger costing review.
• Material, labour and overhead assumptions are explicit and versioned.
• Variance is corrected in the responsible engine.

11. Measurables

• Products with complete costing handovers.
• Expected versus actual material and labour variance.
• Project profit variance.
• Open costing exceptions and age.
• Costing errors found after quotation or manufacture.

12. Dependencies

• Technical supplies validated product, BOM and formula logic.
• Operations supplies actual usage, labour, stock and WIP.
• Client Development applies approved pricing.
• Financial Data reports profitability.

13. Risks

• Finance is expected to invent technical consumption logic.
• Technical remains permanent owner of financial checking.
• System formulas are trusted without known-case testing.
• Margin leakage stays hidden in aggregate results.

14. Immediate priorities

• Define the costing handover from Technical.
• Select known products for end-to-end testing.
• Map expected-versus-actual data availability.
• Document unresolved EVA calculation and integration issues.

1. Purpose

Protect IKON and enable its leaders through consistent people administration, payroll inputs, office coordination, controlled records and employee lifecycle support.

2. One-year finished state

• Recruitment, onboarding, employee changes, office administration and exits follow controlled checklists.
• Contracts, confidentiality obligations, access changes, payroll inputs and disciplinary records are complete.
• Managers and supervisors handle defined basic discipline within a clear framework.
• HR administration supports leaders without taking over their responsibility to lead.

3. Current reality

• Finance currently holds significant HR documentation and administration.
• Existing checklists and files have improved, while the meeting identified further scaling and control gaps.
• Managers can pass recruitment, discipline or administration into Finance when accountability is unclear.
• The disciplinary software already structures offences, evidence and escalation.

4. Problems & constraints

• HR administration can become involved in every basic people issue.
• Recruitment screening and onboarding are not consistently designed end to end.
• System access, confidentiality and restraint reminders can be missed at exit.
• Sensitive salary and employee information limits delegation.

5. What must be resolved

• Define the boundary between central HR administration and line leadership.
• Approve recruitment, onboarding, discipline, payroll-change and exit workflows.
• Define which actions supervisors may handle and when HR or legal support is required.
• Confirm confidentiality and delegation rules.

6. Operating model

Leader raises approved people event → central administration runs process and records → manager owns leadership decision → approvals occur → systems, payroll and files update → exception escalates → completion is audited.

7. Capabilities & training

• South African labour-law and disciplinary fundamentals.
• Structured screening and interview administration.
• Payroll-input control and confidentiality.
• Employee evidence management.
• Manager and supervisor training on warnings and escalation.

8. Roles & accountability

Central HR and Office Administration owns process, records, office coordination, advice and completion controls. Department leaders own hiring decisions, performance management and discipline within the framework. Major matters escalate. Seats follow engine approval.

9. Systems, tools & documents

• Secure employee master file and office administration register.
• Recruitment and interview checklists.
• Contract, NDA, restraint and policy acknowledgements.
• Onboarding, access and exit checklists.
• Disciplinary software and escalation framework.
• Payroll change forms and approvals.

10. Standards

• Every employee event follows the approved checklist.
• Confidential access is limited to need.
• Managers do not outsource leadership to HR administration.
• Discipline follows approved process and evidence standards.
• Departing employees lose access promptly and receive required reminders.

11. Measurables

• Incomplete files or onboarding actions.
• Recruitment administration lead time.
• Payroll corrections and late changes.
• Outstanding disciplinary documents.
• Exit controls not completed on time.
• Leaders trained in the approved process.

12. Dependencies

• Department leaders initiate and complete their responsibilities.
• Finance and payroll need approved employee changes.
• System owners action access changes.
• External labour or legal expertise supports major matters.

13. Risks

• Central HR becomes the manager for everyone.
• Untrained supervisors create labour-law exposure.
• Confidential information is over-delegated.
• Incomplete exits expose IKON’s IP or systems.
• Process becomes bureaucratic instead of enabling.

14. Immediate priorities

• Map the employee lifecycle and current owners.
• Clarify leader versus central HR responsibility.
• Validate discipline framework and supervisor training requirements.
• Audit onboarding, file and exit-control completeness.