Globally standardised systems are a great idea - but they can be less than wonderful if your company doesn't do business "the American way."
Rail travellers arriving at the Indian city of Mumbai - formerly Bombay - are rewarded by an early example of technological imperialism: Victoria Terminus. A pile of grey stone standing five stories high, it was decorated under the auspices of the father of Rudyard Kipling, author of The Jungle Book and other tales from the era of the British Raj. Vast, dark and full of echoes, it looks more like a monument than a station. On hot days - and there aren't many other kinds in Mumbai - it captures, traps and bakes the mixed smells of smoke, dust, body odour and garbage. It's a grand building, a very English building, and one that screams: "We own you, and you'll do things our way, practical or not."
Does anybody realise that technological imperialism didn't go away with the Empire? Take globalisation. "Great idea," says the average CIO. "Let's get some consistency and bring our overseas partners up to speed." And every time I hear a CIO say it, I can see another Victoria Terminus going up - a big, expensive pile that might have worked well in the builder's climate and economy but is simply absurd where it's supposed to go.
Examples? Well, in that same city of Mumbai, a textile company I've come to know well had to use an American ERP system to record sales orders for their rolls of cloth. The trouble was that they needed to maintain two prices for the same bolt of cloth: the export price and the domestic price. The ERP company's reaction was: "Why would you want to do that?" Trust me, they had a perfectly good reason.
The trouble was that in the US, it's illegal to charge a different base price to two different classes of users. And by gosh, said the US software programmers, do things the US way or be off with you.
Did the CIO who initiated that globalisation project have any idea what he was doing? I happen to know that he thought he was bringing in "advanced" technology. But that technology wasn't advanced. It was a technology that worked well (some of the time) in the parent company's economic system. In reality, he wasn't bringing the rest of the world "up to speed" - he was slowing the rest of the world down.
It's a common blunder: few people realise how deeply local assumptions are built in to business software. Another Indian company was trying to put in an American distribution resource planning system that assumed a reliable connection between buyer and seller.
The connection was needed because the supply site had to accept orders before confirming them. It's a good idea in an economic system where you have multiple supply sites and good connectivity.
It's less of a smart idea in India, where connectivity is not good - least of all during the monsoon. Do you know how they got the orders to the supply site? They put them on a diskette and sent the diskette along with the truck that would carry the goods, firmly secured in the driver's pocket. Which worked, but was a hassle. A better fix, but a prohibitively expensive one, would be modifying the software. No problem, said the Indians, we can do it - but US companies don't trust Indians with source code. So the Indians came up with a practical solution: they hired somebody to reset the order status manually. And they didn't bother to tell the corporate CIO because they knew the reaction they'd get. "Manual typing. How primitive."
But it's not primitive. Typing in that situation was an appropriate technology - a technology that is sufficient to deal with the problem but not so complicated that it generates or requires a vast and complicated infrastructure. And in much of the world, where people are paid to open doors or drive elevators, labour-saving automation is not an appropriate technology. In the West, where I've observed the ratio of programmer labour cost to clerk labour cost to be roughly 3-to-1, it makes sense. In other parts of the world, where the ratio can be 50-to-1, you can get an awful lot of typing done while that programmer is trying to reverse engineer source code. In fact, appropriate technologies can work better than high-tech solutions, even in countries where high-tech makes sense.
In Japan, for instance, and in some countries of Europe, the de facto method of communicating with suppliers has nothing to do with three-letter technologies such as MRP or EDI. When a company needs more stuff from suppliers, it sends the suppliers a card, called a kanban card. The amount needed is written on the card, and when the order is fulfilled, the card is sent back with the order. Kanban is much simpler, more straightforward, more accurate (as a practical matter), and quicker overall than EDI. Don't take my word for it - it's an essential tool of the Toyota production system, to which every automotive manufacturer aspires.
Now, most CIOs find this hard to believe. They assume that optimised planning and scheduling software give better schedules than pull-based scheduling with a kanban system. But companies that know both systems have found otherwise. Krone Technique of Cheltenham, UK, a perennial winner of manufacturing and supply chain awards in Europe, relies almost entirely on kanbans. And where it doesn't, Krone uses a visual planning system, because it found this system produced better schedules than those produced with a computer-based planning system. Not "just as well". Better.
What's a visual scheduling system? Sometimes, it's a wall-mounted version of a project planning board, sometimes just a whiteboard with scribbles. Not high-tech enough? Never forget: it's the brain that does the scheduling, and the display technique is almost irrelevant. Well, not quite: at one Japanese company, they put a blackboard at the start of the line and train a video camera on it. Each time a new job is started, they chalk the job up on the board - and anywhere in the plant, you can look up and see a TV monitor with the schedule on it.
One moral might be this: instead of globalising by pushing the high-tech out, globalise by bringing the appropriate tech in. But a better idea, I think, is simply to use appropriate technology wherever it's needed.
One final story. Not long ago at the airport in Jakarta, Indonesia, I met up with a quality engineer from a famous French cosmetics company. Her job: make sure that the product manufactured in Jakarta was the same as the one manufactured back home.
This had involved a lot of travel. So one day, a corporate guru had a typical Victoria Terminus idea. Use the same ERP system in both places and ensure consistency. It turned out, though, that the cardboard packaging material available in Indonesia has different qualities from the material in France. Also, the humidity in Jakarta means you can't use the same printing processes: French inks just run. You could use the ERP system to make sure that they went through the identical processes. But it wouldn't produce an identical product.
After the fiasco, they tried a simpler idea, which my travelling companion was just at the final stages of implementing. They're going to use the Internet to do cooperative quality control; if there's a printing problem in Jakarta, they'll send the micrographs to Nanterre, France, over the Web. Then French chemists and the Indonesian engineers will confer. The result? They think they can get fixes in minutes.
A corporate triumph - but a personal tragedy. While the beaches of the Côte d'Azure are world famous, the ones in Bali are much, much better.
David Dobrin is president of Massachusetts-based B2B Analysts. His opinions on ERP, e-business and supply chain have aired on highways and byways from São Paulo to Mumbai.