Cms itil что это: CMDB, CMS, SKMS… еще что-нибудь?

Содержание

Люди для CMDB или CMDB для людей – Digital Enterprise

«Кто на ком стоял? — крикнул Филипп Филиппович, — потрудитесь излагать ваши мысли яснее»
Михаил Булгаков, «Собачье сердце»

По-моему, Игорь Фадеев в конце прошлого года написал отличную заметку . Как мне кажется, проблема, решение которой он предлагает, встречается в компаниях, пытающихся построить практику управления конфигурациями, не так уж редко.

Я же при обсуждении этой заметки в очередной раз вспомнил, как при первом прочтении ITIL мне показалось, что в части описания управления конфигурациями в книге содержится парадокс, терминологический казус. Как выяснилось, парадокса нет. Но в реальной жизни некотоые попытки организовать практику управления конфигурациями иногда напоминают попытку воспроизвести этот парадокс (может быть тоже невнимательно читали ITIL? 🙂 )

Попробую запутать и вас.
Система Управления Конфигурациями (Configuration Management System, CMS) в официальном переводе определяется так:

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

Т.е. первое предложение говорит нам о том, что CMS используется для поддержки процесса управления сервисными активами и конфигурациями (Service Assets and Configuration Management, SACM). А первая фраза последнего предложения – о том, что процесс SACM поддерживает CMS.

Ещё раз. CMS поддерживает SACM, а SACM поддерживает CMS. Это что, Уроборос (змея, кусающая себя за хвост)?
Может быть проблема в переводе? Смотрим на оригинальное опредление CMS:

A set of tools, data and information that is used to support service asset and configuration management. The CMS is part of an overall service knowledge management system and includes tools for collecting, storing, managing, updating, analysing and presenting data about all configuration items and their relationships. The CMS may also include information about incidents, problems, known errors, changes and releases. The CMS is maintained by service asset and configuration management and is used by all IT service management processes.

Вроде бы, дело не в переводе.
То есть мы имеем вот такую картину?
стрелки обозначают «использует» (или наоборот «поддерживает»)

Так? Да. Но это не вся правда. В определении CMS также сказано, что она «используется всеми процессами управления ИТ-услугами». Т.е. не только SACM является потребителем информации из CMS.

Казалось бы, это очевидно и даже банально. Но нередко, судя по тому, как организация выстраивает практику управления конфигурациями, складывается впечатление, что практика работает сама на себя. Т.е. создание CMS (или, используя более распространённый термин, CMDB [Configuration Management DataBase]) является самоцелью, а не инструментом для решения какой-то иной задачи.

И ровно на преодоление этой проблемы направлена заметка, упомянутая в самом начале.

Собственно, подход, описанный в ней, на мой взгляд, имеет смысл использовать при построении/оптимизации любых управленческих практик.

обзор методологии — CMS Magazine

Есть ли объективная потребность внедрять канонический ITSM в нашей отрасли? Вряд ли, 99% всех IT-компаний, которые занимаются вебом, — малый бизнес, которому такие навороты даром не нужны. Может быть, ITSM уже присутствует в более-менее стройных процессах той или иной студии? Отчасти так.

Методология с относительно недавних пор докатилась и до России, появились ITSM-консультанты и вендоры. Удариться в культизм можно запросто — чем популярнее подход, тем больше людей хочет его внедрить. Такая вот природа человека.

IT Service Management (ITSM) — один из подходов к управлению услугами ИТ-отдела. Сердце ITSM — это свод знаний ITIL (IT Infrastructure Library). В библиотеке тщательно и системно расписаны все процессы, которые повышают качество ИТ-услуг в сторону их ориентированности на бизнес. Библиотека ITIL появилась по заказу правительства Великобритании еще в начале 90-х, с тех пор вышло три редакции ITIL, а общее количество книг достигло 30.

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

Ключевые слова и фразы для ITSM

ИТ-услуга — сама по себе ценность, ориентированность на бизнес, KPI, системность, ITIL, CobiT, Service Desk.

