Service Asset and Configuration Management Tutorial


3.1 Learning Unit 3

This learning unit expands on how the process of service asset and configuration management (SACM) contributes to RCV practices. The lifecycle phase emphasized in this unit is service transition. It provides a complete overview of the purpose, objectives, scope and importance of SACM as a process to generate business value. SACM policies, principles, concepts, activities, methods and techniques are explained in relation to RCV practices. Also the importance and use of configuration items (CIs) is explained, along with tools, activity models, CMS back-ups and historical data. And eEfficient uses of SACM metrics are reviewed in this unit, as well as how service operation interacts with SACM. Let’s look at the purpose of SACM process in the next slide.

3.2 Purpose of Service Asset and Configuration Management(SACM)

The purpose of SACM is to Identify, control, record, report, audit and verify service assets and configuration items, including versions, baselines, constituent components, their attributes, and relationships IT accounts for, manage and protect the integrity of service assets and configuration items (and, where appropriate, those of its customers) through the service lifecycle by ensuring that only authorized components are used and only authorized changes are made. It protects the integrity of service assets and configuration items (and, where appropriate, those of its customers) through the service lifecycle Other purposes will include ensuring the integrity of the assets and configurations required to control the services and IT infrastructure by establishing and maintaining an accurate and complete Configuration Management System. Now, let’s look at the key terms of this process.

3.3 SACM - Key Terms

As we have understood it is always a good practice to understand the keywords predominantly largely being used in this process. First The first keyterm is Attribute. Attribute is a piece of information about a configuration item. Some of the Examples are name, location, version number and cost. Attributes of CIs are recorded in a configuration management database (CMDB) and maintained as part of a configuration management system (CMS). Next would be Audit. Audit is a formal inspection and verification to check whether a standard or set of guidelines is being followed, that records are accurate, or that efficiency and effectiveness targets are being met. An audit may be carried out by internal or external groups. Now let us look at the objective of SACM process in the next slide.

3.4 Objectives of Service Assets & Configuration Management

The objective of SACM process is to define and control the components of services and infrastructure and maintain accurate configuration information on the historical, planned and current state of the services and infrastructure. As we have an understanding of the objective, let us look at the scope of this process.

3.5 Scope of SACM Process

Scope Asset Management covers service assets across the whole service lifecycle. It provides a complete inventory of assets and who is responsible for their control. It includes: • Full lifecycle management of IT and service assets, from the point of acquisition through to disposal • Maintenance of the asset inventory. Configuration Management ensures that selected components of a complete service, system or product (the configuration) are identified, baselined and maintained and that changes to them are controlled. It also ensures that releases into controlled environments and operational use are done on the basis of formal approvals. It provides a configuration model of the services, assets and infrastructure by recording the relationships between service assets and configuration items. SACM may cover non-IT assets, work products used to develop the services and configuration items required to support the service that are not formally classified as assets. Thus thee scope covers interfaces to internal and external service providers where there are assets and configuration items that need to be controlled, e.g. shared assets. In the next slide we will look at SACM process as value to business.

3.6 Business value of SACM

Value to business Optimizing the performance of service assets and configurations improves the overall service performance and optimizes the costs and risks caused by poorly managed assets, e.g. service outages, fines, correct licence fees and failed audits. SACM provides visibility of accurate representations of a service, release, or environment that enables: • Better forecasting and planning of changes • Changes and releases to be assessed, planned and delivered successfully • Incidents and problems to be resolved within the service level targets • Service levels and warranties to be delivered • Better adherence to standards, legal and regulatory obligations (less non-conformances) • More business opportunities as able to demonstrate control of assets and services • Changes to be traceable from requirements • The ability to identify the costs for a service.

3.7 Service Assets and Configuration Management Principles (1 of 2)

Let us now look at the key principles and policies of SACM. The main policy sets out the framework and key principles against which assets and configurations are developed and maintained. Typical principles include: • Ensuring that Asset and Configuration Management operations costs and resources are commensurate with the potential risks to the services • The need to deliver corporate governance requirements, e.g. software asset management, Sarbanes-Oxley etc. • The need to deliver the capability, resources and service warranties as defined by the service level agreements and contracts • The requirement for available, reliable and cost effective services • The requirement for clear economic and performance criteria for interventions that reduce costs or optimize service delivery, e.g. lower maintenance costs • The application of whole-life cost appraisal methods Let’s continue to discuss on these principles in the next slide.

