The systems behind a seasonal business.

01

A business that grew beyond its seasonal roots.

A garden centre looks very different in January than it does on a Saturday in May. Staffing changes, inventory expands, trucks arrive, plants move through production and retail volume accelerates. Payments, labels, purchasing, receiving, ecommerce and customer records all become more consequential at the same time.

When I joined, the retail operation was still strongly seasonal. Over the following decade, it became increasingly year-round while retaining the pressure of a seasonal peak. That added permanent complexity to the systems, staffing, purchasing, marketing and operating work behind the business.

The systems supporting that work could not be treated as separate IT projects. A checkout issue could involve payments, networking, staff procedure and accounting. A purchasing question could begin in an ERP record and end in a reporting decision. Much of my role became owning the spaces between them.

02

The role expanded with the business.

I began as a seasonal employee and, over time, moved into middle management under ownership. Today the scope includes operations and business systems alongside advertising, marketing and retail hard-goods purchasing. I also represent the business at trade shows, where I make buying decisions and manage the budgets attached to those commitments. That commercial responsibility changes how I approach systems work: I am often one of the people making the purchasing, marketing or operating decision that the system is meant to support, then living with the consequence when it reaches a receiving desk, a till, an ecommerce order or a report.

Purchasing and inventory decisions also need a closer view of the records. I develop SAP Crystal Reports against SQL databases and use Excel and SQL reporting for that work. Where a particular task needs something more specific, I build internal applications, automation and data transformations.

I use that reporting to make retail hard-goods buying decisions, adjusting commitments and making room to try new products within the business’s expectations. Plant purchasing belongs to other departments.

I also built an inventory converter for an ERP transition. Its saved records let me check earlier transfers and prepare corrections when new finished materials needed to be included.

Read the inventory-conversion System Trace

03

A transaction is only the beginning.

A product can begin as a buying decision, become an ERP or POS item, arrive through receiving, appear online, be scanned at a register, affect inventory, generate customer information and eventually become part of management reporting. The transaction does not end at the sale; it becomes evidence for the next decision.

That is why the system path is a loop rather than a handoff between departments. I have worked on configuration, reporting and procedures at different points in that loop, but the useful question is always the same: can the person responsible for the next step see what they need, recognize an exception and act without creating a new problem downstream?

CounterPoint is one deep example of that ownership. I implemented and continue to steward its retail environment, but its story belongs in the dedicated CounterPoint case study. Here, it is one of the places where a broader operating responsibility becomes visible.

04

Information has to come back out of the system.

Transaction screens are useful for running a transaction. They are not always the best place to answer a management question. I developed Crystal Reports and SQL queries because purchasing, category performance, inventory and reconciliation questions needed a view that operational software did not always present clearly enough.

Over time, I became a consumer of information structures I had helped create. I use reporting to investigate a stock or pricing question, plan hard-goods purchases, adjust commitments and decide when there is room to try a new product. Plant purchasing remains with other departments.

A report does not make the decision by itself. It gives the person making it a defensible question to investigate. When the numbers do not agree, I can follow them back through the operational path instead of treating a spreadsheet as an answer detached from the work that created it.

05

Sometimes the missing piece is a tool.

The inventory converter is a good example of a narrow tool solving an operational gap. During an ERP transition, the export contained more than the business needed to move. Finished material had to be separated from work still moving through production, transformed into a receiving-system file and retained with enough history to investigate a later omission.

I built the converter around that work rather than around a generic software idea. It prepares the transfer file, keeps the source and prepared records, and gives staff a way to record the upload outcome. When additional finished materials needed to be included, the retained history let me check earlier transfers and prepare repair files for review.

That is the standard I apply to internal tools: they should make an existing responsibility clearer or safer. They should not quietly take ownership away from the people who approve, upload or decide what the record means.

06

Sometimes the missing piece is a procedure.

A receiving workflow can fail for reasons no configuration screen will solve. Goods may arrive before an invoice, free goods may appear on an order, and a zero-value bill should not travel into accounting as though it were an ordinary payable. The people receiving goods need to know what state the purchase order is actually in before they can decide what to do next.

When a vendor changed its software, I did not treat acceptance as a technical sign-off performed in isolation. I assigned scenario validation to the departments that actually receive goods, work through the accounting handoff and live with the exceptions. Their test cases established whether the updated workflow made sense in practice.

That is where procedures, SOPs and training belong. The point is not to document a system for its own sake. It is to give people a repeatable way to handle the real conditions that the tidy default workflow does not cover.

07

Sometimes the right answer is infrastructure.

Workstations, network access, labels, telephony and internal services are part of the operating environment when a failure can stop a sale, delay receiving or leave a user unable to act. I have worked on the hardware, VoIP, access and supporting systems around those activities because the distinction between infrastructure and operations disappears quickly when the business is busy.

When I deployed an internal service desk, the technically interesting path would have meant exposing another service through additional identity infrastructure. The operationally sensible choice was to keep it LAN and VPN only: it met the need without creating another public-facing service, licensing dependency or support obligation.

That decision was not anti-technical. It was a choice to preserve a useful boundary. The best system is not the one with the most components; it is the one with a clear owner, a support path and a reason to exist.

08

A vendor ticket has to become an operating answer.

A problem often begins as 'this does not work.' The useful next step is a reproducible example: what the person tried, what the system recorded, what the business expected and which part belongs to a vendor, a connector, a configuration or an internal procedure.

That pattern appears across retail platforms, ecommerce, marketing services, label equipment, telephony and accounting handoff. Vendors bring product expertise and support paths. Internal users bring the reality of the work. I translate between them, ask whether a proposed workaround actually meets the operating requirement, then test the result with the people who will rely on it.

The pricing diagnostic work is one example. When promotional pricing did not reach ecommerce as expected, I investigated the integration state, escalated the programming issue and built read-only diagnostics that made processing, error and review states visible. The tool did not repair vendor records; it made the next question more precise.

09

The operating model keeps changing.

Every successful system creates the possibility of another workflow. Retail records can support loyalty and marketing. Ecommerce creates inventory and pricing synchronization questions. Production, purchasing and accounting connections create new receiving and reconciliation controls. The work is not a list of products; it is deciding what those connections mean for the people using them.

I do not think of this work as IT sitting beside operations. The systems are part of the operation. My contribution has been learning enough about both sides to decide where a problem actually belongs, then carrying it across the boundaries required to solve it: people, software, vendors, data, infrastructure or process.

Sometimes the answer is code. Sometimes it is a report, a vendor ticket, a configuration change or a new procedure. And sometimes the best systems decision is not to add another system at all.