Download pdf - Cmdb Success Kit

8/7/2019 Cmdb Success Kit

http://slidepdf.com/reader/full/cmdb-success-kit 1/14

GoldMine Datasheet TitleSubtitle: Reinvent your Sales, Marketing and Support Proceses



Table o Contents

Chapter I:A Prescriptive Path for Implementing the Service Catalog and CMDB Together 2

Introduction 2

Roles and Interrelationships 2

The Service Catalog 2

The CMDB 3

Service Level Management 3

A Prescriptive Path or Implementation 4

Service Catalog: Begin with the Business 4

CMDB: Federated Approach 5

Service Level Management: Business-centric Metrics 5

Service Example: Tying it Together 5

Conclusion 6

Chapter II:Common CMDB Pitfalls and How to Avoid Them 7

Introduction 7

Emphasizing Physical Instead o Logical 7

Focus on Relevant Logical Data 7

Automate Logical Denitions 9

Lack o Business Focus 9

Start with the Service Catalog 9

Add Service Level Management 9

Overly Complex Dependency Mapping 10

Only Capture Critical Dependencies 10

Reactive Change Management 11

Proactively Veriy CI Baselines 11

Use Service Maps to Visualize Probable Business Impact 11

Conclusion 11

About FrontRange Solutions 12

Conguration Management Database (CMBD) 1

SUCCESS KIT



2 Conguration Management Database (CMBD)

SUCCESS KIT

Chapter I: A Prescriptive Path or Implementing the Service Catalog and CMDBTogether

Introduction

The expectation o your CEO is clear: IT must align with the business and deliver strategic value to the company But

what’s your best course o action? The release o IT Inrastructure Library version 3 (ITIL v3) promises to ease business and

technology integration with its increased ocus on service strategy Yet meeting business value expectations can be elusive

without a pragmatic, customer-ocused approach to IT, using a best practices process ramework such as ITIL

Once an organization embraces an IT service improvement mentality, they can get lost in the misguided pursuit o the per-

ect ITIL implementation Many ITIL-mature organizations have invested signicant time and money chasing “ITIL-topia”

but have ailed to implement a workable solution that delivers real-world business value

Your quest or achieving integration and increasing value requires a steadast ocus on the needs o the business When IT

aligns with the business during the service catalog strategy and design phases, they can reach consensus on the denition

o services and the associated level o service, quality, and cost Consensus prior to implementation will ensure that yourproject execution will deliver against business expectations

Volume VI o this executive brieng series is dedicated to helping you understand the roles and interdepencies o the

service catalog, the conguration management database (CMDB), and service level management (SLM) Through the use

o real-world service examples you will learn how these IT process areas become the three-legged stool that establishes IT

as a successul strategic business partner

Roles and Interrelationships

You may be asking yoursel, what makes the most sense to tackle rst: the service catalog and service level management

or the CMDB? A solid CMDB is the key to any successul ITIL initiative However, the service catalog is the key to initiating

IT-business alignment While both o these eorts are complex, they are tightly interrelated Thereore, you will need toapproach the service catalog and CMDB in a building-block ashion to keep momentum going

The Service Catalog

Service Catalog Management received an increased ocus in the ITIL v3 amily o processes and plays a critical role in de-

ning the business needs o IT–in business terms The service catalog is a published repository o all core IT service oer-

ings, which can include the business, technical, and proessional services oered to both internal and external customers

Services in the catalog are grouped logically by business customer, resulting in a clearly dened set o services oered to

the business Creating a service catalog can involve iterative negotiations to develop service names, dene service level

agreements, and identiy the organizations that subscribe to services Because services are designed and packaged rom a

business customer point o view, they are aligned with each business process to meet the specic needs o the business

Service descriptions are comprised o our major parts–Oer, Request, Activities, and Resources–each with many sub parts

and attributes:

• Offercontainsservicelevels,pricing,termsandconditionsamongotherattributes.

• Requestcontainsordering,conguration,governanceandagreementsub-componentsandattributes.

• ActivitiesincludeallmajorITprocessessuchasrequest,change,problem,availability,nancialandrelationshipman-

agement Vendor management and provisioning might also be included




SUCCESS KIT

• Resourcesincludeelementssuchasvendors,skillsandlabor,andofcourseallmajorITsystemsthatpertaintothe

