Supply Chain Technology (SCT)
Process Analyst (PA) Playbook

Supply Chain Technology

Version June 2026

Author: Billy Leung · Audience: SCT Process Analyst team for building practice · Full SCT practitioner for building principles · Full supply chain operation group for collaboration, engagement and expectations · Classification: Internal Use Only

Process

A process is a defined sequence of activities performed by named roles, using specified systems and inputs, to produce a documented output. It has an explicit start trigger, end condition, owner, and exception path. It is not a task, a habit, or an informal way of working. A process connects business results across end-to-end supply chain operations and cross-functional teams: it makes the handover points, dependencies, and accountabilities between functions explicit and governed. A process is subject to revision when evidence (incident data, operator feedback, or system change) demonstrates the current design no longer reflects operational reality.

Analyst

An analyst is not an observer, a note-taker, or an advisor. The analyst takes direct ownership of a process, executes it firsthand, and produces evidence-based outputs. Working from direct observation and data, the analyst understands the process end-to-end, identifies inefficiencies, challenges the current design when evidence warrants it, and tests alternative approaches before recommending change. Improvement proposals are supported by evidence: not opinion, not assumption, and not stakeholder preference.

Scope and Intent

This playbook defines the target operating standard for the SCT Process Analyst team. It is written to industrial best practice, not as a description of current SCT operations. Where current practice differs from this standard, the gap is the work. Analysts are expected to close it, not accommodate it.

Contents

1. SCT Context: Vision, Mission and Principles
2. The Process Analyst Role
3. Team Structure and Responsibilities
4. Skills and Quality Required
5. Operating Model: How We Work
6. Definition of Great and Productivity Metrics
7. Transport Tech Stack: Five Capabilities
8. Supplier Ops Tech Stack
9. Process Design and SOP Standards
10. Incident Management and Continuous Improvement
11. System Test and Change Management
12. Master Data and Configuration Governance
13. Onboarding: 30 / 60 / 90 Day Plan
A. Appendix: Writing Style Guideline and Reference Documents

1. SCT Context: Vision, Mission and Principles

▼

The Process Analyst role exists to serve the SCT mission. Every task, SOP, incident response, and configuration change executed by the PA team must be traceable to one of three SCT responsibilities: optimise the present, respond to the past, or enable the future. This section defines the organisational context the PA team operates within.

SCT Vision, Mission and Platform Scope

Our vision is to provide the best supply chain end-user experiences with new technology and process innovation. Every interaction with these new technologies and processes empowers the end user to be more capable and fulfilled.

Our mission is to build a scalable supply chain technology platform that improves customer satisfaction and supply chain working efficiency.

Our supply chain technology platforms serve as digital enablers, optimizing operations by managing order flows, tracking deliveries, and streamlining customer expectations.

Our Role and Responsibilities

SCT Responsibility	Scope	PA Team Contribution
Innovate the new way of working	With future adaptive supply chain technology to meet business growth.	Document current-state processes accurately before new capabilities deploy. Design and publish process documentation for each new capability prior to go-live. Ensure new system behaviour is captured in SOPs before operational teams are trained.
Optimise the present supply chain system configuration	To welcome new business onboarding.	Primary PA domain: carrier onboarding, rate and zone changes, supplier operation requests, WMS and TMS configuration, master data governance. All changes are documented, traced, and validated before deployment to live systems.
Identify, root cause and respond to past supply chain system incidents	To ensure uninterrupted operations.	Maintain the incident scorecard. Apply 5 Whys and Pareto analysis to all P1/P2 incidents. Convert recurring incidents into SOP updates or configuration changes. Measure recurrence rate to validate fix effectiveness.

Our Principles

Our principles are cultivating a self-sustaining supply chain technology team that embraces independent, critical thinking to provide unbiased, expert guidance. By deeply understanding our organization's needs, pain points, and the latest emerging technologies, we enable transparent decision-making and foster a culture of continuous improvement with a transformative change journey, ultimately ensuring a resilient, future-ready supply chain.

PA Team Mission: Optimise present configuration. Respond to past incidents. Enable future innovation. Close the gap between how operations execute and how processes are designed, documented, and governed.

2. The Process Analyst Role

▼

The Process Analyst bridges operational supply chain needs with process design, system configuration, and master data governance across OMS, ERP, WMS, and TMS. The role is not advisory. It is hands-on, evidence-driven, and accountable for the quality of every process it touches.

Team Design Rationale

Four principles govern the team structure. Every member is required to understand these principles.

#	Principle	Description
1	Continuous improvement and growth mindset are qualifiers: not bonuses	Continuous improvement and growth mindset are selection criteria, not development goals. Required: each completed work item leaves the process better than before. Each incident produces a root cause and prevention action. Each process design is subject to revision when evidence warrants it, regardless of who authored the original.
2	Talent pool with transferable system knowledge	Each analyst builds working knowledge across OMS, ERP, WMS, TMS, and carrier systems. Knowledge is not locked to one person or domain. SOPs, config logs, and incident entries are the mechanism by which knowledge persists independent of individual tenure.
3	A small squad: not a large team	Team size is intentionally small. Each member has full workload visibility. Small-team constraints enforce documentation discipline: process knowledge must be written down because headcount cannot substitute for it. There are no passenger roles.
4	Hands-on execution: observe, execute, change, benchmark, hand back	Analysts execute processes directly rather than advising from a distance. Lifecycle: observe, execute, change, benchmark, compare, define position, influence operating model, promote design, hand back to operations. The PA team incubates and matures processes. Ownership transfers to the operational team once the process is stable.

Role Purpose

Process Analysts take ownership of operational processes to understand them firsthand, identify the root problems, design and implement improvements, then hand the mature process back to operations with documented SOPs. Secondary responsibilities include functional requirements documentation, configuration logic management, product master data integrity, and platform support. The role operates in close coordination with Logistics, Service Delivery, Product, Engineering, and vendor teams.

This role IS	This role is NOT
Takes process ownership, executes the process firsthand, identifies the root problems, designs and implements improvements, then hands the mature process back to operations	Observes or advises from a distance without taking process ownership
Authors, validates, and maintains SOPs as the process owner until handover	Documents what stakeholders say without independent validation
Treats each incident as a system signal: investigates, takes corrective ownership, modifies the process, and verifies the fix holds	Resolves individual incidents with no recurrence prevention action
Engages Logistics, Engineering, and vendor teams as active partners	Operates without stakeholder engagement or cross-functional input
Documents, traces, and audits every configuration change	Executes configuration changes without documentation or traceability
Challenges requests that conflict with governance or system rules	Executes department requests without validation

Eight Operating Principles

Mandatory operating standards grouped by SCT responsibility. These are not aspirational guidelines.

#	Principle	Description
OPTIMISE: PRESENT CONFIGURATION
1	Observation before opinion	Validate the current state through direct observation before designing any change. Sources: process walkthroughs, operator interviews, system logs, data extracts. No solution or SOP is drafted before current-state validation is complete.
2	Documentation is the deliverable	All outputs must be written and traceable. Required artefacts: SOP, config log entry, incident scorecard entry. Verbal agreements and undocumented fixes do not constitute completed work.
3	Own your domain end-to-end	Each analyst is accountable for the full lifecycle of assigned processes: discovery, design, documentation, configuration, and ongoing governance. Domain ownership requires active maintenance, not passive assignment.
RESPOND: PAST INCIDENTS AND CONTINUOUS IMPROVEMENT
4	Every incident is a system signal	Each incident is evidence of a gap in process design, configuration, or documentation. Required response: identify the gap, implement a fix, verify recurrence prevention. Ticket closure without root cause documentation does not meet the resolution standard.
5	Improvement is measured, not assumed	All process changes require a defined success criterion before implementation and a documented measurement after. SCT does not accept changes without pre-defined criteria and post-implementation measurement.
6	Escalation discipline protects quality	All L2+ escalations require Senior Team Lead (Senior Team Lead) review before submission. Required fields: symptom, supporting evidence, steps attempted, business impact. Incomplete escalations are returned for completion.
INNOVATE: ENABLING THE FUTURE
7	Clarity enables the future	Undefined scope, unassigned ownership, and undocumented decisions generate incidents. When ambiguity is identified, it must be surfaced and resolved immediately. Process automation requires complete process definition as a prerequisite.
8	Independent, critical thinking	The PA team validates all requests before execution. If a requested change will introduce a defect, conflict with existing configuration, or violate a governance requirement, document the concern and escalate before proceeding.

JD LINKAGE JD Position Scope — Supply chain process design and mapping: "Lead supply chain process design initiatives using Business Process Management (BPM) and Six Sigma methodologies. Develop flowcharts, blueprint documents, escalation paths, and system handover maps for end-to-end logistics and order fulfilment. Translate operational issues into structured workflow improvements and system logic changes."

Process Analyst Asset Register

Optimise: Present System Configuration

Asset	Definition	Where it lives
Standard Operating Procedure (SOP)	Step-by-step documented process covering RACI, inputs, outputs, triggers, tools, and exception paths. One SOP per process.	SCT Process Library
Configuration change log	Record of every system configuration change: what changed, before/after values, logic assumption, approver, date, and linked ticket.	Config Change Log
Process register	Master index of all processes owned by the PA team: process name, Process ID, domain, SOP status, version, and roster owner.	PA Process Register
Carrier rate change record	Documented record of each rate card, FSC (Fuel Surcharge), surcharge, or zone list update: effective date, carrier, systems updated, and validation outcome.	Rate Change Log
Supplier operation request record	Documented record of each supplier configuration change: warehouse address, lodgement point, transport matrix, operational hours.	Supplier Ops Log
Master data change record	Documented record of each master data update: item master, supplier address, carton dimension (before/after values and approver sign-off).	Master Data Log
ShipVia healthcheck report	Periodic end-to-end health audit of the ShipVia configuration. Findings documented with severity rating.	Healthcheck Reports

Respond: Past Incidents

