Thinking BigBy Tom Steinert-Threlkeld | Posted 2003-05-01 Email Print
WEBINAR: On-demand webcast
Next-Generation Applications Require the Power and Performance of Next-Generation Workstations REGISTER >
Endo Pharmaceuticals started out small. But it acted from the beginning as if it would be a billion-dollar company.
Even though Bloom felt the company, at its early size, was more appropriately a potential customer for J.D. Edwards & Co.'s software, he, his team and the cofounders elected to base their operations on SAP AG's R/3 software. This, despite oft- cited warnings from consulting firms from Gartner Inc. to Nucleus Research that SAP's wares work best for companies with thousands of users and billions in revenue.
To Bloom, the downside was also the upside. If he could start with SAP essentially from scratch, and if the company did grow big quickly, it would not outgrow its software. The engine would work if, 10 years hence, the company was not just generating $1 billion in sales, but multiple billions.
The first order of the decade was to transfer transactions, financial reporting and customer service operations onto SAP. That, Bloom figured, would take three months to blueprint and three months more to go live.
Finance was fairly easy, he says. The company used the module "pretty much out of the box.''
But "multiple things raised their heads'' when Endo began trying to work through logistics with customers. First off, the drug marketer had to build an interface that would allow it to connect toand communicate withdistribution locations. An interface also was needed so it could communicate with factories and tell them how much painkiller to produce. No minor matter, when resuscitating brands.
The real head-scratcher, though, was how to build a system for knowing who exactly Endo's customers were and what they were buying.
That is not as simple as it sounds. Drugmakers like Endo sell their products in large quantities to wholesalers. If they just keep track of those transactions, they have little ability to see what is happening in the corner drugstore or in the discount superstore, where prescriptions are ultimately taken and pills dispensed.
To get information about store transactions, an elaborate system of charge-backs is used by pharmaceutical companies to generate market intelligence.
In effect, a maker and marketer like Endo will offer rebates to wholesalers if they provide proof of where their products are finally sold (what stores) and in what amounts.
A method of tracking charge-backs was wholly absent from the SAP software back in 1998, when Endo first needed it.
But Endo could not do without it. So it had to figure out what adjustments needed to be made to SAP R/3, and make them happen.
This was no lightweight undertaking. The first step: figuring out what each element of a charge-back was. In effect, defining terms.
"There are always nuances,'' says Bloom. The process could be "very confusing at best and a disaster at worst.''
"Net sales," for instance, could be defined to include all the rebates. Or not. "It causes you to rethink the whole process,'' he said, when "someone says it doesn't include charge-backs.''
And how do you define a shipment? "You could move something in the warehouse and someone would call it shipped,'' says Bloom. Now it has to leave the warehouse before it is defined as "shipped."
Defining terms is only a start. The next step: Mapping out each type of product transaction for each wholesaler.
Endo, as do other drugmakers, relies on Electronic Document Interchange, a fairly rigid form of exchanging information with suppliers. In effect, Endo has to make sure that its definitions of what a piece of data stands for matches up with the definition each supplier uses for that same piece of data. The classic case: What is an item? Is it a bottle or a box of bottles?
Before Bloom's team got started, the estimate was that five or six data maps would handle all transactions.
When they got done, there were 280.
"It wasn't mentally challenging, it wasn't particularly difficult,'' says Bloom. "But it was time-consuming.'' Completing that one step required two full-time people working 50-hour weeks for two months.
Definitions in place, the SAP software still had to be made smart enough to handle charge-backs. Code had to be created to determine whether each charge-back was valid. The logical steps: Was this coming from a valid customer, with a valid contract on a charge-back program that hadn't expired? And so on. All of which had to be captured and automatically decided, without human intervention, if possible.
Just consider this, after all: Without bulletproof checking, the bottom line can quickly evaporate. Suppliers have been known, Bloom notes, to send in requests for charge-backs multiple times, hoping the prior requests for the same charge-back don't get noticed. "I wouldn't call it totally unethical,'' Bloom says. "But I wouldn't call it totally ethical, either.''
So for three months, anywhere from three to five people worked exclusively to ensure this new capability of R/3 was set up properly, the pricing algorithms were correct, the checking was correct and the features tested out.