business service

The service catalog becomes the shared vision o business and IT, transorming business goals into IT goals

The CMDB

The Conguration Management System and the CMDB are undamental components o the ITIL ramework The role o

the CMDB is to provide a centralized inormation repository o core congurable IT components and relationships to the

associated business service hierarchy

All inormation recorded in the CMDB exists to support the inormation technology service management (ITSM) processes

described by ITIL Because its content is guided by ITIL, building a CMDB typically starts with mapping core IT manage-

ment processes to the conguration items (CIs), the CI attributes, and its relationships to other CIs A CMDB will track a CI’s

conguration attributes (eg those parameters that help manage the CI within the IT service provider unction) Attributes

could be characterized as physical, logical, organizational, or nancial Since the CMDB is primarily a support tool that

enables other ITIL processes, logical attributes that dene the business purpose o the CI are required alongside the physi-

cal attributes to annotate the service Because the CMDB is typically built to control and manage the CIs that are subject

to the IT change control process, the CMDB provides an accurate baseline or planning and compliance management

This design approach will limit the type o CIs and attributes that are tracked to a manageable subset Consequently, the

inventory data repository is very dierent than the CMDB The inventory database tracks the current state o all discover-

able IT inrastructure items and conguration inormation, Alternatively, a well-designed CMDB represents the desired

state (or baseline) o the service map–the business-relevant representation o the IT inrastructure

Thereore, the structure and relationships in your CMDB must make sense rom the perspective o a service and should be

dened rom the point o view o a business consumer Establishing the service map using a bottom-up approach, starting

with individual conguration items, is typically an exercise in utility A top-down approach in which you dene services,

create your service catalog, then use the catalog to drive the structure o meaningul data and relationships in the service

map will result in a CMDB strategy that is manageable and achievable within a reasonable implementation timerame

Starting with the service catalog will narrow the scope o the CMDB driving your ocus on high impact services that aect

your most important business consumers Rather than trying to reconcile thousands o CIs and attributes, you can start

with the business service view and ocus on just those aspects that are relevant

Implementing a catalog rst will also reduce your project risk There are many examples o multi-year enterprise CMDB

projects that have evolved into an IT-centric technical project By the time the CMDB project is completed, the CMDB does

not align to the services the business cares about Furthermore, the personnel required to maintain the enormous quantity

o detailed data being tracked in the CMDB becomes an IT resource nightmare Starting with the service catalog ensures

that the CMDB project remains aligned with the business and sets the project up or success

Service Level Management

Service Level Management (SLM) ensures that ongoing requirements, communications, timerames and expectations

between business and IT are established and proactively managed SLM is also responsible or ensuring that internal IT

expectations are being met While the service catalog denes the services, service level agreements (SLAs) and operating

level agreements (OLAs) establish the service delivery benchmarks Proactive SLM manages and measures actual service

delivery quality against the established benchmarks Thereore, SLM provides the standards against which expectations,

improvements, and perormance metrics are measured SLAs, OLAs and underpinning contracts (UCs) ensure that docu-

mented agreements are in place to support the oerings within the service catalog




SUCCESS KIT

• Servicelevelagreements,andtheprocessesassociatedwiththem,provideamethodologyforintroducingandimple-

menting reasonable expectations between IT and the business consumer They establish a two-way accountability or

service, which is negotiated and mutually agreed upon The service catalog provides context or conversations with

your customers regarding SLAs

• Operationallevelagreementsestablishspecictechnical,informational,andtimeframerequirementsneededforeach

IT group to provide the services that will be delivered to the customer Logically, OLAs must be in place beore negoti-

ating SLAs with the business consumer representative

• Underpinningcontractsincludedocumenteddeliveryrequirementsandexpectationsforanythirdpartyvendorthat

is part o the extended IT service delivery team UCs complete the chain o accountability and control or seamless

service delivery IT’s ability to achieve established service levels will be only as good as the weakest link IT must hold

both internal and external delivery partners accountable or their part o the delivery cycle

In addition to the service catalog, SLM is tightly integrated with the CMDB When you dene service agreements, there are

two steps:

• Breaktheserviceintodiscretecomponents,anddeneacceptableperformancelevelsforeachcomponent.Thecom-

