|
The Problems
The phrase "Best Practices" is so overused, it has become practically meaningless for IT Managers. It is a common understanding that improvement is necessary, but where do you start? What tools are appropriate? Where do you find actionable information and how can this be accomplished with minimal cost? If these questions apply to you, this paper will provide a plan of attack.
First, let's identify a few key problems with many IT support organizations and why they tend to be widespread with inefficiencies that produce suboptimal results. These are problems that neither IT Managers nor staff members like to readily admit. We will review the following five IT operational problems, and then discuss appropriate solutions:
1. Lack of clearly defined, repeatable, well documented processes
2. Knowledge "hoarding"
3. IT "silo management" - independent, decentralized management
4. Insufficient budget and tools
The following sections discuss each problem, their causes, effects, and strategies for eliminating them.
Lack of Clearly Defined, Repeatable, Well Documented Processes
This problem ranks #1 on our list because it is likely the most common and the most admitted problem among IT Managers. So what causes this? Lack of processes is not intentional but it can cause definite problems.
Analysis and Recommendation
The first two solutions (#1 Written acquisition and integration policies, and #2 Written change management guidelines) are most common. Unfortunately, written policies and guidelines, if not meticulously maintained, run the risk of instant obsolescence. It is difficult and impractical to have a single person become a documentation and written policy czar who can adequately capture and maintain these forms of documentation. The alternative is having multiple contributors provide non-standardized, highly variable and difficult to maintain document sets that further undermine the effort and possible benefit.
Solution 3 stands a better chance because, if implemented properly, it continuously detects the causes and changes, and forces a well documented, automated response. Software that triggers and enforces a process that keeps pace with the organization is what is needed. If it is not required as part of your personnel's day-to-day responsibilities and workflow, or in other words, if they don't "use the tool," the problems will persist and the software will fail to achieve the process improvement that it was designed to solve.
Action Plan
If there is not a budget or an ROI-driven investment initiative for an automated Fault Management and Knowledge Management tool, then there is no choice but to mandate that all support personnel create and adhere to written policies for Asset Acquisition and Change, Configuration & Fault Management. Management must then enforce the use of written procedures utilizing best-efforts measurement mechanisms.
If the possibility exists for examining tools, our recommendation is to look for a multi-function product that has a built in process that encompasses fault/change management with little customization required. The logic here is the same one used in ERP software, where many customers have been burned by customizing their product to the point where it could no longer be supported or upgraded. It is true that vanilla packages may not follow your processes exactly, but consider the benefits of the organization conforming to a pre-defined process rather than customizing the tool.
Knowledge Hoarding
This problem often lurks silently among IT staff. Every IT shop has key trusted IT personnel with critical knowledge and expertise. IT Managers tend to rely on these individuals to simply do their job and get things done. Sharing the knowledge and having it translated into processes and best-practices is often resisted. The resistance is natural because these key individuals derive their very job security from their knowledge and skills.
Let's look at an example: Perhaps your organization is using monitoring tools and the software generates an alarm notification to your database administrator (DBA) that a database is reaching capacity limits. Your DBA's pager goes off, he or she responds to the problem and fixes it to prevent an application outage. So where's the problem? The problem with this scenario is twofold. First, what if the DBA is unavailable? Perhaps the alarm goes to another team member via an "escalation rule" in your network monitoring software.
|
