SCM‑NUMS Presenter's TranscriptSlide-by-slide narration with the presentation pinned alongside

1Welcome & Purpose of the Session

Good morning, everyone. Thank you for making the time to be here. What I'm about to present is the SCM‑NUMS Governance and System Assurance binder. That's a long title, so let me unpack it right away. "SCM‑NUMS" stands for Supply Chain Management — Nurse Uniform Management System. It's the platform that will handle every uniform order for every nurse in KwaZulu‑Natal. And the "governance and system assurance binder" is the master document that governs how it was designed, how it was built, how it's secured, how it's tested, and how it will be operated once it goes live.

This is not a sales pitch. It's a governance walkthrough. Over the next half hour or so, I want to leave you with two things. First, a clear sense of what the system does and why it matters — not in technical language, but in the language of a nurse placing an order, a supervisor approving it, and an auditor checking the trail. Second, complete confidence that the controls, the evidence and the sign‑offs in the binder meet the standards this Committee expects — and that they meet the standards the Auditor‑General will eventually apply.

I'll be walking you through 25 slides. Each of them corresponds to a section of the binder. If you want to dive deeper into any of them, the full document is available — every slide you see has a page reference so you can find the source material straight away.

2Agenda — What We Will Cover

Before I dive in, let me set out the shape of the session. We're going to follow the binder's own order — which is also the order in which the system was actually built and governed. That matters, because each section builds on the last.

We start with the project charter and business case. That's the "why" — why the Department decided to build a system in the first place, what problem it was solving, what was in scope and what was deliberately left out. Then we move into requirements: what users needed, what the system needed to do, and what quality standards it had to meet — including a specific new password policy that I'll cover in detail.

From there we look at the architecture — the four layers that make up the system, and how they fit together. Then roles and access: the twelve nursing positions, the supervision hierarchy, and the access matrix that decides who can do what. That's followed by the risk register and the security posture.

In the second half of the presentation, we cover data management and retention, then the traceability matrix and testing programme. After that comes change management, then backup and disaster recovery, then incidents, then training. We close with go‑live readiness, the post‑implementation review, the audit evidence summary, and finally the sign‑off.

The binder runs to 21 numbered sections plus an abbreviations glossary. Each of them stands on its own — but they only make sense as a whole. By the end of this session, you'll see how they lock together.

3Executive Summary — The Big Picture

Let me start with the big picture. SCM‑NUMS replaces a fragmented, paper‑based process with one integrated, web‑based platform. That sentence is short, but it contains a lot. Before this project, a nurse who needed a new uniform was at the mercy of forms, emails, and physical signatures. Some requests sat for weeks. Nobody had real‑time visibility into what had been ordered, approved, or delivered. And building an audit trail from paper records was close to impossible — for the Department, and for the Auditor‑General.

What we've delivered is a system that:

• Registers nurses by their Persal number, validated against the Department's HR database. That means we always know who is ordering.
• Lets nurses place uniform requisitions online against a controlled digital catalogue. No more paper forms, no more email requests.
• Routes those requisitions to their immediate supervisor for approval, based on the nurse's position level and facility.
• Logs every step in a tamper‑evident audit trail — so every action is attributable to a person, a time, and an IP address.
• Gives management real‑time dashboards on ordering, approvals, and expenditure, by district and facility.
• And stays fully compliant with PHSDSBC Resolution 1 of 2022, POPIA, and the PFMA.

The scale is significant. This system will serve 32,000+ nurses, across 11 KZN health districts, and 700+ health facilities. It replaces what was essentially a manual workflow with a modern, auditable digital one.

4Project Charter — Identity and Ownership

Every project in the Department needs an identity — a name, an ID, a sponsor, a Project Manager, a budget, and a timeline. Section 1.2 of the binder sets all of this out. Let me walk through each item on this table.

The project name is SCM‑NUMS — Supply Chain Management, Nurse Uniform Management System. It sits under the SCM Division because the uniform supply chain is an SCM function, and it sits under ICT because it's a technology platform. That dual ownership is important, and you'll see it reflected in the governance structure throughout the binder.

