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