Суть методологии ITSM

Если классический подход направлен на совершенствование самого программного продукта, то при ITSM акценты смещаются на удовлетворение потребностей бизнеса. Через совершенствование программного продукта, да. Но так как между бизнесом (с его философией, ценностями и целями) и ИТ — пропасть, нужен определенный буфер. Методология ITSM помогает управлять ИТ-отделом эффективно, по KPI, понятным как бизнесу, так и айтишникам.

Но самое главное — ITSM направлен на трансформацию сознания людей, культуры ИТ-компании или отдела. По большому счету, любая методология без трансформации культуры превращается в карго-культ, которому так легко и приятно следовать, но который не прибавляет ценности ни на грамм.

Следует различать вот что. Есть ИТ-отделы внутри компаний. А есть ИТ-компании. Первые, как правило, плевали на дружелюбность и ориентированность на клиента (в данном случае на руководство). Вторые — изо всех сил стараются быть похожими на «зрелый» бизнес, делать продукты «для людей», думать о продажах, клиентском сервисе и т.д.

Поэтому ИТ-компании (особенно только зародившиеся) так падки на новые методологии, у них на это минимум две причины.

Они хотят соответствовать Большому Бизнесу. Это похоже на то, как сын подражает отцу. Отрасль ИТ все еще молода, к ней относятся с недоверием и высокомерием. Для большинства крупных бизнесов, «ИТ-компания» — это сборище «компьютерщиков», бородатых и вечно с бодуна. Чтобы показать серьезность своего бизнеса, ИТ искусственно увеличивает собственную важность: рейтинги, сертификаты, методологии, ассоциации.

Они хотят получить конкурентное преимущество. Чем рядовая вебдев-студия может похвастать, зацепить заказчика? Она работает по Scrum? Половина уже работает по Scrum (ну, или так заявляет). Она делает интерфейсы «для людей»? А кто не делает. Схватив тренд погорячее, каждый пытается воздеть его на длинное древко и махать над головой.

Роб Ингланд, автор книг по ITSM и ITIL, спрашивает: «вы видели инженеров, ежегодно предлагающих новые крутые способы строительства, скажем, мостов (как правило — более дорогие и менее надежные, чем те, что применялись на протяжении многих лет)?».

В ИТ же один способ круче другого. Но ITSM сама по себе методология сложная, громоздкая, с множеством метрик. Подходит ли она для того, чтобы просто увеличить собственную важность в глазах клиентов?

Помимо всего, ITSM — процесс цикличный, это тот же Continual Process Improvement, как и в DevOps. Например, так выглядит жизненный цикл ITSM:

Представьте, сколько ресурсов нужно будет бросить веб-студии со штатом, скажем, в 15 человек, на жизнеобеспечение ITSM. Рационально? Вряд ли.

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

Другое дело — ИТ-отделы в крупных компаниях с прогрессивным руководством. Почему у них есть острая потребность в ITSM?

Почему ITSM нужен ИТ-отделам

Бизнесу больше не нужна кучка бородачей, неуправляемых и непредсказуемых. Бизнес хочет рулить всем, все измерять и корректировать траекторию развития.

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

Роб Ингланд

Итак, у нас есть большая компания (не ИТ). У компании есть ИТ-отдел. Бизнес видит ИТ как придаток, слабо понимая, какую ценность он несет, признавая ИТ только как инструмент, который время от времени устраняет технические аварии, позволяя другим сотрудникам компании приносить реальную ценность.

Руководство, бухгалтерия, продажи, проектный отдел и другие — с одной стороны. ИТ — с другой. Они говорят на разных языках, по-разному выглядят, воспринимают друг друга соответствующим образом.

Так бизнес видит ИТ:

Так ИТ видит бизнес:

У бизнеса есть два справедливых желания:

Ставить задачи ИТ-отделу так, чтобы все выполнялось строго в соответствии с задачами бизнеса.

Контролировать выполнение, отслеживать эффективность работы ИТ-отдела.

