Executive Summary
- Cartly.ca reached a point where sales growth began to expose limits in how daily operations were coordinated. Orders increased, suppliers multiplied, and fulfillment paths became more complex, yet core work continued to rely on spreadsheets, disconnected tools, and manual follow-ups. Nothing failed outright, but the effort required to keep everything aligned rose sharply as volume increased.
- Rather than moving directly to an off-the-shelf system, the work began by examining how orders, inventory, purchasing, fulfillment, and finance actually interacted day to day. This revealed structural gaps between how the business operated and how information moved. A unified operational model was designed first, with system support introduced only after responsibilities, handoffs, and timing were clarified.
Background
Cartly.ca operates a growing commerce business spanning product sourcing, inventory storage, order fulfillment, and customer delivery. In its early phase, operations were managed through spreadsheets, basic inventory tools, manual purchase tracking, and loosely coordinated fulfillment processes. Accounting and reporting existed separately, requiring regular reconciliation to reflect what had already happened operationally.
This approach worked while order volume was low and variability was limited. As growth continued, however, coordination effort increased faster than revenue. Inventory was spread across locations, suppliers operated on different timelines, and fulfillment required tighter sequencing. Leadership began to see that while demand remained strong, the underlying structure supporting operations was becoming increasingly fragile.
Initial Observations
Early walkthroughs of daily work revealed that inventory numbers existed in multiple places and rarely aligned without manual adjustment. Purchasing decisions depended heavily on individual judgment and experience rather than shared system signals. Fulfillment teams often recorded adjustments outside core tools, reconciling them later when time allowed.
Financial reporting followed a similar pattern. Operational activity was reconstructed after the fact through spreadsheets and manual cleanup. None of these practices were inherently wrong, but together they created a growing lag between reality and visibility. The business functioned through human coordination, relying on a few individuals who understood how everything connected beneath the surface.
Review & Design Approach
Instead of beginning with software selection, the work focused on mapping how operations actually flowed. Orders were traced from sale through fulfillment, inventory consumption was examined at each adjustment point, and purchasing decisions were reviewed in the context of supplier behavior and lead times. Attention was placed on where ownership shifted and where delays regularly appeared.
This process made it clear that automating existing spreadsheets would not resolve the underlying strain. The objective became designing a coherent operational model that reflected reality before introducing system structure. Only once workflows, responsibilities, and timing dependencies were agreed upon did technical design begin, grounded in how the business truly operated.
Key Findings
The central issue was not the absence of tools, but the absence of a single operational backbone. Stock, purchasing, and order data were accurate in isolation but unreliable in combination. Operational reality was consistently reconstructed after the fact, delaying decisions and creating friction when numbers needed explanation before they could be trusted.
As volume increased, this lag became more costly. Decisions slowed, coordination overhead grew, and risk accumulated quietly. It became clear that introducing a generic ERP without resolving these structural gaps would only digitize existing confusion. The business was scaling, but its coordination model had not evolved alongside it.
Decisions & Direction
The decision was made to establish a unified operational model spanning purchasing, inventory, orders, fulfillment, and finance. Rather than treating these as separate departmental systems, the focus shifted to how information and responsibility flowed across the business as a whole. Spreadsheets were to be replaced with structured workflows tied to shared definitions.
System support was introduced only to reinforce this model. The goal was not feature coverage, but alignment. Operational and financial reality needed to be visible as it occurred, not reconstructed later. The system would serve as infrastructure for coordination, not as a destination in itself.
Implementation
Implementation progressed incrementally, allowing teams to stabilize operations while transitioning away from manual coordination. Inventory movements, purchasing activity, order lifecycles, and fulfillment adjustments were gradually brought into a shared structure. Reporting emerged from operational activity rather than separate reconciliation processes.
Role-based responsibility was clarified through use, not documentation. As teams interacted with the system, ownership boundaries became explicit and timing expectations normalized. This phased approach reduced disruption while steadily lowering reliance on individual memory and informal workarounds that had previously carried the business.
Impact
Over time, inventory accuracy improved as movements were recorded consistently at the point of activity. Manual reconciliation work declined sharply, freeing teams to focus on execution rather than cleanup. Purchasing became more predictable, supported by shared visibility into stock position and demand signals.
Order fulfillment stabilized as coordination gaps narrowed. Management gained a clearer operational view without waiting for reports to be rebuilt. Most importantly, growth was no longer constrained by coordination overhead. Demand had never been the issue; structural alignment allowed the business to support continued scale.
Why This Held
The work held because operational reality drove every decision. The business was modeled before systems were introduced, and technology followed structure rather than dictating it. ERP was treated as supporting infrastructure, not as a solution in itself
By resisting the urge to automate prematurely, the organization avoided embedding misalignment into software. Instead, clarity emerged through understanding how work actually happened. The result was not transformation through tools, but through alignment allowing the business to grow without fighting its own operations.
Note on Confidentiality
Certain operational details, metrics, and internal processes have been intentionally generalized or omitted to preserve confidentiality. The narrative reflects structural patterns and coordination challenges without exposing sensitive commercial information.