← Back to Case Studies
Systems & Automation

Operational Control System for Multi-Location Retail/Distribution

A demonstration system built to show how growing retail and distribution companies can move from reactive firefighting to forward visibility, proactive ordering decisions, and working capital awareness.

Purpose
Business Intelligence & Process Automation
Target Audience
Founders, COOs, Operations Directors, CFOs
Type
Operational Decision Modeling
Approach
Systems thinking, constraint modeling
View Live Demo View on GitHub
Background

Context

At a certain stage of growth, multi-location retail and distribution companies face a predictable inflection point. What worked at two or three locations stops working at eight. The owner or operations director can no longer hold the entire inventory picture in their head. Stockouts happen at one location while excess inventory sits at another. Cash gets tied up in dead stock, but there is no clear signal until it is already a problem.

The business is not failing. It is simply outgrowing informal coordination. Decisions that used to be intuitive now require data. But that data is scattered across spreadsheets, supplier emails, and individual recollections.

I built this system to demonstrate what operational control actually looks like at this stage. This is not about scale or enterprise complexity. This is about visibility, constraint modeling, and decision clarity.

What wasn't working

Operational Problem

Before structured systems, operations at this stage typically struggle with the following:

Inventory decisions made reactively, location by location, without cross-location visibility

Cash flow surprises due to supplier payment terms not being tracked systematically

Stockouts at high-velocity locations while slow-moving inventory accumulates elsewhere

No systematic way to identify dead stock until it becomes obvious

Purchase orders issued without clear understanding of cash impact over the next 30, 60, or 90 days

Dependency on spreadsheets that require manual updates and are prone to versioning issues

Before structured control

AS-IS & TO-BE Process

Without a system, operations typically work like this: store managers notice stock levels getting low and send informal requests to the central office. Someone manually checks supplier availability and pricing. Another person reviews what cash is available. A purchase order is eventually created, but there is no automated check for whether this will cause a stockout elsewhere or whether payment terms will create a cash crunch next month.

The process is fragmented. Decision-making is reactive. Leadership has no consolidated view of what is happening across locations until problems surface.

AS-IS vs TO-BE Operational Process Diagram

The diagram above illustrates the shift from fragmented, reactive workflows to an automated, proactive system where decisions are informed by real-time data and clear constraints.

How I framed the problem

My Approach

I approached this as a systems modeling exercise, not a UI project. The goal was to demonstrate how operational clarity emerges when you model constraints first and automate decisions second.

I started by defining the constraints that govern real-world retail and distribution operations:

  • Supplier lead times determine when stock needs to be reordered
  • Sales velocity determines how much to reorder
  • Margin structure determines which products are worth prioritizing
  • Payment terms determine when cash actually leaves the business
  • Location-specific demand patterns determine allocation logic

Once those constraints were clear, the system design followed naturally. This was not about inventing features. This was about modeling reality and making it visible to decision-makers.

I treated this as a systems exercise, not a UI project.

What the system does

System Design

The system is structured around three core components, each designed to provide decision clarity rather than operational complexity.

Executive Dashboard

A single view that aggregates operational signals across all locations. Leadership can see inventory health, cash flow exposure, and risk indicators without asking anyone for status updates. This is not a feature list. This is forward visibility.

Inventory Control Logic

Automated calculation of reorder points, safety stock levels, and dead stock flags based on sales velocity and supplier lead times. The system does not make decisions for you. It surfaces the logic that should inform your decisions.

Purchase Workflow with Cash Impact

Before a purchase order is approved, the system shows exactly when cash will be required based on payment terms. This prevents surprises. It does not prevent purchases. It prevents uninformed purchases.

The system emphasizes decision clarity, not automation for its own sake.

How it thinks

Automation Logic

The system uses straightforward logic to support operational decisions. I will explain the concepts, not the formulas.

Sales Velocity Calculation

The system tracks how quickly each SKU sells at each location. This determines reorder frequency and quantity. Fast movers get prioritized. Slow movers get flagged.

Reorder Point Formula

Reorder points are calculated based on sales velocity multiplied by supplier lead time, plus a safety buffer. This ensures stock arrives before you run out, not after.

Dead Stock Flag Logic

If a product has not sold in a defined period relative to its expected velocity, it gets flagged. This is not subjective. This is data.

Cash Projection Logic

The system calculates when payments are due based on Net 30 terms and projects cash outflow over 30, 60, and 90-day windows. This allows leadership to see not just what inventory is needed, but when it will impact working capital.

This is operational modeling, not algorithmic optimization. The goal is to make implicit knowledge explicit.

Results

Outcome

The outcome is not a set of features. The outcome is what becomes possible for leadership when operations are modeled systematically.

Forward visibility into inventory health across all locations

Proactive ordering decisions based on velocity, not intuition

Working capital awareness before purchase orders are approved

Risk reduction through automated dead stock detection

This system does not guarantee better decisions. It guarantees that decisions are made with better information.

Buyer signals

Why This Matters

This project demonstrates how I approach operational problems. I do not start with technology. I start with constraints. I model how decisions should flow, then I build systems that support that flow.

I model systems around operational constraints, not around features

I prioritize decision clarity over automation complexity

I design systems that make cross-functional awareness natural, not forced

I understand that operational control is about visibility first, automation second

If you are running a multi-location retail or distribution operation and you suspect that better visibility would change how you make decisions, this is the kind of problem I solve.

Technology

Tech Stack

  • PHP
  • Vue.js
  • JavaScript
  • Blade
  • MySQL
  • Responsive Design

If your operations have outgrown spreadsheets but you are not sure what structured control should look like, I can help. I model systems around constraints, not assumptions.

Start a Conversation

Note: This is a demonstration project built to illustrate operational control principles for multi-location retail and distribution companies. It represents a composite of patterns observed across multiple engagements, not a single client implementation.