Information Technology
443
How do you determine where to set a standard? Exhibit 17.5 illustrates a process to use for determining and setting standards by area. Standards should be set at the highest level in the organizational structure at which they make sense. A wide area-networking standard, designed to connect all offices together, should be set at a global level. An accounting standard designed to ensure that data from all offices is compatible should also be set at a global level. Likewise, an application that has only local utility should be set at a local level.
The real difficulty or a special difficulty comes when setting a standard at a regional level. Many times the regional distinction is more a matter of convenience than logical necessity. Support regions are often set up to provide local time zone and local language technology support. There is not necessarily a user difference or a system difference between the regions.
Some distinctions may exist, however, where regional business management is attempting to meet different strategic objectives. Because technology should align to the business strategies, and not vice versa, differences between regional standards may result.
Another reason for differing standards, the reason that should be sparingly applied, is the difference in the maturity of a region in a particular matter or in a particular area. For example, if one region is significantly mature in its support structure, that region may require a standard call center software and approach. That same approach may not be practical in the other regions based on maturity. In such a case, that standard may not be set for the other regions. The standard could be set once the regions are ready to adopt call center technology.
Standards don’t have to be perfect. A cubit is an ancient unit of linear measure. It was equal to the length of the forearm from the tip of the middle finger to the elbow. While this was a handy unit of measurement as people always had their arms with them, it was not particularly precise. Depending on who applied the measuring, the cubit would be of different lengths. Yet, it provided an important way to measure. With modern need for extreme precision, distances are much more precisely defined. For example, a meter is defined as “the international standard unit of length, approximately equivalent to 39.37 inches. It was redefined in 1983 as the distance traveled by light in a vacuum in 1/299,792,458 of a second.”6
When setting a standard, you must determine the reason that the standard is needed. Standards for standards’ sake do not advance the enterprise. In fact, they can do the opposite by limiting creativity. Also, you should communicate broadly when setting a standard. Every person in an enterprise who may be interested in considering the standard or to whom the standard would be applied should have the opportunity, at least indirectly, to comment.
This opportunity can be provided by an e-mail setting forth the projected standard or, better yet, an e-mail identifying the fact that a standard would
444
The Back Office: Efficient Firm Operations
Implement
Ongoing
Create and refine standards
standards
management
Set and
Purchasing/
Analyze/
IT steering
document
finance update of
recommend and
Steady state
committee review
standards
procurement
approve new
management
and signoff
by area
process
purchases
Set technology
Introduce standard
Introduce standards
Locate all “points of
Quarterly (or more
standards (covered
setting process, and
to finance
entry” for
frequent) review and
previously in this
benefits with IT
department (Cap
procurement of new
update of standards
chapter)
steering committee
approval) and
technology in the
Should be part of the
purchasing
organization
Clearly document
Review IT standards
IT department
department
standards by area,
by area with SC
For all new
operating calendar
with
Change purchasing/
procurement
Refine standards
Reiterate overall
rationale
approval process to
(through IT
with feedback from
process of
include IT approval
department or other
Refine iteratively
business units
documentation,
for technology
department)
with feedback from
review and update
Get cover page
related Capex or
IT team
Assess procurement
signoff from IT
other purchases
requests
steering committee
Route technology
members
Update standards if
purchasing through
needed
Get final IT team
IT department where
signoff on new
possible
Document
standards
exceptions to
standards where
business case can
be made
Assess current
Update
technology
technology
platform
platform
Assess technology
Retire/reacquire
groups in existing
end-of-lifecycle
technology platform
assets
Analyze adherence
Develop plan for
to standards
migrating existing
platform to
Identify, document
homogeneous
and understand
environment
implications of
previous standard
Keep IT steering
exceptions
committee apprised
of plan and progress
Existing technology
lifecycle analysis
Exhibit 17.5
Process for Determining and Setting Standards by Area
Information Technology
445
be set and soliciting input. Then, send an e-mail identifying the particular standard with a discussion addressing the point raised in the first round of discussions. People like to be asked their opinions but oftentimes become jaded when it appears that their opinions were totally ignored. If the standard does not incorporate the opinion, a discussion attached to the standard should raise the issue and identify why it was not adopted.
Standards limit creativity and, as such, technical people often abhor standards. Perhaps even the same person who wrote the original standard, when faced with a different situation, might opt to ignore the standard. But the standard cannot be ignored. It must either be applied or modified.
For example, you are attempting to create an integrated document management system (DMS) throughout your enterprise. Assume you set a standard for your system, DMS-A. All of your offices except one purchased DMS-A, and you begin to integrate the solutions. One office, however, purchased DMS-B because they believed DMS-B was a better solution. It provided some additional functionality and fit better into their environment. This refusal to follow standards is sure to cause problems. First, even if DMS-A and DMS-B will integrate, that integration will be harder than simply integrating the same system worldwide. Second, your central project team, and any centralized support that may be required, must now learn two systems, DMS-A and DMS-B. Third, any future developments that you may consider must now also consider and test against each of the two DMSs. You have increased the complexity of your network, increased the cost of maintaining your systems, and increased the cost and complexity of future projects by failing to enforce the standard.
Operations
The road to good intentions is paved with hell.
—Donald E.Walker, Never Try to Teach a Pig to Sing
IT operations refers to the utility services provided by the IT department.
IT operations generally covers management of hardware, network, network security, enterprise security, communications, user administration, and e-mail systems.
Approaches for effectively managing the operations area by implementing standard operating procedures (SOPs) for the most common, repetitive tasks are provided. This section also covers techniques for improving quality through process improvement and root cause analysis for diagnosing system problems. Additionally, it covers methods for calculating appropriate staffing levels for the operations areas.
The operations unit most often receives only negative attention when service outages occur, and rarely receives positive recognition. The techniques
446
The Back Office: Efficient Firm Operations
discussed in this section can help raise the visibility, service level, and positive feedback in the organization.
Scope of Operations
Operations incorporates the following processes and areas as shown in Exhibit 17.6:
• Problem management (help desk)
• LAN/ WAN infrastructure and services management
• Systems and network security management
• Systems administration (patches, upgrades, tuning)
• E-mail administration
• User login and profile management.
Asset
Management
Problem
Management
Demand
Management
LAN/WAN
Management
Disaster
Recovery
Security
Change
Control
Systems
Administration
Telecom
Equipment
Support &
Administration
Administration
Operators
Exhibit 17.6
IT Operations
Information Technology
447
• Operators—daily systems operations (cost recovery, facilities, job scheduling, output management performance, production control, and
quality assurance)
• Telecom equipment support and administration
• Change control (change requests, analysis of impact of changes, and test plans)
• Disaster recovery (business continuity and contingency planning,
backup and restore procedures, and test plans)
• Demand management (service level management, service request man-
agement, and workload monitoring)
• Asset management (configuration management, contract and software
distribution management, and inventory)
• Systems and infrastructure uptime monitoring
• Systems and network capacity measurement and management
• Vendor management (infrastructure, hardware, and systems software) It all comes down to how well you do operations. You can implement the best systems, but if they don’t work consistently, they have little value. You can develop processes, and if they are not followed, they might as well not have been developed. If your operations are not smooth, if your downtime is not kept under control, and if you don’t do a good job supporting your users, your technology will be seen as a failure.
As with projects, operations’ needs a framework, a set of standard
processes. A good example can be found from Microsoft or the ITIL. Microsoft has developed its Microsoft Solutions Framework (MSF) to guide technology operation projects such as an Exchange deployment project or an infrastructure upgrade project. The Information Technology Infrastructure Library (ITIL) on the other hand is a set of books developed by the United Kingdom’s Office Of Government Commerce (OGC). The books