Наполнение CMDB или «инициализация» должна выполняться каждый раз, когда меняются правила учета. И это не обязательно «глобальная перестройка». Фактически это деятельность завязанная на цикл пересмотра плана управления конфигурациями. Если в плане меняется что-то , требующее сбора дополнительной информации, то выполнять эту процедуру придется.

Такая работа действительно может выполняться в виде проекта, но по правилам предусмотренным в рамках процесса.

2. Раздача «прав учетчиков» — это воля менеджера процесса. Если он готов обеспечивать целостность CMDB и соблюдение правил учета, когда каждый первый — «учетчик», то почему бы и нет. Вопрос только в том, как он это собирается делать?

3. Насколько я понимаю, контроль и оценка — периодическая деятельность, направленная на оценку работы процессов и подготовку мероприятий по совершенствованию. А устранение расхождений в имеет два входа: аудиты CMDB, которые действительно можно привязать к аудитам процессов, но аудиты CMDB могут быть не только периодическими, но и привязанными к значимым событиям, например, нашли большое количество расхождений.

4. Бывает

5. А это уже вопрос к тому как строится контроль работы процесса, % заполнения CMDB не единственный важный показатель. С учетом п.2. мне бы например была интересна актуальность данных, соблюдения правил учета.

Если коротко, то идея конфига заключается в том, чтобы учитывать востребованную информацию в соответствии с определенными, исходя из потребностей, правилами. Теоретически можно попробовать это обеспечить и без процессов. Но именно наличие контроля, четко определенных процедур, направленных на выявление и удовлетворение потребностей в информации дает возможность добиться цели. Иначе действительно, зачем процесс, мы и так неплохо работаем: «кто что хочет и как хочет учитывает». В результате получить достоверную информацию, которой можно было бы верить — невозможно.

А давайте и я из своего вагона выгружу мыслишку на заданную тему.;)

А зачем вообще нужен самостоятельный процесс управления конфигурации?

Например, в нашем текущем проекте конфиг реализован как самостоятельный процесс, состоящий укрупнено из 5 практически автономных видов деятельности:

1) Первичное наполнение CMDB – выполняется при создании или при глобальной перестройке CMDB, фактически разовая деятельность.

2) Обновление данных CMDB – в основном внесение изменений в CMDB по результатам реализации изменений.

3) Устранение расхождений в CMDB – корректировка информации о CI по результатам периодических аудитов CMDB.

4) Предоставление информации – выдача информации из CMDB по запросу, когда автор запроса не имеет доступа к CMDB.

5) Формирование и предоставление отчетности – отчетность по процессу.

Все вроде бы красиво и по ITIL, но на практике вышло следующее:

Деятельность «1» не процесс, а скорее проект, по крайней мере, на практике реализуется именно как проект, и включение такой деятельности в постоянно действующий процесс кажется излишним.

Деятельность «2» является самой содержательной частью процесса. Изначально предполагалось, что ограничение числа специально подготовленных специалистов (учетчиков), вносящих информацию в CMDB, позволит обеспечить надлежащую корректность информации в CMDB. Однако на практике права учетчиков быстренько раздали всем, и разделение на исполнителя изменения и учетчика стало чисто формальным. Таким образом, данная деятельность растворилась в управлении изменениями.

Деятельность «3» конечно нужна, но ее существование в отдельном процессе вызывает сомнение т .к. у нас уже есть процесс «Контроля и оценки», в рамках которого осуществляется контроль над всеми процессами. Логичным кажется осуществление и этой деятельности в рамках процесса «Контроля и оценки».

Деятельность «4» вообще ни разу не выполнялась, так как доступ к CMDB имеют все сотрудники, имеющие хоть какое-то отношение к ИТ-инфраструктуре.

Деятельность «5» свелась к отчетам по % заполнения CMDB, а так как это разовая деятельность, то и такая отчетность к процессу фактически не относиться.

Вот и получается, что тяжеловесный конфиг, пожирающий массу ресурсов, мог быть реализован в виде пары процедур в процессе управления изменениями и в процессе «Контроля и оценки», плюс разовый проект по созданию CMDB. А вы как думаете?;)

Простите. Я больше не буду.

«как отправная точка — это жизнеспособный вариант, подтвержденный практикой»

А если на практике внедрить для обновления cmdb управление непрерывностью ИТ-услуг (чтобы пока привыкали), то практика покажет, что и это жизнеспособный вариант

Ты слишком категоричен в выводах. Не могу с тобой согласиться. Отмечу лишь, что не предлагаю делать целью всего процесса управления изменениями «обновление CMDB» раз и навсегда. А как отправная точка — это жизнеспособный вариант, подтвержденный практикой. Т.к. свалить на людей абсолютно новую культуру ведения изменений с согласованиями, приоритетами т.д. сложнее, чем научить их сначала все изменения проводить через процесс, а затем нарастить в нем мяса.

