Pharmaceutical and medical supply
Medical Field Force Software Case Study
Kite Medica
The challenge
Kite Medica supplies healthcare products to doctors, nurses, paramedical staff and patients, and by 2016 was running that business with more than a hundred people across several regions. Its marketing executives worked from remote locations and travelled a great deal, and the material they needed in front of a client, product manuals and supporting documents, was produced and circulated through the ordinary office routes. That put a delay between a representative in the field and the office, so requests and queries raised during a visit reached the management team slowly and were answered slowly. Sales reporting, incentive calculation and month-end payroll all depended on the same paperwork arriving and being read, which meant the management team was looking at a picture of the field that was always a few days old.
The approach
We began by mapping the business rather than the software, recording the day-to-day activities of each role in the organisation and setting out the corresponding workflows with the inputs each one needed and the outputs it was expected to produce. Those workflows were then separated by the platform that suited them, because the work a representative does standing in a clinic is not the work an administrator does at a desk. The office-side functions were built as a single-page web application covering the full set of operations, and the representative was given an Android application carrying the smaller set of functions actually used in front of a client, principally presenting products to existing and potential customers and reporting from the visit. Both run against a common web service, so the two applications are views onto one set of records rather than two systems that have to be reconciled.
The outcome
A representative now reports from the visit itself, so the management team sees activity as it happens rather than after the paperwork has travelled, and a query raised during a visit is answered against a record rather than waiting for the paperwork to arrive, which is where most of the turnaround time had been going. Quotations are generated from the captured data automatically and reach the customer within seconds instead of being prepared by hand. Because the same records drive the commercial calculations, sales incentives are computed on a live basis rather than assembled at the end of a period, and salary slips are produced accurately at month end from the figures already in the system. The reporting the management team asked for comes off the operational data directly, which turned a strategy conversation into one held against current numbers.
A field force is a reporting problem before it is an application problem. Kite Medica’s representatives were not short of effort; they were separated from the office by the time it took paper to move, and every commercial decision downstream inherited that delay.
What a paper-driven field force actually costs
The obvious cost is the delay itself. The one that does more damage is that the delay compounds downstream. Sales reporting waits for the paperwork, incentive calculation waits for the sales reporting, and payroll waits for the incentive calculation, so a form that arrives three days late is not three days of latency — it is three days added to the start of a chain.
A management team looking at a picture of the field that is always a few days old is not making slow decisions; it is making decisions about a situation that no longer exists. With more than a hundred people across several regions, the gap between the field and the office was the largest single source of that error.
Why we mapped the business before designing the software
The first deliverable was not a screen. It was a record of what each role in the organisation actually does day to day, and the workflow behind each of those activities with the inputs it needs and the outputs it is expected to produce.
That is a slower start and it is what makes the rest of the build decidable. Without it, every argument about a feature becomes an argument about opinion. With it, the question “should this go on the mobile app” has an answer, because you can see whether the activity happens in a clinic or at a desk.
Why splitting by platform beats splitting by feature
The usual instinct is to build one application and hide the parts a representative does not need. It produces a phone application that is an administrative system with most of it switched off.
The work a marketing executive does standing in front of a doctor is narrow and specific: presenting products to existing and potential customers, and reporting what happened on the visit. The work an administrator does at a desk is the whole surface. Those are different applications, so the office side was built as a single-page web application covering the full set of operations and the representative was given an Android application carrying only what is used in front of a client.
What one shared web service prevents
Both applications run against a common web service, which sounds like an implementation detail and is the load-bearing decision. Two applications writing to one set of records cannot disagree; two applications with their own stores will, and the disagreement surfaces as a reconciliation task somebody performs by hand every month.
It is also what makes the downstream calculations honest. Quotations are generated from the captured data rather than prepared by hand, incentives are computed on a live basis rather than assembled at period end, and month-end salary slips come off figures that are already in the system rather than being re-entered from a summary. The same principle is what Sazinga Field is built on, and it applies across the healthcare supply chain wherever the people who meet the customer are not the people who process the order.