3.8 Service Assets and Configuration Management Principles (2 of 2)

• The transformation from ‘find and fix’ reactive maintenance to ‘predict and prevent’ proactive management • The requirement to maintain adequate asset and configuration information for internal and external stakeholders • The level of control and requirements for traceability and auditability • The application of continual improvement methods to optimize the service levels, assets and configurations • Provision of accurate asset and configuration information for other business and Service Management processes • Integration of Asset and Configuration Management with other processes • Migration to a common asset and CMS architecture • And Level of automation to reduce errors and costs. Moving on let us look into the concepts of SACM.

3.9 Basic Concepts in SACM

Now lets discuss some of the basic concepts of the process. 1. Service Asset refers to: Any resource or capability that could contribute to the delivery of a service. Examples of service assets include a virtual or a physical server, a software licence, a piece of information stored in a service management system, or some knowledge in the head of a senior manager. 2. Configuration Item (CI) refers to: A configuration item (CI) is a service asset that needs to be managed in order to deliver an IT service. Examples of CIs include Service lifecycle CIs, Service CIs, Organization CIs, Interanl and excternal CIs or Interface CIs. In continuation to these concepts, let us look at the remaining in the next slide.

3.10 Basic Concepts in SACM

3. Configuration Record refers to: A sSet of attributes and relationships about a CI. Configuration records are stored in a configuration management database (CMDB) and managed with a configuration management system (CMS). It is important to note that CIs are not stored in a CMDB; configuration records describe CIs that are stored in the CMDB. Service Knowledge Management System (SKMS) refers to: A s Set of tools and databases that are used to manage knowledge, information and data. Many configuration items are available in the form of knowledge or information, and these are typically stored in the SKMS – for example, a service level agreement(SLA), a report template or a definitive media library. The SACM process is not responsible for managing the SKMS. Some items in the SKMS will be owned and managed by the SACM process, but others will be owned and managed by other processes or people. Let us now move on to discuss about configuration management starting with a configuration model in the next slide.

3.11 A Logical Configuration Model

Configuration Management delivers a model of the services, assets and the infrastructure by recording the relationships between configuration items as shown in the picture. This enables other processes to access valuable information, e.g.: • To assess the impact and cause of incidents and problems • To assess the impact of proposed changes • To plan and design new or changed services • To plan technology refresh and software upgrades • To plan release and deployment packages and migrate service assets to different locations and service centres • To optimize asset utilization and costs, e.g. consolidate data centres, reduce variations and re-use assets. The real power of Configuration Management’s logical model of the services and infrastructure is that it is THE model – a single common representation used by all parts of IT Service Management, and beyond, such as HR, finance, supplier and customers. In the next slide let us look configuration management system.

3.12 Configuration Management System (CMS)

Configuration Management System To manage large and complex IT services and infrastructures, Service Asset and Configuration Management requires the use of a supporting system known as the Configuration Management System (CMS). The CMS holds all the information for CIs within the designated scope. Some of these items will have related specifications or files that contain the contents of the item, e.g. software, document or photograph. For example, a Service CI will include the details such as supplier, cost, purchase date and renewal date for licences and maintenance contracts and the related documentation such as SLAs and underpinning supporting contracts. The CMS is also used a for wide range of purposes, for example asset data held in the CMS may be made available to external financial Asset Management systems to perform specific Asset Management processes reporting outside of Configuration Management. The CMS maintains the relationships between all service components and any related incidents, problems, known errors, change and release documentation and may also contain corporate data about employees, suppliers, locations and business units, customers and users. In the next slide let us look at the use of data and information in CMS.

3.13 The Architectural layers of the CMS.

The figure on the slide shows how the CMS covers the data and information layers of the knowledge/information/ knowledge hierarchy . At the data level, the CMS may take data from several physical CMDBs, which together constitute a federated CMDB. Other data sources will also plug into the CMS such as the definitive media libraries. The CMS will provide access to data in asset inventories wherever possible rather than duplicating data. Configuration information evolves as the service is developed through the service lifecycle. Often there are separate mechanisms for managing different service lifecycle stages as well as different means of managing different applications and platforms. The CMS typically contains configuration data and information that combined into an integrated set of views for different stakeholders through the service lifecycle as illustrated in the figure. It therefore needs to be based on appropriate web, reporting and database technologies that provide flexible and powerful visualization and mapping tools, interrogation and reporting facilities. Many organizations are already using some elements of SACM, often maintaining records in documents, spreadsheets or local databases, and some of these may be used in the overall CMS. Automated processes to load and update the Configuration Management database should be developed where possible so as to reduce errors and optimize costs. Discovery tools, inventory and audit tools, enterprise systems and network management tools can be interfaced to the CMS. These tools can be used initially to populate a CMDB, and subsequently to compare the actual ‘live’ configuration with the information and records stored in the CMS. In the next slide let us look at the components of CMS process.