Asset	Definition	Where it lives
Incident scorecard entry	Structured record of each incident: symptom, severity, root cause, corrective action, preventive action, recurrence risk rating, and closure confirmation.	Incident Scorecard
Root cause analysis (RCA) document	For P1/P2 incidents: structured 5 Whys or fishbone analysis producing a named root cause and a preventive action plan.	RCA Library
Incident pattern report	Periodic Pareto analysis grouping incidents by domain, type, and recurrence. Identifies structural gaps driving repeat incidents.	CAPA Reports
Contingency document	For active system outages: live record of incident state, actions taken, decision log, and recovery steps. Eight-section structure per Section 10 of this playbook.	Contingency Docs
Vendor engagement record	Notes from vendor and carrier meetings: discussion points, agreed improvement actions, owner, and due date.	Vendor Engagement Log

Innovate: Future Adaptive Technology

Asset	Definition	Where it lives
Process blueprint	Current-state and to-be process map for a new or redesigned process: swimlane flow, RACI, system handover points, and gap analysis.	Process Blueprints
Business requirement document	Structured capture of a business need: problem statement, scope, constraints, success criteria, and fit-gap analysis against current system capability.	Business Requirements
Change specification	System-level change requirement broken down into user stories and acceptance criteria ready for engineering sprint backlog.	Change Specs
User Acceptance Test (UAT) document	Test cases, execution results, defect log, and sign-off record for a system change or new feature.	UAT Records
Knowledge change document	Updated Confluence page reflecting a process or system change: human knowledge source or Artificial Intelligence (AI) knowledge source. Published at the same time as the production deployment.	Knowledge Change Log
Idea pipeline register	Living register of improvement ideas: problem statement, proposed approach, expected benefit, submitter, date, and current status. Reviewed monthly by Senior Team Lead (Senior Team Lead).	PA Idea Pipeline

Asset completeness rule: An asset is only complete when it contains all required fields, is saved in the correct Confluence location, and has been peer-reviewed or signed off as required. A ticket comment, a Slack message, or a verbal agreement does not constitute an asset.

3. Team Structure and Responsibilities

▼

Five members across onshore and offshore locations. Role boundaries are explicit to prevent task duplication, coverage gaps, and unowned work items.

JD LINKAGE JD Position Scope — Stakeholder & Vendor Collaboration: "Partner with Logistics, Service Delivery, Engineering, Finance, and Category teams to define and validate requirements. Engage with vendors and external partners to document improvement needs, enhancement requests, and progress follow-ups. Participate in platform reviews, issue triage, and integration discussions."

Triage LeadOnshoreTriage and 1st Level Support

First point of contact for all incoming tickets and requests
Performs initial triage: classify severity (P1/P2/P3), identify affected system, assign to the right analyst
Handles 1st-level diagnosis: resolves straightforward issues without escalating
Maintains the ticket queue: no ticket older than 3 business days without a status update
Flags capacity issues or priority conflicts to Senior Team Lead
Represents the onshore voice in standups and stakeholder communications

Task	Metric tracked	Target
Ticket triage and classification	Tickets triaged per day	All tickets classified within 2 hours of receipt
1st-level resolution	Tickets resolved without analyst escalation	Track ratio of resolved at triage vs escalated
Queue health	Open ticket count, oldest open ticket age	No ticket older than 3 business days without a status update
Stakeholder response	Response time to requestor	Same-day acknowledgement for all P1/P2 tickets
Capacity management	Flags raised to Senior Team Lead (Senior Team Lead) when analyst load is at risk	Proactive, not reactive to missed deadlines

Senior Team LeadOffshoreSenior Team Lead

Holds end-to-end process understanding across the full transport tech stack
Tracks day-to-day analyst task load and output quality. Senior Team Lead is the offshore operational manager.
Acts as escalation bridge between offshore analysts and SCT leadership (SCT Operations Manager, MP)
Reviews all SOP drafts and analyst outputs before they enter the formal review path
Leads or co-leads complex discovery sessions and cross-system process investigations
Supports analyst development: identifies skill gaps, coaches on process methodology
Reviews and approves all L2+ escalations before they are submitted

Task	Metric tracked	Target
Analyst task tracking	Tasks in progress per analyst	Daily visibility: no analyst with unknown workload
SOP draft review	Drafts reviewed per week	Reviewed within 2 business days of submission
L2+ escalation review	Escalations reviewed before submission	100% of L2+ escalations reviewed by Senior Team Lead (Senior Team Lead) before sending
Incident escalation handling	Escalations received and resolved	Root cause documented for every escalation
Discovery session leadership	Sessions led or co-led per month	At least 1 complex session led per fortnight
Analyst coaching	Development check-ins per analyst	Monthly 1-on-1 check-in with each offshore analyst

Process Analyst Talent Pool: Process Analyst A, Process Analyst B, Process Analyst C

Process Analyst A, Process Analyst B, and Process Analyst C operate as a shared Process Analyst talent pool. They are not siloed by role title. Each analyst is capable of executing across all process domains. The roster column indicates the current primary owner as of June 2026. Ownership rotates based on capacity, development needs, and backlog priority.

Important: This table represents example process assignments as of June 2026. It is the Process Analyst team's responsibility to keep the process map and process register updated when ownership changes or new processes are added. Senior Team Lead (Senior Team Lead) signs off all roster changes. This table must reflect the live register at all times.

Process group	Process	Definition of great	Metric	Roster owner
Carrier Rate Changes	FSC Update	All FSC changes validated and live before carrier effective date	Zero billing errors post-update	Process Analyst A
	Rate Card Update	Rate cards consistent across Shippit, Machship, and Ship-engine before go-live	Zero rate discrepancies at carrier invoice reconciliation	Process Analyst A
	Surcharges Update	Surcharge rules applied correctly across all carrier platforms	No incorrect surcharge on live orders post-update	Process Analyst A
	Zone List Update	Zone lists aligned across Shippit, Machship, and Ship-engine	Consistent zone list across all platforms	Process Analyst B
Carrier Onboarding	Carrier Enablement	Label generation, tracking, and rate selection verified before go-live. SOP published and peer-reviewed	Zero config errors at first live order despatch	Process Analyst A
	Lodgement Point configuration	Lodgement points configured consistently across all systems	Consistent lodgement points across Ship-engine, Shippit, and Machship	Process Analyst A
Supplier Operations	Warehouse Address Update	Address updated in all systems with validation confirmation sent to Supplier Ops	No mismatch between Central OMS and carrier system	Process Analyst B
	Warehouse Operational Time	Operational hours updated and validated in despatch logic	No despatch failure attributable to incorrect operational hours	Process Analyst B
	Transport Matrix Update	Transport matrix updated, tested, and SOP revised before go-live	Carrier assignment correct for all affected order types post-update	Process Analyst B
	Return Address Update	Return address updated across all carrier integrations with validation	Zero return delivery failures attributable to incorrect address	Process Analyst B
	Additional Warehouse	New warehouse fully configured in OMS, WMS, and carrier systems before first despatch	First despatch from new warehouse with zero system config errors	Process Analyst B
	Lodgement Point Update	Lodgement point updated and validated in all carrier portals and Ship-engine	No carrier pickup failure attributable to incorrect lodgement point	Process Analyst B
Daily Operations and System Health	Unmanifested Orders	Zero unmanifested orders carried to next business day without a status update	Orders resolved or escalated same day	Process Analyst C
	ShipVia New Submissions	All submissions processed same day with no backlog	Submission log up to date daily	Process Analyst C
	API Test Orders	100% pass rate on standard suite. Any failure logged and escalated to Senior Team Lead same day	Test log updated daily. Zero unlogged failures	Process Analyst C
	Monday Board	All tasks have a current status. No task older than 2 days without an update	Board current at daily standup	Process Analyst C
	ShipVia Healthcheck	Healthcheck completed within the day. All findings documented with severity rating	Healthcheck report published same day. Displaces all other tasks when run	Process Analyst C
SCT Ticket Queue	Ticket review and resolution	All assigned tickets reviewed within 1 business day. Resolution rate matches or exceeds intake	100% of P1/P2 tickets have root cause documented at closure	All three
	SOP peer review	All SOP drafts reviewed by a second analyst before submission to Senior Team Lead (Senior Team Lead). No structural gaps on submission	Zero SOPs submitted to Senior Team Lead without peer review	All three

4. Skills and Quality Required

▼

Competency requirements for the Process Analyst role. Skills are grouped by category. Quality indicators define the observable standard expected at full competency.

Technical Skills

Skill	Required level	Applied in
SQL	Proficient: write queries, understand schema, perform data analysis and anomaly detection	Incident root cause analysis; master data validation; configuration audit reporting
Excel / Sheets	Advanced: pivot tables, formulas, data modelling, structured comparisons	Rate change tracking; scorecard maintenance; process benchmarking
BPMN process mapping	Practitioner: produce current-state and future-state swimlane diagrams to BPMN standard	All process design and SOP authoring work
Six Sigma / structured problem solving	Working knowledge: apply 5 Whys, Pareto, fishbone to incident and process analysis	Incident RCA; process gap analysis; continuous improvement initiatives
ERP systems (SAP B1)	Functional: understand order and inventory flows; execute config changes with governance	Master data governance; config change documentation; ERP incident triage
WMS / TMS / OMS platforms	Functional: navigate and configure Loginext, Shippit, Machship, Aftership, Central OMS	Transport stack process design; carrier onboarding; incident triage
SOP and technical documentation	Proficient: author complete SOPs using the canonical The Organisation template with no gaps	All documentation outputs across every domain
UAT and change testing	Competent: design test cases, execute UAT, produce results summaries and go/no-go assessments	All system configuration changes and platform releases

JD LINKAGE JD Personal Requirements — Technical Skills: "2+ year SQL experience (writing queries, schema understanding, data analysis). Strong Excel skills (formulas, pivot tables, data modelling). Proficiency with Business Process Model and Notation (BPMN), Six Sigma tools, and structured process documentation. Experience creating SOPs, data governance policies, and configuration documentation."

Professional Skills