The project ID is KZN-ICT-2026-01. That's the formal identifier used across every governance document, every audit report, and every change record. If you need to reference this project in any Committee minutes or correspondence, that's the reference to use.

The sponsor is the Head of Department for KZN Health. That's the executive accountable for the outcomes of the system.

The Project Manager is Mr Themba Sikosana, who also serves as Technical Lead. That means the same person is accountable for delivery and for the technical quality of the system — which is deliberate, because it keeps those two responsibilities tightly coupled.

The project ran from 26 May 2026 to 15 October 2026. That's a five‑month delivery window, which is aggressive but achievable given the limited scope and the technology choices we made.

The budget framework is based on the Project Manager's remuneration — specifically, the maximum overtime allowed for the project duration. There's no external vendor, no licensing fees, and no outsourced development. The system is built and maintained in‑house by the Department's own ICT team.

5Challenges Addressed and Value Delivered

This slide is really two slides in one: what the situation was before SCM‑NUMS, and what we delivered. Let me take them one at a time.

The challenges before SCM‑NUMS

• Inefficient manual processes. Paper‑based ordering was slow, error‑prone, and completely lacked transparency. A request would leave a facility, travel through the postal system or by hand, and sit in a stack somewhere until someone processed it.
• Email‑based requests. When email replaced paper, it didn't solve the problem — it just moved it into a shared inbox. There was no central register, no way to prioritise, and no reliable way to audit what had happened to any given request.
• No real‑time visibility. Management at district and provincial level had no way to see, in real time, what was being ordered, what had been approved, or how much was being spent.
• Audit difficulties. Because the evidence was scattered across facilities and inboxes, producing a coherent audit trail was an enormous manual effort — and often incomplete.
• Fraud risk. With no traceability, mismanagement — whether deliberate or accidental — went unnoticed until it was far too late.
• Inconsistent practice. Each district, sometimes each facility, had its own way of doing things. There was no single standard.

What we delivered

• A fully digitised ordering process — one system, one workflow, applied everywhere.
• A complete audit trail for every transaction, from the moment a nurse logs in to the moment a uniform is delivered.
• Role‑based access control across five distinct user roles, so that every user can do exactly what their position requires — and nothing more.
• Real‑time financial and operational dashboards for management at every level.
• Full compliance with PHSDSBC Resolution 1 of 2022, the bargaining council resolution that governs nurse uniform entitlements.
• And zero licensing cost, because the entire stack runs on open‑source software and is maintainable by our in‑house ICT team.

6Scope — What's In and What's Out

Good governance means being just as clear about what the project does not do as what it does. Section 1.4 of the binder is very specific about this, and I want to draw your attention to both sides.

What is in scope

• 32,000+ nurses across 11 districts. Every nurse in every district, in every facility, will be able to use the system.
• 700+ health facilities. Every facility that issues uniforms is covered.
• Online ordering with a visual catalogue. Nurses see the uniforms, choose sizes, and place their order online.
• An approval workflow based on position hierarchy. A nurse's supervisor — determined by the twelve position levels — approves or rejects their order.
• Role‑based access control across five distinct roles. Nurse, Supervisor, Stores Officer, Head Office, and Auditor. Each sees and does only what their role permits.
• A complete audit trail and financial reporting. Every action is logged; every rand is accounted for.
• HR database integration. Nurses are validated against the Department's HR system in real time.

What is out of scope

• Physical uniform manufacturing. The system manages orders, not production.
• Procurement of raw materials. That's a separate procurement process.
• Logistics fleet management. The system doesn't manage vehicles or drivers.
• Physical distribution logistics. It records that a uniform was issued; it doesn't route the delivery van.
• External system integrations beyond HR. In this release, we integrate with HR only. Other integrations — like the Stores Module — are planned for a future release.

7Objectives and Milestones

Section 1.5 and 1.6 lay out seven objectives and seven delivery milestones. The table on the left shows you both — objectives on the left, milestones on the right. Let me go through them in plain language.

The seven objectives — and where they stand

