Troubleshooting When a Computer System Goes Haywire

And you wonder why computer systems break down... Leave them alone and computers won’t even come to life – unless there is a pesky poltergeist in the room. But I am getting ahead of myself again...

The design of systems, Computer Science textbooks say, is preceded by this process called systems analysis. In a nutshell, the analyst takes a good hard look at a manual business process prior to computerization and streamlines it by proposing to remove redundancies in the process.

Only when the redundancies and the non-essentials have been removed from the manual process will the analyst try to ascertain where computer systems – hardware, software, peripherals – can come in to automate tasks that, in this day and age, should really be beneath the dignity of humans to perform.

As a natural consequence, a redesigned business process using computers to complement the heretofore purely manual tasks is supposed to shorten processing time, improve productivity, reduce manpower needs and increase profitability.

Remarkably simple? In a perfect world...

In the real world, everything is complicated even at the systems analysis stage. The streamlining of business processes supposedly removes redundancies based on industry standards and established best practices.

Try saying this to those who have spent year after year performing the same redundant and wasteful processes. Frequently, they will even tell the analyst that these are the correct practices; and to hell with standards. Those won’t work here, that is the frequent claim.

Whatever they say about favouring computerization, they will hold onto existing processes because these are – psychologists hypothesize – established comfort zones. It is never easy to accept that what one has simply performed as established procedures over the years are actually wrong or outmoded – or, that there are better alternatives.

This is not to say that would-be end-users participating in the business process analysis are the only ones capable of being culpable. Systems vendors, constrained by the need to make a buck, can be eager to compromise standards by agreeing to customization after customization. There is nothing wrong with customizing an existing standard system per se; it is when the customization overwhelms the standards that a whole system can go haywire.

Personally, I had seen this happen up close; and had to step in just because the requested tweaks would never have come to an end. Far from the entire business process being streamlined, what was happening was a mere computerization of the manual process or, as we used to jestingly refer to it, the creation of a manumatic system.

Instead of computers taking over repetitive chores – and thereby decreasing manpower needs – more people were, in fact, being requested! How the devil was that possible?

Then, of course, when a computer system is put in place and integrated with other existing systems, it is always simpler to get the computers in the workstations to talk to each other than to get people to do exactly the same. I was actually witness to a heated argument about who would encode a mere four pages of figures.

“My people are overburdened!” one declared. “So are mine!” the other countered. Disgusted, I asked somebody else to do the encoding. Four pages, duh... And how much time spent on Facebook? If only people can be reconfigured...

Among end-users, there can also frequently be this mistaken notion that once a computer system has been acquired, a mere poke at the keyboard will bring out a magical genie from the monitor to reassuringly say, “Master, your wish is my command...”

Wake up from your Ali Baba dream! It is never that way.

First of all, people are part and parcel of the entire system. Second, systems are designed by humans; and there will always be bugs or problems not previously anticipated by the original programmers. That is why most off-the-shelf systems – your Windows OS, for one – come with automatic updates for downloading patches or service packs.

When there are problems, the systems providers can come in. That is why they always have a clause in the contracts that they sign with organizations that state that they can be summoned to fix glitches to a certain extent. Before they even come, the end-users themselves can always sit down to find solutions. Workarounds are also part of the system; else, organizations will have no need for manpower whatsoever.

But of course, as already mentioned, getting people to sit down to find solutions can be the real problem and not the computer system at all. The problem is exacerbated if management is not computer savvy. Then, end-users resort to finger-pointing instead of finding solutions which can – as I had myself seen first-hand – be remarkably simple. But of course, if there is a blame-game ongoing, it is human nature to want not to be seen.

Many of the end-user problems that can be encountered regarding computer systems can often also be attributed to an organization’s computer training policy; and frequently, the lack of it. These days, and especially among younger employees, it is simply assumed that everyone will be comfortable sitting in front of a PC.

The assumption is not without merits. In this day and age, most everyone would have had some MS Word or Excel experience from school alone; not to mention hours upon hours spent surfing the Internet with a browser.

Yet, the assumption is also faulty in that it assumes that everyone has had the same level of computer learning in school. In reality, this is not true at all. I had personally encountered even young people who had not yet discovered that there were such things as keyboard shortcuts or that there was so much power that could be unleashed by simply clicking the mouse’s right button.

Personally, I feel that all end-user training must begin with the quest for a full understanding of the operating system. Yet, I know an awful lot of people who went straight to word processing even without fully understanding the OS. Frequently, many of these were not even formally trained.

When these people get to the workplace, not only will their productivity already be compromised; they are also not armed to explore the power behind a system – whatever system! Truth be told, my own hypothesis based on experience on why people are sometimes reluctant to accept computerized tasks – such as in my example earlier – can be down to the fact that they are feeling overwhelmed by something that they think of as highly technical.

I still vividly recall one line from the book “PC for Dummies” that I bought way back when I was just getting started in the wonderful world of personal computing. The author encouraged the reader to tinker around with the computer and tried to be reassuring by saying that “the PC will not explode.” This was said facetiously; but there was an underlying truism especially for technophobes.

How many people that sit in front of computers are actually wary of exploration if not really thinking of an explosion then at least of something going frightfully wrong? There are still plenty of the sort around in the workplace. Not that it is ever their fault. Do you ask somebody who has never held the steering wheel of a car to drive you around the city?

To get back to the crux of the matter – and granted that hardware can indeed break down – whenever computer systems go haywire, now we all know where to look first. The computers? Nah... They are lifeless objects made and operated by people.

-------------------------------------------------------------------------------------------
If you enjoyed this article, please click the Like button or share it freely on social media. It helps to pay this site's domain name and maintenance costs.

Share |