3.14 Major Components of Configuration Management System

There are four major components of CMS and they have been explained in this slide. First being Secure libraries and secure stores A secure library is a collection of software, electronic or document CIs of known type and status. Access to items in a secure library is restricted. Libraries are used for controlling and releasing components throughout the service lifecycle, e.g. in design, building, testing, deployment and operations. A secure store is a location that warehouses IT assets are stored. It is identified within SACM, e.g. secure stores used for desktop deployment. Secure stores play an important role in the provision of security and continuity – maintaining reliable access to equipment of known quality. Next is The Definitive Media Library The Definitive Media Library (DML) is the secure library in which the definitive authorized versions of all media CIs are stored and protected. It stores master copies of versions that have passed quality assurance checks. This library may in reality consist of one or more software libraries or file-storage areas, separate from development, test or live file-store areas. It contains the master copies of all controlled software in an organization. The DML should include definitive copies of purchased software (along with licence documents or information), as well as software developed on site. Master copies of controlled documentation for a system are also stored in the DML in electronic form. The DML will also include a physical store to hold master copies, e.g. a fireproof safe. Only authorized media should be accepted into the DML, strictly controlled by SACM. The DML is a foundation for Release and Deployment Management . The exact configuration of the DML is defined during the planning activities. The definition includes: • Medium, physical location, hardware and software to be used, if kept online – some Configuration Management support tools incorporate document or software libraries, which can be regarded as a logical part of a DML • Naming conventions for file store areas and physical media • Environments supported, e.g. test and live environments • Security arrangements for submitting changes and issuing documentation and software, plus backup and recovery procedures • The scope of the DML, e.g. source code, object code from controlled builds and associated documentation • Archive and retention periods • Capacity plans for the DML and procedures for monitoring growth in size • Audit procedures • Procedures to ensure that the DML is protected from erroneous invalid or unauthorized change (e.g. entry and exit criteria for items). Third being the Definitive spares An area should be set aside for the secure storage of definitive hardware spares. These are spare components and assemblies that are maintained at the same level as the comparative systems within the controlled test or live environment. Details of these components, their locations and their respective builds and contents should be comprehensively recorded in the CMS. These can then be used in a controlled manner when needed for additional systems or in the recovery from incidents. Once their (temporary) use has ended, they are returned to the spares store or replacements are obtained. Next component being Configuration baseline A configuration baseline is the configuration of a service, product or infrastructure that has been formally reviewed and agreed on, that thereafter serves as the basis for further activities and that can be changed only through formal change procedures. It captures the structure, contents and details of a configuration and represents a set of configuration items that are related to each other. Establishing a baseline provides the ability to: • Mark a milestone in the development of a service, e.g. Service Design baseline • Build a service component from a defined set of inputs • Change or rebuild a specific version at a later date • Assemble all relevant components in readiness for a change or release • Provide the basis for a configuration audit and back out, e.g. after a change. The last one being Snapshot A s Snapshot of the current state of a configuration item or an environment, e.g. from a discovery tool. This snapshot is recorded in the CMS and it remains as a fixed historical record. Sometimes this is referred to a footprint. A snapshot is not necessarily formally reviewed and agreed on – it is just a documentation of a state, which may contain faults and unauthorized CIs. One example is where a snapshot is established after an installation, perhaps using a discovery tool, and later compared to the original configuration baseline.

3.15 Activities of Asset Management

Fixed assets of an organization are assets which have a financial value, can be used by the organization to help create products or services and have a long-term useful life. For an IT service provider these may include data centers, power distribution and air-handling components, servers, software licences, network components, PCs, data, information etc. Most organizations have a process that manages these assets. This process is usually called fixed asset management or financial asset management. It carries out activities such as: Identifying each asset, including unique naming and labels Identifying and recording asset owners Maintaining an asset register that includes details of all fixed assets Understanding the purchase cost, depreciation and net book value of each asset Helping to protect the assets from damage, theft etc. Carrying out regular audits to ensure the integrity of fixed assets. Many configuration items that are managed by the service provider are fixed assets of the organization (or of their customer), and the service provider is responsible for protecting these assets in line with overall organizational policies. In the next slide we will discuss about the Software asset management.