• Digitise the ordering process across 100% of facilities. This is still in progress because it depends on the roll‑out, but the technical work is complete.
• Implement role‑based access control across five roles — done. Every user's permissions are enforced by the system at the menu, action, and data level.
• Provide real‑time order visibility under three seconds — done. Response times have been benchmarked and confirmed.
• Maintain a complete audit trail — done. Every action is logged with the user, the timestamp, the IP address and the user agent.
• Achieve full PHSDSBC Resolution 1 of 2022 compliance — done. Every entitlement rule in the resolution is encoded in the system.
• Integrate with the HR database for real‑time Persal validation — done. Nurses are validated the moment they register.
• Achieve 99.5% uptime — currently under continuous monitoring, with high‑availability infrastructure in place.

The seven delivery milestones

The binder tracks seven phases. Requirements and Design are complete — that's where the BRS, URS, architecture, and database schema were signed off. Development and Testing are in progress. Facility testing begins at the end of September 2026, the pilot runs in early October at five facilities, and full province‑wide go‑live follows mid‑October.

8Business Requirements — The Problem We Solved

Section 2 opens with the business problem statement. It's a page worth reading carefully, because it anchors everything that follows. Let me tell you the story it tells.

Before SCM‑NUMS, the Department's uniform ordering process took 30+ days from request to delivery. That's the headline number. Underneath it, three things were happening. First, requests came in by email — meaning no central register existed, and nobody could tell you how many were outstanding at any given moment. Second, data errors were common, because every facility was retyping names, Persal numbers and sizes by hand. Third, records were lost — physical forms disappear, inboxes get cleaned, and follow‑ups get dropped.

And crucially, nobody could answer the basic audit questions. Who ordered this? Who approved it? When was it delivered? Those are simple questions, and the old process couldn't answer them reliably.

SCM‑NUMS changes that in three moves. First, online registration and ordering. Nurses log in, see the catalogue, choose sizes and quantities, and submit. Second, automated validation. Every Persal number is checked against HR; every quantity is checked against the maximum allowed. Third, digital approval with real‑time tracking. The request goes straight to the nurse's supervisor, and both parties can see the status at every stage.

The old process and the new one sit side by side on this slide — and the difference is stark. What used to take a month of back‑and‑forth now takes a matter of days.

9Key Business Requirements

Section 2.3 lists eight business requirements. Each has an ID, a priority, and a business driver. Let me explain what each one is really asking for.

• BR‑01 — Nurses must register with their Persal number. This is the identity anchor of the whole system. If we don't know who's ordering, we can't control anything downstream. So the very first requirement is: prove who you are, using the Department's own HR identifier.
• BR‑02 — Supervisors must approve or reject orders. Accountability. Every order must pass through a human being — the nurse's own supervisor — before it becomes a commitment. That's the line of accountability.
• BR‑03 — Every transaction must be logged with a full audit trail. Nothing happens in the system without being recorded. That's the foundation of audit readiness.
• BR‑04 — Role‑based access control. Users see only what they need to see and can do only what they need to do. That's the security requirement.
• BR‑05 — Financial and operational reports. Management needs the numbers — by district, by facility, by item. That's the oversight requirement.
• BR‑06 — HR database integration for validation. We do not create duplicate identities. We validate against the Department's own master data.
• BR‑07 — Centralised uniform catalogue. Every facility sees the same catalogue, at the same prices. That's the consistency requirement.
• BR‑08 — Support for 32,000+ users. The system has to scale to the whole province. That's the scalability requirement.

All eight of these were reviewed and approved by the Uniform Management Steering Committee. They are the requirements against which the system is measured — and against which our test cases have been designed.

10User and Functional Requirements

Requirements come in two flavours on this slide. On the left, what users need. On the right, what the system must do. Let me go through both.

User requirements — five roles

