Enterprise Information Technology is facing new challenges every day. There is a call for better utilization of funds, shrinking margins and immediate results.
The main driving force behind upgrading systems is an increasing demand for Automation, increasing costs of support for obsolete products and fast changing technology Trends. The other possible factors that compel the need for change are poor usability or little knowledge about in-house systems, inefficient integration of various enterprise systems, lack of a long standing and visionary IT support staff.
Every decision making is influenced to a large extent by the people involved. Similar is the case for IT system upgrades. By system I refer to the technology and not the underlying hardware. IT managers favor systems/ platforms that they themselves or their workforce is familiar with. IT service providers push for the most cost effective solution to the given problem at hand. The limited budgets, competitive market conditions and the need for quick solutions forces both the Solution seekers and providers to ignore - a large portion of the current systems (connected to the requirement at hand), bottlenecks that can be faced in the future, and introduction of more needs for integration to existing systems.
This leaves the Customers, vendors, developers and end users of the systems weighing pros and cons of the system that has passed by and the system that has sprung up. Of course the new system will have significant improvements over the old ones but they might miss out on one or two characteristics liked by the previous users and usually create more integration points or exception scenarios known only to the people involved in the project.
This is where the “history” of the systems plays a very significant role in smooth functioning of the new system. Here we can attribute a good factor of success to the key contact points in IT staff who can understand the old as well as the new system, the changes made and the exception points where the old system is to be referred again.
Here is the place where a good Level 3 support team comes in handy. Now a days, the trend is to obtain maximum utilization and support related activities are mostly considered as expenditure and not investment. Hence the support team is usually overloaded with nothing but fixing of a few priority problems that have been assigned to them. A typical support team should 1 - have atleast three members with 2 - at least 50% of them with an experience of more than a year in the team and 3 - their utilization should not be above 85%.
- A one person support is a frustrating experience where you do not have the liberty to turn to help or anyone or to get a second opinion on what you are doing.
- There should always be continuous learning in a system. No level of documentation can give you the right exposure to a system unless you have experience with the interacting systems, the code itself and the people / purpose the system serves. People experienced with the system are important for grooming the next set of support engineers and also for monitoring the change that happens when a new system is commissioned.
- An over utilized team would only be able to patch up a system rather than enhance it. They are under the constant pressure of fixing somebody’s problems that they do not get the time to appreciate the system, explore, learn and improve it.
Exploring and appreciating the system gives a feel of ownership to the support engineers that they think about ways to make the system more robust and easy to use. And since this change comes from a team with in-house knowledge, the changes may be minor but significant. This enables the system to slowly evolve with lesser bugs and significant performance improvement. Any significant changes to the system should involve the Support / existing IT team. This would ensure that the solutions are nothing but the best in terms of utilization of existing systems and applications.
A stable support team would be able to provide periodic releases to different components of the systems, and also identifying existing bottlenecks that degrade the systems. It helps them to align their knowledge towards the underlying technology of the systems and to apply changes in technology to best suit the needs of the current system.
In short when an Enterprise system is overhauled for replacement by a better one, the change should be initiated, planned and executed with not just the potential users, but also with those who actively understand, appreciate, maintain and improve it at the ground level. This would ensure a successful evolution to stable and robust systems with the knowledge and history intact.