It is surprising how many computer
systems used by retailers fail to produce accurate figures and are inherently
unreliable. Such problems are not limited to old, or in-house developed
systems. Some of the software packages on the market are also lacking.
On the surface it may appear as though such issues are caused by software
bugs or by errors in implementing the system. However, it is often poor
system design that is the main source of recurring problems. If your system
has inadequate architecture (internals), no matter how many ‘bug
fixes’ are made, it will continue to malfunction. If the frame of
a house is unsound, no volume of plaster can cover the cracks — they
will keep coming back. If your thin-client POS system is slow at times,
there is little you can do about it - ever. When you have 100 terminals
bidding for the same resource at the centre (the main server), at times
it will suffer from a peak overload. At times it will also be the Internet
going slower than usual.
Consider another situation: one of the fundamental requirements in retail
systems is the need to ensure that the same information is available in
various locations. For example, a store’s stock on hand information
about an item must be the same in the store and in the head office. That
sounds simple enough, but unless your stock control system has been designed
to work with stock transactions rather than with stock balances, it may
not be able to reliably show the stock on hand. For instance, let’s
assume that the opening stock level is 5 units and it is reduced to 4,
because 1 item is sold in the shop. At the same time a stock receipt of
10 units is entered in the head office (for the store). As a result the
head office database will end up with 15 units of stock in the store,
and the store database will have 4 units. The problem is that neither
4, nor 15 are correct.
If you are using a properly designed system, both the store and the head
office databases would show the same stock balance: 14, irrespective of
where the transactions were entered into the system and in what sequence.
This can only be done by exchanging stock transactions between locations
instead of stock balances.
This is why when choosing a new system, it is important to avoid the
common mistake of focusing only on system features vs. cost, without giving
a very high weighting to system architecture. It is like buying a car
— it is easy to end up with a cheap lemon with a lot of features
that keep malfunctioning and giving you constant grief. Choose wisely,
or ask for help in making the choice.
| 