Первая задача худо-бедно выполняется, если в штате есть менеджер с техническими знаниями, который способен переводить задачи бизнеса на язык айтишников. Либо, что на грани фантастики, задача решается наличием айтишников, способных правильно интерпретировать задачи бизнеса, «думать, как пользователь» и т.д.

Вторая задача решается в основном никак. То есть эффективность работы ИТ-отдела можно как-то попытаться измерить, взглянув на эффективность работы отдела, который айтишники обслуживают. Поздно починили 1С, не отправили отчет в налоговую, получили штраф — кому выписать люлей? (правильный ответ: ответственному менеджеру).

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

Поэтому по предписаниям ITSM процесс работы ИТ-отдела меняется в соответствии с такими принципами:

Первый приоритет — восстановление услуги.

Приоритет задач определяется с учётом услуг, с которыми они связаны.

Новые идеи оцениваются на основе того, улучшают ли они услуги.

Изменения управляются так, чтобы сделать жизнь легче, а не так, чтобы «всё записывать».

Пользователи рассматриваются как коллеги, нуждающиеся в помощи, а не как приставучие неудачники; их запросы — как требующие ответа, а не как заведомо глупые;

Основное направление коммуникаций с ними — проактивная помощь, а не старательное избегание.

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

Конкретика?

Практически методология не предлагает ничего сверхнового — стоит почитать любую литературу по ITSM. Цикл Деминга? Мы и раньше про него знали (тот же канбан отчасти на нем базируется). KPI? Если вы думаете, что в ITIL будет четкое указание: для управления инцидентами применяйте такие-то метрики — то забудьте сейчас же. Как уже говорилось, любая методология адаптивна. Поэтому:

Брать KPI из чужого опыта, литературы или форумов — неправильно. Причина: чужой опыт никогда в точности не ляжет на ваш. Не KPI должны определять задачи бизнеса, а наоборот. Вывод KPI — процесс творческий. Здесь, думаю, всем понятно.

Измерять максимум KPI, сколько вообще возможно (информация-то лишней не будет!). Тоже заблуждение.

KPI должны выводиться на основании конкретно ваших целей, а вы при этому должны отдавать себе отчет: для чего вам этот KPI и к чему вы хотите в итоге прийти на определенном уровне управления ИТ. Кстати, сами уровни достаточно неплохо расписаны вот здесь.

ITSM и ITIL — это отнюдь не сборник конкретных рекомендаций, как действовать в какой ситуации. Это еще одна философия.

Аналоги ITIL

Разбираться в библиотеке ITIL сходу, не нюхав методологий ранее, — самоубийство. Поэтому эксперты рекомендуют начинать с чего полегче:

Во-первых, присмотритесь к облегченной версии ITIL, официальное название — ITIL Small-Scale Implementation5. Это официальное издание ITIL, в котором авторы попытались смасштабировать ITIL для нужд малого бизнеса.

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

ISM1 — «коробочное решение для управления ИТ-услугами». Звучит очень многообещающе, но только для тех, кто умеет разговорить Яна ван Бона.

Core Practice3 («Основные практики», СоРr) — интересная новая разработка, достойная внимания.

Русскоязычных источников теоретических знаний не так много. Есть книги в переводе:

Овладевая ITIL. Скептическое руководство для ответственных лиц, Роб Ингланд.

Введение в реальный ITSM, Роб Ингланд.

Метрики для управления ИТ-услугами, Питер Брукс.

Введение в ИТ Сервис-менеджмент, Ян Ван Бон.

И сообщества, гугл в помощь.

Вроде заключения

Даже вооружившись правильными KPI и произведя правильную «трансформацию» процессов своего ИТ-отдела или ИТ-компании, вы оставляете открытым главный вопрос. А изменит ли это культуру людей, ваших сотрудников? Раз конечная цель — ориентированность на бизнес и пользователя, то эта мысль должна засесть в мозгу у каждого. Как понимаете, сертификат не сможет поменять людей изнутри.

