Портал №1 по управлению цифровыми
и информационными технологиями

SKMS или база знаний?

Опубликовано 6 ноября 2012
Рубрики: Защищаем ITIL, Обо всём на свете
Комментарии

Сегодня хочу поговорить об одной из недооцененных концепций в ITIL – SKMS. 

Система управления знаниями по услугам определена в словаре терминов так:

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

Как обычно, несколько строчек текста обо всём и ни о чём. Приходится разбираться.

В заблуждение читателей (которые готовятся к базовому экзамену) вводит "эволюция": CMS – это прокаченная база данных ИТ-активов и связей между ними, а SKMS – это CMS плюс другие источники данных. Какие? Очевидно, это загадочная "вся информация, которая необходима поставщику ИТ-услуг". Исчерпывающего списка, понятно, нет, а «для примера» информации, которая к активам не привязана, приводятся всевозможные портфели (заказчиков, услуг, приложений…), модели, планы, отчеты, реестры и даже данные о погоде. И вот при беглом прочтении начинаешь сомневаться: а существуют ли такие технологии, чтобы "вот это вот всё" сразу? Не говоря уже о единых процедурах.

Как насчет "базы знаний" (Knowledge Base)? Примеров масса и в ITSM-инструментах и вообще.

Так почему же ITIL ничего не пишет о KB? Даже в книге ITIL Service Transition «Knowledge base» упоминается всего пять раз, в том числе один раз в Глоссарии.

А в Глоссарии вот что:

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

Вуаля. ITIL говорит, что БЗ – это технологическая платформа SKMS. Элегантно, правда?

Мне же кажется, что главное отличие – в целевой аудитории. Аудитория SKMS – это не только и не столько поддержка действующей ИТ-инфраструктуры. За рамками инструкций по эксплуатации ИС и памяток для пользователей ИТ-организация копит и другие знания. Вот так, вычеркивая техподдержку, я прихожу к охвату SKMS. А идея про единую платформу – мне нравится.

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

ОБУЧЕНИЕ
ITIL 4 Foundation, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от соавторов ITIL 4

Также по теме:

