| [Article] |
d
Evaluating computerized solutions? Three things you need to know before they jump out and bite you in the you-know-what.
1. SURFACE BEAUTY, INNER STRENGTH
When evaluating a software application, it’s helpful to keep in mind the cautionary tale of the man who married the gorgeous girl for her looks, then found out afterward that there was insanity in her family.
What you see is not necessarily what you get. Whether sizing up a potential spouse or a software solution for your business, it's prudent to have the following mental model: there's an important difference between (a) the user interface, and (b) the underlying algorithms.
The user interface is what you see on screen. It’s how you, the user, interact with the software. It’s how you are able to input data, and it’s how you extract the application’s outputs (reports).
The underlying algorithms, you don’t see. These are the formulas, the actual number-crunching rules, by which the data that you input get computed and processed. They’re what happen after you input your raw data. The algorithms are the main thing you’re paying for in a piece of software.
For the record: it is far, far easier to make a pretty user interface than a robust algorithm.
Designing a user interface is largely a question of esthetics, taste, and graphic design. These are serious, worthwhile, admirable concerns; and no doubt they're a lot of fun for the users. Just like a good-looking girl can be a lot of fun (even if she has mental health issues). But in plain terms, pretty graphics aren't central to the creation of useful business software. A text-based application, even with plain-Jane graphics, continues to be very useful even in the era of GUI; just ask any Linux or bank CASA application user.
But algorithms, that’s a different story. Have you ever been shown impressive, professional-looking menus and input screens, which all went for naught when the application simply couldn't produce the expected reports during the demo? That was an application with a nice facade but weak or no underlying algorithms to speak of. That's because it's far harder to create solid algorithms than pretty screens.
Mrs. Flor Katipunan, MIS Manager at a major government corporation, has a common-sense test for vendors who try to bowl her over with impressive graphics. Mindful that the success or failure of the software choice directly affects her career and reputation, she simply asks to see the application producing printouts of the reports that she's seeking. That quiet request puts any graphical razzle-dazzle into proper perspective. When she utters that requirement, the discussion swerves back to the real issue, which is: underneath the impressive coat of many colors, does the software solve my problem?
Enough said.
2. INFINITELY CONFIGURABLE EQUALS DIFFICULT TO USE
Do you have the notion that any software you obtain for your organization should be configurable to the exact way you like, to yield any report you care to specify, in any format that you care to dictate, now and forever, amen?
It’s certainly possible to get that kind of software. But it’ll cost you. And we’re talking about much more than cash. Here’s what you’ll have to live with: high development costs, long development times, long debugging times, high complexity in day to day use, a high level of dependency on your in-house expert as well as your vendor, and complexity in turnover when your resident expert resigns.
An infinitely configurable application would by definition require a high degree of tailoring; and tailoring means programming. And in practice, programming means a salaried in-house “high priest” and lots of hand-holding from your vendor (with the accompanying annual or monthly maintenance contract).
Therefore, your insistence on infinite flexibility can in fact make you hostage to those who have the skills to deliver, or claim to be able to deliver, on that vision of infinite flexibility. If you’re an SME, can you hack the price?
But there is another way: off-the-shelf software. If the problem you’re trying to solve is a common aspect of business operations (accounts receivable, accounts payable, inventory control, billing, payroll, customer relations management, MIS, and such), the plain fact is that these are standard business processes for which off-the-shelf packages are available. In the hundreds.
“Ready-to-wear” software, assuming it is brought to market by competent people, is simple to set up and uncomplicated to use. It requires minimal training for users; and the users themselves don’t have to be computer experts, certainly not programmers. They can be the owners and the line people themselves (you know? the really useful people in the business?)
RTW software is inexpensive because it is generic; it is not tailored specially for you; it is meant to be sold to thousands of SMEs.
To the innocent, that last is a negative; but in fact it is salvation for the SME. A generic, packaged application will typically have all the standard reports that you need; and only the anal-retentive or the obsessive could want anything much different. How different could your customer ledgers or sales book be from your competitor’s, anyway? or from the accounting textbook examples?
A well-chosen off-the-shelf package frees you to grow your business; it does not sidetrack you into a new career of (unhappy) system administrator and (reluctant) software development project manager.
Elpidio Ibaņez, Jr., President and COO of First Philippine Holdings Corp., tells the story of a stunning success. In December 2000, Dole Phils. then-CFO Noel Casanova put his employer, and his career, in the limelight by betting against conventional wisdom. He and his team implemented a usually expensive, difficult-to-implement enterprise (ERP) software in just four months.
He did this by decreeing that there be no modifications or customizations to the basic package. Casanova’s four-month implementation time was a record-breaker, beating out all other Dole country units in the rest of the world. Ibaņez of First Holdings capped his story: “It’s when you go for customizations that you get into trouble. I’ve seen this happen many times.”
At around the same time as the Dole Phils. feat, medium-sized companies Stateside were similarly waking up to the realization that off-the-shelf solutions are the way to go. For more fascinating stories dramatizing this mighty migration to common sense, read this piece from CIO Magazine’s website: http://www.cio.com/archive/051501/ faster.html.
3. CAPTURED DATA VS. NON-CAPTURED DATA
Once in a while an application user (the customer) will approach the application developer (the programmer) and ask for a “slight change” in the application. The experience can often be stressful and frustrating for both, for various reasons. encompassing everything from differing priorities, work loads, personal opinions about the relevance of the request, deadline pressures, etc., which we need not get into here.
Here’s a simple framework that will help both parties see each other’s imperatives with somewhat more mutual understanding.
DATA ALREADY CAPTURED? If the “slight change” being requested makes use of existing data that the program already captures, effecting the modification is relatively easy. Relatively. The requested slight change may mean reorganizing a report format or a writing a crucial change into the algorithms. Mind you, the work involved can still be substantial, but relatively less so than the other possibility described below.
DATA YET TO BE CAPTURED? Now if the “slight change” requires that the software capture a new type or types of data, you can no longer call the changes “slight.” To oversimplify, work will have to be done in at least the following areas:
First, the programmer will have to modify the user interface to capture the new type(s) of data;
Second, the programmer will need to rethink and rework the validations operating on data inputs (filtering rules that nip absurd inputs in the bud; e.g., labeling a male as being in the third trimester of pregnancy);
Third, the programmer will need to overhaul the underlying algorithms so that they do assimilate and process the newly captured data (this is a killer); and Fourth, the programmer will have to create a data conversion utility to make the old data compatible with the new data structures.
Obviously, you can expect the latter type of mod to cost more, to be much more difficult to set specs for, and to take quite a bit longer. -RSR
.
Questions? Reactions? Write to balmori@balmorisoftware.com.
............................................................................................................................................................