Good systems can go bad
Build a good system with an advanced technology. Win praises for it. Use it for your business for many years. Fix only what breaks, even as the environment changes. Deny all criticisms. Good systems cannot go bad. Or can they?
Recently, I came across a few electronic car park systems. The car park lot availability counters were easy for drivers to read from afar. The barriers at the entrances had friendly messages and even creative advertising space. The systems could automatically detect the contactless cashcard in the car. The barriers were automatically and steadily raised for cars to enter the car park. There was just one problem with all of them: Even after taking into consideration possible business reasons for a margin of error, they counted the number of available car park lots wrongly.
So your organization has a state-of-the-art Infocomm system. Wait, was it state of the art, circa 1980s? Does the system still do well at what it was primarily built to do? Do your staff members and, where applicable, customers still consider it state of the art?
We hear much about change. Many organizations seem to believe their Infocomm systems can change by themselves, though, automatically adapting as the operations and business environment change over the years. The Infocomm team, which lost sleep and proper meals for months or years to build that Infocomm system, would understandably wish for that, if it had not already moved on to the next praise-worthy system. But most Infocomm systems are not that smart; not yet.
For example, a business has an internally used Infocomm system, which automatically processes data collected from the systems providing services to customers and generates many detailed reports monthly. When it was developed, it won awards for its high level of automation in its industry at that time. Years later, to move the business forward, top management sees the need to approach business decisions differently by analyzing the same business data differently. Proper implementation of the software changes would require many months. Meant to be an interim measure, the data is exported monthly so that some staff members can manually create the new reports. Unfortunately, the required manual effort is so great that just as a round of reports is done, the next round needs to be started on. This manual process continues beyond the financial quarter, and soon, beyond the financial year, too. This is hardly moving forward. The Infocomm system that was supposed to ease work eventually constrained the business.
It is good practice for an Infocomm system to be, firstly, designed for change, as someone puts it. It is good practice to thereafter manage change systematically. It is better practice to foresee and plan how the Infocomm system will evolve.
Legacy systems need not necessarily become ugly monsters, provided their architecture allows for adaptability and they have been diligently maintained. It seems a large profitable international company with a time-critical core business was still using PDP-11 well, even in recent years. That Infocomm system was certainly not preserved at its early state to reach such a good return to investment. I understand highly competent staff made continual improvements to keep it relevant to the business.
Neglecting and denying the flaws of good Infocomm systems can cause them to become useless, and therefore bad, to the business. To most businesses and their customers, what matters is not how advanced in technology an Infocomm system is, but how useful it is to the people using it.