3.16 Software Asset Management

Let us now discuss about the activities of software asset amangement. Software asset management (SAM) is responsible for the management of software, software licenses and codes for activating software – whether these are installed on computer systems or held as copies that could be installed. SAM includes management, control and protection of software assets and the risks arising from their use. Effective SAM is dependent on use of appropriate tools, including a CMS and a definitive media library (DML). The next is a pictorial representation of relationship between DML and CMDB in CMS.

3.17 The relationship between the DML and a CMDB in the CMS.

This slide gives you the pictorial depiction of the relationship between the DML and CMS which has have been explained earlier under components of Configuration management . In the next slide let us look at the activities of Asset and Configuration Management activities.

3.18 Asset and Configuration Management Activities

High-level activities for Asset and Configuration Management are shown in an example of an activity model in the figure. The activity model illustrated in the figure is often used where there are many parties or suppliers and activities need to be established to obtain the configuration information and data from third parties. We will discuss about each activity in the next slide.

3.19 Asset and Configuration Management Activities

This slide gets into the details of different activities of asset and configuration management . First being Management Planning .There is no standard template for determining the optimum approach for SACM. The management team and Configuration Management should decide what level of Configuration Management is required for the selected service or project that is delivering changes and how this level will be achieved. This is documented in a Configuration Management Plan. Often there will be a Configuration Management Plan for a project, service or groups of services, e.g. network services. These plans define the specific Configuration Management activities within the context of the overarching Service Asset and Configuration Management strategy. Next is Configuration identification. The configuration identification process activities are to: • Define and document criteria for selecting configuration items and the components that compose them • Select the configuration items and the components that compose them based on documented criteria • Assign unique identifiers to configuration items • Specify the relevant attributes of each configuration item • Specify when each configuration item is placed under Configuration Management • Identify the owner responsible for each configuration item. Next is configuration control Configuration control ensures that there are adequate control mechanisms over CIs while maintaining a record of changes to CIs, versions, location and custodianship/ ownership. Without control of the physical or electronic assets and components, the configuration data and information there will be a mismatch with the physical world. No CI should be added, modified, replaced or removed without an appropriate controlling documentation or procedure being followed. Policies and procedures need to be in place Next is status accountisng and reporting Each asset or CI will have one or more discrete states through which it can progress. The significance of each state should be defined in terms of what use can be made of the asset or CI in that state. There will typically be a range of states relevant to the individual asset or CIs. The last being activity is verification and audit. The activities include a series of reviews or audits to: • Ensure there is conformity between the documented baselines (e.g. agreements, interface control documents) and the actual business environment to which they refer. • Verify the physical existence of CIs in the organization or in the DML and spares stores, the functional and operational characteristics of CIs and to check that the records in the CMS match the physical infrastructure • Check that release and configuration documentation is present before making a release. Before a major release or change, an audit of a specific configuration may be required to ensure that the customer’s environment matches the CMS. Before acceptance into the live environment, new releases, builds, equipment and standards should be verified against the contracted or specified requirements. There should be a test certificate that proves that the functional requirements of a new or updated CI have been verified, or some other relevant document (e.g. RFC). Plans should be made for regular configuration audits to check that the CMDB and related configuration information is consistent with the physical state of all CIs, and vice versa. Physical configuration audits should be carried out to verify that the ‘as-built’ configuration of a CI conforms to its ‘as-planned’ configuration and its associated documents. Interrogation facilities are required to check that the CMDB and the physical state of CIs are consistent. These audits should verify that correct and authorized versions of CIs exist, and that only such CIs exist, and are in use in the operational environment. From the outset, any ad-hoc tools, test equipment, personal computers and other unregistered items should either be removed or registered through formal Configuration Management. Registration or removal will be via the Change Management process and has to prevent the authorization of non-acceptable CIs or the removal of CIs that may be supporting business processes. Unregistered and unauthorized items that are discovered during configuration audits should be investigated, and corrective action taken to address possible issues with procedures and the behaviour of personnel. All exceptions are logged and reported. We have now discussed the activities in detail, in the next slide let us look at an exercise.

3.20 Practical Exercise