ponent inormation in the CMDB becomes the integration point with SLM

• Denetheoverallservicelevelforthefullservicebyaddingupthesumoftheparts.Eachcomponent’sestablished

perormance becomes a contributing actor to the overall service SLA

A Prescriptive Path for Implementation

Service Catalog: Begin with the Business

Nothing works better than collaborating with your business consumer representatives (“the customer”) to agree on the

initial core set o services that will be contained in the catalog Quite oten, the best approach is or IT to create the rst

drat o the catalog by documenting the services they believe they provide Once this step is complete, the catalog can

then be validated with the customers

This approach gives you a springboard or discussion and an opportunity to obtain buy-in rom your customer Attempting

to start collaboratively rom a blank slate tends to give the customer the (mistaken) impression that you do not know what

services you provide

Consider creating an external catalog view or your customers and an internal catalog view or IT The external catalog

is simply the “menu” that stipulates the services that are provided to the customers with an appropriate description The

internal catalog contains all the necessary components and relationships that are needed to deliver that service to the

customer

IT proessionals need to know the components that make up the services but should not rely on the service catalog to

document every detail; instead it should be accompanied by a CMDB There should be a record in the CMDB or each

service, and a relationship record that creates logical service groupings to represent the service hierarchy Relationship

attributes are also created to represent the association o a business service with the set o technical and application com-

ponents that are required to keep the business service running The CMDB is also a mechanism used to associate services to

the users o each service The combined set o logical and physical CIs and relationship between business services, business

support systems, and business users is reerred to as the service map




SUCCESS KIT

CMDB: Federated Approach

When the CMDB is designed as a logical representation o the service map, drill-through access to the detailed physical

conguration is a best practices design approach The IT resources in the CMDB are the logical (business purpose) represen-

tation o the physical (discoverable) asset inormation (eg physical inventory, such as servers, routers, switches, or storage

devices) and o relationships between CIs These logical elements can be automatically linked to the IT inrastructure items

(IIs), providing a business view o how IT inrastructure elements support higher-level business processes

The best way to support drill-through data access in your CMDB architecture is with a ederated approach Construct di-

erent views o the data or dierent purposes, while at the same time storing and updating the data in local data stores

A critical success actor or your project is to keep the CMDB data easily maintainable and manageable Federation is the

enabler o this strategy

Service Level Management: Business-centric Metrics

As the IT organization becomes more experienced in managing services, the perception o IT resources evolves rom an

enabling inrastructure to a strategic service asset Services and the resources or delivering them are optimized around

business objectives, and real-time economics drive decision making

Customers care about the end result and not about the components required to deliver the service For example, a cus-

tomer order entry system may be comprised o network access, Windows® systems, an Oracle® database and third-party

ulllment services A problem in any o those elements can aect the entire order entry system The customer is not

concerned with which element impacted their order entry system, but only that the system–as advertised–is not working

according to expectations

Thereore, truly useul SLM goes beyond component/network metrics and includes service and business metrics, such as

dening the time it takes to provision a new service (mean time to provision, or MTTP), repairing an existing one (mean

time to repair, or MTTR), or responding to a trouble-ticket call

Service Example: Tying it Together

The IT department has a service oering o web hosting at three dierent levels: bronze, silver, and gold The catalog

describes the service, what is included, the price, how the service is charged, and associated service level agreements Also

documented are the component services including support, provisioning, maintenance, backup, and availability Resources

“to-be provided” describes the hardware, sotware, and the conguration necessary to create the web hosting inrastruc-

ture based on the bronze, silver or gold service level The associated congurations or each level will be quite dierent

To provide a web hosting service designed to meet gold availability and perormance requirements, IT will likely need a

hot standby environment, which will require a redundant set production servers

Let’s see how the service catalog acilitates the service ordering process The marketing department needs a new website

or an upcoming promotion The marketing manager accesses the service catalog rom the sel service portal and viewsthe recommendation: Web hosting, silver level, includes Linux, one rack, 1 gigabyte per month, at $20000 per month

plus $10000 per gigabyte o storage The marketing manager agrees with the recommendation and enters into a hosting

agreement with IT

This agreement now allows requests or provisioning and conguration to be carried out such as ordering servers, de-

