SOP Analyst

AMain.com, Inc.Chico, CA
Onsite

About The Position

The SOP Analyst is the documentation and measurement engine of AMain’s new SOP & Process Improvement function, working alongside a Process Improvement Engineer and IT Automation Experts to systematically inventory, analyze, redesign, implement, measure, and codify the way every department actually works. This role exists to move AMain from a hero-driven organization, where knowledge lives in a few people’s heads, to a process-driven organization where work is documented, owned, improved, and survives turnover. The Analyst owns the bookends of the improvement lifecycle — discovery and documentation up front, impact measurement and codification at the end — and collaborates with the Engineer and Automation team on redesign and implementation in the middle. OPERATING APPROACH Document what actually happens, not what is supposed to. Before improving a process, ask whether it needs to exist at all. Measure impact rather than assume it. Codify what works into living SOPs that survive turnover and scale. Walk the floor, sit with the team, observe before recommending — and ship a workable v1 SOP rather than waiting for the perfect one.

Requirements

  • 2-5 years of experience in business analysis, process analysis, operations, internal audit, project coordination, or a comparable analytical role with hands-on process documentation.
  • Strong process documentation skills — proficient with flowcharts, swimlanes, and structured SOP writing.
  • Advanced Excel skills (pivots, lookups, structured workbooks) and comfort quantifying process metrics from messy data.
  • Demonstrated ability to interview stakeholders, observe processes, and translate unstructured operational reality into clean documentation.
  • Strong written and verbal communication — the deliverable is a document that someone else will follow.

Nice To Haves

  • Familiarity with Lean, Six Sigma, BPM/BPMN, Kaizen, or similar improvement methodologies (not required — strong process instincts matter more than the belt).
  • Bachelor’s degree in business, industrial engineering, operations management, supply chain, information systems, finance, or equivalent professional experience.
  • Background in retail, distribution, multi-channel e-commerce, or other multi-site operations.
  • Hands-on experience with documentation platforms (SharePoint, Notion, or similar) and version control.
  • Working knowledge of BI / dashboarding tools (Power BI, Tableau, Looker).
  • Exposure to SQL or comparable querying for pulling baseline and impact data.
  • ERP / WMS / CRM exposure
  • Experience supporting internal audit, SOX, or compliance documentation efforts.

Responsibilities

  • Build and maintain a master inventory of all department processes (Purchasing, Merchandising, Distribution Sales, Warehouse, Customer Service, HobbyTown corporate stores, IT, Finance, HR, Marketing) — what each department does, who owns it, how often it runs, and what triggers it.
  • Map current-state processes using flowcharts, swimlanes, and step-by-step SOPs. Capture what actually happens, not what people say is supposed to happen.
  • Interview process owners, do-ers, and downstream consumers. Walk the floor — warehouse, CS desk, buying desk, retail stores — and observe processes in flight. Document edge cases and exceptions.
  • Establish and maintain documentation standards (format, naming, version control, ownership, review cadence) so every SOP is structured the same way and easy to find.
  • Own the centralized SOP repository (SharePoint, Notion, or equivalent). Every active process should have a single, current, owned source of truth.
  • Quantify each process — time per execution, frequency, fully-loaded labor cost, error rate, downstream impact.
  • Identify bottlenecks, redundancies, hand-off friction, rework loops, and low-value steps. Surface the “do we need this at all?” candidates — processes that exist out of habit, not necessity.
  • Rank improvement opportunities by impact (time / cost / error / risk) and feasibility. Bring a prioritized backlog to the team rather than a long list of complaints.
  • When something breaks repeatedly, dig past the symptom to the process or system root cause and document it for the redesign conversation.
  • Partner with the Process Improvement Engineer to design future-state processes. Validate whether a process should be killed, simplified, automated, or kept and tightened.
  • Bring the people who do the work into the redesign conversation; their friction signals are the most valuable input. Capture trade-offs and dissents.
  • Document the redesign rationale — what changed, why, what was considered and rejected — so the decision survives turnover.
  • Translate redesigned processes into requirements the Automation Experts and IT can build against. Crisp inputs / outputs / exception paths, not vague intent.
  • Coordinate change management with affected departments — training, communication, cutover timing, fallback plans. Adoption is part of the deliverable, not someone else’s problem.
  • Update the SOP library to reflect the new process the moment it ships. Old SOPs get archived with a “superseded by” pointer; they don’t silently expire.
  • Before any change ships, define and capture the baseline metrics it is supposed to move (time, cost, error rate, throughput, customer impact, audit findings).
  • Measure the same metrics 30, 60, and 90 days after the change ships. Report the actual delta, not the expected one.
  • Roll measured impact into a quarterly Process Improvement scorecard — total dollars and hours saved, errors prevented, processes retired — for leadership review.
  • When a change didn’t hit its target, report that clearly. A failed change with honest measurement is more valuable than a “success” with no data.
  • Maintain SOPs as living documents — assigned owner, last-reviewed date, scheduled review cadence. SOPs that haven’t been reviewed in 12+ months get re-validated, not assumed correct.
  • When measurement shows a change underperformed, take it back through the cycle. Iteration is the default, not a sign of failure.
  • Build training materials, run walkthroughs with affected teams, and confirm adoption. A documented process that no one follows is the same as no process.
  • When a redesign solves a problem cleanly, codify the pattern so other departments can apply it without re-discovering.
© 2026 Teal Labs, Inc
Privacy PolicyTerms of Service