<<

. 75
( 92 .)



>>

Another issue for multioffice firms is the collaboration between geographi-
cally dispersed IT employees. Many times the relationship between IT profes-
sionals in two markets may be acrimonious because of communication issues.
Many firms have been successful at minimizing this behavior by organizing
field personnel into virtual teams. For example, the virtual team responsible
for IT process documentation may actually be composed of members from
many different cities. This allows geographically separated employees to work
together on IT projects and allows them to build a relationship while working
441
Information Technology

COMPANY SIZE (NUMBER OF EMPLOYEES)
RESOURCE 0“25 25“50 50“100 100“200 00“400

CIO/IT director ” 0.25 0.50 0.75 1.00

Network/systems engineer ” 0.50 0.75 1.00 1.50

Network/systems administrator 0.25 0.50 0.75 1.00 2.00

Help desk supervisor ” ” 0.50 1.00 1.00

Jr. network/systems administrator 0.50 1.00 1.50 2.00 3.00

Help desk/desktop support 1.00 2.00 3.00 4.00 5.00

Exhibit 17.4 Typical IT Operations Resources Required for
Small- and Mid-Sized IT Departments (single location)



on a common cause. To fully build these teams, however, it is important for
them to meet regularly. Consider having these teams meet at least once a
month by conference call. Team members should be assigned action items and
expected to move those action items to resolution and report on them regu-
larly. Key members of the team should meet at least annually, in person, to dis-
cuss the more critical issues, plan for future development of the team, and
build stronger interpersonal relationships. The relatively minor cost of these
in-person gatherings is well offset by the benefits gained in system stability
and overall technology expenditure.
One challenge with professional services companies is that sometimes
offices are small. Even a small office, however, may need on-site support
staff. This situation can cause the number of support staff compared to
billable professional to increase, which, in turn, increases costs. This situa-
tion, however, can be mitigated with proper planning. First, the firm could
simply decide that proper service to professional staff requires the extra
cost. Even if a firm decides that in the first instance, it™s likely that the
firm will put extreme cost of pressures in other areas of technology. There-
fore, technology leadership must find a way to get the most benefit out of
the local asset.
One way to accomplish this is to recognize that a local office IT person
will be doing things other than support. Certain support aspects must be
provided locally. It is not possible for a remote call center to change a hard
drive or a monitor. Rather, it takes hands on, feet on the street in the local
office. The local office IT person, however, may not spend 100 percent of his
or her time conducting the support. Rather, he or she may also spend some
time monitoring the servers, planning and executing upgrades, testing soft-
ware, and performing various other projects. Significant cost savings can be
442 The Back Office: Efficient Firm Operations

obtained by focusing on these ancillary tasks. Each IT person likely has
strengths and weaknesses. If you can organize the tasks such that a local IT
person is responsible for all of a region™s efforts in a particular area, or po-
tentially even the global firm™s effort in a particular area, then that person
can take his or her nonsupport time and spend it in that area. By using other
local IT support to fill in the other areas that are needed in that local office,
all aspects of technology can be covered. The benefit of proceeding this way
is that you are minimizing redundant tasks, such as each office creating its
own intranet system, or setting its own standards.
For example, if left to fill its own needs, each local office would likely cre-
ate a document repository. This system would have features unique to that
office and would likely have a unique platform. Electronic document sharing
between the offices would be more difficult because the disparate systems
would be difficult to integrate. Minimizing redundant tasks is likely the sin-
gle biggest way that a large organization with multiple offices, especially
smaller offices, can control costs and improve services.


Standards
The nicest thing about standards is that there are so many of them to choose from.
”Ken Olsen, founder of Digital Equipment Corp., 1977

Everything in life that™s easy is made easy because of standards. Standards
and difficulty are inversely proportional. Plugging in your notebook com-
puter is easy because we have a standard voltage and connector. Visit a dif-
ferent country and your life might be a bit more difficult. Your connector
might not fit in the receptacle on the wall, so you would need an adaptor.
Luckily, there is a standard adaptor to bridge between two conf licting stan-
dards. Even then, the power supplied may be a different voltage, requiring
you to use a transformer. If you did not have the adaptor or the transformer,
you would not be able to connect. Your life would have been made more dif-
ficult as a result of lack of standardization. You should pay close attention to
this simple concept throughout your technology enterprise.
That is not to say that everything should be standardized on a global basis.
Many standards simply do not lend themselves to global application, perhaps
because they address local or regional issues or because they themselves de-
pend on other standards that conf lict between geographic locations.
With standards comes a loss of control. For example, a program that deals
specifically with U.S. taxes may not need to be a global standard, but rather
a U.S.-based standard. Also, when rolling out a system globally, standards
between locations may differ based on particular building codes or power
configurations.
443
Information Technology

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 de-
signed 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 con-
venience than logical necessity. Support regions are often set up to provide
local time zone and local language technology support. There is not necessar-
ily a user difference or a system difference between the regions.
Some distinctions may exist, however, where regional business manage-
ment is attempting to meet different strategic objectives. Because technol-
ogy 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 spar-
ingly 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 ma-
ture 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 pre-
cision, distances are much more precisely defined. For example, a meter is
defined as “the international standard unit of length, approximately equiva-
lent 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 commu-
nicate 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 Steady state
document finance update of recommend and
committee review management
standards procurement approve new
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
445
Information Technology

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 stan-
dard 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 stan-
dards. 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 manage-
ment 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 re-
fusal 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 cen-
tralized 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, net-
work 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 ser-
vice 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 posi-
tive feedback in the organization.

<<

. 75
( 92 .)



>>