[
Article
]
what's the difference and why should you care?
Practically anyone who works in an office setting nowadays routinely uses spreadsheet software. Most of us are content to use them for simple models, like "Add Column A to Column B, putting the totals in Column C, then multiply everything by 0.255." Spreadsheets are great for making sales projections, costings, what-ifs - anything requiring manipulating lots of alternative scenarios.
But some users go further; they create more ambitious models, like entire payroll or accounting systems. To do this, they use the so-called macro capabilities of spreadsheet software, something that most spreadsheet users don't bother to learn. The resulting spreadsheet models are complex, impressive, and surely satisfying to their creators' creative longings.
An alternative to the spreadsheet model is the purpose-written application. There are various such applications, meant to do payroll processing, or accounting, or inventory control, and so forth. (When we speak of purpose-written apps in this article, we're referring to both off-the- shelf packages and tailor-made applications.)
Comparing applications to spreadsheet models is like comparing cars to trucks. To the indifferent layman, they're both vehicles that can do very similar things, and are therefore interchangeable; but to the transportation professional, cars and trucks have distinct missions. In a similar vein, there are some big differences between the purpose-written application and the home-brewed spreadsheet model. These differences could determine whether you have an efficient back-room or one that's mired in wasted motions.
1) STRONG AUDIT TRAILS. An audit trail is a piece of supporting evidence that an event (such as a business event) has occurred. For example, an official receipt number is evidence (and hence part of the audit trail) of a collection transaction; a Journal Voucher number is an audit trail of a general ledger entry; and an invoice is an audit trail of a sale transaction.
A well-designed, purpose-written application will not only preserve the audit trail, but it can also make the relationship between transaction and supporting document "unbreakable." For example, a well-designed billing application will automatically create a receivable the very instant a sale is recognized; this way, the organization doesn't have to rely on someone remembering to update the accounts receivable after every sale. Furthermore, this same well-designed app should automatically extinguish the receivable as soon as a collection is posted.
A well-designed app can create benign chains of these (desirable) unbreakable relationships to give the user a compelling benefit at the fundamental organization-of-work level. An example will illustrate the benefits.
Will you still be able to believe your information five years after software rollout?
Balmori Software understands business, we understand management, we understand audit trails. Our user-friendly software solutions keep your data reliable year after year after year.
Suppose you're paying a supplier. A well-designed back-room app will print out a disbursement check if and only if it detects that a payment authorization (a check voucher) has been properly encoded into it earlier. That's not all. In turn, the app would have earlier allowed the encoding of the check voucher if and only if it detected within its database that an accounts payable existed in the first place.
And that is still not all. Again, the app would have earlier created an accounts payable if and only if it detected that a purchase had originally been properly encoded. And in turn, the original purchase would have been encoded only if it had been approved by a proper authority.
For the user, this benign chain of unbreakable relationships means that the authorized signatory can confidently sign the check without needing to double-check the many layers of supporting documents for that disbursement, as people operating in a manual system are obliged - doomed - to do. (The one thing the app user does need to ensure is that the purchasing decision is well controlled, because that process starts outside the computer. You've gotta start somewhere.)
Whether the company issues five or five hundred checks a day, imagine the amounts of time saved; imagine the fundamental streamlining of the very way work is organized in that fortunate organization. And imagine the sense of security bequeathed by the knowledge of all those interlocking preconditions protecting basic business transactions against clerical errors.
2) ERROR TRAPPING. An error trapping capability detects certain important types of mistakes and prevents the encoder from proceeding unless he first corrects these mistakes. Much time is saved when you nip problems in the bud, rather than let them bloom and propagate, only to discover them at a much later stage, then have to retrace your steps and undo the damage.
For example, a well-designed general ledger app will automatically detect, as you are data-encoding, if your total debits do not equal your total credits; and it will alert you to the discrepancy, and require you to correct it, before allowing you to proceed any further.
For another example, a well-designed payroll app won't allow you to continue with the payroll cycle if even just one employee shows negative take-home pay. It will call your attention to the anomaly, and require you to analyze and correct either your data-encoding or assumption-setting, before letting you resume the payroll processing.
Many companies commit and correct mistakes many times a day, and the less attentive have come to consider errors a normal part of life. Usually, they respond by developing procedures to correct these errors, which would seem sensible. They build the error-correcting into some workers' job descriptions. They allocate process time to error correction. But by responding thus, the organization - without meaning to - has institutionalized the errors; its response shows that it has accepted them as inevitable. And by doing so, the organization has also in effect institutionalized inefficiencies.
The better response is to stop the errors from occurring in the first place. The Japanese had this epiphany in the 1970s, when they saw the cost impact of the quality assurance department sending back product for repair and rework. Why not re-engineer the production line to prevent these imperfections occurring in the first place? they reasoned. And thus started a decades-long Japanese domination of electronics and motor vehicle manufacturing.
By trapping errors, well-designed applications save you tons of time you used to spend tracking down, and then remedying, mistakes that were very avoidable to begin with. If you can be guaranteed that you never again have to squander these vast unrecoverable swathes of wasted time, you can imagine how much more productive your organization will be. (Click here for more on error trapping.)
3) ALGORITHMS WILL CHANGE OVER TIME, WHETHER YOU LIKE IT OR NOT. Any piece of software is at heart a collection of algorithms - logical (you hope), mutually consistent (you hope) rules expressed in mathematical form. These algorithms are mathematical expressions of real-world conditions, such as: "when we sell one unit of our TurboWhatchamacallit, deduct 1 from the stock- on-hand of that item, and also add that item and amount to the sales book, and also add that amount to our accounts receivable ledger, and also record that event in the customer ledger, and also compute and record the VAT payable on that item, and also compute the cost-of-sale of that item."
Met too many yeah-I've-written-lots-of-85percent-completed-applications.com?
Balmori Software's user-friendly solutions have been the MIS backbone of thousands of businesses since 1985
That last was an example of an algorithm that will never change, because it describes fundamental relationships in an accounting system. But plenty of other algorithms in business experience can be very changeable indeed.
For example, Republic Act 8424 (1998), also known as the Comprehensive Tax Reform Program, may not exactly have reformed our taxation structure, but it certainly changed the way income tax gets computed, at the arithmetical level. When R.A.8424 took effect (1998), all payroll app authors in the Philippines had to rewrite their algorithms. They had no choice; though the taxation changes were piddling in terms of net take-home for most people, the basic arithmetic had undeniably changed.
And then, in July of 2008, R.A. 9504 came around, and once again massively changed the way payroll is computed. (R.A. 9504 supposedly exempted minimum-wage earners from income tax... as long as they stayed within a collection of ifs, ands, and buts as long as your arm.)
Now if you're relying on a spreadsheet model, and an algorithm in it needs to be changed, but the original author is no longer on the scene, chances are nobody else can do the necessary tweak. (Oh, you know this already.) A purpose-written app, by contrast, will be supported by its vendor via an upgrade containing the new algorithm(s). (Click here for more on algorithms.)
4) ROBUSTNESS. Everything that's been mentioned up to this point builds up to the notion of "robustness." A software application is robust if it's resistant to internal inconsistencies, to casual questionable modifications to its algorithms, to being overwhelmed by unexpected forms or quantities of data. We also call an application robust if it eliminates unnecessary data re- inputting, because each instance of manual data inputting is another opportunity for errors to creep into the database. In short, robustness begets reliability. Bottom line: robustness means you can continue believing your data for many years to come. Think about that.
For example, does your payroll system allow you to delete an employee record in mid-year? No payroll system should ever allow this, as any payroll clerk knows. Payroll applications shouldn't delete any employee records in mid-year, because the end-of-year alphalist reports to tax authorities require detailed data on all employees, whether still on the rolls, fired, or resigned during the current year. Alas, inadvertent deletion of employee records is all too easy in a spreadsheet model.
Does your inventory control app rigidly and consistently relate all inventory movements to, respectively, either sales, customer returns, accounts receivable, customer ledgers, and receivables ageing; or to purchases, returns to supplier, accounts payable, and supplier ledgers? (The answer should be: yes, yes, yes, yes, yes, yes and yes, as any trained accountant knows. Difficult to see a spreadsheet model enforcing all these unbreakable relationships.)
Furthermore, when the data relationships are this complex, you wouldn't want your algorithms to be casually modified by just anybody. Alas, but this is a fact of life with spreadsheet models: critical elements or formulas can be so easily modified or inadvertently erased. If your algorithms are too easily modified, and by people not subject to a certain professional discipline, you soon fall victim to that great unacknowledged bugaboo of information consumers: that sinking feeling that you can't quite believe your own data anymore.
This creeping contamination is more easily avoided when an app is a well-designed, purpose-built solution than when it is a spreadsheet model.
5) ABILITY TO "TALK TO" DOWNSTREAM (OR UPSTREAM) APPLICATIONS. Let's return to the payroll example. The payroll process produces outputs that you need to submit to banks and government authorities. In the Philippines, increasingly, these entities are demanding that you submit reports to them in both hard-copy and electronic formats. A purpose-built app can be engineered to produce these reports so that they can be submitted by diskette or flash drive or e-mail to the SSS, PhilHealth, HDMF, BIR, and to your payroll disbursing bank.
And even if these entities didn't demand it, you'd want it sooner or later, to protect yourself from other people's mistakes: a report in electronic format eliminates re-encoding by the recipient entity - yet another opportunity for errors to be introduced by an entity outside your control.
6) USER FRIENDLINESS. A single-purpose tool is always easier to use than a multi-purpose one. A stand-alone hacksaw will cut through a frozen bolt-head faster than the hacksaw in a Swiss army knife. By the same token, a well-designed, purpose-built app can be engineered to be easier to use than a spreadsheet-based model. How so?
The spreadsheet model confronts the user as a tapestry of numbers, usually so sprawling that it requires users to pan and scroll the screen in all four directions. Data-entry points are at various difficult-to-spot places on the page. Land your highlight bar on the wrong cell, and you could end up overwriting a crucial formula or constant.
Learned your lesson with Mr. Yes-I-know-I-promised-it-in-3-months-but-now-I-need-24-months-to- debug-it?
Call us now for easy-to-use, reliable business solutions that work from Day 1.
A purpose-built app, on the other hand, will present just the relevant menus and input screens that you need for the current task at hand, and nothing else extraneous to that task. For example., if you're encoding disbursements, a purpose-written app will present just the (sub)menu for inputting disbursement details, and nothing else.
User-friendliness is not a trivial issue. A user-friendly application is more likely to be used longer, to produce fewer errors, and to be successfully turned over to a successor- user when the original user moves on. A user-friendly app also makes the user more productive by preventing clerical errors through its error-trapping features.
In contrast, most people's personal experience is that a spreadsheet-based model is user-friendly only to its original creator, and often not even to him.
CONCLUSION. Ever since Dan Bricklin brought Visi-Calc to a grateful world in 1978, the electronic spreadsheet has been a wonderful gift to analysts, businessmen, and students everywhere. It's been a valuable tool for empowering the questing individual pursuing a personal commercial vision - building an investment what-if scenario, comparing crop statistics to confirm a personal intuition, and so forth.
But spreadsheet models can also be very fragile. They have serious weaknesses in the areas of audit trails, error trapping, algorithm maintenance, inter-operability with other downstream/upstream applications, and user-friendliness. Spreadsheets are not, and were never meant to be, the backbone of a corporate data-processing infrastructure. This makes it difficult to see spreadsheet models becoming more than specialized tools within the user organization. It's difficult to see any one spreadsheet model living on as a long-term corporate resource, the way a purpose-built app would. Meaning, once its creator leaves, the spreadsheet model he developed will likely not endure long in his former department.
Spreadsheets also have other things going against them as infrastructural company resources. For example, compared to a database, a spreadsheet has a pretty low data storage capacity. For the heavy lifting in an organization, you'll want strong audit trails, error trapping, algorithm integrity, interoperability with other applications, user-friendliness, and accessibility by ever larger groups of people (scalability) as your organization recognizes the reality that we are all interconnected. To access these benefits, the purpose-built app is the way to go. - rsr
Questions? Reactions? Write to balmori@balmorisoftware.com.
New!
SURE! General Ledger Ver. 8 web-enabled variant is now available.
Encode data or print reports from anywhere in the world (or through your workplace LAN).
Click here for more.