Поэтому, кто заинтересовался, готовьтесь идти трудной дорогой привыкания к изменениям.

Оригинал: http://blog.sibirix.ru/2015/03/12/itsm/

Связь между CMDB и CMS

В этом разделе описывается, как
База данных управления конфигурацией (CMDB) вписывается в более широкую
система управления конфигурацией (CMS) . Согласно ITIL V3, CMS состоит из баз данных и инструментов, которые управляют данными конфигурации для поставщика услуг. CMS — это основа, поддерживающая полный сервис
жизненного цикла в ИТ.

Цели CMS:

Максимальная ценность для бизнеса
Управление критически важными для бизнеса службами
Обеспечение соответствия политике управления и внутренней безопасности
Включите автоматизацию для максимальной эффективности
Разрешить управление активами

CMS может включать различные
Инструменты управления ИТ и базы данных , такие как база данных активов, система управления базой данных изменений и CMDB.

Рекомендуем прочитать — Влияние CMS на бизнес — полное руководство

Единая точка отсчета:

CMDB предоставляет единую точку отсчета, что делает ее окончательным справочным механизмом для всех ИТ-решений, обеспечивая прозрачность для бизнеса в зависимости между бизнес-процессами, пользователями, приложениями и базовой ИТ-инфраструктурой. Это повышает уровень осведомленности операторов о состоянии бизнес-служб в режиме реального времени, таких как доступность электронной почты, производительность веб-сайта и т. д. Все ведущие решения CMDB построены для поддержки федеративного подхода CMDB, что означает, что не все данные конфигурации должны находиться в одной физической базе данных. Вместо этого первичные системы и репозитории данных остаются авторитетным источником информации, а CMDB становится справочной информацией о том, где находится эта информация и как получить к ней доступ.
ITIL V3 теперь признает важность такого федеративного подхода и рекомендует сделать его основной частью структуры CMS. При объединении основные данные хранятся в базе данных CMDB, которая связана с другими, более подробными хранилищами данных. Эта связь обеспечивает доступ CMDB ко всем элементам конфигурации (CI). Следовательно, CMS включает в себя CMDB или несколько CMDB, а через федерацию доступ ко всем первичным хранилищам данных и их соответствующему содержимому. Добавляя ключевые функции, такие как аналитика, информационные панели и управление активами, CMS расширяет ценность CMDB для ИТ.

Влияние на культурные и организационные изменения:

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

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

Рекомендуем прочитать — Руководство по успешному управлению проектами с использованием CMDB

Однако продажа преимуществ — это только начало. Как указывает ITIL, просто изменить ИТ-услуги недостаточно для преобразования организации. В конце концов, организация будет развиваться таким образом, что позволит ей использовать измененные ИТ-услуги.

Связь как внутри ИТ, так и между ИТ и бизнесом может значительно улучшиться при внедрении CMDB. По сути, CMDB должна стать интеграционной платформой, объединяющей несколько процессов и инструментов. Организация должна внедрить всеобъемлющий план коммуникации, чтобы помочь в управлении культурными изменениями.

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

Любая оценка зрелости процессов и инструментов должна включать оценку людей не только с точки зрения компетенций, но и с точки зрения их отношения и поведения. Информация, полученная в результате этой оценки, должна затем использоваться для управления культурными изменениями. Требование улучшения документации может изменить культуру от накопления информации к обмену информацией. Это требование может оказать существенное влияние на культуру.

Обучение на ходу:

Ваша организация, как и все остальные, будет учиться на ходу. По мере того, как ваша организация будет развиваться, вы будете продолжать использовать это обучение с помощью CSI. Без внедрения CMDB ни одна организация не может достичь определенного уровня зрелости. Всегда будут проблемы роста, но результаты будут более чем достойными.

Нажмите здесь, чтобы перейти к курсу по управлению услугами

Автор: SiddharthPareek

404: Страница не найдена

ITОперации

