[
Article
]
(This is Part 1 of a two-article series on a topic of some concern to most SME businesses. It can be read in conjunction with Part 2, or as a stand-alone piece. Click here to read Part 2.)
Battle-scarred software professionals, company owners, and hands-on users who've been through the experience agree that after the software selection process, the software set-up stage is the most delicate part of computerization. That's because it's the time when poor choices about seemingly trivial issues can lead to serious problems months onward. Because the issues seem inconsequential, top managers may "leave it all up to the troops." Then it becomes like the case of a poor navigator starting out with a 1-degree error in his bearings. Halfway into the voyage, he's hundreds of miles off course. To avoid an analogous disaster in your computerization experience, pay special attention to the set-up process.
Encoding the reference files is a design task, not just a clerical task. The first task in setting up a software application is to build the reference files. These are the basic assumptions that the software app needs to be able to do its work: customer records, supplier records, product codes, account codes, etc. If you are in charge of implementing an application, the important thing to keep in mind is this: though encoding all this data looks like a mere clerical task, the preparatory work prior to encoding is anything but. It's like painting a car; the preparatory work is where the painter's observational faculties, experience, and skill are fully deployed, and it is also the part of the work that takes the most time. Similarly, there are crucial design choices to be made about a software application's reference files before you even turn on your computer, before you even set fingertips to keyboard. What are these?
The important design considerations are best expressed as questions. Before launching your new software and pounding away at the keyboard, get these questions answered first.
For General Ledger applications: How should we structure the account codes for the chart of accounts? What cutoff date do we use for our account beginning balances? How many levels of account organization does the software allow us to use? Before you plunge headlong into the setup process, ask the vendor's software consultant for suggestions. These guys have watched scores of companies make this decision and can give you useful insights.
For Inventory Control applications: How do we code each SKU (stock-keeping unit)? Should we continue using our traditional product code structure? Should we invent our own product codes, or should we adopt bar codes? What format should we adopt in rendering our product descriptions (brand name first, or size descriptor first, or formal name first)? Will it benefit us to departmentalize our product line, and how does that affect the coding of our products? Do we want to categorize our customers and suppliers into sub-groups? To what account codes in our general ledger will we associate our sales/collections/purchases/disbursements totals?For Payroll applications: Do we use numerics or alphanumerics for employee codes? Do we store personal employee data, or just stick to data relevant for statutory deduction requirements? What are the specific algorithms we use for computing bonuses, 13th month pay, incentives and commissions, and other income and deduction items. Which income items in the payslip are subject or not subject to withholding tax? to SSS/Philhealth/HDMF contributions?
A particularly sensitive aspect: beginning balances. All sorts of applications require all sorts of beginning balances. General Ledger applications require a beginning balance for each account title in the chart of accounts. Inventory Control applications require a stocks beginning balance for each stock item in your inventory. AR/AP packages require an a/r or a/p beginning balance for each customer/supplier record.
Should you wait for audited beginning balances?, a lot of people ask. We throw back the question at them: Does the finality or non-finality of the numbers have any relevance to your goal of computerization? Think about this: if you wait for audited financial statements to form the basis of your beginning balances, it's a near certainty that you will have to wait a few more months before you can get started with your software setting-up. But do you really have to wait those additional months while the external auditor "perfects" his report?
Remember, everybody is always having to be making adjusting entries all the time. Is there anything particularly imperative about starting with "perfect" numbers? You can always make adjusting entries anytime, whether you are on a manual system or a computerized system, and much more easily if you are already computerized. Our recommendation: go with a reasonable unaudited beginning balances, and simply accept that they'll be adjusted somewhere down the road. But by then you're fully computerized; and you'll be making your adjusting entries to a successfully computerized set of books, which is a sweeter state than flailing around arguing about the correct numbers for beginning balances - and never quite getting around to "being computerized." Bottom line: you don't need to wait for audited financial statements before launching your computerization.
Software solutions that deliver. No excuses.
Easy-to-use, reliable solutions that work from Day 1.
Since 1985
Choosing the cutoff date: not for junior staff or inattentive managers. Let's confront this head-on. The subject of beginning balances forces everybody to make a danger-filled choice: the choice of cutoff date (the specific point in time where you transition from manual to computerized mode). Your choice of cutoff date determines whether you have a pleasant computerization experience or a miserable one. In other words, whether you have very little encoding or a massive amount of it to do later on.
Let's say that today is April 8. If you choose December 31 of the preceding year as your cutoff date, then your beginning balances have to be the balances as of the close of business on December 31. On the other hand, if your cutoff date is March 31, then your beginning balances are totally different. Since today is April 8th, you can easily see that you have a lot more catch-up transactions to encode with a cutoff of last December 31 than if your cutoff were March 31 of the current year. And obviously much less still if you choose April 7th - yesterday - as your cutoff. Any of these choices is defensible by a clever corporate debater; but the real question is, How much encoding work are you prepared to endure? Allow us to explain.
People tend to say, "Well, as long as we're computerizing anyway; we might as well computerize all our transactions beginning from January 1 of this year." (Meaning, the cutoff date is December 31 of the preceding year.) And the statement seems so reasonable, so obvious, so common-sense, that it's usually accepted without question. But it makes a big difference if the date at the time you utter that thought is a few days or a few months distant from January 1. Before you swallow that "no-brainer" statement, understand this: the further back in time your cutoff date is, the more catch-up transactions you will need to encode, and therefore the longer your set-up process will take.Most damningly, the longer set-up takes... what do you think is happening to the transactions that keep coming at you in real time while you're catching up with transactions from months and months ago? Your current transactions are being sent to the end of the line, when in fact they should be your first priority. Reality is not going to stand still while you catch up with your encoding.
The longer the set-up takes, the longer you have to wait before you enjoy the benefits of computerization. The longer the set-up takes, the longer you are not servicing customers quickly, not making decisions optimally, not getting things done efficiently. In numerous cases, the very tension between the vision of "fully computerized records" versus the reality of serving customers/suppliers/relevant publics right now is enough to cause the computerization effort to fail. In our experience, this is the single most common reason why computerization efforts fail.
Someone who is not a businessman may fail to see the significance of this last point (someone, say, who values perfect reports over speedy customer service). On this point, for your sake, it had better be the business people, not the bureaucrats in your company, who get to make the choice on cut-off date.
What, then, is the appropriate cut-off date?
Twenty-seven years of never letting anybody down.
We stand by you. Since 1985.
Being strategically clever about the transition process. The sensible approach is counterintuitive: you should choose as recent a cutoff date as possible, and input beginning balances based on that recent date. In effect you need to decide boldly what data to leave un-computerized. In our example earlier, you'd do yourself a big favor by choosing either March 31, or even better, April 7, as your cutoff date.
It's in your interest to be fully up and running as quickly as possible. That means having the guts and the discipline to resist the siren song of "complete data for the year." That means focusing instead on the more sensible, wealth-generating, and entrepreneurial goal of "being ready to handle all the transactions that come in starting now."
What, then, do I do with that part of the year that I leave un-computerized? you ask. Here's an irreverent thought: keep handling them manually. Yes, you heard that right. Why is this suggestion not as crazy as it sounds? Because those last few months' transactions will very soon complete their normal life cycles, then will cease to be a concern. Old, un-computerized accounts receivable will be collected, then will no longer be a concern. Un-computerized accounts payable will be paid, then will no longer be a concern. For the few weeks or months that they do remain "open," all the way through to the end of their normal life cycles, they can be manually handled by your human bookkeeping clerks. Then they fade away, then they're no longer a concern.
In the meantime, your current transactions have been fully computerized from day one (the cutoff date). One day soon - perhaps in as little as one quarter - you will find that all your current transactions are solidly computerized. By the next fiscal year, you're already a veteran at reaping the fruits of computerization. Another few months later, you won't remember what it was like to be running your back-room manually. And then you'll be glad you took the gutsy stand of not encoding all your transactions from January 1.But what about taxes and government reporting requirements? Our hard-nosed answer: live and deal with a hybrid of manually generated and computer-generated reports for just this year; it'll be the last time you'll have this "messiness." Heck, you've been dealing with this messiness for years anyway; what's one more year?
Here's a final thought: It's only when you complete the set-up process, when you are inputting actual, current transactions, that your new software is earning money for you. Everything before that is cost. It is therefore in your best interest to make sure the set-up aspect is completed as fast - and as accurately - as possible. -rsr
(This is Part 1 of a two-article series on a topic of some concern to most SME businesses. It can be read in conjunction with Part 2, or as a stand-alone piece. Click here to read Part 2.)
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.