Комментариев: 9

  • Станислав Уштей

    Если согласится что сервис – это Бизнес-приложение, то в рамках управления жизненным циклом такого сервиса, собирается огромное количество информации: ИТ-архитектурной; Бизнес-архитектурной; Регламентно-Методической, Базисной и.т.д.

    Например SAP Solution Manager претендует на роль инструмента – который все это содержит в себе и взаимосвязано управляет всем этим хозяйством – читай: “управляет полным жизненным циклом SAP-решения”.

    При этом, все понимают, что он не заменяет BPM средства моделирования и CMDB средства учета активов и КЕ

    Поэтому, пока SKMS – звучит как “шаровая модель коня в вакууме” – Хотя желания понятны

  • Альберт

    Заголовок звучит примерно как: Google или Microsoft Knowledge Base? 🙂
    База знаний это некий результат, выжатый из RAW формата инцидентов, проблем, изменений и прошнурованный CMDB.
    SKMS – у нас в голове, нужно ли нам обобщать информацию или нет, это вопрос подхода. До какого-то уровня можно обходиться и RAW информацией. Но если мы понимаем что есть потребность в обобщении информации, на основе её количества (инцидентов, проблем, изменений) или приоритетности, то мы это делаем.
    Важно понимать, что все это требует ресурсов не только на обобщение знаний, но и на их периодическую ревизию. По-хорошему это должно быть зашито в системе управления IT услугами или как-то к ней прикручиваться.

  • Дмитрий Исайченко

    Костя, я думаю, в ITIL термин SKMS не предполагает наличия единой технологической платформы. Даже в приведённой Вами цитате сказано: “Набор инструментов и баз данных” (во множественном числе). То есть SKMS – исключительно концепция, а не какая-либо конкретная база или приложение (собственно даже про CMS так написано и это очень-очень правильно и самое главное – жизненно). Концептуально в SKMS должны (или по крайней мере могут) входить:

    1) средства мониторинга услуг;
    2) система управление проектами (поскольку проекты могут менять и состав, и характеристики, и технологию предоставления услуг);
    3) IDM-решение (для крупных компаний – почти наверняка, ведь это и ролевая модель, и авторизованные уровни доступа по каждому субъекту, то есть технологическая основа процесса управления доступом);
    4) средство управления контрактами и взаиморасчетами с поставщиками и потребителями;
    5) решения для проведения инвентори и развертывания ПО на объектах управления;
    6) система управления документами или просто организованное файловое хранилище для нормативных и рабочих документов по управлению ИТ-услугами;
    7) BI-решение для формирования отчетности по процессам и услугам (возможно извлекающее и агрегирующее информацию для отчетов из разных источников);
    и так далее.

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

    Таким образом, SKMS является естественным расширением понятия CMS (например, в части управления проектами и мониторинга состояния услуг) и тем более – традиционных ITSM-решений (которые обычно представляют собой workflow-автоматизацию процессов + одну или несколько CMDB). И это довольно сильно отличается от устоявшегося понимания термина KB.

    Я так думаю, доказательств у меня нет. Но такая картинка бьётся и с жизнью (где все гораздо богаче, чем “у нас есть один мегапродукт за много миллионов USD, который умеет все”), и с книгами ITIL (по крайней мере, с тем, что я помню из книг). Что скажете? Или я вообще не о том написал?

    • Pavel Solopov

      А что не может входить в SKMS? Судя по Вашему перечислению таких исключений не найти…

      • Дмитрий Исайченко

        А нет такого вопроса. Повторюсь, в отличие от телекома, где для систем OSS/BSS проработана архитектура данных (SID) и функциональная архитектура (TNA), SKMS – это просто концепция. И на верхнем уровне в SKMS действительно может быть включена фактически любая подсистема (тем более, что и ИТ-услуги могут быть очень разными, и на концептуальном уровне нет ограничений, а значит и знания – платные они или нет, в чем заключаются, как управляются и так далее).
        Практическую ценность вопрос о границах SKMS приобретает только в конкретном контексте – там, где эта концепция обретает форму – архитектуру и конкретный состав технических решений. Вот в конкретной компании, понимая всю специфику, действительно можно (а иногда и важно) выбрать и зафиксировать границы SKMS. Особенно актуально это при реализации комплексных систем управления, а не просто отдельных процессов ITSM.

  • Дмитрий Исайченко

    Кстати, можно провести очень наглядные и убедительные (на мой взгляд) параллели с системами OSS/BSS в телекоме. Только там все гораздо больше проработано и есть понятие целевой стандартной архитектуры, а не просто открытые списки “вплоть до погоды”, как в книгах ITIL. Но концептуально это похожие вещи.

  • Pavel Solopov

    Если посмотреть на СИСТЕМУ шире нежели просто комплекс программно-технических средств, то система может включать ещё и так называемое ОРГАНИЗАЦИОННОЕ обеспечение, ну или проще роли и регламенты.
    Тогда получается нечто такое:
    SKMS = KB+CMDB+регламенты использования, наполнения, ведения, взаимодействия между этими (и возможно другими) DB.

    • Дмитрий Исайченко

      Мне эта формула не кажется полезной по двум причинам:

      1. Это очень частный случай. Здесь нет многих решений, которые могут использоваться поставщиком для управления своими услугами. Ведь и примеры про информацию о погоде можно привести, как бы это ни казалось забавным.
      2. Знак “+” здесь очень условный. Например, я думаю Вам будет очень нелегко доказать (опираясь на текст книг IITL), что KB не является частью CMDB. Скорее уместно использовать объединение множеств.

  • Pavel Solopov

    Полезной для кого и с какой точки зрения?

    Ну да, забыл дописать ещё “+другие DB”.
    Плюс конечно условный, можно его понимать и как объединение множеств.

    Общими словами звучит так:
    SKSM это совокупность различных баз данных (данные, программно-аппаратные средства их хранения и сбора) и процедур их наполнения, актуализации и использования.

    Может так будет полезней? 🙂

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.