Страница, которую вы пытались открыть по этому адресу, похоже, не существует. Обычно это результат плохой или устаревшей ссылки. Мы приносим свои извинения за доставленные неудобства.

Что я могу сделать сейчас?

Если вы впервые посещаете TechTarget, добро пожаловать! Извините за обстоятельства, при которых мы встречаемся. Вот куда вы можете пойти отсюда:

Поиск

Ознакомьтесь с последними новостями.
Наша домашняя страница содержит самую свежую информацию об ИТ-операциях.
Наша информационная страница содержит дополнительную информацию о сайте, на котором вы находитесь, IT Operations.
Если вам нужно, пожалуйста, свяжитесь с нами, мы будем рады услышать от вас.

Просмотр по категории

Качество ПО

Как проверить манифест Kubernetes
Команды разработчиков должны проверять манифесты Kubernetes. Разработчики могут ориентироваться при проверке и возникающих проблемах с помощью нативных …
Перспективы двух выпускников учебного лагеря Nucamp по кодированию неясны
Учебный лагерь по программированию может стать толчком к карьере в сфере технологий, но только для тех, кто готов пройти лишнюю милю. Вот как два неразработчика…
10 основных навыков Скрам-мастера
Скрам-мастера помогают разработчикам Agile, владельцам продуктов и другим членам команды выполнять задачи, начиная от планирования спринта и заканчивая лидерством на службе. ..

Архитектура приложения

Как архитекторы могут использовать математику салфеток для прогнозирования производительности
Хотя современные программные системы могут быть чрезмерно сложными, архитекторы все еще могут использовать простую математику, чтобы быстро подобрать…
Учебник по основным концепциям структуры команды разработчиков
Чтобы установить правильный размер команды разработчиков, менеджеры должны учитывать обязанности каждого члена и пути коммуникации, как …
10 учебных курсов для подготовки к сертификации по микросервисам
Хотя получить сертификат по архитектуре микросервисов не всегда просто, существует множество курсов, которые вы можете пройти, чтобы …

Облачные вычисления

Как выполнять и автоматизировать ротацию ключей в Azure Key Vault
Чтобы добавить еще один уровень безопасности, узнайте, как автоматически менять ключи в хранилище ключей Azure с помощью пошаговых инструкций. ..
Развертывание Azure Key Vault и управление им с помощью Terraform
Terraform управляет ресурсами с помощью файлов конфигурации на облачных платформах. Следуйте этому пошаговому руководству, чтобы узнать, как …
6 разработчиков вариантов PaaS с открытым исходным кодом, о которых следует знать в 2023 году
PaaS с открытым исходным кодом — хороший вариант для разработчиков, которым нужен контроль над хостингом приложений и упрощенное развертывание приложений, но не…

ПоискAWS

AWS Control Tower стремится упростить управление несколькими учетными записями
Многие организации изо всех сил пытаются управлять своей огромной коллекцией учетных записей AWS, но Control Tower может помочь. Услуга автоматизирует…
Разбираем модель ценообразования Amazon EKS
В модели ценообразования Amazon EKS есть несколько важных переменных. Покопайтесь в цифрах, чтобы убедиться, что вы развернули службу…
Сравните EKS и самоуправляемый Kubernetes на AWS
Пользователи AWS сталкиваются с выбором при развертывании Kubernetes: запускать его самостоятельно на EC2 или позволить Amazon выполнять тяжелую работу с помощью EKS. См…

TheServerSide.com

Как разработчики могут сохранять мотивацию при удаленной работе
Чувствуете, что потеряли преимущество в удаленной работе? Следуйте этим советам, чтобы оставаться энергичным, оттачивать свои навыки и укреплять …
Скрам против Канбана: в чем разница?
Когда вы сравниваете Scrum и Kanban, вы понимаете, что у них столько же общего, сколько и различий. Здесь мы поможем вам выбрать …
Различия между Java и TypeScript должны знать разработчики
Вы знаете Java? Вы пытаетесь изучить TypeScript? Вот пять различий между TypeScript и Java, которые сделают .