ploying licenses, and granting access to users, which are part o the bundled service oering “Web Hosting: Silver” The

ordering-speciying-provisioning process is also part o the service catalog system The service catalog integrates with the

inventory management system to conrm that the required systems and settings dened by the CMDB service map are




SUCCESS KIT

provisioned and discovered in the inventory management system The catalog also integrates with an SLM system that

manages the vendors that provide underpinning services

When the service ulllment process is automated, the web hosting system provisioning steps are supported using a ulll-

ment workfow system and a change management system, where appropriate The associated inrastructure items are

being added, discovered, and reconciled to the CMDB service map The CMDB now has a new IT system that it will track,

and will report the main elements back to the catalog system With integrated asset management tools, IT can also track

the actual consumption o storage and report back as a subscription service being used by the specic business unit

Once the web hosting service is operational, the service catalog plays a dierent role: managing against established service

levels Initially the service catalog is linked to the CMDB to document “resources to be provided” Now it links to the CMDB

to identiy “resources impacting service” Service impact may be indicated by an infux o user incidents associated to a

server that is down Or, it might be indicated by an SLA alert, proactively notiying IT that a server is precariously close to

breaching a perormance SLA

Meanwhile, the marketing executive can access the service catalog portal, which provides complete transparency to the

various services acquired, the cost drivers, the service level agreements, the history o requests, and the consumption thatservice has undergone When service levels are impacted, proactive broadcast notications can be sent to aected busi-

ness users The CMDB integrated with the service catalog enables this type o proactive mass communication and service

transparency

Conclusion

The service catalog, CMDB and service level management comprise the three-legged stool that establishes IT as a strategic

business partner Yet a prescriptive path or implementation is vital to your success Begin by establishing a documented

service catalog, developed in coordination with the business This serves as a catalyst or business-IT alignment and

empowers business and IT managers to make decisions on IT activities based on risk, priority, and value, rather than cost

alone

Next, implement your CMDB, ensuring the structure and relationships make sense rom the perspective o a service Imple-

menting the service catalog as part o an IT sel service portal, integrated with the CMDB establishes IT as a business service

provider When service descriptions include CMDB content and context, the service catalog becomes the shared vision o

business and IT, transorming business goals into IT goals

Finally, use service level management to ensure that ongoing requirements, communications, timerames, and expecta-

tions between business and IT are established and proactively managed While the service catalog denes the services, ser-

vice level agreements, operating level agreements, and under pinning contracts establish the service delivery benchmarks

Remember, truly useul SLM goes beyond component/network metrics and includes service and business metrics that are

meaningul to the business

With this pragmatic, customer-ocused approach to implementing the service catalog, CMDB, and service level manage-

ment, IT is sure to meet the expectation o the CEO: delivering strategic value to the company




SUCCESS KIT

Chapter II: Common CMDB Pitalls and How to Avoid Them

Introduction

The expectation o your CEO is clear: IT must align with the business and deliver strategic value to the company This

requires proactively managing IT inrastructure as a business, thus embracing IT service management (ITSM) A crucial com-

ponent o your service management strategy is implementing a conguration management database (CMDB)

Although the implementation o a complete CMDB system can be a multi-year project, by ocusing on the business re-

quirements that are most important, a pragmatic CMDB implementation should show results within 90 days So why have

countless CMDB projects ailed to deliver business value or a reasonable return on investment?

Volume VII o this executive brieng series answers this question by discussing the most common CMDB implementation

pitalls and how to avoid them Included is practical advice rom industry experts regarding the amount and type o data

that should reside in your CMDB You will also gain insights into the FrontRange CMDB and discover why it can deliver

rapid time to value

Emphasizing Physical Instead of Logical

The misconception that the CMDB should represent as close to 100 percent o the actual physical IT inrastructure as pos-

sible was a common pitall o many early projects Years were invested in designing the superset data model that could

track every individual IT component on the network, every possible relationship between inventory items, every discover-

able attribute, and every status change

This approach typically results in a multi-year CMDB endeavor, reminiscent o enterprise data warehousing projects o the

1990’s Multiple auto discovery tools are required to discover the complete IT inrastructure and application topology

Complicated reconciliation rules must be coded to resolve duplicate data collected by multiple discovery tools Manual

