Skip to content

Case study 03 · Healthcare business

Ocean Healthcare

ERP and financial intelligence

Business process analysis and financial-systems requirements for an ERP with a financial-intelligence layer: ledger, receivables, payables, inventory, cash, profitability and liquidity.

Status: Requirements and solution designThis engagement is at the requirements and solution-design stage. The capabilities described are designed, not built, unless stated otherwise.

1 · Context

The client and the project

Ocean Healthcare manages stock, sales, suppliers and cash across its operations. As the business grows, management needs both reliable accounting records and a clear understanding of what those records say about profitability, liquidity and performance.

2 · Challenge

The operational challenge

Transactions are recorded, but turning them into timely answers about margins, cash position and the profitability of products or activities requires manual analysis. Approvals and controls depend on individuals rather than on the system.

3 · Our role

What HornBridge is responsible for

  • Business process analysis
  • Financial-systems requirements and solution design
  • Design of the financial-intelligence layer
  • Control and approval-workflow design
  • Management reporting and recommendation framework

4 · Approach

How the solution works

The design covers the transactional core of the business — general ledger, revenue and receivables, payables, inventory and cost of goods sold, cash and bank — with approval workflows and operational controls built in.

Above that core sits a financial-intelligence layer: profitability and margin analysis, liquidity and cash-flow visibility, and performance dashboards that highlight what management should look at and what action may be needed.

Recording

A traditional ERP records the transactions: what was sold, bought, paid and held.

Understanding

HornBridge’s design adds the next step: what those transactions mean for margin, cash and performance, and what management may need to do about it.

Architecture

Designed architecture: from transactions to decisions

Solution design. The transactional core records what happened; the intelligence layer explains what it means.

Control point

  1. 1

    Transactions

    What happened

    • General ledger
    • Receivables and payables
    • Inventory and cost of goods sold
    • Cash and bank
  2. 2

    Controls

    Whether it is right

    • Approval workflows (control point)
    • Reconciliations (control point)
    • Audit trail (control point)
  3. 3

    Intelligence

    What it means

    • Profitability and margin
    • Liquidity and cash flow
    • Performance against plan
  4. 4

    Management

    What to do

    • Performance dashboards
    • Reporting and recommendations
    • Actions for review
Result

Traditional ERP records transactions. This design helps management understand them and act.

Solution design. The transactional core records what happened; the intelligence layer explains what it means.

Original diagram of the system’s structure. Screenshots are not shown, to protect client and patient information.

5 · Components

Key system components

General ledger and accounting workflows
Posting rules and period routines that keep the accounts consistent.
Revenue, receivables and payables
Customer and supplier balances with ageing and follow-up.
Inventory and cost of goods sold
Stock valued consistently and matched to the sales it supports.
Cash and bank balances
Current cash position across accounts.
Profitability and margin analysis
Where margin is earned and where it is lost.
Liquidity and cash-flow visibility
Short-term obligations against expected receipts.
Financial performance dashboards
Management views of performance against expectations.
Management recommendations
Reporting that points to the decisions the figures call for.

6 · Controls

Technical and financial controls

  • Approval workflows for purchasing, payments and adjustments
  • Segregation of duties in the accounting cycle
  • Bank and stock reconciliation routines
  • Audit trail on postings and changes

7 · Status

Where the project stands

Status: Requirements and solution design

This engagement is at the requirements and solution-design stage. The capabilities described are designed, not built, unless stated otherwise.

8 · Benefits

Intended benefits

These are the benefits the system is designed to deliver. They are not reported results.

  • management understands margin, liquidity and performance without manual analysis.
  • controls rest on the system rather than on individuals.
  • monthly reporting that leads to specific management actions.

Practices

Practices involved

Next step

Discuss a similar system.

Tell us how your organisation works today. We will reply with how we would approach it and what a first release could include.