Balmori Software Inc.

[ 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. At the end of Part 1 you will find a link to Part 2.)

Battle-scarred software professionals, company owners, and hands-on users who've been through the experience can agree on one thing. 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 what look like 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.

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. These include customer records, supplier records, product codes, account codes, etc.

If you are in charge of implementing an application, recognize this: though typing in your reference files looks like a clerical task, the preparatory work you need to do before encoding is anything but routine.

It's like painting a car. The preparatory work is the part that demands the painter's observational faculties, experience, and skill. And it's also the part of the work that takes the most time. AND: sloppy preparation means the paint job won't last.

It's like that with setting up a business app. You face crucial design choices about an app'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)?

We want to departmentalize our product line; how does that affect how we design our product codes? Should we categorize our customers and suppliers into sub-groups? With 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 capture detailed employee personal data, or just stick to the minimum data needed for statutory deduction requirements? What are the specific formulas 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?

It's only when you're done answering all these questions that you're ready to fill in the blanks in the set-up screens of your app.

The design decisions you've just made constitute a significant milestone. But - surprise - that was actually the easier part.

What comes next is the tricky part. The part that can make your roll-out a purgatory, if you're not careful.

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 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 you: Does the finality or non-finality of the numbers make any difference to your computerization goal?

Think about this. If you wait for audited financial statements before inputting 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 set-up. But do you really have to wait those extra months while the external auditor "perfects" his report?

Remember, everybody is always having to be making adjusting entries all the time. Do you really have to start out with "perfect" numbers? Here's a hint: you can always make adjusting entries anytime. This is true whether you are on a manual system or a computerized system. But encoding adjustments is much easier if you are already computerized.

Here's a thought: go with a reasonable unaudited beginning balances, and just accept that they'll be adjusted somewhere down the road. The important thing is that 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.

Choosing the cutoff date: a perilous decision. This decision is not for junior staff or inattentive managers. Let's confront this head-on. Deciding on the cut-off date - the specific point where you change over from manual to computerized mode - is a dangerous moment. 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 last December 31 as your cutoff date, then your beginning balances are the ending balances as of December 31. That means your beginning balances are three months and eight days old as of today. But if you happen to choose March 31 as your cutoff date, then your beginning balances are a mere eight days old today. The implications of this choice on the amount of encoding work you face are enormous.

A December 31st cutoff would require you to input three and a quarter months' worth of transactions just to catch up to today, April 8. But a March 31 cutoff would have you input only a week's worth of catch-up transactions. And much fewer transactions still if you were to 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 have this tendency 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 that statement seems so reasonable, so obvious, so common-sense, that co-workers usually accept it without question.

But it does make 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," 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.

The longer the set-up takes, the longer you have to wait before you can 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 your back room running efficiently.

Face it, there's a tension between the vision of "fully computerized records" versus the reality of serving customers/suppliers/relevant publics right now. You simply can't have both during a computerization rollout. In our experience, insisting on achieving both during a rollout leads to failure.

And concretely, while you're wrangling the set-up, while you're catching up with transactions from months and months ago... what do you think is happening to the transactions that keep coming at you in real time ? We'll tell you what's happening. 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. Customers won't tolerate poor service just because you're "rolling out a new software."

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. 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?

The sensible approach is counterintuitive: choose as recent a cutoff date as possible. Then input beginning balances based on that recent date. In effect you need to make a bold decision: what data to leave un-computerized. In our example earlier, you'd be doing yourself a big favor by choosing either March 31, or even better, April 7, as your cutoff date.

It's in your interest to have your computerization up and running as soon 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 being more sensible, on generating wealth, and being entrepreneurial. And that means focusing on "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? It's not a crazy idea because those last few months' transactions will soon complete their normal life cycles, then will stop being a concern.

You'll collect your old, un-computerized accounts receivable, then they stop being a concern. You'll pay off your un-computerized accounts payable; then they're no longer a concern. For the few weeks or months that these items do remain open, your bookkeepers can handle them manually. (They did this for years, didn't they? What's a couple more months?) Then these un-computerized transactions fade away, then they're no longer a concern.

Your payoff is, in the meantime, your current transactions have been 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're inputting actual, current transactions, that your new software is earning money for you. Everything before that is cost. It is thus in your best interest to see that you complete the set-up aspect as fast as possible. -rsr



Share on

                                                                

---