Though this is a group exercise, consider doing it by taking help of the concepts that we have discussed so far in the previous slides. In the next slide let us look at information management considerations for SACM.

3.21 Information Management considerations for SACM

Information management is the integral part of any process in Service management. Here are the key points that one needs to consider for information management; Backup copies of the CMS should be taken regularly and securely stored. It is advisable for one copy to be stored at a remote location for use in the event of a disaster. The frequency of copying and the retention policy will depend on the size and volatility of the IT infrastructure and the CMS. Certain tools may allow selective copying of CI records that are new or have been changed. The CMS contains information on backup copies of CIs. It will also contain historical records of CIs and CI versions that are archived, and possibly also of deleted CIs or CI versions. The amount of historical information to be retained depends on its usefulness to the organization. The retention policy on historical CI records should be regularly reviewed, and changed if necessary. If the cost to the organization of retaining CI information is greater than the current or potential value, do not retain it, taking note of relevant regulatory and statutory requirements in relation to retention of records. Typically, the CMS should contain records only for items that are physically available or could be easily created using procedures known to, and under the control of, Configuration Management. When Configuration Management has been operating for a period of time, regular housekeeping should be carried out to ensure that redundant CI records are systematically archived. Moving on let us look at the triggers, inputs and outputs of SACM.

3.22 SACM Process Triggers, Inputs and Outputs

Updates to asset and configuration information are triggered by change requests, purchase orders, acquisitions and service requests. This slide shows you what all trigger an input and the output for the same. Inputs to service asset and configuration management include: • Designs, plans and configurations from service design packages • Requests for change and work orders from change management • Actual configuration information collected by tools and audits • Information in the organization’s fixed asset register. Outputs from service asset and configuration management include: • New and updated configuration records • Updated asset information for use in updating the fixed asset register • Information about attributes and relationships of configuration items, for use by all other service management processes. This information should be presented in appropriate views for each audience • Configuration snapshots and baselines • Status reports and other consolidated configuration information • Audit reports. In the next slide let’s discuss on the interfaces of SACM process.

3.23 SACM Service Management Interfaces

By its very nature – as the single virtual repository of configuration data and information for IT Service Management – SACM supports and interfaces with every other process and activity to some degree. Some of the more noteworthy interfaces are: • Change Management – identifying the impact of proposed changes • Financial management – capturing key financial information such as cost, depreciation methods, owner and user (for budgeting and cost allocation), maintenance and repair costs • ITSCM – awareness of assets the business services depend on, control of key spares and software • Incident/, problem/ or error – providing and maintaining key diagnostic information; maintenance and provision of data to the service desk • Availability management in detection of points of failure. The relationship with change and release and deployment is synergistic, with these processes benefiting greatly from a single coordinated planning approach. Configuration control is synonymous with change control –understanding and capturing updates to the infrastructure and services. Let us now look at the CSF’s and KPIs of this process.

3.24 SACM CSF's And KPI's ( 1 of 3)

The following list includes some sample CSFs for SACM Process. Each organization should identify appropriate CSFs based on its objectives for the process. Each sample CSF is followed by a small number if typical KPIs that support the CSF. These KPIs should not be adopted without careful consideration. Each organization should develop KPIs that are appropriate for its level of maturity, its CSFs and its particular circumstances. Achievement against KPIs should be monitored and used to identify opportunities for improvement, which should be logged in the continual service improvement(CSI) register for evaluation and possible implementation To understand better, Llet us take one CSF which states that Accounting for, managing and protecting the integrity of CIs throughout the service lifecycle. So the supporting KPIs would be Improved accuracy in budgets and charges for the assets utilized by each customer or business unit, Increase in re-use and redistribution of under-utilized resources and assets , Reduction in the use of unauthorized hardware and software, non-standard and variant builds that increase complexity, support costs and risk to the business services , Reduced number of exceptions reported during configuration audits , based on urgency/priority/change type, Increase in scores in survey of stakeholder satisfaction for the change management process, Increase in accuracy of predictions for time, quality, cost, risk, resource and commercial impact Let us look at couple more CSF’s and relevant KPI’s in the next two slides.

3.25 SACM CSF's And KPI's ( 2 of 3)

