This page is a professional portfolio showcasing my work as an IT Business Process Consultant in discrete manufacturing. It includes a brief overview of my focus areas, selected case studies, and sample deliverables that demonstrate how I support ERP enablement, UAT/BIT testing, and change adoption across planning, execution, inventory, and quality.
How to Navigate This Page
Please feel free to review the information provided from start to finish. However, if you want to jump around in the document, I have provided recommendations based on area of interest:
- Interested in requirements/testing, start with Requirements, Traceability, and Testing Approach
- Operations Focused, go to Case Study 3 (feasibility/capacity)
- IT focused, start with UAT/BIT + Roadmap Governance
Who am I and What is My Approach?
I focus on helping discrete manufacturers run more smoothly by aligning people, process, and systems.
I bridge manufacturing operations and technical implementation by:
- Translating real work into clear requirements
- Validating end-to-end workflows through UAT and Business Integration Testing
- Partnering with change management to drive adoption
- Defining metrics that prove value generation. In high-variation environments, I treat people as part of every equation and design solutions that match real behavior, build trust in the data, and make the standard way the easiest way.
In high-variation environments, I treat people as part of every equation and design solutions that match real behavior, build trust in the data, and make the standard way the easiest way.
What I Bring to a Manufacturing Organization
- Bridge Business + IT:
- Translate manufacturing needs into testable requirements and workflows
- End-to-end optimization:
- Map As-Is/To-Be, identify constraints, standardize handoffs and exception handling
- Delivery rigor:
- Build repeatable UAT and Business Integration Testing programs; defect triage; signoffs
- Adoption + change:
- Partner with Business Change Management; resistance planning; role-based training
- Value realization:
- Define KPIs, baseline performance, monitor outcomes post-implementation
- Roadmap + documentation:
- Develop system/process roadmaps and preserve institutional knowledge
Why This Matters for You
- For a Supply Chain Business Relationship Manager:
- I emphasize value delivery, prioritization, stakeholder partnership, adoption, and measurable KPIs (schedule adherence, OTIF, inventory accuracy, shortages, expediting).
- For Senior SAP Functional Analysts:
- I emphasize manufacturing planning and execution discipline (MRP, capacity constraints, production orders, confirmations) plus master data governance (BOMs, routings, work centers) and a rigorous UAT/BIT testing approach.
- Bridge (all three):
- I translate real manufacturing work into testable requirements, validate end-to-end workflows, and land changes with training, governance, and metrics so the system outputs are trusted in day-to-day operations.
IT-First Delivery: UAT/BIT + Roadmap Governance
IT delivery rigor that protects operations and proves value” (not “testing for testing’s sake”).
- UAT and Business Integration Testing (BIT) as controls, not a phase:
- I use UAT/BIT to prove end-to-end readiness across planning, execution, inventory, quality, and reporting so operations are not the test environment.
- Traceability that prevents rework:
- I maintain a clear chain from business goal → requirement/user story → acceptance criteria → UAT cases → BIT scenarios → defects → release notes → training → KPIs.
- Defect triage discipline (root cause + operational risk):
- I drive fast, structured triage to separate configuration vs code vs data vs process/training issues; I prioritize fixes by production and supply chain impact, then validate with retest criteria.
- Roadmap governance that stays connected to value:
- I translate requests into a prioritized backlog with dependencies, decision points, and success measures (KPIs and adoption), keeping stakeholders aligned on what ships next and why.
- Cadence and decision rights:
- I establish a predictable rhythm (prioritization, design reviews, defect triage) with clear ownership for approvals, exceptions/overrides, and go-live readiness.
- Go-live and stabilization readiness:
- I define entry/exit criteria for release, coordinate cutover readiness (including support handoff), and monitor early-life performance so changes stick and value is realized.
Roadmap Governance Model
How work moves from idea to release.
Delivery FLow: Simple, Repeatable
Intake → Discovery → Solution design (functional + technical) → Prioritize backlog (value, risk, dependencies) → Build/config + integration → UAT → BIT (end-to-end) → Release + cutover → Training + adoption → KPI review → Continuous improvement
Governance Rules: What keeps it controlled
- Cadence:
- Weekly backlog + defect triage; biweekly design/integration review; monthly roadmap review with KPI readout.
- Decision rights:
- Clear owners for scope, priority, exception/override approvals, and go/no-go release decisions.
- Definition of ready / done:
- Entry and exit criteria for build, UAT, BIT, and release (no “soft done” without test evidence and support readiness).
- Dependency visibility:
- Integration touchpoints, data readiness (master data), environment readiness, and cross-team handoffs tracked explicitly.
- Change control + documentation:
- Versioned requirements, release notes, training updates, and support runbooks so operations and IT can sustain the change.
Selected Case Studies
Each case study refers to work completed during my employment at The Wittern Group as a Technical Business Analyst
Case Study 1
Structured ERP improvement program (cadence + backlog + governance)
Challenge: reactive support and scattered priorities; limited visibility to value and progress.
My role: helped structure proactive improvement with stakeholders and consultants.
What I did: established cadence, work packet/backlog approach, success criteria, and impact awareness.
Outcome: clearer ownership, predictable decision points, and sustained execution rhythm.
Manufacturing system lens: Protected end-to-end impacts across planning, execution, inventory, and reporting so improvements did not create downstream surprises.
See Case Study 1: Expanded for further information
Case Study 2
Cross-functional workflow and data improvements (traceability + usability)
Challenge: processes that technically “work” but break in real operations due to handoffs, exceptions, and data trust.
My role: defined workflow requirements and validated outputs with stakeholders before treating work as “done.”
What I did: scoped process, aligned ownership/definitions, and ensured outputs supported real decisions.
Outcome: improved visibility and reduced workarounds because teams could trust and use the workflow.
Manufacturing system lens: Defined exceptions, handoffs, and ownership so workflow outputs became decision-grade, not just technically correct.
See Case Study 2: Expanded for further information
Case Study 3
Manufacturing planning reality check (feasibility, shortage noise, capacity/staffing)
Challenge: schedule feasibility and shortage signals not consistently trusted; manual workarounds and firefighting.
My role: synthesized constraints into prioritized improvement actions and clarity on what must be true for planning signals to be trusted.
What I did: analyzed feasibility drivers, staffing/capacity assumptions, and process/system gaps.
Outcome: practical action path to stabilize planning signals and reduce operational noise.
Manufacturing system lens: Focused on the trust chain: master data and execution signals first, then planning outputs (MRP and capacity) become reliable.
See Case Study 3: Expanded for more information
Requirements, Traceability, and Testing Approach
I partner closely with stakeholders and delivery teams to keep work testable, traceable, and adoptable from discovery through rollout.
My goal is to make the work feel clear and manageable for everyone involved. That means asking the right questions up front, capturing not just the happy path but the real exceptions and handoffs, and documenting requirements in a way that people can build, test, and confidently use. I also keep traceability in place from the original business goal all the way through testing, release, training, and the KPIs we use to confirm the change is working.
How I keep work testable, traceable, and adoptable
- Discovery includes exceptions, handoffs, and decision points, not just happy paths.
- Requirements cover process + data + roles, plus upstream and downstream impacts.
- Acceptance criteria define clear pass/fail conditions.
- Traceability is maintained from goal → requirement → test → release → training → KPI monitoring.
Traceability model
Business goal → Process step → Requirement/User story → Acceptance criteria → UAT cases → BIT scenarios → Defects → Release notes → Training → KPIs
Requirements Traceability Matrix (RTM) sample
This table shows how I maintain traceability from business goal to requirements, testing, release, training, and KPIs.
| RTM ID | RTM-Exec-001 |
| Business Goal | Improve planning accuracy by ensuring execution transactions reflect reality (materials, labor, yields, completion timing) |
| Process Step | Production execution: release → issue/backflush → confirm operations → record scrap/rework → receive/close |
| Requirement / User story | Production execution must capture timely and accurate confirmations (quantities, time, scrap/rework) so MRP and capacity planning outputs are reliable. |
| Acceptance Criteria (pass/fail) | Timely confirmations: Given an operation is completed, when confirmations are entered, then the confirmation date/time reflects the actual completion window (not end-of-week batching) per defined policy. Capacity feedback loop: Given labor or machine time is confirmed, then actual time is recorded (or a controlled standard is applied) so planners can compare planned vs actual and refine routings/labor standards. Material consumption integrity: Given components are issued/backflushed, then consumption is captured at the appropriate step and exceptions (short issue, substitute, over-issue) are recorded with a reason code. Scrap/rework impact: Given scrap or rework occurs, then quantities and reason codes are captured and the impact is visible to planning (supply shortfall, additional capacity, or rework routing as applicable). Order close readiness: Given an order is closed, then required execution transactions are complete (issues/confirmations/receipts) or an exception is documented and approved. |
| UAT Case(s) | UAT-EXEC-001; UAT-EXEC-002; UAT-EXEC-003; UAT-EXEC-004; UAT-EXEC-005 |
| BIT Scenario(s) | BIT-EXEC-001 (Schedule → release → execute → confirmations → MRP impact); BIT-EXEC-002 (Scrap/rework → updated supply/capacity → replanning) |
| Defect(s) | DEF-_ |
| Release Notes | REL-_ |
| Training | TRN-EXEC-001; TRN-EXEC-002; TRN-EXEC-003 |
| KPI(s) | Confirmation timeliness %; Planned vs actual labor variance; Inventory consumption variance; Scrap/rework rate; Schedule adherence improvement |
| Status | Draft |
Master data governance
Planning Trust Starts Here
In manufacturing planning, master data is a governed business asset. I drive clear ownership and change control for BOMs, routings, work centers, and planning parameters; then I validate high-risk scenarios in UAT/BIT and monitor exceptions with metrics to prevent planning noise and shop-floor workarounds.
Selected Case Studies: Expanded
Case Study 1: Expanded
Structured Improvement Program and Consulting Partnership
Context: The Wittern Group (discrete manufacturer of vending machines); manufacturing ERP improvement and support operating model with consulting partnership.
Problem: Reactive support and disconnected priorities reduced confidence and slowed value realization.
What I did (high level):
- Established a consistent operating cadence for alignment and decisioning
- Structured work as a prioritized backlog/work packets with justification and dependencies
- Reinforced end-to-end thinking to avoid changes that ignore upstream/downstream impacts
- Anchored success criteria and reporting rhythm to support continuity and transparency
People play into every equation: Governance and cadence work only when stakeholders are engaged, decision rights are clear, and outcomes are tied to how people actually execute work.
Case Study 2: Expanded
Cross-Functional Workflow and Data Improvements
Context: The Wittern Group (discrete manufacturer of vending machines); cross-functional improvements spanning operations, engineering, and business functions.
Problem: Technical changes can fail if definitions, ownership, and exception handling are unclear, or if outputs are not trusted.
What I did (high level):
- Aligned stakeholders on process intent and success criteria
- Mapped handoffs and exceptions so real work was represented
- Defined requirements for workflow steps and decision-support outputs
- Validated that the workflow reduced friction, not added it
People play into every equation: If a workflow adds ambiguity or cognitive load, teams create workarounds. Adoption is designed, not assumed.
Case Study 3: Expanded
Feasability, Capacity, Shortage SIgnals, and Trust
Context: The Wittern Group (discrete manufacturer of vending machines); discrete manufacturing planning and execution with real-world constraints.
Problem: If feasibility signals and shortage logic do not match reality, planners and supervisors stop trusting the system, and manual planning takes over.
What I did (high level):
- Identified feasibility drivers (materials + staffing + routings + capacity assumptions)
- Highlighted sources of noise (false signals) and their operational impact
- Converted constraints into prioritized improvement actions and metrics to monitor
People play into every equation: Trust in signals determines behavior. When trust drops, the system becomes optional and variability increases.