Управление Service Asset и Configuration (Service управление на активите и конфигуриране), как този процес е правилно наречена в v3 на ITIL®, - един от най-трудните за разбиране и прилагане ITIL® процеси, във всеки случай, тази оценка трябва да бъде от проучвания на нашите слушатели.

Нека се опитаме да разберем тези проблеми, преглед на някои от рисковете, които съпътстват практиката на този процес.

За да започнете (както винаги) ще се занимава с основните понятия на процеса. При управлението на активи и работни конфигурации, нови концепции, които не са съществували през втората версия на ITIL®. Накратко се рови в основните понятия на използване на определението от речника.

• System Configuration Management (Система за управление на конфигурацията, CMS) - набор от инструменти и бази данни, които се използват за конфигуриране доставчик за управление на данни на ИТ услуги.

• ССФ включва също така информация за инциденти, проблеми, известни грешки, промени и пресата. Може да съдържа данни за служители, доставчици, места, бизнес звена, клиенти и потребители
• CMS включва инструменти за събиране, съхранение, управление, актуализиране и отчитане на всички CI и връзката им

• база данни за управление на конфигурацията (за управление на конфигурацията на базата данни, CMDB) - база данни, използвани за съхранение на конфигурационните записи през целия им жизнен цикъл. Configuration Management System (Конфигурация на системата за управление, CMS) управлява CMDB и CMDB и всяка се състои от КИ и ДИ други атрибути за връзка.

• Запис на CI (Sonfiguration Record) - запис, съдържащ подробна информация за CI. Всеки запис документира жизнения цикъл на един-единствен CI. Запишете конфигурацията се съхранява в CMDB.

• Конфигурационният блок (конфигурация т, CI) - актив, услуга компонент или друг елемент, който е или ще бъде под контрола на процеса на управление на конфигурация. Може да бъде:
  • жизнен цикъл CI услуга
  • обслужване CI
  • организационна CI
  • вътрешен CI
  • външен CI
  • CI интерфейс

Ние илюстрираме тези разпоредби малка диаграма, взета от книгата на Service Transition:

От схемата и определения, ние виждаме, че:

CMS - по-широко понятие от CMDB и може да съдържа предмети, които не са CI.

Ние не говорим само за базата данни, но на цялата система от свързани помежду си бази данни, инструменти, уеб сайтове и интерфейси с различни нива на съхранение, представяне и дисплей.

Списъкът на това, което може да бъде ПО, значително разширява и може да включва както физическата и logichekie ПО, като IT и бизнес обекти.

Разбира се, не всички фирми имат трудна системата за управление на конфигурация, дори и в сънищата си, но ITIL® визия е впечатляващ. Така че какви са трудностите и рисковете очакват хората, които са решили да прилагат този процес, какви грешки те често правят? Нека да разгледаме някои от тях:

Неправилно или ясно определени цели и задачи на процеса

Още в самото начало, дори и на етапа на планиране, трябва да се определят ясни акценти, тъй като самият процес, CMS структура и организация на взаимодействие с други процеси или отдели значително в зависимост от това, което е необходимо задачи, за да бъде решен. Вариантите са:

Установяване на контрол върху основните елементи на ИТ инфраструктурата, определянето на отношенията между двете части на ИТ инфраструктурата, както и между тях и основните бизнес услуги за критичните за бизнеса промени

Счетоводство на активи, да поддържа контрол, поддръжка на изискванията за сигурност, интеграция със системи за наблюдение

Prompt и точен опис на ИТ активи за счетоводни искания

Лиценз Control

Но нека си представим, че ние да се е занимавал с необходимите задачи. Тогава ще имаме първия капан:

Подход: "ние събираме всички данни, които е възможно", което води до претоварване на процеса, както и невъзможността да го подкрепят

