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

Дайте нам что-нибудь…стандартное

Опубликовано 21 июня 2012
Рубрики: Обо всём на свете
Комментарии

Наверняка коллеги-консультанты (и не только из Cleverics :)) сталкивались со следующим: например, необходимо разработать перечень категорий и набор атрибутов для конфигурационных единиц, вы описываете заказчику методику, а вам заявляют – "парни, вы уже …цать подобных проектов сделали, ну неужели у вас нет каких нибудь стандартных категорий и атрибутов? Ну или из предыдущего проекта дайте, мы подправим – и все будет хорошо". Это также случается сплошь и рядом  и с разработкой первичного каталога услуг, особенно если подобный каталог используется в качестве "костыля" для процесса управления инцидентами.

Ну и собственно вопрос – даете? :) А надо ли давать, как считаете?

ОБУЧЕНИЕ
Учебные курсы и сертификация на русском языке
специалистов по ИТ-менеджменту

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

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

  • Vladimir Kalenov

    Консультант = best practices, мне кажется пропущена сама формула 🙂

    Для любой задачи конкретной Компании существует Консультант, такой что Консультант = best practices

    Доказательство:
    Консультант = N*Good practice + N*Ранее созданных решений + Анализ проблемы заказчика + Внимание к деталям + Учет специфики заказчика
    , заметим что:
    Анализ проблемы заказчика + Внимание к деталям = -N*Ранее созданных решений

    => Консультант = N*Good practice + N*Ранее созданных решений – N*Ранее созданных решений + Учет специфики заказчика = N*Good practice + Учет специфики заказчика = Best Practice.

    ЧТД

    P.S. С пятницей 🙂

    • Vladimir Lyaleko

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

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

      Однако есть примеры продажи готовых ITSM боксов, с полным комплектом документов, готовым каталогом, настроенной системой автоматизации и т.д. На мой взгляд ценность подобных “проектов” сомнительна, однако подобные подходы востребованы на рынке…. и пост Михаила это отчасти подтверждает.

      • Pavel Solopov

        На мой взгляд ценность подобных «проектов» сомнительна

        Это конечно тема из разряда “определение ИТ-услуги” (т.е. сто раз обсуждали, единого мнения нет, но обсуждения очень бурные) 🙂 Но всё же выскажусь.

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

        Но применяя типовые решения мы должны в чём-то ограничивать себя, подстраиваясь под эту типизацию.
        С бизнес-процессами пока немножко по другому, многие свято верят, в то, что их БП какие-то особенные и обеспечивают КОНКУРЕНТНЫЕ преимущества. И действительно это может быть так, но не более чем в 10% (моя личная оценка).
        Поэтому типовые решения решения, особенно в ИТ, должны преобладать.
        А что касается атрибутов КЕ и их категорий, так они уже вообще давно должны быть все перечислены в ITIL, ну нет тут реально простора для “уникальности”.
        Давайте может организуем Open Source НСИ для КЕ?

        Или жалко своим хлебом делиться? 🙂

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

          Паша, стандартизация CMDB возможна, но не как стандартная модель данных CMDB. Причина заключается в том, что применение “стандартной CMDB” и задачи заказчика может не решить, и данных для сбора потребуется куча. То есть опять стандартизация инструмента подменяет собой постановку задачи. Правда есть вендоры которые и стандартную модель данных предлагают, и уверяют заказчика, что вся это информация “отдискаверится” сама, но на практике эти заверения выглядят … неубедительно.
          Что можно типизировать в CMDB, так это создавать своего рода паттерны, которые определяют некоторый фрагмент модели данных CMDB в привязке к тем или иным задачам. Например, Вам нужно обеспечить такой-то и такой-то учёт лицензий и лицензионный контроль – вот заготовка. Или, Вы хотите отобразить влияние сети на работоспособность приложений – вот заготовка. Причём наиболее важным содержанием паттерна будут даже не атрибуты CI, а конфигурация связей.
          Собственно, у нас давно копится такой опыт, и он пополняется с каждым проектом, в рамках которого мы строим настоящую CMDB (хотя проектов таких, к моему сожалению, не очень много). Шарить это в формате Open Source – не вижу смысла. Приходите на курсы 🙂

          • Pavel Solopov

            Паша, стандартизация CMDB возможна, но не как стандартная модель данных CMDB.
            Не согласен я с вами, Дима. если конечно мы одинаковый смысл в данные слова вкладываем. 🙂

            Типов КЕ достаточно ограниченное количество, атрибуты их тоже ограничены, возможные типы связи между различными типами КЕ тоже ограничены. Все эти типы и атрибуты будут подходить для 90% случаев, да даже для 99%. И только в 1% возможно КЕ будут обладать какими-то уникальными характеристиками, не вписывающимися в эту модель (например, если вы сами сетевые устройства паяете, и не можете определить то ли это у вас маршрутизатор, то ли коммутатор…).

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

            Шаблоны, как вы говорите, это тоже хорошая тем, но это уже уровнем выше.
            Ладно, раз вы не хотите, придёться самому проект “Народной CMDB” замутить. Вот только не знаю на какой бы платформе. 🙂

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

              >”Все эти типы и атрибуты будут подходить для 90% случаев, да даже для 99%”

              Павел, мы о разном. “Подходить” в смысле предметной области – безусловно, есть же CIM например. “Подходить” в смысле для решения задачи заказчика – абсолютно не факт. Например, Вы опишите схему данных СХД. При этом у многих заказчиков не будет задач, связанных с таким детальным учётом СХД, а будут задачи инвентарного учёта и отображения влияния СХД на работоспособность систем. В том-то вся и фишка, что лучше всего стандартизируется атрибутный состав и это меньше всего для реализации CMDB в каждом конкретном случае.
              CMDB – это не база, в которой “есть всё”. Для реализации очень важно чёткое определить информационные потребности. Этим и сейчас не занимаются, а уж при наличии CMDB, претендующей на звание стандартной и вовсе перестанут. А ведь есть ещё вопрос конкретного ландшафта, на котором CMDB будет включать в себя другие источники и специализированные системы (например, запихивать сетевые дела вплоть до портов активного оборудования, трасс и розеток внутрь неспециализированной CMDB – не самый результативный путь).
              Так что это та самая благая дорога. Счастливого пути 🙂

              • Pavel Solopov

                Есть два подхода к разработке структуры CMDB.
                1. Начать придумывать её с нуля.
                2. Взять базовую (в которой описано всё по макисмуму) и отсечь лишнее, оставив то, что соответствует текущим задачам заказчика.

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

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

                  “Есть два подхода к разработке структуры CMDB”

                  Почему только 2 и почему именно эти? Например, Выше я предложил третий. Определяем информационные потребности и там, где опыт позволяет, применяем паттерны. И я уверен, что это лучше, поскольку в этом методе определение информационных потребностей – обязательный шаг, а в случае “взять всё и вычеркнуть ненужное” – нет. Чёткое знание информационных потребностей – CSF для CMDB. Стандартный атрибутный состав – нет.
                  Более того, в подходе с НСИ не очень понятна цель создания. Например, чем Вас не устраивает CDM и дополнительные “отраслевые” пакеты расширений модели данных? Что Вы хотите в Вашей модели сделать лучше? (Видите – опять разговор начинается с задачи, а не с метода решения)

                  • Pavel Solopov

                    К своему стыду не знаю, что такое CDM? и даже гугл мне в этом не помог. Видимо первое, что мне в нём надо улучшить, это узнать о нём. 🙂

                    Посему перейду к первой части вопроса. 🙂
                    Подход с паттернами никак не отменяет наличия “базового справочника” (давайте всё же говорить не про “стандартную CMDB”, поскольку это словосочетание может не верно трактоваться).
                    И уже тем более не отменяет определения информационных потребностей.
                    Паттерн, это шаблон, который вы накладываете на этот самый справочник, т.е. этот тот же самый способ выкинуть лишнее. Но ведь не факт, что данная ситуация идеально впишется в паттерн. Возможно вам потребуется его расширить и здесь вам поможет “базовый справочник”, как подсказка, какие ещё атрибуты и категории могут быть.

                    “Базовый справочник” это информация для размышления. Помощник, а не готовое решение.
                    Может быть действительно всё уже сделано до нас, вот вы мне сейчас ссылку на CDM кинете, посмотрю, может ничего и делать не надо.

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

                      Ссылки на CDM у меня нет, насколько мне известно в публичном доступе этих материалов нет. Это разработка компании BMC, которая представляет собой базовую модель данных Atrium CMDB. Модель содержит классы объектов и связей, с наследованием, с атрибутным составом. Неплохо документирована. Поспрашивайте своих коллег, наверняка у вас эти материалы есть.

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

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

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