Book Excerpt: Building best practices for IT
- By Bruce Allen, Dale Kutnick
The following article is excerpted from Building Operational
Excellence: IT People and Process Best Practices by Bruce Allen and Dale
Kutnick. Used with the permission of the authors, Addison-Wesley and Intel
All successful businesses must have a product model -- a lesson that dot-com
companies discovered during the 'Internet bubble.' No product model means no
survival. Today's IT departments face a similar challenge. IT organizations need
to identify who their customers are and what products and services those
customers value. Failure to understand and provide value mean that the customers
will look elsewhere for services.
Viewing IT organizations as providers of products means viewing their
business model differently. Many IT organizations are run as a pure cost center
or raw efficiency shop. An organization recognized only for reducing costs will
face a perpetual struggle to gain additional resources. Although reducing costs
is important, COE efforts are designed to show efficiency.
A series of steps can develop a plan of attack to create a product/pricing
model.The first step is to identify and create a product model around the
consumption constituency. What do the consumers (or customers) care about? What
products and services, when bundled, make sense to them? The second is
structuring service levels. Identify the services users understand and are
willing to pay for, capture what the users feel are appropriate levels of
service for the price, and report those levels back in the form of service-level
agreements and performance reports. The way that IT organizations report
performance and the metrics selected to prove performance are particularly
important. Executing a product cost analysis to determine whether complex cost
recovery charge-back methodology or pure allocation is an appropriate funding
model is a good starting point. The idea is to communicate pricing efficiently
with the end-user consumption constituency.
This approach is not an appropriate strategy for
all IT organizations. The predominant driver as to whether an IT group goes
after building a complex, robust IT product model is its funding strategy. If an
IT organization is funded merely as a corporate subsidy itself, it does not have
to track or report IT resource allocation or perform true cost recovery. Such an
IT group does not have a strong incentive to build this model to end up being a
real service provider with a real product model. That IT group also has a much
harder time proving value to the organization versus the IT group trying to
package what it does and performing true cost recovery from the business side,
mapped to consumption of real IT products and services.
Increasingly, due to financial reasons, hardware and software resource
ownership is found in business units or LOB IT groups, while the support for
such resources may rest with a central IT group. In such cases, a particular
resource, such as a server or printer, may have to be quoted at a particular
support cost to be paid by the business user. These arrangements break the
typical bundled IT offerings found in initial product models.
Therefore, central shared services groups are exposing high degrees of
granularity in their internal costs. One mistake that often is made in pricing
these offerings is tying the price points to a specific infrastructure
combination -- for example, Oracle 9 on Windows 2000/.NET on a Hewlett-Packard
server. Research shows that such pricing influences undesirable buying behavior
as 'buyers' try to second-guess the pricing and go with the 'cheapest' model
rather than the most appropriate 'fit.' In this example, because Oracle support
is less expensive on Windows 2000 versus UNIX, the user may select Windows
2000/.NET rather than choose the operating system best suited to the
application. To avoid this issue, IT organizations should indicate pricing
models that take into consideration the enterprise architecture requirements to
realize long-term benefits.
Also, to further mitigate this buying behavior, IT organizations building
these offerings into their product catalogs must focus on two dimensions -- an
abstraction complexity and particular service level -- and build these into a
product pricing matrix. The complexity and service-level intersection point must
reflect total internal support costs. For most items, a minimum of three and a
maximum of seven complexity levels should be defined, while three service levels
should be used. Complexity level is determined primarily by the degree of
standardization, scale, locality, and heterogeneity. When a buyer selects a
managed offering, the selection then would fit into the pricing matrix
appropriately. Accommodations must be made for buyer demands that may fall
outside the matrix, and a pricing assessment and oversight function would be
Research shows a positive response from users to this type of price model,
but it also can cause additional and unforeseen demands that must be handled.
For example, organizations that have begun charging back managed network
services directly based on network bandwidth consumption then are approached by
their business users to help optimize their network usage and ''get the cost
down.'' IT organizations moving to a managed product model must anticipate and be
ready to respond to such requests to ensure overall client satisfaction.
Some IT organizations will get requests from users to unbundle a product to
select specific elements from an overall package. An uplift charge (10 to 30
percent) built into the pricing model for unbundling, covers the cost of
customizing and supporting a nonhomogeneous product model.
Another hindrance to the pricing model is when it includes any offerings
based on pure measurement (such as resource consumption and user accounting).
Often, these types of measurement capture for charge-back or cost recovery must
be custom built and can be expensive to initiate and maintain. IT groups must
understand the inherent overhead costs in administering any cost-recovery model.
Higher aggregation of service elements under a product -- and avoidance of a
restrictive a la carte model -- leads to costly tracking and billing
administrative overhead. For shared services IT groups, the problem of accurate
service pricing will get more difficult as server size grows and multiple user
cost centers have to share a single infrastructure element or application cost.
The managed service offering, typically focused on execution of an IT process
and predominantly consisting of labor costs, can be charged on a fixed basis or
a time-and-materials (T&M) model, or on a piecework structure that takes
into account the amount per change handled and the percentage per procurement
Organizations undertaking their first-generation efforts around productizing
should think about those critical products most exposed to their customer base,
such as desktop support. Begin with a service description that describes the
scope. Questions to ask are these: What is included? What is not included? What
kind of computing environment is it? What service levels are expected? What kind
of contract terms do we have?
IT products and their metrics are exposed or delivered as the value currency.
Failure to collect those metrics (which show the value back to the business)
invalidates the purpose of product catalog creation.
Distributed applications are challenging the
traditional way to do cost recovery. In the mainframe space, resource
utilization charge-back was typically based on MIPS, storage, or output
consumption. Those models do not always fit in many types of modern
applications. A tremendous lack of standard user-level accounting data exists
across all technologies. The absence of this data is a barrier to some newer
Pricing is influenced or driven by the costs that support the particular
services provided. For example, if the user population is centralized, the cost
figures or implications will be lower. A more dispersed or remote environment
tends to raise the cost levels. Similarly, flexible service-level requirements
tend to lower costs. The more stringent service levels become and the more
specific products and services provided around service levels become, the more
influential they are as cost drivers. To an extent, improving productivity can
enhance service levels; beyond that, improved service levels are linked to
increased investment because they lead to increased costs.
Other cost drivers include the extent of applications
and infrastructure standardization. Increased standardization leverages existing
skill sets, driving costs down. A heterogeneous environment with a wide array of
technologies to be supported increases support costs. This notion of ''adaptive
infrastructure'' as a means of reducing complexity is outlined in the book
The Adaptive Enterprise: IT Infrastructure Strategies to Manage Change and
[also from the ''IT Best Practices Series'' from Addison-Wesley and Intel
Enterprise management can reduce investment decision risks because a formal
method of strategic planning/architecting can be institutionalized and refined
to enable considerable time-savings. The higher the levels of integration and
discipline achieved via enterprise management, the more cost levels can be
As IT becomes more closely related to the business,
organizations are migrating to newer accounting charge-back models in an attempt
to tie the actual IT value back to the business in more real and direct terms.
Performing the actual cost mechanism begins with identifying the cost pools.
After you have identified and added the various costs associated to the
different cost pools, you influence or modify them by the different decision
The four commandments of product/pricing
* The cost/pricing mechanism must be understandable to all
* Cost/price must be predictable (on the buy side)
for business-planning purposes.
* Cost/price must be clearly related to IT
value received (actual or perceived).
* IT organization-supplied services
must be priced competitively with competing open-market services.
IT organizations should determine the unit price for desktop, project, and
application subscription services, and compare the internal cost with
outsourcing prices. This process should be undertaken in a formal benchmark,
whereby service levels are tightly coupled to competitive market prices and cost
overheads in managing outsourced arrangements are considered. If the internal
cost is too high and cannot be driven down to match outsourcing prices, the
assessed service should be outsourced. Otherwise, IT operations groups should
confidently position this service to business units as matching commercial
standards. This will raise business units' understanding of IT services and
increase their trust in the in-house service quality and cost-efficiency.
The roadmap to establishing a charge-back strategy is as follows:
Calculate the service costs.
3. Make outsourcing
To determine the service cost, each budget element should be analyzed and
apportioned to deduce the total cost of every application server and all related
infrastructure needed to support it (such as storage and network usage). Servers
should include mainframe, UNIX, Windows 2000/.NET server, and LAN. The desktop
service cost should include PCs, palmtops, laptops, and LAN servers. The
application subscription service cost should include the data center, technical
support, and WAN.
Some budget elements are easy to allocate to servers,
and others are difficult. In this light, assumptions should be made to
distribute cost -- for example, taking a direct pass-through charge-back
approach that distributes cost to individual departments or business units that
are using the application on the server. Additional desires must be considered,
such as building in costs for infrastructure or using pricing strategies to
influence buying behavior. Subsequently, IT operations groups should aggregate
the various servers' cost to deduce service cost. The allocation mechanism, or
cost per user/employee/department, must then be set. After this is implemented,
the tracking, billing detail, and reporting should happen. A yearly
period-variance adjustment must occur to handle over/undercharges.
To find out more about 'Building Operational Excellence: IT People and Process Best Practices' please go to the Addison-Wesley Professional Web site.