Типичен грешка в началото на строителството на процеса: всички очарован от възможността за събиране на CMDB толкова информация, колкото е възможно. В резултат на това тежко изпитание всички сили, проведени общо опис, базата данни е изкован по целия път до последния мъртъв мишката - това е всичко, щастие! Но няма късмет, както винаги, не, защото всички малки събирането веднъж, вие имате всичко това богатство, за да се поддържа актуална, показваща се на CMDB промени всъщност се случва с многобройни CI. Поради това по-рано никой не мислеше и усилия, за да не поддържат събра, идва бързо deactualization част (и ако не са щастливи, а по-голямата част) данните в CMDB, и като следствие - ужасно разочарование и неверие в силата на ITIL®. И тук е втората клопката, която е тясно свързана с първата:

Загуба на информация за конфигурацията на значение с течение на времето, което води до грешка, както и трудностите, и прекомерните разходи за корекция

Управление на конфигурацията - специален процес, метафорично прилича повиши малко дете: малко от раждането му, е необходимо постоянно да се грижи за него и това е добре. Не само, че не се задави с голямо парче в началото, ние също трябва да поддържа цялата необходима в процеса. На практика, има ситуации, когато по някакви причини, има загуба на реални данни в CMDB, така че е важно да се определи дали появата на състоянието и помисли рационалното за своите коригиращи мерки. Най-ефективната мярка е да се идентифицират одит, т.е. проверка на данните и реалната CMDB ПО. За съжаление, на одита е скъпо, изисква допълнителни ресурси и като минимум, правилното определяне на обхвата на одита. На практика селективен одит се извършва по-често.

Подкрепа за данни в CMDB актуална е толкова важно, колкото съдържанието на информацията на самата база данни. данните в необходимите CMDB:

Те трябва да бъдат от значение (ясно да показват състоянието на физическата инфраструктура в момента)

Те трябва да са надеждни (отсъствие на грешки в самите данни)

Те трябва да са популярни (нуждите на клиентите CMDB)

И тук е уместно да се разгледа следната разпоредба, която също изисква внимателно и внимателен подход. Те са следните:

Създаване на стабилна ниво на точност, т.е. съответствието между модела и действителната конфигурация

За да се реши този проблем не е лесно, защото тук трябва да се реши правилно уравнение с няколко неизвестни:

Определяне на нивото на детайлност - например, какво атрибути ще бъде най-ПО, че ще бъде само атрибут, а това - за да бъде достоен за този CI?

Определяне на необходимата комуникация както между ПО, както и между CI и юридически лица - например, между ПО и услуги между ПО и инцидента проблема, RFC, пресата.

Тъй като за първи път за решаване на всички правото няма да е лесно, проблемът е решен в няколко повторения. В следващите повторения могат да бъдат решени следните задачи:

Като прибавим към данните за CMDB, които са били необходими за потребителите, но това не беше в CMDB

Премахване от данните на CMDB които не са били твърди от потребителите база

Когато всички необходими повторения, за да определят средствата, необходими за подкрепа на данните от CMDB към днешна дата. Присъствие (отсъствие) на тези ресурси е от решаващо значение.

По този начин, ние виждаме, че препоръките на ITIL ни дадат възможност да се предпазят от често срещаните грешки, и да ни даде правилният подход за решаване дори сложни задачи, като например изграждането на редовен процес обслужване на активи и конфигурация на управление.

По тази тема се обсъжда в следните курсове:

Подобни въпроси бяха повдигнати в следните проекти:

• Организация на процеса на управление на конфигурацията в банка BSGV
• Изпълнение на процеса на управление на конфигурацията в Обслужващо дружество АД "RusHydro MC" РАО ЕЕС на България
• Изпълнение на процеса на управление на конфигурацията в VTB24
• Изграждането и внедряването на процеси за управление на конфигурацията в Група Sual

ITIL® и PRINCE2® - регистрирани търговски марки на AXELOS Limited.

Swirl лого ™ - запазена марка на AXELOS Limited.