| [Article] |
d
What really makes the world go 'round: love, money... and technical support
It's been said that six months after you roll out a business application software, the data that's been encoded into it is already more valuable than the application itself.
When you think about it, that's probably reasonable. When you calculate the cost of the man-hours spent encoding data into the software, in six months you're likely approaching what you originally paid for the software to begin with. But what takes the value of the data over the top is a new circumstance: the surprisingly sudden sense of dependency on all that encoded data that's felt all over your organization. The new ability to coordinate effortlessly that couldn't happen before. The intoxicating new ability to get information that simply wasn't available before. The ability to produce effortless MIS reports to guide superior, more confident decisions. The new speed at which things get done compared to before. All of this adds up to productivity gains whose value far exceeds the original cost of the application. And it's the gift that keeps on giving; the longer you use the software, the longer your productivity gains abide, and the further back in the dust the cost of the software is left behind.
But mind, computerization brings with it its own problems. Human society – and the world of business in particular – have concluded long ago that the benefits of computerization far outweigh the problems it creates, so every year more and more organizations take the plunge. Reasonable, rational people have made the calculation that the problems can be dealt with, and economically too, but the problems are there.
What are the relevant problems for the typical business concern? Experience shows that the biggest headache for Philippine businesses is data corruption. (At Balmori Software, data corruption is 70% of our technical support practice.) When your data get corrupted, all the wonderful benefits that your company has come so quickly to rely on ... stop. Until you can get someone on the case.
That someone is called the technical support provider. The tech support provider knows the application software well enough to be able to recover the data that's been corrupted, or to recommend a reasonable course of action if recovery is not in the cards.
If you are unable to get technical support for an application, then you can't count on being able to build a business for the long haul with the aid of that application software. Especially if that application is a mission-critical application. At some point, there'll be a crash and you can't do your business mission to the standards your customers have come to expect, or at all. Sure, you may be able to use the app trouble-free for a few months, or even a couple of years; but sooner or later, trouble will strike, your data will get corrupted (that's a surer bet than a Manny Pacquiao fight); then what do you do? You'd better have technical support that'll help you get back on track.
Consider what it would be like to buy a car that doesn't have a dealer service organization. “Oh, it looked so sleek in the pages of Car and Driver I just had to buy it!” Sure, for a few months it'll run well. But this is the Philippines, remember, where the roads are maintained by the 1st Engineering District of Hell, and the drivers pass the high standards of the LTO, having purchased third-party liability insurance from Desk-in-the-Esquinita Insurance Agency representing Nonexistent Insurance Corporation.
Once the mechanical problems start, what are you going to do? You either repair it yourself – and good luck with that, Ms. Accounting Graduate working at a bank or trading company - or you bring it to a generalist talyer. Or a specialist talyer (“We specialize in all kinds of cars”). And the generalist talyer, or the specialist talyer, with its knowledge base of general principles of the internal combustion engine from models of 10 years ago, will muddle its way through this strange brand's fuel injection system (“but if it's the black box, we don't have the equipment to diagnose that; you'll just have to replace”), or use trial and error to figure out how to rip out the panel covering the aircon evaporator. And they'll do this every time you come back for servicing, thus butchering your exotic, technically-unsupported pride and joy in slow motion.
And this is why you don't see many Fiats or Citroens on Philippine roads today. Filipinos may long for the quirky charm of Renault Twingos or Lada Rivas or Caterham Super Sevens, but most (most) of them are smart enough to stick to Toyota Corollas and Honda CRVs and Hyundai Tucsons, because these things have the one thing that - for the down-to-earth person - outweighs charm and sexy looks and interesting design specifications: technical support in times of trouble.
Similarly, a business application needs a reliable technical support infrastructure before you dare count on it for more than two weeks as an enabler of your critical business processes. If you're intending to build a business that you can take to an IPO or bequeath to your children, you need more than just “good software;” you need to be able to count on it day in and day out for 10 years.
What are the specific causes of the data corruption that makes otherwise “good software” useless for the long haul unless underpinned by technical support? The most common causes are:
1) Viruses. This is well-known and needs no explanation. Sure, you can buy anti-virus software and firewall applications; but malware writers are always coming up with new variants to thwart the protective measures. When you get caught out, the data damage is often severe.
2) Electrical fluctuations. Ask any electrician, and he'll tell you why the Philippine electrical grid is so prone to power fluctuations. Because computers are particularly vulnerable to power fluctuations, this has given birth to a product category designed to compensate for it, the UPS appliance (uninterruptible power supply). But UPSs can run down, too. Most people imagine a UPS to be like a TV (“Why, I bought mine in 1985 and it still runs good.”) because it looks like a sleek household appliance. Well, a UPS is not like a TV. It's got a lead-acid battery inside, which dies in about three years like a car battery, which of course most users never realize (because it looks so much like a sleek appliance, not at all like the greasy grimy battery beside the radiator in their car...), and this causes them to plug into a UPS long after its battery has died, and the next time there's a power fluctuation, they get … data corruption.
3) Bad hardware components. This is a little less well-known among the lay population. There are two types of bad hardware components: poor-quality brand components that are questionable out of the box, and respectable components that have simply reached the end of their lives. Both types of bad hardware can be avoided through rational, disciplined behavior. To protect against the first type, you ask around the technically knowledgeable community and identify the bad brands, and simply avoid the false economy of buying garbage. Against the second type, you institute a system of preventive maintenance and asset age monitoring. (Easy to say, not so easy to do.)
Of course there is a powerful protective behavior we all can and should undertake against data corruption; it's called backing up your data. Let's be clear here: anyone who neglects to back up his data deserves all the grief that he's going to get when disaster strikes, plus a smart slap on the back of the head from the nearest available security guard. Backing up is basic behavior, no question, but back-up disks or flash drives can get lost. Or get tossed in the washing machine. Or you could back up data that's already corrupted. Hence backing up is no absolute guarantee against data corruption.
Despite all our best efforts to institute protective policies and protocols, something will go wrong somewhere, sometime. Guaranteeing total invulnerability to just these three threats becomes prohibitively expensive, so most organizations will do what is reasonable, but will not, cannot, be obsessive about it. So, the bottom line is, you'll take your hits eventually, just like the rest of us, even Fortune 500 companies in New York City. When that happens, you better have competent technical support you can turn to. Because if you don't, you'll simply have to start again from scratch or go back to manual data processing (we never could understand this except as a gesture of despair).
If you have to restart from scratch, you must acknowledge that your business operations – perhaps your ability to deliver critical services – will be degraded for a few weeks or months. Keep in mind, the whole world has already gotten used to seeing you go100 kph; suddenly you're doing 30 kph. And that means your image of reliability among your customers and suppliers will fray. And it might or might not result in their becoming more open to alternative relationships. Like, with your competitors. But even if it's just a function that doesn't impact on customer service that gets impaired, like printing out a stock card postings report, the vitality and therefore the overall competitiveness of the organization – its rhythm - will weaken until you can get the data repaired or restored.
What conditions should you look for in order to assure yourself of a decent expectation of reliable technical support?
1) Ideally, the technical support is provided by the company that created the software to begin with. It stands to reason; the creator knows the source code, possesses the source code, and therefore knows the product intimately, most relevantly the file and data structures, since these are the very things that have to be fixed after a data corruption episode.
2) Ideally, the application itself already has a large installed base, because a large installed base means the vendor's tech support department has “seen it all,” as it were, many times before. Therefore, such an experienced, battle-scarred tech support department can get to the heart of the problem fast, without a lot of back and forth and experimenting with this and experimenting with that.
3) The organization providing tech support is stable, and can be expected to stick around indefinitely, and not vanish completely when immigration laws suddenly ease in Zambia or Mars, or when a particularly sticky problem emerges (see passage on software robustness below).
4) The software product that the tech support organization is supporting should ideally be the main product, not just a sideline, of the organization providing tech support. If you bought the application from a vendor primarily engaged in selling hardware, which sold you the app only because their hardware could not run without the app, then how much commitment can you expect them to display when your problems are in the nature of corrupted data (meaning to say, technically not the fault of the software or the hardware that they sold you)?
5) The software product being supported should be robust to begin with, so that the need for technical support is infrequent, and its causes confined to external circumstances, rather than flaws in the software itself. If disruptions to business operations caused by exogenous variables like viruses and bad hardware are expensive and vexing, then problems caused by bad program code are unforgivable. Unforgivable because they'll introduce you to exquisite tortures that are totally avoidable in the first place – by you refusing to deal with any but truly competent providers. -RSR
Questions? Reactions? Write to balmori@balmorisoftware.com.