• Nurses need to register, order, view their history, and edit pending orders. Simple, but the whole system depends on this working smoothly.
• Supervisors need to approve or reject orders, activate nurse accounts, and — if they approve something by mistake — re‑open it.
• Stores Officers need to manage inventory, issue uniforms when an approved order arrives, and run stores reports.
• Head Office needs province‑wide oversight, the ability to configure the system, and user management.
• Auditors need read‑only access to everything — including audit logs and compliance reports. Their independence depends on it.

Functional requirements — ten modules

FR‑01 to FR‑10 cover the ten things the system must do: registration, authentication, role‑based access control, catalogue management, order placement, approval workflow, audit logging, reporting, account activation, and order editing. Each one is mapped to a specific PHP file in the codebase — so we can trace any requirement to the exact code that implements it, and from there to the exact test case that proves it works.

11Non‑Functional Requirements and Password Policy

Functional requirements describe what the system does. Non‑functional requirements describe how well it does it. Sections 3.3 and 3.4 cover ten of them — performance, security, availability, scalability, compliance, audit, usability, maintainability, interoperability and data integrity. Today I want to focus on security, because it underpins everything else.

Security — NFR‑02

• bcrypt hashing with salt for every stored password. Even if someone got hold of the database, they couldn't read the passwords.
• A 30‑minute session timeout. If you walk away from your desk, the session closes itself.
• HTTPS (SSL/TLS) for all traffic. Nobody can eavesdrop on the network.
• CSRF tokens on every form. That stops attackers from tricking a logged‑in user into doing something they didn't intend.
• PDO prepared statements. SQL injection becomes impossible, because user input is never concatenated into queries.
• Output encoding. Cross‑site scripting is blocked at the point where data is displayed.
• Account lockout after five failed logins. Brute‑force attacks are stopped before they get anywhere.

Password complexity — the new rule

Section 3.5 is new in this version of the binder. Every password must now be at least 6 characters long, and must contain at least one uppercase letter, one lowercase letter, one number, and one special character. The client (the browser) and the server enforce the same rules. The client gives the user immediate feedback — a live checklist — and the server rejects anything that slips through.

12System Architecture — Four Layers

Section 5 lays out the architecture. It's a four‑layer stack. Let me walk through it from top to bottom, because it makes the rest of the system much easier to understand.

• Layer 1 — Presentation. This is what users see. HTML5, CSS3, JavaScript, jQuery, and Font Awesome icons. The user interfaces are the Nurse Portal, the Supervisor Dashboard, the Admin Console, and the Auditor Interface. It's built to be responsive, which means it works on a desktop in an office, a tablet on a ward, and a phone on the move.
• Layer 2 — Application. This is the business logic. PHP 8.2 running on Apache 2.4, with Composer for dependency management. The modules cover authentication, orders, approvals, catalogue, reports and audit. Everything that makes a decision — like whether a nurse is allowed to order, or whether a supervisor can approve — lives in this layer.
• Layer 3 — Data. This is where the information is stored. MariaDB 10.4+ accessed through PDO. Fourteen core tables, including nurses_users for accounts, uniform_orders for order headers, and order_items for the details of each order.
• Layer 4 — Infrastructure. This is the platform underneath. Windows 10 Enterprise (22H2), hosted at SITA — the State Information Technology Agency. SITA provides enterprise‑grade hosting, security, and compliance for government systems.

13Core Database Tables

The data model is the backbone of the system. Section 5.4 documents fourteen core tables. Twelve of them carry the operational load. Let me walk through what each one is for.

• nurses. The Department's HR master data — read‑only inside SCM‑NUMS. This is where a nurse's Persal number, surname, name, district and facility are checked during registration. It's not created by the system; it's consumed by it.
• nurses_users. The system's own user accounts. When a nurse registers and is activated, their account is created here — with Persal number, email, hashed password, active flag and position.
• uniform_orders. Every order header. One row per order, with the user, the status, the total amount, and who approved it.
• uniform_catalogue. The uniform items themselves — categories, names, prices, sizes, and the maximum quantity allowed per order.
• order_items. The line items under each order. If an order has five different items, there are five rows here — each with a size, quantity, price and subtotal.
• admin_users. System administrators — Head Office and District administrators. Separate from nurse accounts, with their own role and permissions.
• admin_audit_log and nurses_activity_log. The two audit trails. Every admin action and every nurse action is recorded here — with user, action, description, IP address, and user agent.
• supervisor_approvals. The record of every approval and rejection, including the reason if a rejection happened.
• positions. The twelve‑level nursing position hierarchy — with each position's level, whether it's a supervisor, and its scope.
• order_cycles. The ordering windows — which periods in the year allow orders to be placed.
• user_order_limits. Tracks which nurse has already ordered in the current cycle, so they can't order twice.