Skill	Required level	Quality indicator
Continuous improvement mindset	Entry requirement. Treats every completed task as an opportunity to improve the process, the documentation, or the system it touched. Discomfort with the status quo is the baseline.	Each closed incident produces a documented prevention action. No ticket closed without root cause. Repeat incidents prompt a process or config review, not just a re-fix
Systems thinking	Diagnoses how connected parts produce recurring patterns. Traces flows across system boundaries rather than treating each component in isolation. Understands why incentives drive actors toward the wrong problem: identifies the upstream structural condition that generates a symptom, not just the symptom itself.	RCA reaches the structural level: config design, incentive misalignment, or process gap. Recurring incidents in the same domain trigger a domain-level review, not another point fix
Critical thinking	Evaluates requests, assumptions, and proposed solutions independently before acting. Does not accept a stated problem at face value: asks what is actually happening, what evidence supports it, and what alternative explanations exist. Provides unbiased expert guidance even when it contradicts the requestor's position.	Challenges are documented and escalated before execution, not absorbed. No change implemented on the basis of assertion alone. SCT position papers reflect independent analysis, not stakeholder-led conclusions
Analytical thinking	Identifies root cause from incomplete data. Separates symptoms from causes without guidance. Applies structured methods: 5 Whys, Pareto, fishbone.	RCA entries cite evidence, not assumptions. Recurrence rate below 15% for closed P1/P2 incidents within 60 days.
Semantic precision	Distinguishes accurately between terms, elements, components, definitions, opinions, options, agreed facts, data, evidence, relationships, and flows. Applies the correct category to each input before acting on it. Does not treat an opinion as a fact, a term as a definition, an option as an agreed position, or a flow as a fixed relationship.	All written outputs (SOPs, analysis documents, escalations, and stakeholder communications) use each category correctly and consistently. No document conflates stakeholder opinion with validated evidence, or a proposed option with an agreed decision. Escalations and RCA entries cite the evidence category explicitly: data, agreed fact, or observed finding.
Assertive quality	States a position in every output. Does not return an open question to the requestor where a conclusion can be drawn from available evidence. Distinguishes between a finding (what was observed), a conclusion (what it means), and a recommendation (what to do). All three are required before an output is complete.	Every SOP, RCA, escalation, and analysis contains a stated conclusion or recommendation. No output closes with an unresolved question the analyst had the evidence to answer. Peer review flags outputs that describe without concluding.
Written communication	Produces clear, structured documents in technical specification style. Declarative, direct, no narrative framing. Conclusions lead, reasoning follows.	All written outputs (SOPs, analysis documents, RCAs, and escalations) pass review without structural revision. No missing exception paths or scope gaps on first submission. Escalations and communications include all required fields on first send.
Stakeholder engagement	Conducts structured discovery interviews. Validates findings against direct observation before documenting. Manages expectations clearly when scope or timeline is constrained.	Current-state maps, process designs, and analysis outputs are validated with the operator before documentation begins. No output (SOP, RCA, business requirement, or escalation) is authored from secondhand description alone.
Attention to detail	Catches configuration mismatches, data inconsistencies, and SOP gaps before they reach review.	Zero known-error outputs published across SOPs, analysis documents, config logs, and communications. Config changes traced to source document on every occasion.
Self-direction	Manages own task load without prompting. Flags blockers proactively and early. Does not wait for instruction on routine work or previously agreed processes.	Task tracker updated before end of shift daily. No unlogged work at Senior Team Lead's daily review. Blockers raised before they affect delivery

JD LINKAGE JD Personal Requirements — Soft Skills: "Detail-oriented, analytical thinker with structured communication style. Resilient, self-directed, and reliable in managing workload and deadlines. Strong stakeholder collaboration and vendor engagement capability. Clear written and verbal communicator with documentation discipline."

Experience Requirements

Area	Requirement	Notes
Supply chain or logistics operations	Direct exposure to order fulfilment, carrier operations, or warehouse execution	Minimum 1 year. Must understand the operational context they are designing processes for
System configuration or master data	Hands-on experience configuring or governing data in ERP, WMS, TMS, or OMS	2 years SQL required. Must understand system dependencies, not just UI navigation
Process documentation	Authored SOPs, process maps, or functional specifications in a professional context	Must demonstrate familiarity with structured documentation standards prior to joining
Incident analysis	Applied a structured RCA method (5 Whys, Pareto, or equivalent) to a real operational problem	Ability to distinguish root cause from symptom is a hiring filter.
Cross-functional stakeholder work	Operated in a role requiring coordination across multiple departments or external vendors	High-volume operational environment preferred.

JD LINKAGE JD Personal Requirements — Professional Experience: "Experience in supply chain, logistics, or systems operations with exposure to master data, process design, and incident resolution. Familiarity with WMS, TMS, OMS, and ERP platforms (e.g., SAP B1). Strong cross-functional collaboration experience in high-volume operational environments."

Disqualifying Behaviours

Disqualifying behaviours: These behaviours are incompatible with the role. Presence of any pattern is a performance issue, not a development area.

Behaviour	Why it is disqualifying
Closes incidents without documenting root cause	Prevents recurrence detection. Directly violates Operating Principle 4: Every incident is a system signal, and the resolution standard that ticket closure without root cause documentation is not accepted
Authors SOPs from secondhand descriptions without process observation	Produces inaccurate documentation that creates false confidence in processes not reflecting operational reality
Makes configuration changes without a config log entry	Breaks traceability. Creates unresolvable incidents when the change causes a downstream defect.
Absorbs blockers silently without flagging to Senior Team Lead	Hides workload problems until they become delivery failures. Undermines Senior Team Lead's visibility function
Resists revising a process they authored when evidence warrants it	Treats documentation as finished work. Directly contradicts the continuous improvement and growth mindset entry requirement
Executes department requests without validation	Requests conflicting with system rules or governance requirements must be challenged before processing.
Requests a template without first attempting own research, ideation, and a draft	Asking for a template before producing any independent thinking is a shortcut that bypasses the core PA skill set. The required sequence is: research the context, ideate an approach, produce a first draft, then seek feedback for refinement. Templates are reference points, not starting points. Each process, SOP, or analysis must be tailored to the specific situation and scenario. A generic template applied without adaptation is not a PA team output.
Responds with a flat refusal without supporting reasoning	A plain no without reasoning, alternative options, or a position statement is not expert guidance. The PA team is required to provide independent, critical thinking. Every decline must include the rationale for the position and, where possible, an alternative approach or a recommendation for how the requestor can achieve their objective through a different path.

5. Operating Model: How We Work

▼

The operating model has three dimensions: (1) internal team operation; (2) engagement within the SCT/Tech group including escalation to specialist functions; (3) cross-department engagement with business partners. All analysts are required to understand and apply all three dimensions.

Dimension 1: How the PA Team Works Internally

Work intake and flow

Request enters system

→

Triage Lead triages and classifies

→

Analyst assigned and works

→

Senior Team Lead (Senior Team Lead) tracks and quality checks

→

Output reviewed and published

Practice	Owner	Standard
Ticket assignment	Triage Lead (Triage and 1st Level Support)	Triage Lead classifies severity, identifies the system, and assigns to the domain owner.
Daily task visibility	Senior Team Lead (Senior Team Lead)	Senior Team Lead (Senior Team Lead) tracks each analyst's live task load daily. Analysts update tracker before end of shift. No analyst has unknown or unlogged work at close of day.
Standup cadence	Senior Team Lead (Senior Team Lead) (facilitates)	Daily offshore standup: each analyst states active tasks, blockers, and what completes today. Senior Team Lead (Senior Team Lead) flags ShipVia Healthcheck days and capacity conflicts to Triage Lead.
Peer review	All analysts	Every SOP draft is peer-reviewed by a second analyst before it reaches Senior Team Lead (Senior Team Lead). Reviewers check structure, voice, exception paths, and domain accuracy.
Escalation to Senior Team Lead	All analysts	Escalate when: scope is unclear, a task requires system access you do not have, a vendor is unresponsive for 48+ hours, or a change may affect a live integration.
Knowledge transfer	Senior Team Lead (Senior Team Lead) signs off	When a process changes hands, the outgoing analyst produces a written handover: current state, open items, known anomalies. Verbal-only handovers are not accepted.

Output quality gates

Output type	Gate 1	Gate 2	Gate 3 (publish)
SOP document	Peer analyst review	Process owner review	Senior Team Lead (Senior Team Lead) + SCT lead sign-off
Incident scorecard	Analyst self-check all fields	Senior Team Lead (Senior Team Lead) spot-check	Closed when root cause confirmed
UAT results summary	All test cases completed	Senior Team Lead (Senior Team Lead) reviews go/no-go	SCT lead approves release
Config / master data	Validation routine run	Product owner notified	Audit log entry created

Dimension 2: PA Team Within SCT and Tech Group

The PA team is L1 process triage and documentation. When a problem requires deeper system expertise, the team escalates through defined paths.

L1: PA Team, triage and analysis

→

L2: SCT SME, system specialist

→

L3: Tech Group, Engr/DBA/SecOps

→

L4: Vendor, external support

Scenario	Escalate to	PA team provides	Expected return
ERP / SAP B1 config or data issue	ERP Prod Owner (ERP Product Owner)	Incident scorecard entry: symptom, root cause hypothesis, steps tried, affected records	Confirmed root cause, config fix, resolution documented for scorecard
OMS / Central data integrity issue	SCT DBA / The Organisation Database Architect	Data extract showing anomaly, affected order IDs, expected vs actual values, timeline	Root cause at data layer, approved fix, confirmation of no downstream impact
Ship-engine or shipping logic defect	The Organisation Engineering (Dev and Deployment Manager)	Test case showing defect: input, expected output, actual output. PA team cannot fix code	Bug confirmation, fix timeline, post-fix validation criteria for PA team to UAT
Carrier API integration defect	The Organisation Engineering + vendor L2/L3 support	Integration incident log: request/response payloads, carrier, affected consignments, frequency	Vendor acknowledgement, fix ETA, interim workaround. PA team documents all vendor comms
Salesforce CRM defect	Salesforce Prod Owner (Salesforce Product Owner)	Workflow step failing, affected records, business impact	Confirmed fix. PA team updates SOP if the fix changes the documented process
CXOne / CCaaS defect	CXOne Prod Owner (CXOne Product Owner) / CX Service Prod Owner (CX Service Product Owner)	Incident description, timestamp, affected queue, customer impact summary	Platform-level resolution. PA team does not configure CCaaS
Security or data privacy concern	The Organisation SecOps (via Infra and Security)	Description of concern, data involved, whether breach or misconfiguration. Escalate immediately	SecOps assessment and remediation. PA team logs the escalation
Product roadmap request from process gap	Relevant Product Owner via SCT leadership	Business case: the process gap, frequency, impact, and proposed system change	Roadmap decision: accepted, deferred, or declined. PA team documents outcome and workaround