reconciliation processes must be established or records that all through the cracks rom nightly reconciliation processing

Manual entry has to be perormed to set up the complete logical conguration hierarchy Many CMDB projects attemptingthis level o completeness and accuracy can require two or more ull-time IT personnel to establish and manage ongoing

data maintenance tasks In addition, without strong IT change control processes, it is only a matter o time beore un-

planned changes result in a baseline CMDB that is out o synch with the current state IT inrastructure Many CMDBs that

were designed around strong ITIL principles and initially populated using robust discovery tools ailed because IT could not

justiy the resources required to keep up with ongoing data management

Focus on Relevant Logical Data

These early CMDB projects could have delivered comparable business value–but at a dramatically lower total cost o

ownership–i IT had conducted more up ront planning with their business constituents Instead o an “all-or-nothing”

strategy, orienting the CMDB around business services allows IT to design an inrastructure model scaled to support only

the inrastructure inormation needed to maintain control and stabilize critical business services–the true benet o a

CMDB This logical inrastructure, with physical relationships where appropriate, results in a much more manageable set

o data than the ull physical view o every aspect o the hardware, sotware, and network topology This discussion o

logical versus physical views highlights the dierence between inventory management and conguration management

Don’t conuse inventory management with confguration management

Simply stated, the goal o the CMDB is to provide an accurate, up-to-date representation o the business support systems

that keep your business running and employees working, and is easily accessible rom the service desk




SUCCESS KIT

Inventory management is concerned with having the most comprehensive and up-to-date view o the entire IT inrastruc-

ture Conguration management is ocused on creating a specic ltered view o service assets, representing only those

assets that are critical to delivering IT services that ultimately support the company’s core business services Conguration

management assists us in understanding the business unction o the asset rather than what the asset is

For example, a conguration manager needs to know that a computer server is used as a database or a set o critical busi-

ness unctions Yet many o the data elements related to the computer server that are identied by a discovery tool are

not relevant to the conguration management unction Scaling back the CMDB to track only relevant data about critical

business service resources is a critical success actor or your CMDB project

With this in mind, determining the granularity o your physical CI hierarchy is dependent on the level o detail that can be

tracked rom your Service Management records (eg incidents, problems, changes, releases, etc) To illustrate, consider this

sample business service In this example, you support the nance department, which delivers the Financial Management

Service Financial Management is provided by the SAP System The SAP System includes the SAP Accounts Receivable,

Accounts Payable, Business Intelligence, and Project Management sub systems The SAP Accounts Receivable sub system is

supported by the ollowing physical IT systems:

• SAPwebserver

• SAPapplicationserver

• SAPdatabaseserver

• SAPbackupdatabaseserver

• Knowledgebasesubsystem

• SAPapplicationsoftware

• Oracle11idatabasesoftware

• Networkdevice-LAN

The SAP Accounts Receivable sub system is supported by the ollowing logical IT systems:

• SAPSupportAgreement

• SunServerHardwareLeaseAgreement

This business service, related sub systems, associated physical IT systems, logical CIs, and relationships between each node

in the hierarchy can be modeled in the CMDB to create a service map

I you are only able to associate an incident to the SAP sub system, and track Requests or Change to the SAP networkdevice, it doesn’t make sense to maintain CI records or each network circuit, router, and switch that are “lower” in the

service hierarchy

When you deploy integrated FrontRange discovery tools in conjunction with ITSM Inventory Management and Congura-

tion Management modules, you can maintain both physical and logical views Each view becomes a separate and distinct

tool to support dierent ITSM processes Identiying the physical conguration inormation o a server with perormance

issues is important when conducting root cause analysis On the other hand, logical business service impact inormation is

vital when prioritizing break/x incident resolution




SUCCESS KIT

Automate Logical Defnitions

With the FrontRange Foundation database extensibility eatures, you can choose between creating a CMDB that models a

detailed physical representation o the network and its connections or a logical application-dependent view Based upon

set criteria you dene, FrontRange business rules and workfow automate the process o identiying which assets are criti-

cal, and which are not, to create a logical view o the asset, highlighting the applications that dene the role o the asset

IT will make better business decisions when it is easy to identiy the purpose o core business system assets Based on IT

best practices, the CMDB becomes the IT reerence tool to quickly research and pinpoint business services and business

