Moving pharmacy point-of-sale off the back-room server: a business-model conversion

1. In parallel:
   Daily work

   Ring up a sale; fill a prescription; keep the store running
2. In parallel:
   Model

   On-premise cost is the technician visit nobody invoices
3. De-risk

   Reverse-engineer the existing POS logic before moving it
4. Build

   New transaction flows and POS wireframes with UI teams
5. Run

   Post-launch client engagement and enhancement loop

Product workflow, shown through the decisions and handoffs.

Results

Multi-location connectivity and revenue monitoring across retail networks, with the post-launch engagement loop feeding enhancements back into the product.

What I learned

Reliability, support and change management belong inside product strategy. The model works only when the everyday experience supports the promise, including the inconvenient conditions a demo leaves out.

From my original account

At McKesson, independent and chain pharmacies ran our point-of-sale and pharmacy management system on a server in the back of the store. Everyone called the project a migration. It was a business-model conversion: an on-premise product is expensive for a reason nobody puts on the invoice, because when something breaks a technician has to drive there.

The truck roll

At a retail-pharmacy technology business I managed a $25M project budget and a 7-person team. The product was the point-of-sale and pharmacy-management system that independent and chain pharmacies used to ring up a sale and fill a prescription, and the project was to move it off the server in the back of the store.

Everyone called it a migration. It was a business-model conversion. An on-premise product is expensive for a reason nobody puts on the invoice: when something breaks, a technician drives to the store. The truck roll. A software-as-a-service product removes the truck roll — but only if you rebuild the things that made it necessary. So we built REST APIs where there had been direct database calls; hierarchical authorisation so a chain administrator could manage many stores and a store manager only one; integration with external inventory and ordering; multi-location connectivity and revenue monitoring so an owner of multiple pharmacies could see them on one screen; and over-the-air updates, so the software in the store changed without anyone driving there.

I wrote the transaction process flows and worked with the interface team on the point-of-sale wireframes. But the lesson I took was strategic, not technical: the migration is the business. Every architectural decision — where authorisation lives, how updates ship, how a store stays online when the network does not — was really a decision about whether the subscription model could work.

Tools in this chapter REST APIs · multi-tenant authorisation · over-the-air deployment · revenue monitoring · process flows and POS wireframes · program budgeting

De-risk before moving: we reverse-engineered the existing point-of-sale logic so the new version reproduced the transaction behaviour stores depended on, rather than discovering the differences at the counter. The service proposition was tested against ordinary disruption: a dependency unavailable, a busy period, a store needing help.

I managed the $25M project budget and a seven-person team. I wrote the new transaction process flows and the point-of-sale wireframes with the UI teams, and owned post-launch client engagement and the enhancement feedback loop.