Escalation standard: All L2+ escalations require Senior Team Lead (Senior Team Lead) review before submission. Required fields: symptom, evidence, steps attempted, business impact. Incomplete escalations are returned for completion.

Dimension 3: PA Team with Cross-Department Partners

Department	They bring to us	Delivered to them	Key engagement rule
Transport	Carrier issues, despatch failures, rate and zone change requests, carrier onboarding, SLA breach reports	Carrier config SOPs, rate change execution and documentation, carrier onboarding process, Ship-engine rule updates	Triage Lead is the triage point. Process Analyst B and Process Analyst A are primary. Carrier escalations must include carrier name, order IDs, and failure type
Supplier Operations	Supplier setup requests, warehouse config changes, transport matrix updates, return address changes	Supplier Operation Request SOPs (Process Analyst B domain), config changes executed and documented, validation confirmation	All requests logged as tickets through Triage Lead. Process Analyst B owns end-to-end. Verbal requests are not accepted.
Logistics / Warehouse	WMS configuration issues, 3PL integration problems, despatch or receiving process gaps	WMS process SOPs, config change documentation, incident analysis for recurring warehouse-system failures	Analysts shadow warehouse operations before designing WMS changes. 3PL config changes confirmed with 3PL before go-live
Customer Care	Customer-reported delivery issues, tracking anomalies, notification failures, unmanifested order escalations	Tracking healthcheck SOPs (Process Analyst C domain), notification trigger documentation, unmanifested order resolution, incident reports	Care is the early-warning system for customer-impacting incidents. Treat Care-reported patterns as process signals
Product Category	Product master data queries, attribute mapping questions, category-level fulfilment rules	Master data governance support (backup role), documentation of attribute logic, escalation to product owner if needed	PA team is gatekeeper and documenter, not decision-maker. Category decisions are owned by Category team
Planning	Volume forecast data affecting carrier capacity, seasonal configuration changes, transport matrix requirements	Transport matrix updates, carrier config changes for seasonal rules, process documentation for planning-driven cycles	Peak season carrier config changes are predictable and must be scheduled, not treated as urgent reactive tickets
Buyer / Merchandising	Supplier onboarding requests with logistics implications, new product type queries	Escalation of supplier setup requirements to Supplier Ops and SCT, documentation of new fulfilment rules	Buyer requests with supply chain system implications are routed through Supplier Ops first, then to PA team via ticket queue

Cross-Department Engagement Rules

Rule	What it means in practice
All requests enter via the ticket queue	No department bypasses Triage Lead. Verbal requests, Slack messages, and emails are not work items until logged as tickets. Analysts who receive direct requests redirect them to Triage Lead for formal logging.
PA team documents, departments decide	The PA team translates operational decisions into documented process. Business decisions are owned by the requesting department. The PA team ensures those decisions are accurately reflected in SOPs, configuration, and system logic.
Current-state validation is mandatory	Before authoring or updating any SOP, the analyst must validate the current-state process with an operator who executes it. Peer review rejects SOPs based on secondhand descriptions.
Post-implementation follow-up is required	Within 10 business days of SOP publication or config go-live, the PA team confirms with the relevant department that the change is operating as designed. If not, a formal process review is initiated.
Requesting department owns the decision	System configuration change requests must include business justification and departmental leadership approval. The PA team executes and documents. The requesting department is accountable for the decision.

6. Definition of Great and Productivity Metrics

▼

Quality standards and team health metrics. Senior Team Lead (Senior Team Lead) reviews compliance monthly. SCT Operations Manager reviews the monthly summary quarterly. Metrics surface workload imbalance, quality drift, and process gaps. They are not individual performance scores.

Definition of Great: Output Quality Standards

Area	Meets standard	Exceeds standard	Does not meet standard
SOP quality	Template followed, peer reviewed, published on time	Zero exception-path gaps, process owner confirms it matches reality, no revision within 30 days	Published without peer review, missing exception paths, or contradicts how the process runs
Incident resolution	Ticket closed, fix documented in scorecard	Root cause confirmed, recurrence risk rated, SOP update raised if a process gap was found	Ticket closed with no root cause documented, or same incident recurs within 60 days
Process change	Change made, config log updated, product owner notified	Success criterion defined before the change, measured after, outcome documented with before/after comparison	Change made without a defined success criterion or post-change measurement
Vendor engagement	Meeting attended, notes taken	Agreed actions logged with owner and due date, followed up within agreed timeframe	Meeting attended but no action log produced, or agreed actions not followed up
Task visibility	Task tracker updated daily	Senior Team Lead has real-time visibility with no unknown items at end of shift	Tasks not logged, blockers absorbed silently, workload invisible to Senior Team Lead
Knowledge transfer	Verbal handover completed	Written handover document: current state, open items, known anomalies, signed off by Senior Team Lead	Verbal-only handover with no written record
Innovative ideas	Submits at least one reasoned idea per quarter to the SCT idea pipeline with a problem statement, proposed approach, and expected benefit	Actively refines ideas with peer input, presents to the SCT group for discussion, and pursues sponsorship for implementation planning from SCT leadership	No ideas contributed to the pipeline. Observations about process or system gaps are not converted into structured improvement proposals

Team Productivity Metrics

Metric	Tracked by	Frequency	Healthy indicator
Tickets triaged per week (Triage Lead)	Triage Lead	Weekly	100% triaged within 2 hours. Escalation rate stable or declining
Tickets closed vs opened ratio	Senior Team Lead (Senior Team Lead)	Weekly	Closed >= opened. No ticket older than 3 business days without a status update
SOPs published per analyst per month	Senior Team Lead (Senior Team Lead)	Monthly	Minimum 1 new or updated SOP per analyst per month
SOP revision rate within 30 days of publication	Senior Team Lead (Senior Team Lead)	Monthly	Less than 20% of published SOPs require revision within 30 days
Incident recurrence rate within 60 days	Senior Team Lead (Senior Team Lead)	Monthly	Less than 15% of P1/P2 incidents recur within 60 days
Root cause documented on closure	Senior Team Lead (Senior Team Lead)	Weekly	100% of closed P1/P2 incidents have a documented root cause
Config changes with before/after measurement	All analysts	Per change	100% of carrier rate or config changes have a documented outcome
Vendor action item follow-up rate	All analysts	Per meeting	100% of agreed vendor actions logged with owner and due date
Analyst task log completeness	Senior Team Lead (Senior Team Lead)	Daily	Zero analysts with unknown workload at end of shift

Metric interpretation: Rising SOP revision rate indicates peer review requires tightening. Rising incident recurrence indicates root cause analysis was incomplete. Metrics are used to improve team processes, not to assign individual blame.

7. Transport Tech Stack: Five Capabilities

▼

SCT Transport Tech Stack vision (updated 14 Apr 2026). Five capabilities are moving The Organisation from service dependency on Shippit/Machship to algorithmic control via the The Organisation Ship-engine. PA analysts must understand all five capabilities: incident triage, SOP authoring, and UAT work all map directly to this stack.

Strategic direction: Exit quote calculation and carrier-selection from Shippit and Machship. Centralise in The Organisation Ship-engine. Handle carrier scan data as pure transfer, not translation. Exit Aftership for SMS/email; replace with The Organisation group SMS.

Capability	Sub-capabilities	As-is	Vision	PA team relevance
C1 Carrier Selection Decision Engine	C1.1 Carrier contract service and terms C1.2 Quote calculator C1.3 Customer checkout preference C1.4 Cart shipping strategy rules C1.5 Operation carrier selection strategy rules C1.6 Carrier performance SLA C1.7 Least cost route	Ship-engine + Shippit + Machship	The Organisation Ship-engine only + direct carrier API quotes	Carrier SLA config SOPs, selection rules documentation, UAT for Ship-engine rule changes (Process Analyst A domain)
C2 Carrier Consignment Integration Middleware	C2.1 Integration with The Organisation (Supplier API) C2.2 Label generation C2.3 Integration with carriers (Shippit, Machship, 3PL Direct-Carrier)	The Organisation Supplier API + Shippit + Machship + 3PL Direct-Carrier	Expand The Organisation direct-carrier integration; maintain Shippit and Machship	Label generation health check SOPs, consignment transmission incident triage, direct-carrier onboarding docs (Process Analyst B and Process Analyst A)
C3 Transport Management System	C3.1 Vehicle skillsets C3.2 Trip planning and optimisation C3.3 Driver app	Loginext	Maintain Loginext (variable cost) + Ship-engine expands into route-decision for carrier collection	Vehicle config SOPs, trip planning process docs, Loginext incident tracking
C4 Parcel Track and Trace Data Middleware	C4.1 Event data ingestion C4.2 Milestone mapping C4.3 Predictive estimated delivery date C4.4 Vehicle GPS	Aftership + Loginext	Aftership = transfer only (no translation); unlock predictive EDD and Vehicle GPS into Ship-engine	Tracking healthcheck routines (Process Analyst C domain). Milestone mapping rules. False-delivered incident patterns: MobileRejected mapped to Delivered is a known gap
C5 Customer Delivery Status Notification	C5.1 Notification trigger logic (Central) C5.2 Media: SMS, email (Aftership to The Organisation group SMS) C5.3 Feedback / NPS capture	Central + Aftership	Exit Aftership SMS and email; The Organisation group SMS consolidation	Notification trigger SOPs, NPS escalation flows, SMS migration change support and UAT (Process Analyst C daily operations)

8. Supplier Ops Tech Stack

▼

This section is a placeholder for the Supplier Operations technology stack process map. The process map will document the systems, integrations, and process flows that govern supplier onboarding, purchase order management, supplier data management, and fulfilment coordination.

Process map: to be developed. Owner: SCT Logistics Solution Architect (Logistics Solution Architect). Target completion: aligned to next SCT quarterly planning cycle. When published, this section will follow the same five-capability structure as the Transport Tech Stack in Section 7.

Expected Scope