Let us take one the next CSF which states that Supporting efficient and effective service management processes by providing accurate configuration information at the right time. So the supporting KPIs would be Percentage improvement in maintenance scheduling over the life of an asset (not too much, not too late), Improved speed for incident management to identify faulty CIs and restore service, Reduction in the average time and cost of diagnosing and resolving incidents and problems (by type), Improved ratio of used licences against paid-for licences, Improvement in time to identify poor-performing and poor-quality assets, Reduction in risks due to early identification of unauthorized change , Reduced percentage of changes not completed successfully or causing errors because of poor impact assessment, incorrect data in the CMS, or poor version control.

3.26 SACM CSF's And KPI's (3 of 3)

moreIn this slide the CSF which states about that Establishing and maintaining an accurate and complete configuration management system (CMS). So the supporting KPIs would be Reduction in business impact of outages and incidents caused by poor service asset and configuration management, Increased quality and accuracy of configuration information , Improved audit compliance , Shorter audits as quality configuration information is easily accessible , Fewer errors caused by people working with out-of-date information. So far, we looked at the triggers, inputs, outputs, interfaces, CSfs and KPIs of SACM. In the next slide let us look at the risks and challenges of this process.

3.27 The challenges and risks of SACM

Challenges to SACM include: • Persuading technical support staff to adopt a checking in/out policy – this can be perceived as being a hindrance to a fast and responsive support service; if the positives of such a system are not conveyed adequately then staff may be inclined to try and circumvent it; even then, resistance can still occur; placing this as an objective within their annual appraisal is one way to help enforce the policy • Attracting and justifying funding for SACM, since it is typically out of sight to the customer units empowered with funding control; in practice it is typically funded as an ‘invisible’ element of Change Management and other ITSM process with more business visibility • An attitude of ‘just collecting data because it is possible to do’; this leads SACM into a data overload which is impossible, or at least disproportionately expensive, to maintain • Lack of commitment and support from management who do not understand the key role it must play supporting other processes. Risks to successful SACM include: • The temptation to consider it technically focused, rather than service and business focused, since technical competence is essential to its successful delivery • Degradation of the accuracy of configuration information over time that can cause errors and be difficult and costly to correct • The CMS becomes out of date due to the movement of hardware assets by non-authorized staff; half-yearly physical audits should be conducted with discrepancies highlighted and investigated; managers should be informed of inconsistencies in their areas.

3.28 Typical SACM activities performed on a daily basis by SO

Service asset and configuration management is primarily covered in ITIL Service Transition, but there are some aspects that service operation staff will be involved on a day-to-day basis. Examples of these include: •Informing service asset and configuration management of any discrepancies found between any CIs and the CMS •Making any amendments necessary to correct any discrepancies, under the authority of service asset and configuration management, where they involve any service operation components or services •Labeling and tagging physical assets (e.g. serial numbers and bar codes) so they can be easily identified •Assisting with audit activities to validate existence and location of service assets. Responsibility for updating the CMS remains with service asset and configuration management, but in some cases operations staff might be asked, under the direction of service asset and configuration management, to update relationships, or even to add new CIs or mark CIs as ‘disposed’ in the CMS, if these updates are related to operational activities actually performed by operations staff. Operations staff may also assist service asset and configuration management activities by communicating changes in state or status with CIs impacted by incidents. With this we have come to the end of the learning unit 3, let us quickly summarize in the next slide.

3.29 Learning Unit Summary

In this learning unit, we have covered topics on: • Purpose, objectives and scope of the SACM process • Basic concepts, principles and activities of SACM process. • Details about key concepts of CI, CMDB, CMS and DML • Triggers, inputs and outputs • Interfaces with other service management processes • CSFs and KPIs for the process • Challenges and risks and the typical SACM activities carried out in Service Operation Before we proceed to the next learning unit on service validation and testing, complete the quiz section to check your understanding. Thankyou!

3.30 SACM Quiz Scenario

Here is a scenario based quiz. Take your time to go through the scenario given and try answering the questions. Once done compare your answers with the once given on the last slide of this quiz.


... ...



Published on {{detail.created_at| date}} {{detail.duration}}

  • {{}}
  • Views {{detail.downloads}}
  • {{detail.time}} {{detail.time_zone_code}}



About the On-Demand Webinar

About the Webinar

Hosted By





About the E-book

View On-Demand Webinar

Register Now!

First Name*
Last Name*
Phone Number*

View On-Demand Webinar

Register Now!

Webinar Expired

Download the Ebook

{{ queryPhoneCode }}
Phone Number {{ detail.getCourseAgree?'*':'(optional)'}}

Show full article video

About the Author


About the Author