Every table is ACID‑compliant, indexed for performance, and covered by the backup strategy we'll look at in a few slides.

14Position Hierarchy and Supervision Rules

SCM‑NUMS is built on a twelve‑position nursing hierarchy, and that hierarchy drives who can approve whose orders. Let me read them from entry level up.

1. Enrolled Nursing Auxiliary (Level 1). The entry level.
2. Staff Nurse (Enrolled Nurse) (Level 2).
3. Professional Nurse — General Stream (Level 3).
4. Professional Nurse — Specialty Stream (Level 4).
5. Clinical Nurse Practitioner (Level 5).
6. Operational Manager — General (Level 6, Department scope). The first supervisory level.
7. Operational Manager — Specialty / PHC (Level 6, Department scope).
8. Assistant Nurse Manager (Level 7, Facility scope).
9. Deputy Manager Nursing (Level 8, Facility scope).
10. Manager Nursing / Matron (Level 9, Facility scope).
11. Director / Chief Director Nursing (Level 10, Facility scope).
12. Facility CEO (Level 11, ultimate facility authority).

Supervision follows three simple rules, and they're important. Position 6 supervisors see only their own facility and their own department — so a nurse in the Maternity Unit is supervised by the Operational Manager of that unit, not by someone in a different department. Positions 7 and above see everyone in their facility, across all departments — because they carry facility‑wide responsibility. And nobody can supervise themselves or someone at their own level — which is the anti‑fraud principle at the heart of the system.

15Access Matrix — Who Can Do What

Role‑based access control is where security becomes real. Section 6.4 of the binder draws out a matrix of every function against every role. The table on the left is that matrix. Let me walk through what it means.

• Nurses can register, log in, place orders, edit their own pending orders, and view their own history. They cannot approve orders, activate accounts, or view anyone else's data — not even their own supervisor's.
• Supervisors can view their supervisees' orders, approve or reject them, activate accounts, and re‑open approved orders. They cannot approve their own orders — a rule that was deliberately hard‑coded into the system.
• Stores Officers manage inventory, issue uniforms when approved orders arrive, and run stores reports. They have read‑only access to requisitions and audit logs.
• Head Office has the highest level of access — system configuration, user management, and order cycle setup. Head Office is the only role that can change system‑wide settings.
• Auditors have read‑only access to everything — including audit logs and compliance reports. Their access is deliberately limited to reading, because their value depends on independence.

16Risk Register

Section 7 is the risk register. It's maintained by the ICT Governance Committee and reviewed quarterly. There are ten live risks — and every one is currently mitigated or actively monitored. Let me go through them so you can see the reasoning behind each one.

• R‑01 — Unauthorised access to nurse personal information. This is the biggest risk in any system that holds PII. We mitigate it with RBAC, bcrypt hashing, SSL/TLS, session timeout, IP logging, and account lockout.
• R‑02 — Downtime during peak usage. With 32,000+ users, even a short outage is disruptive. We mitigate it with high‑availability infrastructure, load balancing, 24/7 monitoring, and failover systems.
• R‑03 — Data loss. Daily backups, off‑site storage, a documented DR plan, and monthly restore tests. If we lose a disk, we can be back within hours.
• R‑04 — POPIA non‑compliance. A privacy impact assessment, data classification, access controls, and periodic compliance reviews.
• R‑05 — User resistance. The classic risk of any new system. We mitigate it with comprehensive training, printed manuals, phased rollout, and a helpdesk.
• R‑06 — HR integration failure. API testing, fallback procedures, UAT, and robust error handling. If HR validation fails, the nurse is told immediately and can escalate.
• R‑07 — Cyber attack. Prepared statements, input sanitisation, CSRF tokens, a web application firewall, and regular penetration testing.
• R‑08 — Performance at scale. Query tuning, caching, scalability testing, and continuous monitoring.
• R‑09 — Weak passwords. The enforced complexity policy, bcrypt hashing, and lockout. This risk was new in the last revision — before, it was effectively unmitigated.
• R‑10 — Silent backup failure. This is the risk that a backup job fails quietly and nobody notices until you need to restore. We mitigate it with error logging, exit code checks, and weekly verification runs.