Capability area	Description
Supplier onboarding and configuration	Processes for enabling new suppliers, configuring supplier profiles, lodgement points, warehouse addresses, and operational parameters in OMS and ERP
Purchase order management	End-to-end PO lifecycle: creation, transmission, acknowledgement, amendment, and closure. Integration between Central OMS, SAP B1, and supplier systems
Supplier data management	Master data governance for supplier records: contact details, banking, lead times, MOQs, and product attributes
Transport and carrier coordination	Processes governing how supplier despatch events feed into the transport stack: carrier assignment, label generation, and tracking event initiation
Supplier performance and compliance	Processes for tracking and reporting supplier on-time performance, defect rates, and compliance against agreed SLAs

9. Process Design and SOP Standards

▼

Process design applies Business Process Management (BPM) and Six Sigma methodologies to convert operational problems into structured, documented, maintainable workflows. Current-state observation is required before any future-state design is produced.

Supply Chain Capability Process Hierarchy

Level	Definition	Decision scope	PA team application
Capability	A high-level grouping of related business processes that provide a strategic function. Example: Transport, Supplier Operations, Customer Care.	Strategy: where do we play	Identifies which SCT capability domain the SOP belongs to. Determines the Process ID prefix used in the SOP document header.
Process group	A collection of related business processes within a capability that work together to achieve a specific outcome.	Tactical: how do we play	Groups related SOPs in the SOP library index. The Process group name appears in Level 2 of the Process ID.
Process	A sequence of activities or tasks performed by people, systems, or machines to achieve a defined business goal. Includes: policy, RACI, version control, qualification operator register.	Operational: who and what to play	One SOP per process. This is the primary unit of PA team documentation output. All mandatory SOP template fields apply at this level.
Activity	A specific task or action within a process. Includes: input, trigger, tool, data, form, conversion, report, output, handover.	Operational: who and what to play	Activity detail populates the Process Details step structure within the SOP. Each step in the SOP corresponds to one or more activities.

Process ID convention: Every SOP must carry a Process ID that traces to this hierarchy. Format: [Domain prefix]-[Capability].[Process group].[Process].[Activity]. Example: LOG-1.1.1.1 (Logistics, Capability 1, Process Group 1, Process 1, Activity 1). The canonical source for all Process IDs is the SCT Capability and Process Hierarchy Map (see Appendix).

Process Design Checklist

Scoping and Discovery

Define process scope with the relevant product owner: agree explicit start and end points
Map all systems the process touches: OMS, ERP, WMS, TMS, Ship-engine, carrier portals
Identify all role handoffs including The Organisation to carrier, 3PL, or vendor handoff points
Observe the process live or shadow an operator through at least one full cycle
Document operator pain points verbatim: do not paraphrase or interpret at this stage

Current-State Mapping

Produce current-state flowchart or swimlane using BPMN notation
Identify waste types: waiting, rework, manual re-entry, duplication, missing ownership
Validate current-state map with the operator before proceeding
Check against applicable SLA, carrier contract, or policy requirement: flag all gaps

Future-State Design and Sign-Off

Score each gap: Impact (H/M/L) x Effort (H/M/L): prioritise quick wins first
Draft future-state flowchart and translate into configuration requirements
Define measurable success criteria for each proposed change
Confirm technical feasibility with Engineering or the relevant system product owner
Present findings and get process owner approval before authoring the SOP

SOP Authoring Standards

Standard	Requirement
Template	Canonical The Organisation SOP template only. No freeform documents
Domain prefix	TRN / LOG / SUP / CUS / ERP / SCT: applied to all document IDs
Voice	Active, second person or imperative: no passive voice
Exception paths	Mandatory for every key step: not optional
Known system anomalies	Required section when any system quirk affects the process
Formatting	No emoji, analytical prose, no decorative elements
Review path	Peer review, then process owner review, then SCT lead sign-off
Health check routines	Document as process design artefacts: named owner, version, exception paths

SOP Template Standard

All The Organisation process documentation must conform to this template structure. Each section is mandatory. The template applies to all domain prefixes: TRN, LOG, SUP, CUS, ERP, SCT.

Document Header

Field	Definition	Example
Process ID	Hierarchical numeric identifier aligned to the SCT process register	4.1.2.1
Process Level	The level within the hierarchy (L1 to L4)	Level 4
Process Hierarchy	Full path from L1 to the current process level	(L1) 4. Purchasing (L2) 1. Purchase Order Management (L3) 2. Create Purchase Order (L4) 1. Obtain Purchase Requisition
Domain prefix	Applied to the document ID. TRN / LOG / SUP / CUS / ERP / SCT	LOG-4.1.2.1

Required Sections

Section	Content required	Authoring note
Process Purpose	State what needs to be achieved by executing this process. One to three sentences. Declarative, not descriptive.	Lead with the outcome, not the activity
Process Scope	Two sub-sections: (1) What is in scope. (2) What is not in scope: explicit exclusions that prevent boundary ambiguity.	Explicit exclusions are mandatory. A scope with no out-of-scope list is incomplete
High-Level Process Hierarchy	Show where this process sits within the broader L1-L4 model. Diagram or indented list format. Must be consistent with the Process ID and Process Hierarchy header fields.	Use the SCT process register as the source. Do not create new hierarchy levels
Policy	The rules governing this process: what is permitted and what is not. Written as declarative statements.	Policy items must reference the source authority where applicable (e.g. carrier contract, SLA, system rule)
Effort	The amount of work units required to complete this process. State the unit: minutes, hours, or days.	Example: 30 minutes for a standard submission; 2 hours if escalation is required
Frequency	How often this process is executed. State the cadence clearly.	Examples: Daily, Weekly, On-demand, Triggered by carrier notification
Variants	Documented deviations from the standard flow for specific conditions: different business units, warehouses, product categories, carrier types, or order types. Each variant must be named and its deviation from the standard flow explicitly stated.	Do not merge variants into a single flow. Each variant gets its own named subsection
Process Flowchart	Visual swimlane or flowchart covering the standard flow. Each lane represents a role or system.	BPMN notation preferred. Minimum: swimlane with role separation and decision diamonds
Process Details	Step-by-step table covering each process step.	Every step in the flowchart must have a corresponding row in the Process Details table
Terminology	Definitions of all terms, acronyms, and system names used in this document.	Include system-specific terms, internal The Organisation terminology, and carrier or vendor terms
Version Control	Chronological log of all changes to this document. Minimum fields: date of change, author, change details.	Every published version must have a version control entry. No undocumented revisions

Process Details: Step Structure

Each step in the Process Details table must include the following fields. Fields must be completed for every step. Peer review returns steps with empty fields for completion.

Field	Content required
Process Step	Step number and a short descriptive label. Example: Step 1 - Investigate vendor
RACI	Responsible / Accountable / Consulted / Informed: one named role or system per letter. R and A are mandatory for every step
Trigger from	The event, output, or condition that initiates this step
Input	The data, document, or system state required to begin this step
Action	The specific action performed in this step. Imperative voice. One action per step
Output	The result produced by completing this step: a document, system state, notification, or decision
Trigger to	What this step's output triggers next: the next step, an escalation, or a process end
Data	The data fields read or written during this step and the system they reside in
System	The system or tool used to execute this step
Dependency	Any upstream step, external system, or third-party action that must be complete before this step can proceed
Policy	Any specific policy rule that applies to this step, overriding or qualifying the document-level policy
Description	Free-text elaboration where the action field alone is insufficient. Include exception handling and known system anomalies

Process Details Table: Column Structure

Step	RACI	Description	Tools
1 Step name	R: A: C: I:	Trigger from: Input: Action: Output: Trigger to: Data: System: Dependency: Policy:	System / tool name
2
3

Terminology Table Structure

Term	Definition
(term or acronym)	(plain-language definition)

Version Control Table Structure

Date of change	Author	Change details
15 Sept 2021		SOP creation
16 Sept 2021		Reviewed
(date)		(description of change)

Version control rule: Every revision to a published SOP requires a new version control entry before the revised document is submitted for peer review. Senior Team Lead (Senior Team Lead) rejects undocumented revisions at the review gate.

Knowledge Management Standards

All SCT process documentation is part of the Supply Chain Knowledge Management (KM) programme. Standards for classification, maintenance, and quality assurance are defined below.

KM Content Type and Ownership

Element	Definition	Owner
Knowledge Content Type	The classification of the document within the KM hierarchy. For SCT process documents: Process Design, SOP, Policy, Configuration, or Integration. The Knowledge Content Type determines which review cadence and QA standard applies.	SCT Knowledge Content Owner
Knowledge Content Owner	The named individual accountable for the accuracy and currency of a knowledge document. Not the author: the owner. Ownership transfers when a team member changes role. No document may exist without a named Knowledge Content Owner.	Assigned at document creation. Reviewed at each version update
Knowledge Content Owner R&R matrix	A register mapping each knowledge document to its owner by name and content type. Maintained as a Confluence page. Column per person, row per document type.	Senior Team Lead (Senior Team Lead) maintains on behalf of the PA team

KM Register and Visibility Cadence

SCT knowledge content follows a structured visibility and recurrence cadence to ensure all documents remain current and gaps are identified proactively.

Activity	Frequency	Output
Knowledge register gap summary	Reported to SC heads on the standard cadence	Gap register identifying documents without an owner, overdue for review, or missing required sections
People gap identification against KM R&R matrix	On each version update and quarterly	Named gaps: documents where the current owner has changed role or left
Hierarchy ID numbering system for version control register	Established at document creation. Updated on each version increment	Unique hierarchy ID applied to each SOP aligned to the Process ID structure (e.g. LOG-4.1.2.1-v2)
SOP version control and action recurrence cadence review	Quarterly	Review of all SOPs flagged for recurrence action: version history audit, owner confirmation, and next review date set

Knowledge Content Page Structure QA

All new and updated Knowledge Content pages must pass a page structure QA before publication. QA is applied page-by-page.

QA check	Standard	Applied to
Knowledge Content Format Structure QA	Drive completeness of each Knowledge Content page detail. All non-qualified content cannot be published.	All new Knowledge Content pages at creation
QA existing Knowledge Content page structure and format	Systematic audit of existing published pages for structural compliance. Non-compliant pages are flagged and returned to the Knowledge Content Owner for remediation.	Existing published pages on the defined review cadence
QA any new Knowledge Content page structure and format	All new pages pass structure and format QA before publication. QA is performed by a reviewer who is not the author.	All new pages before first publication