users that are impacted by an unplanned system ailure or a planned system outage With FrontRange Conguration

Management, each core business and IT service can be dened as a logical CI Relationships can be created rom the logi-

cal service to the set o IT services I you plan to manage your IT prioritization by business service impact, you may want

to put the extra eort into modeling the ull logical hierarchy o the business service With FrontRange Visualization, you

can use the visual map to view the logical business service hierarchy and perorm business impact analysis

Lack of Business Focus

The most common pitall o current CMDB projects is the lack o business ocus Your project will become overly complex

and unnecessarily complicated unless you ocus on the business processes that are most important to your customers

An enterprise CMDB project can easily devolve into a very IT-centric technical project By the time it’s complete, the CMDB

may not align to the services your customers care about That’s why we recommend dening a baseline service catalog

beore implementing your CMDB to ensure the project remains aligned with the business

Start with the Service Catalog

Creating a service catalog involves dening the set o primary services IT oers and supports, developing agreed upon and

common names, dening service level agreements, and then connecting them to the inrastructure and organization

First, identiy your key business stakeholders by department, business unction, or business service and rank their relative

importance, oten driven by their nancial value/impact to the business You may support departments such as sales, mar-

keting, human resources, nance, procurement, and customer support Or you may model your support around business

services like online banking, loan unding, and insurance claims

Next, identiy the core business processes by stakeholder and create a service denition based on the enabling set o tech-

nical or proessional IT capabilities For example, i human resources is one o your key business stakeholders, corporate

communication may be one o its core business processes Clearly, an IT service required to support corporate communica-

tion is email The IT systems that map to the Email IT Service include Microsot Exchange, IBM Lotus Notes, and Blackberry

BepragmaticwhenmodelingservicesandsystemsintheCMDB.KeepyourCMDBtoamanageablesizebylimitingthe

CIs and CI attributes to just those aspects that are relevant to your business processes Additionally, it is not necessary to

include the entire set o business services, IT support services, and IT systems in the CMDB Leave IT systems to the CMDB

and business and IT support services to the service catalog and service level management

Add Service Level Management

Service Level Management (SLM) ensures that ongoing requirements, communications, and expectations between business

and IT are proactively managed The service catalog sets the standards against which expectations, improvements, and

perormance metrics are measured Service level agreements (SLAs), operating level agreements (OLAs) and underpinning




SUCCESS KIT

contracts (UCs) ensure that agreements are in place to support the oerings within the service catalog

Ideally, SLAs can be created in two steps: rst, breaking the business service into discrete sub services and supporting

components, and second, dening acceptable perormance levels or each component The component inormation in the

CMDB becomes the linkage point with the SLA Separate SLAs can be dened or each aspect o the overall service For

example, a service request in the service catalog will have an acceptable resolution threshold The related CI components

may also have their own system availability and response thresholds Incidents associated with a problematic system will

have an incident response time and resolution time SLA

FrontRange Service Level Management allows easy association between each SLA and its corresponding IT support system

CI in the CMDB The FrontRange management dashboard provides a valuable tool or managing each aspect o the overall

business service SLA based on individual component SLAs

Overly Complex Dependency Mapping

Many CMDB projects ail because the many-to-many relationships between CIs result in a service model that is extremely

complex, impossible to view, and impractical to use or managing the business

One o the most dicult things to model in the CMDB is the relationship between two CIs, which is called dependency

mapping For example, an end-to-end supply chain process is comprised o manuacturing control system A, warehousing

system B, order ulllment system C, and general ledger system D tied together through le transers, bulk database loads,

distributed object calls, and message-oriented middleware Because discovery tools cannot comprehensively analyze the

dierent dependency types, manual intervention is required to generate a map depicting the fow dependencies rom A

to B to C to D

Only Capture Critical Dependencies

To avoid complexity and achieve usability, we recommend that during the rst phase o the CMDB project you only cap-

ture the most critical dependency between two IT assets such as:

• Comprisedof

• Dependson

• Runson

• Supports

By modeling a single, critical relationship between CIs, your service model becomes much easier to view and can be eec-

tively used to make important business decisions Multiple relationships between two CIs are common in the real world

However, modeling each relationship in the CMDB will likely compromise the business value o the visual service map Ad-