17Security Controls and POPIA Compliance

Section 8 of the binder walks through the security posture in detail. It's divided into two areas: the technical controls, and POPIA compliance. Let me take them one at a time.

Technical controls

• bcrypt hashing with salt for every password — one‑way hashing that can't be reversed.
• Session‑based authentication with a 30‑minute inactivity timeout — so a shared workstation doesn't stay logged in.
• RBAC with least privilege across five roles — every user sees only what they need.
• SSL/TLS encryption in transit — nothing is transmitted in plain text.
• PDO prepared statements and CSRF tokens — the two most common web attacks are blocked at the source.
• Output encoding to prevent cross‑site scripting — user data is never interpreted as code.
• Comprehensive audit logging and account lockout — every action is recorded, and brute force attempts are stopped.

POPIA — the eight conditions

The Protection of Personal Information Act sets out eight conditions for lawful processing. The system has been assessed against all eight: accountability, processing limitation, purpose specification, further processing limitation, information quality, openness, security safeguards, and data subject participation. We are fully compliant on all eight. Each one is documented in Section 8.2 of the binder, with the specific implementation described.

18Data Management and Retention

Data has a lifecycle. Section 9 of the binder sets out how we manage it from the moment it enters the system to the moment it's disposed of. There are four things to understand: classification, ownership, retention and disposal.

Classification

Every piece of data in the system is classified. Personal information and credentials are CONFIDENTIAL — access restricted, encrypted, audited. Order information, system configuration and financial reports are INTERNAL — access controlled, audited, but not treated as highly sensitive. Each classification carries its own handling rules, and those rules are enforced by the system.

Ownership

Data has clear owners. The Data Owner is the KwaZulu‑Natal Department of Health — the Department is accountable for the data. The Data Steward is the Supply Chain Management Division — responsible for the day‑to‑day handling. And the Technical Custodian is the ICT Division — responsible for the platform on which the data sits.

Retention

• Active user records are kept indefinitely — because they're needed for daily operations.
• Inactive user records are kept for 5 years, then archived; at 10 years, they're deleted.
• Order records and audit logs are kept indefinitely — because that's what an audit trail requires.
• Reports are kept for 5 years.
• Backups are kept for 30 days daily, 12 months monthly, with yearly archives kept indefinitely.

19Traceability, Testing and UAT

You can't claim a system is ready without proving it. That's what the Requirements Traceability Matrix — Section 10 of the binder — does. It maps every requirement to a design element, a test case, and a UAT scenario. Nothing is orphaned. We maintain 100% traceability.

The numbers on this slide tell the story: 8 business requirements, 5 user requirements, 11 functional requirements (including the password complexity requirement), all mapped to 86 individual test cases. That's the audit trail from "what did we promise" to "what did we prove".

Test phases

There are six test phases plus UAT:

• Unit testing — every function tested in isolation. In progress.
• Integration testing — modules tested together. In progress.
• Functional testing — end‑to‑end business workflows. In progress.
• Security testing — vulnerability scanning, OWASP checks. In progress.
• Performance testing — load testing with 32,000 simulated users. Planned for next.
• Facility testing — actual testing at pilot facilities. Planned for the end of September.
• UAT — user acceptance testing with real business users. Planned for early October.

UAT — the final proof

Nineteen scenarios are planned, with twenty‑two participants drawn from pilot facilities, various supervisor levels, stores, head office and internal audit. Eighty‑six individual test cases across the six scenario groups. Nothing moves to production until the business users have signed off.