Scope of tech-supported QA: Technology can support limited checks on content logic (process structure, missing fields, broken links). Technology cannot replace human QA for: contextual judgment, contract alignment, organisational consensus, and behavioural accuracy. Human Knowledge Content Owner sign-off is mandatory on all content regardless of tech QA result.

10. Incident Management and Continuous Improvement

▼

Incident management operates at two levels: a Contingency Rapid Response process for system or workflow outages, and a standard scorecard-driven process for operational incidents. The Contingency Rapid Response process does not wait for a ticket to initiate. Any system or workflow outage triggers it immediately.

Contingency Rapid Response Process

Trigger: Any system or workflow outage. SCT does not wait for a ticket. The Contingency Rapid Response process activates immediately upon detection, in parallel with or prior to formal ticket creation.

Step	Action	Owner	Output
1	Assign SCT Contingency Response Owner. The first SCT member to confirm the outage nominates or is assigned as Response Owner. Ownership is explicit and named, not shared.	SCT leadership (SCT Operations Manager) or senior available SCT member	Named Response Owner confirmed and communicated within 15 minutes of outage detection
2	Form focus group and initiate kick-off call. Response Owner assembles the relevant SCT specialists and system owners. Kick-off call objective: confirm scope and impact, identify affected systems and customers, assign initial investigation tracks.	Response Owner	Focus group formed. Kick-off call completed. Scope and impact confirmed
3	Open contingency document and begin live capture during the focus group. Document in real time: timeline of events, decision points, data collected, corrective action plans under consideration. The document is the single source of truth for the incident.	Response Owner (document lead). Focus group members (contributors)	Live contingency document with timeline, decision log, data, and corrective action plan
4	Send SCT incident notification email to all relevant SCT stakeholders confirming the outage, current status, and a link to the live contingency document.	Response Owner	SCT incident notification email sent with document link and current status summary
5	Arrange cadence calls until incident closure. Response Owner schedules regular update calls at a frequency appropriate to severity: P1 every 30-60 minutes, P2 every 2-4 hours. Each call updates the contingency document. Cadence continues until the system is confirmed restored.	Response Owner	Cadence call schedule communicated. Document updated after each call
6	Create tickets with full SCT documentation links. Each ticket links to the contingency document, relevant decision log entries, and corrective action items.	Triage Lead (ticket creation). Response Owner (links)	Tickets created with contingency document link, timeline reference, and corrective action tasks
7	Convert contingency documentation to Post-Incident Report at closure. PIR must include: full incident timeline, confirmed root cause, business impact assessment, corrective actions taken, and a structured Preventive Action Plan with named owners and due dates.	Response Owner with Senior Team Lead (Senior Team Lead) review	Post-Incident Report published. Preventive Action Plan with named owners and due dates
8	Communicate PIR and close the incident. Response Owner sends the SCT incident closure notification email with the PIR linked. Email confirms: incident closed, root cause, corrective actions taken, and preventive action plan timeline. Response Owner retains accountability for preventive action items until each is confirmed complete.	Response Owner	SCT incident closure email sent with PIR. Preventive action items tracked to completion

Contingency Document Structure

Section	Content required
Incident header	Incident ID, date/time detected, date/time resolved, system(s) affected, Response Owner, severity
Timeline of events	Chronological log from detection to resolution: what happened, when, who identified it, what action was taken
Decision log	All decisions made: what was decided, who decided, alternatives considered, rationale
Data collected	System logs, error messages, data extracts, screenshots, API responses gathered during investigation
Corrective action plan	Actions taken to restore the system: what was done, by whom, at what time, and the effect
Business impact	Customer impact, order volume affected, operational disruption, estimated financial impact where quantifiable
Root cause (confirmed at closure)	Single confirmed root cause statement. Category: config / process / data / vendor / system bug
Preventive action plan	Structured table: action item, owner, due date, status. Minimum one preventive action per root cause

Contingency vs standard incident: The Contingency Rapid Response process applies to outages: system unavailability, workflow failure affecting multiple orders, or customer-facing service disruption. Individual ticket faults, configuration queries, and data anomalies follow the standard incident handling process below. When in doubt, apply the Contingency Rapid Response process and scale back if not needed.

Standard Incident Handling Process

For operational incidents that do not constitute an outage: configuration faults, data anomalies, individual system errors, and recurring ticket-based issues. Triage Lead performs first-level triage. Senior Team Lead tracks analyst workload and escalation paths.

Standard Incident Handling Checklist

Intake and Triage (Triage Lead)

Log the incident: timestamp, system affected, reporter, initial symptom description
Assign severity: P1 customer-impacting / P2 operational degradation / P3 latent issue
Check if recurring: search incident log before starting fresh RCA
Route to the appropriate analyst (Senior Team Lead tracks capacity and domain ownership)

Root Cause Analysis

Apply 5 Whys or Pareto analysis: identify root cause, not just triggering symptom
Categorise root cause: config error / process gap / data quality / vendor / system bug
Document findings in the scorecard with evidence: not just conclusions

Resolution and Follow-Through

Implement or raise the config fix: document the change and its logic
If vendor-related: document discussion points, agreed actions, and follow-up dates
If the incident revealed a process gap: raise an SOP update or new process design task
Monitor system performance post-fix: confirm the change had the intended effect
Close the scorecard entry: resolution summary, root cause confirmed, recurrence risk rating

JD LINKAGE JD Position Scope — Logistics system incident scorecard and continuous process improvement: "Track and analyse logistics system incident trends to identify recurring root causes, automation gaps, and process inefficiencies. Maintain a logistics incident and configuration change scorecard to support structured performance analysis and visibility. Provide data-driven insights from incident logs to support root cause analysis and identify process and system design gaps."

Incident Scorecard Fields

Field	Content required
Incident ID	Auto or sequential reference
Date / time	When detected; when resolved
System	OMS / ERP / WMS / TMS / Carrier / Other
Severity	P1 / P2 / P3
Root cause category	Config / Process / Data / Vendor / Bug
Analyst owner	Named individual, not the team
Recurrence risk	High / Medium / Low + rationale
SOP update triggered	Y / N: link if Y

Common Transport Stack Incident Patterns

Capability	Pattern	Typical severity	Root cause category
C4	Tracking event gaps: carrier scan events not reaching Aftership, or milestone mapping incorrect. False-delivered status (MobileRejected mapped to Delivered) is a known pattern	P1 if customer-visible	Milestone mapping config
C2	Label generation failure: consignment created in OMS but label not generated or wrong carrier assigned. Check Supplier API to Shippit/Machship transmission and Ship-engine selection logic	P1 if blocking despatch	Config or integration
C1	Quote / carrier selection mismatch: wrong carrier selected or selection rules not firing. Check Ship-engine rules config and Shippit/Machship SLA settings	P2 cost/ops impact	Rules config
C5	Notification not triggered: customer not receiving delivery status updates. Check Central trigger logic first, then Aftership SMS/email pipeline.	P2 CX impact	Trigger logic or Aftership config

11. System Test and Change Management

▼

SCT applies a structured four-level testing model across all new features, configuration changes, and system enhancements. Testing ownership is distributed across Developers, SCT, Operations key users, and Business result owners. No change proceeds to production without completing the applicable levels for its scope.

SCT Four-Level Testing Model

Level	Test type	Owner	Definition and scope
Pre-testing	Business scenario and regression test case creation	Operations key users	Operations key users define and document new feature business scenarios and regression test cases before any development or configuration work begins. Test cases must cover the full range of business conditions the change will affect, including edge cases and variant flows.
Pre-testing	Test case scenario sign-off	Business result owner	Business result owner reviews and approves all test case scenarios before testing begins. Sign-off confirms the test cases reflect the intended business outcome and scope. Testing does not proceed without this approval.
Level 1	Unit test	SaaS developer	Developer-owned test of function effectiveness and performance within individual development components. Validates that each unit of code or configuration behaves as specified in isolation. Completed within the development environment before integration.
Level 2	System integration test (SIT)	SCT	SCT-owned test of parameter handover between system integrations: Central versus SaaS platforms. Validates that data passes correctly across system boundaries, API contracts are met, and no data loss or transformation errors occur at integration points. PA team executes SIT and documents all results against pre-defined test cases.
Level 3	User acceptance test (UAT)	Operations key users	Operations key users walk through new feature business scenarios in the test environment. Test cases authored at pre-testing stage are executed step by step. UAT validates that the system behaves correctly from the operational user perspective. Sign-off at user level is required before proceeding to business acceptance.
Level 3	Business acceptance	Business result owner	Business result owner reviews the UAT outcome and provides formal sign-off that the change meets the intended business requirement. Business acceptance is required before any production deployment is approved. Outstanding defects must be resolved or formally deferred with written justification.
Level 4	Post-deployment system qualification validation	SCT / Operations key users	Validation of the deployed change in the production environment against the same test cases used in UAT. Confirms the deployment was successful and the system behaves in production as it did in test. Defects identified at this stage trigger the standard incident handling process immediately. Validation period and pass criteria must be defined before deployment.

Go-live gate: Production deployment requires: Level 1 unit test completed by developer; Level 2 SIT completed and documented by SCT; Level 3 UAT signed off by Operations key users; Business acceptance signed off by Business result owner. All four gates must be cleared. No exceptions without written deferral approval from SCT leadership.

Testing Ownership Summary

Role	Owns
Operations key users	Business scenario and regression test case creation (pre-testing); UAT execution (Level 3); Post-deployment qualification validation (Level 4, jointly with SCT)
Business result owner	Test case scenario sign-off (pre-testing); Business acceptance sign-off on UAT outcome (Level 3)
SaaS developer	Unit test (Level 1): function effectiveness and performance within development components
SCT (PA team)	System integration test (Level 2): parameter handover between Central and SaaS platforms; Post-deployment qualification validation (Level 4, jointly with Operations key users); Test results documentation; change readiness assessment; defect escalation

PA Team UAT Execution Checklist

Pre-Test Preparation

Confirm scope: what is being tested and what is explicitly out of scope
Identify impacted transport stack capabilities (C1-C5) and downstream system dependencies
Prepare test cases: happy path, known edge cases, and failure modes
Confirm test environment access and data availability before test window opens

During Testing