ditionally, unless your IT inrastructure is relatively static, maintaining an accurate view o the ever-changing relationshipsbetween CIs will quickly become an overwhelming task Even with sophisticated automated dependency mapping tools,

most organizations are challenged to maintain true, accurate relationships in the CMDB There is simply too much logic

that must be dened and maintained to keep the dependency-mapping tool in synch with the evolving purpose o today’s

business systems, especially with the advent o virtual data centers




SUCCESS KIT

Reactive Change Management

The inability to quickly identiy changes to an individual CI or a group o CIs that comprise a service has been the down-

all o numerous CMDB implementations Change management should not be an aterthought, and must be managed

proactively The design o the Change and Conguration Management processes should be considered in concert with the

planned use o the ITSM toolset

Proactively Veriy CI Baselines

FrontRange Foundation enables you to set a baseline or CIs so you can instantly veriy the consistency o all CIs in a ser-

vice I a change occurs, a fag is raised and a more detailed investigation automatically determines which components are

out o compliance with the baseline

Two actions can be taken I the change is in response to an approved Request or Change, then the change can be ac-

cepted, which creates a new baseline However, i the change is unauthorized, a new incident can immediately be created,

ensuring IT can get the underlying asset back into compliance Without integrated change management, the CMDB will

quickly become an outdated representation o the inrastructure baseline

Use Service Maps to Visualize Probable Business Impact

Service maps can be used to improve service availability through proactive analysis o change and more rapid response to

service interruption

A service map, at its most elementary level, is a visual model o a set o interrelated CIs in the CMDB, or example, a com-

puter network A more robust service model will include the business services supported by that network The service

model allows you to visualize the impact o change to components o a service With a service map you can proactively:

• Applya“what-ifscenario”tounderstandtheimpactofanoutagetoservices,users,andotherCIs

• AutomaticallydetectCIchangesandupdatesincludingexpectedvs.actualandversioning

• ViewandidentifyunauthorizedchangestocriticalCIcomponentsofservices

When an interruption to a critical business service occurs, IT must quickly identiy the priority o an incident to ensure

resources are eciently mobilized to address the highest impact issues rst By viewing a map o the service, IT can more

easily identiy the root cause, analyze the relationship between CIs and business service, and rapidly assess the impact and

the urgency o the outage and the potential change that may have caused it to occur

Conclusion

Implementing a CMDB doesn’t need to be a death march nor a science project with limited business benet With the right

tools, and a pragmatic, customer-ocused approach you can accelerate the project and avoid common pitalls to ensure

your CMDB is actionable and delivers business value When you scale down your CMDB project to ocus on core business

services and primary support systems, you will deliver a more immediate return on investment at a lower total cost o

ownership




SUCCESS KIT

About FrontRange Solutions

FrontRange Solutions develops sotware and services that growing mid-size rms and distributed enterprises rely on

every day to build great customer relationships and deliver high-quality customer service The company applies a unique

combination o innovation and automation with a standards-based approach to simpliy core business processes, includ-ing: IT service management; customer relationship and sales orce management; and PC liecycle management More than

150,000 o the world’s best-known brands use FrontRange oerings to quickly improve their interactions with external and

internal clients and achieve better business results For more inormation, call 8007767889 or visit wwwrontrangecom

All Rights Reserved

GoldMine, HEAT, Enteo, Centennial Discovery, DeviceWall and other FrontRange Solutions products, brands and trademarks areproperty o FrontRange Solutions USA Inc and/or its aliates in the United States and/or other countries Other products, brandsand trademarks are property o their respective owners/companies

USE OF THE SOFTWARE DESCRIBED IN THIS PAPER AND ITS RELATED USER DOCUMENTATION IS SUBJECT TO THE TERMS AND CON-DITIONS OF THE APPLICABLE END-USER LICENSE AGREEMENT (EULA)

The inormation contained in this document is provided “as is” without warranty o any kind To the maximum extent permitted byapplicable law, FrontRange disclaims all warranties, either express or implied, including warranties or quality, accuracy, merchantability, tness or a particular purpose, title and non-inringement; and in no event shall FrontRange or its suppliers be liable or anydamages whatsoever including direct, indirect, incidental, consequential, loss o prots or data or special damages, even i advisedo the possibility o such damages