В чем спорность? В теории не так написано?

Очень спорная цель. Если есть кипучая энергия, её лучше направлять в мирное русло, чем на обновление CMDB

Но я веду речь именно об упорядоченной деятельности, единообразной и управляемой, которая может быть направлена на достижение определенных целей, например таких как, обновление CDMB. В каждой организации ИТ-специалисты что-то меняют в инфраструктуре, при этом не каждая может похвастаться упорядоченностью этой деятельности.

Я согласен с такой оценкой.

2. «Если стандартное изменение фиктивно, и не несет пользы с точки зрения процесса, то зачем ему быть в классификаторе». Так это ж элементарная физика;)! Под воздействием силы лени, тело стремиться вернуться в состояние покоя. Поэтому приходится прикладывать некую силу – мотивацию, превышающую силу лени. Но так как «оценка эффективности процесса — непростое дело», соответственно и с метриками у нас беда, то и вектор силы мотивации у нас направлен черт знает куда. И при наложении еще и силы лени, стремящейся вернуть тело в состояние покоя кратчайшим путем, получаем от участника процесса не совсем те действия, какие от них ожидали.

3. «Мы уже как-то обсуждали этот вопрос. Действительно, оценка эффективности процесса — непростое дело». Обсуждали, дело не простое. Но вы предлагаете на основе этой оценки принимать принципиальные решения, вот я и подумал, вдруг у Вас уже есть конкретные решения проблемы.

4. «А в чем Вы видите противоречие?»

«процесс управления изменениями на начальном этапе может внедряться даже как простой способ обновления CMDB и не более».

«процесс управления изменениями необходимо сразу проектировать с расчетом на снижение негативного влияния». Дальше, правда, идет уточнение «а вот запускать стоит постепенно, вводя новые требования и расширяя охват процесса и функциональность процедур в рамках процесса, по мере освоения предыдущих», но в комментарии к первой мысли я уже выразил свое сомнение в полезности отрезания хвоста по частям. И опять же про оценку эффективности. Если мы толком не знаем, как мерить эффективность процесса управления изменениями, значит, мы и при его проектировании ничего не мерили, методики то нет, значит, не знали, снизят ли принимаемые меры негативное влияние или нет?

В целом же, не смотря на отдельные вопросы, я с Вашими мыслями, Евгений, согласен. В отдельных случаях, когда акцент изначально на конфиге (а так далеко не всегда), можно поначалу использовать упрощенный процесс управление изменениями. Более того, нечто подобное мы с коллегами сейчас продумываем для нашего хромого процесса управления изменениями.

1. Если деятельность по реализации изменений уже упорядочена, то конечно одной из задач будет интеграция с процессом управления конфигурациями, я не предлагаю делать шаг назад. Не буду спорить о том, как это бывает на практике, т.к. она бывает разной, но мне пока больше попадались ситуации, когда работающего ПРОЦЕССА управления изменениями нет.

2. Пополнение классификатора, в том числе, стандартными изменениями — серьезная работа, которая требует, в том числе, работы менеджера процесса. Если стандартное изменение фиктивно, и не несет пользы с точки зрения процесса, то зачем ему быть в классификаторе.

3. Мы уже как-то обсуждали этот вопрос. Действительно, оценка эффективности процесса — непростое дело.

4. А в чем Вы видите противоречие?

Не то чтобы совсем не согласны, но обсудить стоит, тема интересная.

«Мысль первая…» Практика показывает, что ведение CMDB является как раз самой трудоемкой частью связки изменения+конфигурация, так как к внедрению этих процессов деятельность по реализации изменений уже, как правило, упорядочена и регистрируется в виде заданий, работ и т.п. Кроме того, процесс изменений нужен хотя бы как вход в конфигурации. Так что предлагаемая экономия кажется не слишком полезной, скорее наоборот, больше потеряем на переделках и переучивании.

«Мысль вторая…» Теоретически все верно, однако, например, в текущем проекте неожиданно выяснилось, что те регламенты стандартных изменений, которые координаторы изменений сами же для себя и разработали, в реальной практике неприменимы, а используются лишь фиктивно, для улучшения отчетности. Теперь координаторы утверждают, что у них не может быть и двух одинаковых изменений.

«Мысль третья…» Конечно, формализация деятельности уже сама по себе способствует снижению числа ошибок. Но вот как определить, насколько процесс управления изменениями достигает своей цели, не очень понятно. Хотелось бы примеры метрик.

«Мысль четвертая...» Немного противоречит мысли первой, но лозунг красивый.