Execute each test case: record result as pass / fail / conditional pass
Document failures: steps to reproduce, expected vs actual, screenshot or log reference
Flag user impact risks immediately: do not save for the summary document
Confirm integration touchpoints behave as expected: OMS to Ship-engine, TMS to carrier, Aftership to Central

Post-Test and Release

Produce test results summary: cases run, pass rate, open defects, go/no-go recommendation
Document change readiness assessment: include conditional requirements for production release
Support rollout communications: ensure impacted teams know what changed and when
Monitor post-go-live health for agreed period: log anomalies in the incident scorecard

JD LINKAGE JD Position Scope — Testing, Release & Change Support: "Contribute to User Acceptance Test (UAT) and change testing across configuration updates, process fixes, and system enhancements. Document test results, user impact, and change readiness for new releases. Assist with rollout communications and post-change health monitoring."

Ship-engine testing requirement: Validate carrier selection output across a minimum of three order profiles: metro, regional, and bulky. Rule changes in C1 sub-capabilities may produce interaction effects not visible in single-profile testing.

Change Management

Change management governs how SCT plans, executes, communicates, and validates system and process changes. All changes within scope must follow the defined document types and communication standards.

Change Scope

Category	Type	Description
In scope	System customisation	Architecture change; Feature enhancement; Integration change; Logic change; Data mapping change
	System configuration	Database parameter value; UI configuration page business rule change; UI configuration page database parameter value change
	Process change	Process tool change; Process data change
	Knowledge change	Human knowledge source page change; AI knowledge source page change
Out of scope	Process change outside SaaS / system platform product scope	Changes to operational processes that do not involve a SaaS or system platform component
	People change	Organisational structure, role, or personnel changes

Change Management Document Types

Document type	Purpose and owner
Change request document	Formal record of the change request: what changes, why, scope definition, and requestor. Required for all in-scope changes before any work begins
Change impact assessment (SCT position paper)	SCT-authored assessment of the technical and operational impact of the proposed change. Documents dependencies, risks, affected systems, and recommended approach
Testing document	Consolidated record of all testing levels completed: Unit test (developer), System integration test (SCT), User acceptance test (Operations key users), Business acceptance test (Business result owner)
Pre-deployment planning document	Step-by-step deployment plan including rollback procedure, deployment window, responsible parties, and go/no-go criteria
Post-deployment system qualification document	Validation results confirming the deployed change behaves in production as it did in test. Required before hypercare monitoring closes
Knowledge change document	Updated human knowledge source pages or AI knowledge source pages reflecting the change. Must be published before or at the same time as the production deployment
Change log register index	Master index linking all change-related documents for the change. Maintained in Confluence. All document links included before the change is marked complete

SCT Change Notification Channels

All SCT notifications for system changes, technology incidents, schedule changes, and healthcheck updates are sent by email with a Slack cc.

Channel	Address	Used for
Email (primary)	supply_chain_department@organisation.com.au	All SCT system notifications, incident notifications, change communications, and healthcheck updates to the full Supply Chain department
Slack (cc)	supplychain_every1-aaaad7hc3jmjg3nwzzvmkrhtum@organisation.slack.com	Carbon copy of all email notifications to the #supplychain_every1 Slack channel. Ensures visibility for team members who monitor Slack as their primary channel

Change Management Email Template

Subject line format: SCTech System Notification: [ticket no] | [Platform] | [Topic] | [notification sequence]

Field	Content required
Subject line	SCTech System Notification: [ticket no] \| [Platform] \| [Topic] \| [notification sequence]
Launch date and time	Exact date and time of the change deployment or event
Who does this affect	List the teams affected by this change
System platform	The system or platform where the change occurred
Purpose	Complete description of the change being made and why it is being made. Sufficient detail for a non-technical recipient to understand the business reason
What are the impacts	Describe the operational impact of the change. Attach or link screenshots to show the changes where applicable
SCT action	Any action SCT must take as part of or following the change. Example: Hypercare monitoring for 2 business days post-deployment
Reference links	All relevant ticket links and Confluence articles where RCAs, test results, and change documentation are recorded

Notification sequence convention: Use sequential numbering when a change requires multiple notifications (e.g. 1/3 for initial advisory, 2/3 for deployment confirmation, 3/3 for closure).

12. Master Data and Configuration Governance

▼

Master data and configuration governance is a secondary function within the PA team. The team operates in a backup capacity to the product owner squad. All changes must be documented, traceable, and validated against operational rules before deployment to live systems.

Supply Chain Data Type Reference

Supply chain data type	Definition	Data nature	PA governance implication
Master data (Digital twin)	Core data that remains consistent across business processes, such as product information, supplier details, and customer records. Examples: inventory availability-to-promise feed, carrier zone and skillset serviceability, carrier contract service zone rate, warehouse bin location stocks.	Snapshot	Change affects multiple systems simultaneously. Validation routine required before and after. Approver sign-off mandatory. Notify all integration-dependent system owners.
Configuration data (Decision)	Settings, logic, parameters or instructions that define how processes and systems are executed, such as workflow rules and system preferences. Examples: customer order under open status, warehouse bin putaway strategy.	Snapshot	Change requires config log entry with before/after values. Logic assumption must be documented. Post-change system qualification required before marking complete.
Record data (History)	Data generated from day-to-day business activities, such as closed orders, shipments, and invoices.	Transaction	Immutable once created. Governance focus is audit trail completeness, not change control. Any correction requires a documented adjustment record, not an overwrite.

Master Data and Config Checklist

Data Quality and Approvals

Validate the data change request against operational rules and reporting dependencies before approving
Confirm the change aligns with integration dependencies across OMS, ERP, WMS, and TMS
Run applicable validation routine or data quality check before and after the change
If cleansing: document scope, method, rows affected, and outcome

Configuration Documentation

Document the config change: what changed, why, what logic assumption it reflects
Record the attribute update in the system config log: not just in a ticket comment
Trace the change back to the originating SOP or process decision: link in the log

Audit and Reporting

Generate audit report entry: approver, date, reference
Confirm no downstream reporting queries or dashboards are broken by the change
Notify the relevant product owner that the change has been applied and is traceable

JD LINKAGE JD Position Scope — Master Data & Configuration Governance: "Serve as gatekeeper for product master data approvals, quality control, and lifecycle updates across ERP, OMS, TMS, and WMS. Ensure alignment of master data with operational rules, reporting needs, and integration dependencies. Document system configuration changes, logic assumptions, and attribute updates for supply chain platforms. Maintain traceability of configuration changes as per logistics SOPs and stakeholder responsibilities."

System Scope Reference

System	Scope within PA governance
OMS (Central)	Order lifecycle, customer data, fulfilment logic, notification triggers
ERP (SAP B1)	Finance, inventory, supplier master
WMS	Warehouse locations, pick rules, 3PL config
The Organisation Ship-engine	Carrier selection rules, quote logic, route decisions
Shippit / Machship	Carrier integration, label generation, consignment config
Loginext (TMS)	Vehicle config, trip planning, driver app settings
Aftership	Tracking event mapping, milestone rules: being simplified to pure transfer

Scope boundary: PA team role in master data is backup and governance support. Changes affecting live integrations or customer-facing data require product owner approval before the PA team executes.

13. Onboarding: 30 / 60 / 90 Day Plan

▼

Structured 90-day onboarding plan. Priorities are sequenced: system access first, then internal domain inductions, cross-department introductions, vendor inductions, pilot domain ownership, and a formal evaluation session. Priorities 1-5 must be substantially complete before Priority 6 is initiated.

Onboarding Priority Sequence

Priority	Activity and scope	Owner	Completion criterion
1	System access provisioning: OMS/Central, SAP B1, WMS, Loginext, Shippit, Machship, Aftership, Ship-engine, ticket system, process register, SOP library	SCT Operations Manager / IT	All systems accessible and verified by end of day 1
2	Internal SCT 1-on-1 inductions: SME domain sessions. Individual induction session with each SCT team member covering their domain: Senior Team Lead (Senior Team Lead) (transport stack and process methodology), Triage Lead (triage and ticket flow), Process Analyst A (rate changes and carrier onboarding), Process Analyst B (supplier operations), Process Analyst C (daily operations and system health). Each session covers domain scope, current workload, known issues, and open SOP gaps.	Senior Team Lead (Senior Team Lead) coordinates	5 induction sessions completed. Notes documented. Domain map reviewed with Senior Team Lead
3	Cross-department manager inductions: Introduction meeting with the operational lead for each partner department: Transport, Supplier Operations, Logistics/Warehouse, Customer Care, Product Category, Planning, Buyer/Merchandising. Understand their team's primary interface with SCT, current pain points, and preferred communication channel.	SCT Operations Manager schedules. New analyst leads	7 department inductions completed. Contacts and escalation paths logged
4	The Organisation internal networking: Attend relevant team standups, planning sessions, and cross-functional meetings as observer. Build working familiarity with The Organisation operational vocabulary, team structures, and decision-making channels.	Self-directed with Senior Team Lead guidance	New analyst can name key contacts and locate any The Organisation team in the directory
5	Tech vendor inductions: Induction sessions with primary technology vendors: Shippit, Machship, Loginext, Aftership. Each session covers: current integration scope, support channels, known issues, enhancement request process, and vendor roadmap as it affects The Organisation.	Senior Team Lead (Senior Team Lead) arranges. New analyst attends with a senior analyst	4 vendor induction sessions completed. Support channel references documented
6	Pilot domain ownership handover (1 domain): Take full ownership of one assigned process domain. Outgoing analyst or Senior Team Lead produces a formal written handover: current-state documentation, open incidents, SOP status, known anomalies, and pending work items. New analyst assumes accountability from handover completion date.	Senior Team Lead (Senior Team Lead) assigns domain and signs off handover	Handover document complete and signed. New analyst passes 30-minute domain knowledge review with Senior Team Lead
7	SCT leadership 1-on-1 feedback and evaluation session: Weekly 1-on-1 with SCT Operations Manager (SCT Operation Manager) commencing from week 1. Agenda: progress against onboarding priorities, blockers, quality of outputs, skill gap identification, and development goals. At 90-day mark: formal evaluation session with documented assessment, 6-month development goals agreed, and domain expansion plan confirmed.	SCT Operations Manager schedules weekly from day 1	Evaluation documented. Development goals agreed and filed. Domain expansion plan confirmed