20Change Management Records

Section 13 of the binder is the change log. Five changes have been recorded since June 2026. Every one of them followed the same disciplined process: request, assessment, CCB review, testing, approval, deployment, and monitoring. Let me go through each one.

• CH‑001 (15 June 2026) — Remove document upload functionality. The original system had a document upload feature, but it duplicated records already maintained in HR. It was removed. Impact was low, because no user workflow depended on it.
• CH‑002 (15 June 2026) — Approvals and activations routed to the immediate supervisor. This was a functional change that aligned the workflow with the PHSDSBC supervision hierarchy. Impact was medium, because it affected every approval.
• CH‑003 (28 July 2026) — Remove price from the nurse‑facing interface. Prices were visible to nurses when they were ordering, which could bias their choices. The price was removed from the nurse view but retained in the admin view for finance. Impact was medium.
• CH‑004 (28 July 2026) — Only quantity limits, no rand limits. Finance uses quantity caps, not rand caps, so the system was adjusted. This is the kind of change that keeps the system aligned with how the business actually works.
• CH‑005 (28 July 2026) — Admin portal becomes finance‑only; "orders" renamed to "requisitions". A language change that clarifies the intent across the system. Impact was medium.

All five changes were requested by Mr Mtshali and Mr Mkhize, approved by the Change Control Board chaired by Mr Mtshali, with Mr Themba Sikosana as Technical Lead. Every one was tested before deployment, and every one has a documented rollback plan.

21Backup, Recovery and Disaster Recovery

Section 14 is one of the most operationally important parts of the binder. It defines exactly how we protect the data. Let me start with the two objectives that drive everything else.

Recovery objectives

• RTO — Recovery Time Objective: 4 hours. If the system goes down, we restore service within four hours. That's the outer limit. In practice, most scenarios are faster.
• RPO — Recovery Point Objective: 1 hour. In the worst case, we lose at most one hour of data. That's enforced by taking hourly incremental backups.

The backup suite

Three batch scripts do the work, and they're all registered under a single Windows Task Scheduler task called SCM-NUMS Backup Suite:

• backup_full.bat — runs daily at 17:00. Takes a full MySQL dump of nurses_db, zips it with 7‑Zip, and stamps it with a date‑time. Keeps the last 30 daily backups.
• backup_incremental.bat — runs hourly after 17:00. Captures only the deltas since the last backup, using MySQL binary logs. Keeps 7 rolling copies.
• backup_remote.bat — runs daily at 17:30. Copies the newest backups over SMB to the pharmacoportal VM, giving us a genuine off‑site copy.

Retention and verification

Thirty daily backups, twelve monthly, yearly archives kept indefinitely. And every week — Sunday at 03:00 — an automated restore test runs into a test database. If the backups don't restore, the test fails, and we get alerted before it matters.

22Incident Management

Section 15 defines what happens when something goes wrong. It's a structured process: detect, triage, investigate, resolve, review, close. The whole sequence is designed to make sure nothing falls through the cracks.

Priority levels

• P1 — system down, data loss, or security breach. Response within 15 minutes, resolution within 2 hours. This is reserved for the worst cases.
• P2 — major functionality affected. Response within 30 minutes, resolution within 4 hours. For example, if ordering stops working across an entire district.
• P3 — non‑critical functionality affected. Response within 2 hours, resolution within 24 hours. A single report failing, for example.
• P4 — minor issues and enhancements. Response within 24 hours, resolution within 5 days. Cosmetic issues or small feature requests.

Escalation path

Every incident starts with Level 1 Helpdesk. If they can't resolve it, it goes to Level 2 — the Project Manager and SCM Team, who handle the technical investigation. If it's a major incident, it escalates to Level 3 — the ICT Manager. Critical incidents go to Level 4, the CIO. And the ultimate escalation, for the most serious situations, is Level 5 — the Head of Department.

23User Manual and Training