Onboarding sequencing rule: Priorities 1 through 5 must be substantially complete before Priority 6 (pilot domain handover) is initiated. A new analyst who takes domain ownership before completing vendor and cross-department inductions will lack the context needed to manage incidents and stakeholder requests in that domain.

30 / 60 / 90 Day Execution Checklist

Days 1-14: Access, Induction, and Orientation

Provision and verify access to all systems: OMS, SAP B1, WMS, Loginext, Shippit, Machship, Aftership, Ship-engine
Complete 1-on-1 induction session with each SCT team member: document domain notes
Complete induction meeting with each cross-department manager: log contacts and escalation paths
Attend standups and cross-functional meetings as observer: build operational familiarity
Complete induction session with each tech vendor: document support channels and open issues
Read this playbook in full: confirm understanding with Senior Team Lead
Read all published SOPs in assigned domain: log gaps and outdated references

Days 15-30: Structured Learning and Shadowing

Shadow Triage Lead through a full triage week: observe ticket classification, escalation decisions, and stakeholder communication in real time
Shadow Senior Team Lead through one complete incident RCA: observe how root cause is identified, documented, and converted into a preventive action
Shadow Process Analyst B or Process Analyst A through one end-to-end rate change or carrier config task: observe the full execution and documentation sequence
Pass a documented knowledge check on the transport stack (C1-C5): self-assess first, Senior Team Lead (Senior Team Lead) administers and confirms
Identify three process gaps or documentation inconsistencies in the assigned domain SOPs: document findings and present to Senior Team Lead
Co-author one SOP section with a peer analyst under supervision: review and input only, not independent ownership
Contribute test cases to one active UAT cycle under supervision
Complete one ticket triage alongside Triage Lead: Triage Lead makes the call, analyst documents the reasoning
Day 30 readiness gate: Senior Team Lead reviews domain gap findings, confirms system access is functional across all platforms, confirms all induction notes are documented and filed

Days 31-60: First Outputs and Domain Preparation

Receive and review pilot domain handover document from outgoing analyst or Senior Team Lead
Lead first independent discovery session with peer support: produce current-state map
Author and publish first SOP through the full review path
Own two incident scorecard entries end-to-end including post-fix monitoring
Contribute independently to one UAT cycle: produce test cases and results summary
Set up personal task tracker aligned to the team format
60-day check-in with Senior Team Lead (Senior Team Lead): domain knowledge review and first output quality assessment

Days 61-90: Domain Ownership and Evaluation

Complete pilot domain handover: signed off by Senior Team Lead (Senior Team Lead) after 30-minute knowledge review
Assume full ownership of assigned domain: process design, incident triage, UAT
Lead one external vendor or carrier meeting: document agreed actions
Peer-review one SOP draft authored by another analyst: provide written feedback
90-day evaluation session with SCT Operations Manager: outputs and assessment documented
Agree development goals and domain expansion plan with SCT Operations Manager

Appendix: Reference Documents

▼

Four SCT documents provide the source architecture, process frameworks, and operating model that this playbook is built upon. Process Analysts are expected to be familiar with all four.

Process Analyst Writing Style Guideline

Core Principles

Write in technical specification style: declarative, direct, no narrative framing.
Lead with the conclusion. Follow with reasoning, then supporting data (Barbara Minto Pyramid Principle). This is a communication structure rule, not an analytical one: complete the evidence-based analysis first, then present the output conclusion-first.
Answer the question first. Justify second.
State results and decisions directly. Do not build to a conclusion.
Active imperative language throughout. Steps are commands, not descriptions.
No passive voice where accountability can be stated explicitly.
Use full name before (short name) on first use. Example: Supply Chain Technology (SCT), not SCT alone on first reference.

What to Avoid

No filler phrases: Let's, We can, I'll go ahead and, This section captures, The following standards define.
No storytelling or narrative framing.
No first-person plural (We, Our) in specification content. Use role names or team names explicitly.
No emoji anywhere.
No decorative elements or qualitative padding.
No see section N or as above positional language.
No the following as a sentence opener when a colon already introduces the list.

Sentence and Paragraph Structure

One idea per sentence in specification tables.
Bullet items are complete statements, not fragments.
Every cross-reference names the full title, not just a number.

Terminology and Specificity

All named roles are explicit: use proper names, not the team leader or management.
All escalation levels are named in context when first introduced.
All operating principles referenced by number must include the full principle title.
Named outputs are specific artefacts: SOP, config log entry, incident scorecard entry. Do not use "documentation" or "a record".
Metrics cite a measurable target, not a qualitative aspiration.

Table Content Rules

Column headers: bold, concise noun phrases.
Cell content does not repeat the column header.
Does not meet standard column: specific failure descriptions, not generic negations of the Meets column.
Tip boxes: bold label prefix followed by the specification. No narrative.

Professional Communication and Escalation

Lead with observed facts, not an accusation or a Why question. State what was detected, when, and what the impact is.
Broadcast messages (@here, @channel) must contain: what happened, what is the impact, and what action is being taken. Not a question to the group.
Reserve escalation broadcasts for confirmed incidents with known impact. Questions and investigations go to the direct owner first.
All incident communications follow the SCT notification format: what changed, who is affected, what SCT is doing, and reference links.
Do not assign blame in written communication. Describe the system or process gap, not the person who triggered it.

UI and Design

Use a simple earth tone colour theme. Primary palette: black, white, grey, and teal in varying shades. Reserve orange strictly for key information highlights.
All tables must be uniform in width. Text must never overflow or overhang the table or header boundaries.
No rounded corners on headers or title bars.
Section headers (ColorBar) span the full usable page width. Tables sit inside the header width.

Reference Documents

#	Document	Author	Description	Link
1	SCT Transformation Approach	Product Squad Lead	Defines the end-to-end Supply Chain Technology project methodology and deliverables. Covers the five-stage transformation approach (Business strategy, Design principles, Process design, Technology landscape, Change methodology), the Design-to-Deploy framework, sprint methodology, CAB approval gates, and the cross-functional business analysis framework. This is the reference for how SCT approaches all project and change initiatives.	Open document
2	SCT Tech Stack: Architecture Model and Integration Flow Diagrams	Logistics Solution Architect	Contains the full set of SCT technology stack architecture diagrams including Delivery Tech (SAP B1, Carrier integrator, Aftership, Loginext), Interactive Tech (Salesforce, CXOne, Ada/Sage chatbot, Workato), Transport Tech stack vision (five-capability model C1-C5), ERP Tech stack vision, Supplier Operations Tech stack vision, end-to-end fulfilment integration flow diagrams, and all system integration model diagrams including Central, SAP, Shippit, Machship, Loginext, and Aftership. This is the primary architecture reference for all PA team technical work.	Open document
3	SCT Capability and Process Hierarchy Map	Transport Tech Lead	Defines the full The Organisation Supply Chain functional capability and process hierarchy from Level 1 capability to Level 4 business activity. This is the canonical source for all Process IDs, process group names, and the hierarchy structure used in SOP document headers. All SOPs authored by the PA team must trace their Process ID back to this hierarchy map. Process Analysts must read this document before authoring any new SOP.	Open document
4	SCT Agile Way of Working	Process Lead	Describes the SCT agile operating model including team structure and responsibilities across the four SCT sub-teams (Delivery Technology, Process Automation and B2B Solutions, Service and Workforce Technology, Transformation and Knowledge), the CAPA (Corrective and Preventive Action) approach to problem identification and RCA, data-driven decision making principles (pyramid principle, Pareto, 5 Whys), weekly work plan cadence, and the SCT supply chain gaps identification approach. This is the reference for how the PA team approaches daily operations, continuous improvement, and stakeholder engagement.	Open document

Supply Chain Technology (SCT)Process Analyst (PA) Playbook

1. SCT Context: Vision, Mission and Principles

SCT Vision, Mission and Platform Scope

Our Role and Responsibilities

Our Principles

2. The Process Analyst Role

Team Design Rationale

Role Purpose

Eight Operating Principles

Process Analyst Asset Register

Optimise: Present System Configuration

Respond: Past Incidents

Innovate: Future Adaptive Technology

3. Team Structure and Responsibilities

Process Analyst Talent Pool: Process Analyst A, Process Analyst B, Process Analyst C

4. Skills and Quality Required

Technical Skills

Professional Skills

Experience Requirements

Disqualifying Behaviours

5. Operating Model: How We Work

Dimension 1: How the PA Team Works Internally

Work intake and flow

Output quality gates

Dimension 2: PA Team Within SCT and Tech Group

Dimension 3: PA Team with Cross-Department Partners

Cross-Department Engagement Rules

6. Definition of Great and Productivity Metrics

Definition of Great: Output Quality Standards

Team Productivity Metrics

7. Transport Tech Stack: Five Capabilities

8. Supplier Ops Tech Stack

Expected Scope

9. Process Design and SOP Standards

Supply Chain Capability Process Hierarchy

Process Design Checklist

Scoping and Discovery

Current-State Mapping

Future-State Design and Sign-Off

SOP Authoring Standards

SOP Template Standard

Document Header

Required Sections

Process Details: Step Structure

Process Details Table: Column Structure

Terminology Table Structure

Version Control Table Structure

Knowledge Management Standards

KM Content Type and Ownership

KM Register and Visibility Cadence

Knowledge Content Page Structure QA

10. Incident Management and Continuous Improvement

Contingency Rapid Response Process

Contingency Document Structure

Standard Incident Handling Process

Standard Incident Handling Checklist

Intake and Triage (Triage Lead)

Root Cause Analysis

Resolution and Follow-Through

Incident Scorecard Fields

Common Transport Stack Incident Patterns

11. System Test and Change Management

SCT Four-Level Testing Model

Testing Ownership Summary

PA Team UAT Execution Checklist

Pre-Test Preparation

During Testing

Post-Test and Release

Change Management

Change Scope

Change Management Document Types

SCT Change Notification Channels

Change Management Email Template

12. Master Data and Configuration Governance

Supply Chain Data Type Reference

Master Data and Config Checklist

Data Quality and Approvals

Configuration Documentation

Audit and Reporting

System Scope Reference

Supply Chain Technology (SCT)
Process Analyst (PA) Playbook