Section 16 is the user manual — the practical, step‑by‑step guide every user will read. It covers eight core procedures, each one illustrated and written in plain language. Let me list them, because they map directly onto how the system is used day to day.

1. How to register as a nurse. Enter your Persal number and surname, get verified against HR, complete your profile, and wait for your supervisor to activate your account.
2. How to log in. Enter your Persal number and password, and you're in.
3. How to place a uniform requisition. Browse the catalogue — automatically filtered to your gender — choose sizes and quantities, review the total, and submit.
4. How a supervisor activates a nurse account. Review the pending registrations from your supervisees, verify their details, and activate.
5. How a supervisor approves or rejects a requisition. Review the order, check the items and the total, and either approve it or reject it with a reason.
6. How a supervisor re‑opens an approved requisition. If an order was approved in error, the supervisor can re‑open it with a reason, and it goes back to pending.
7. How an admin manages the catalogue. Add new items, edit existing ones, deactivate old ones — and every change is logged.
8. How a stores officer manages inventory and issues uniforms. Adjust stock, issue uniforms against approved requisitions, and run stores reports.

Training programme

Training is delivered in phases. First, a train‑the‑trainer session at Head Office. Then two district training rounds across all 11 districts, covering nurses, supervisors and stores officers. Then specialist sessions for auditors, supervisors, helpdesk and admin users.

• Nurses: 32,000+ — training delivered by district;
• Supervisors: 450 — targeted sessions with a refresher;
• Stores Officers: 22 — advanced training;
• Head Office: 15 — advanced training; and
• Auditors: 8 — audit‑specific training.

24Go‑Live, Post‑Implementation Review and Sign‑Off

We're almost there. Sections 18 through 21 cover the final stretch — readiness, cut‑over, review, evidence and approval.

Go‑live readiness — six domains

Before we move to production, six readiness domains must each be signed off:

• Business readiness — requirements approved, UAT completed, business continuity plan ready, stakeholder communication done.
• Security readiness — security assessment completed, all risks mitigated, password complexity enforced, user access provisioned, audit logging enabled.
• Data readiness — data migration completed, validation verified, quality confirmed, backups in place.
• ICT readiness — infrastructure provisioned at SITA, backup and DR tested, monitoring configured, support team trained.
• Operational readiness — training completed, user manuals distributed, helpdesk operational, incident management ready.
• User readiness — all users registered, access provisioned, training completed, communication sent.

Four of these are already signed off. Operational and user readiness are the last two, and both depend on training completing on schedule.

Cut‑over plan

The go‑live cut‑over is performed after hours on go‑live day, in nine timed steps from 20:00 to 21:45. Every step has a rollback plan. If anything goes wrong, we can restore the previous state within minutes.

Post‑implementation review — nine KPIs

Once the system is live, we measure it against nine KPIs: requisition processing time under 10 days, user satisfaction above 80%, uptime above 99.5%, audit log completeness at 100%, training completion at 100%, incident resolution under 24 hours, user registration rate at 100%, password complexity pass rate at 100%, and backup success rate at 100%.

Audit evidence — nineteen categories

When the Auditor‑General arrives, there are nineteen categories of evidence ready: the RBAC matrix, audit logs, password evidence, change records, test results, UAT sign‑offs, backup evidence, DR results, risk register, training records, go‑live approval, PIR, and the backup scripts themselves. Everything is indexed, page‑referenced and available.

25Closing — Thank You

That brings us to the end. Let me leave you with three thoughts.

First — the system is real. SCM‑NUMS is not a slideware concept. It's built, it's tested, and it's ready for pilot. Every claim in this presentation is backed by a page in the binder. If you want to see any of it, we can open it up and show you.

Second — the governance is strong. RBAC, POPIA compliance, audit logging, backup automation, change control — these aren't afterthoughts. They were designed in from day one. Every control in the system exists because a requirement demanded it, and every requirement is tested and traceable.

Third — the value is measurable. From 30‑day paper processes to a 10‑day digital standard. From zero visibility to real‑time dashboards. From scattered evidence to a complete audit trail. And from a manual, error‑prone workflow to a controlled, auditable one.