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

Новая процессная модель?

Опубликовано 20 августа 2014
Рубрики: ITSM, Практика и опыт, Процессы
Комментарии

Все побежали, и я побежал.
Из известного советского к/ф.

Работая на рынке обучения по управлению ИТ и процессного консалтинга вот уже 10 лет, мы не могли не задуматься о том, как лучше объяснить себе и другим людям, как, собственно, устроено управление ИТ.

Разумеется, существует изрядное число различных процессных моделей, но, на наш взгляд, все они имеют те или иные недостатки. Поэтому ни N процессов ITIL (20<N<30, никто не знает, сколько точно), ни 34, а теперь уже 37 процессов COBIT нам в качестве ответа не годились. Были свои сложности и с проприетарными моделями от таких уважаемых вендоров как Microsoft, HP, BMC, IBM и ряда других.

Поэтому в 2011 году, будучи под впечатлением от eTOM, использованного нами в качестве процессной основы для создаваемой системы управления в телеком-операторе, мы начали первые эксперименты с формированием структуры своей процессной модели. В 2013 году мы познакомились с ISM, но и это знакомство не отменило нашего желания продолжать идти своим путём. И вот весной 2014 года при помощи ряда обстоятельств былые мысли оформились в некоторый результат (см. картинку).

sms

Получившаяся картинка сложнее, чем мы предполагали в начале пути, но структурнее, чем ITIL, проще, чем COBIT, целостнее, чем ISO 20000, упомянутые проприетарные модели и даже (на наш взгляд) – ISM. Постепенно размышляя о том, что получается, и делая первые пробы применения нашей модели на практике, мы видим, что у неё есть будущее.

А, задумавшись о будущем, я сформулировал два важных вопроса к коллегам-профессионалам:

  • Актуальна ли для вас целостная процессная модель или в вашей практике пока достаточно перечня 4-5 базовых процессов?
  • Если актуальна, на какие процессные модели вы сейчас опираетесь, и что вас в них не устраивает?

Что скажете, коллеги?

ОБУЧЕНИЕ
IT Service Management
Учебные курсы от соавторов ITIL 4

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

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

  • Nargiza Suleymanova

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

    P.S. Получилось здорово 🙂

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

      Наргиза, здравствуйте! Спасибо за тёплые слова 🙂

      динственное пожелание- увидеть небольшое описание каждой плиточки.

      Честно говоря, материала, готового к публикации, у нас пока нет. Есть понимание, что где, что с чем связано, есть внутренние черновики.

      Скажите, пжл, а зачем Вам описание плиточек, чтобы ответить на заданные мной вопросы? 😉

      • Nargiza Suleymanova

        Дмитрий, вы уж простите, что на собственно вопросы не ответила 🙂

        Кратко отвечу:

        1. Актуальна

        2. Удалось построить свою собственную модель (правда, название "модель" не совсем подходит для этого коллективного "творчества"), сочетающую в себе услуги, процессы и чуточку проектов- но это индивидуальная схема для конкретной компании с учетом именно наших особенностей. Модель далеко не идеальна, но на текущем этапе решает задачу единого представления того, что у нас происходит и как с этим жить 🙂

        P.S. С вами лично могу поделиться, на суд общественности выносить не готова.

  • Александр

    Cobit 5 – наше всё!

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

      Александр, Вы, в том числе, используете COBIT 5 для организации процессов – в качестве структуры системы управления ИТ? Как? Расскажите, очень интересно!

      • Александр

        Мы профессионально занимаемся оргстроительством и реформированием. В том числе (но не прежде всего!) в сфере ИТ. Оргпроектирование и постановка системы регулярного менеджмента – задачи совершенно не ИТ-шные, поэтому ИТ-шникам заниматься ей противопоказано. ИТ-шники, и прежде всего профессиональные системотехники (а как же!), начинают применять несвойственные подходы, начинают проектировать структуры. Но первичны процессы. А следовательно можно наладить поцессы практически в любой структуре. Это не означает, что нужно отказаться от структурных изменений тогда, когда это разумно. Но в большинстве случаев это не нужно. Строится дерево целей/задач/функций, выводятся нужные процессы, строятся матрицы ответственности и т.д. Или я вопрос неправильно понял?

        Но Cobit 5 – безусловно наиболее продуманная модель. Заказчики, конечно, находятся на таком уровне зрелости, к сожалению, что воспринимать могут только максимальные абстракции, типа представленной в данном материале. Не могу не согласиться. Но мы в своей работе отталкиваемся от базовых процессов, перводя их в нужную абстракцию только если требуется. К счастью, благодаря вашим усилиям, подготовленных клиентов становится все больше с годами. Низкий поклон!

  • АНдрей

    Любая деятельность осуществляется в виде процессов. Для обсуждения и анализа процессов нужен определенный язык, понятный всем участникам обсуждения. Обычный "человеческий" язык для этого не подходит в силу его низкого уровня формализации – одна и та же фраза понимается людьми по-разному, иногда сильно по-разному. Поэтому были разработаны методики анализа процессов (SADT)  и соответствующие нотации (IDEFx).

    Целостная модель – Уровень детализации целостной модели должен быть достаточным для осмысленного обсуждения. Пример – когда консультанты спросили Ю.В.Ипатова о том, какой уровень детализации ему нужен, то он ответил: хотя бы такой, чтобы я мог отличить процессы на птицефабрике от процессов на металлургическом комбинате. В отношении целостной модели есть еще одно замечание – пока вы её строите(описываете через построение модели) она перестает быть актуальной. Единственный выход здесь – использовать BPM системы, желательно поддерживающие BPMN 2. Но и тут не всё слава Богу. Эта нотация слабо пригодна для анализа.

    На какие процессы опираемся – на существующие, поскольку еще ни разу не приходилось что-то организовывать с нуля. Сам ITIL, к стати, не есть результат эмпирического познания. Авторы исследовали деятельность множества ИТ подразделений и обобщили полученные знания в виде единого документа. К стати, описания процессов в его классическом понимании там нет. А жаль. Есть процесс, он в общем должен делать нечто и взаимодействует с другими процессами. Как он должен  это нечто делать(реальный алгоритм)? какого рода взаимодействие – вход/управление/механизм? об этом авторы кокетливо умалчивают.

    • Антон

      Вы даже в понятиях путаетесь. 

      Эмпирически – как раз и значит, что получены знания путем опыта, эксперимента.

  • Альберт

    Целостная процессная модель не актуальна, жизнь меняется гораздо чаще. Можно конечно брать за основу что то вроде http://www.isaca.org/Blogs/829445/Lists/Photos/635254340234635393.jpg

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

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

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

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

    Ни в коем случае не умаляю проделанную Вами работу – она элегантна, но я бы предложил Вам попробовать вот какой  подход:

     в создаваемой системе всегда делать уникальную цепочку добавленного качества для основной деятельности (смысл существования системы – её предназначение – её основной продукт), а

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

  • Alexander Zhilinsky

    В целом очень неплохо! Правда, я бы "разработка и внедрение" всегда называл бы "развитие" и относил бы туда много как перечисленных плиточек, так возможно выделял бы и другие (бэктрекинг, тестирование, приемка). Управление изменениями недостаточно полно, если понимает управление изменениями в объеме ITILv3.

    Только хотел позудеть – что почти 3 года прошло (пока я внимательно не читал материалы), а за 3 года ничего кардинально нового не появляется, нет же смысла в очередной раз обсуждать отличия проблем от инцидентов, а стандартных запросов от изменений, и где располагается управление рисками 8)

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

      так возможно выделял бы и другие (бэктрекинг, тестирование, приемка). Управление изменениями недостаточно полно, если понимает управление изменениями в объеме ITILv3.

      Верно, это внутри CHG, но это, по-существу – мета-процесс. Там внутри и управление требованиями, и планирование и сборка релизов. При этом выделять все подобные куски на верхнем уровне мы не видим смысла (это усложнение и это меняется от организации к организации).

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

      Только хотел позудеть — что почти 3 года прошло (пока я внимательно не читал материалы), а за 3 года ничего кардинально нового не появляется

      Саша, а как же это: http://www.realitsm.ru/2014/06/standard-itsm-integration?

      • Alexander Zhilinsky

        Не читал, но одобряю! 8)

        А тянут ли на глобальный методический прорыв такие узкоспециальные вещи? Все-таки, вряд ли. По мне, так правильный практический методика\подход внедрения ITSM для средних\малых предприятий гораздо больше на звание прорыва подходит.

  • Сергей Гузик

    Добрый день!

    Дмитрий, для нас процессная модель всегда актуальна.

    Для создания процессной модели для Заказчиков опираюсь на CobiT "цели бизнеса цели ИТ – процессы" (отбор процессов в процессную модель). Никогда не получалось отобрать все (34)37, да и как говорит нам Приложение 1 – не нужно это. Отобранные процессы проверяются на наличие поддерживающих, которые тоже включаются в процессную модель и к отобранным процессам обязательно добавляю несколько, которые нужны для успеха внедрения (управление работами, управление качеством, управление регламентными работами, при необходимости: управление доступом, управление событиями …).

    Состав выбранных на схему процессов комментировать не хочу 😉 верю, что какому-то Заказчику этот состав подходит на 100%, Заказчику с другими бизнес целями потребуется другой набор процессов. В качестве "малого джентельменского набора" консультанта с которым можно безпроигрышно начинать различные проекты, скорее не соглашусь:

    – Этот набор точно "не малый", а очень большой набор для первого-второго этапа внедрения? Будет ли разделение на ядро и "обвес"?

    – Хотелось бы увидеть бизнес цели которые эта процессная модель закроет (сопоставить затраты на процессную модель – охват бизнес целей)

    Не нашел как присоединить файл, перечислю "ядро" процессов в нашей типовой процессной модели:

    – Управление проектами

    – Управление уровнем услуг

    – Управление обращениями и заявками

    – Управление событиями и инцидентами

    – Управление изменениями

    – Управление регламентными работами

    – Управление работами

    – Управление качеством услуг

    – Управление конфигурациями и документацией

    Остальные процессы идут в дополнение к ядру.

    • Alexander Zhilinsky

      ++, Сергей, мне очень нравится вопрос о бизнес-целях

      ps. единственное, опять же – все кто занимаются эскплуатацией, делают акцент в процессах на эксплуатацию. А охват "типового" управление изменениями не покрывает и малой части работ по софту, закидывать это все в управление проектами плохо – нужно некое "управление развитием"

      • Сергей Гузик

        Александр, полностью соглашусь по Изменениям и Софту. Управление развитием – это управление портфелем проектов или что то шире? 

        Сейчас очень необычные процессные модели получаются для компаний, в которых некоторые подразделения используют Agile принципы при разработке ПО. Увязывание в одной процессной модели различные подразделения Компании в которых используются разные методологии разработки, а так же есть "классические" эксплуатация и проектное управление, есть не ИТ услуги, есть требования рынка и регуляторов, и все это направляется некими принципами Руководства …  

        • Alexander Zhilinsky

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

          Дима, как я понял, в своей модели считает, что это в Change и наверх выносить не стоит, дабы не усложнять. По мне, так от заказчика зависит – и быстроразвивающиеся заказчики по опыту всегда имеют сложную разработку\развитие (свою или у подрядчика, не важно).

          Кстати, как раз софтовый Agile дает современный подход к разработке и внедрению – один из вариантов набора процессов условного "управления развитием", куда входит управление проектами как прикладной процесс управления именно проектами, а не разработкой.

           

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

            Дима, как я понял, в своей модели считает, что это в Change и наверх выносить не стоит, дабы не усложнять. По мне, так от заказчика зависит

            Просто в крупной компании Change вряд ли может быть одним процессом – всегда, в завимости, от предметной области, будут или подпроцессы или разные CHG-модели. Именно потому, что разработка существенно отличается от внедрения или изменения на уровне десктопов. Вот я и считаю, что выносить "потроха" CHG наверх не стоит – они все равно будут справделивы только для части активностей по управлению изменениями.

  • Александр Тараторин

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

    Ну и еще одна придирочка – ну почему "планирование архитектуры", а не "управление архитектурой"?

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

      Александр, рад Вас видеть!

      Поддержу ряд коллег…

      Коллеги удивительным образом игнорируют мои вопросы и задают свои. Ну давайте хотя бы "баш на баш"? 🙂

      которые намекают на недостаточность раскрытия темы ИТ развития

      Ну вот мне так не кажется. Может быть по неопытности. Сам поток работ по развитию – конечно, есть. Долгосрочное планирование – через ИТ-стратегию (хотя для данной модели это вход, а не результат исполнения внутреннего процесса, но для такого дизайна у меня есть основание). Среднесрочное планирование – в процессе 4. В терминах райфовской операционной модели – это почти в чистом виде Demand. Краткосрочное планирование – внутри CHG, который для разработки будет включать в себя цепочку Requirement mgmt, Development mgmt, Release mgmt, Deployment mgmt. Упомянутое тестирование – как обычно – в Release mgmt (квалификационное тестирование) и Deployment mgmt (приёмочное тестирование). Если изменение крупное, будет еще и проектирование, но это традиционно – часть PJM.

      При этом я не вижу смысла вытаскивыть эти составные части по разработке на верхний уровень. Мне больше нравится "спрятать" их в CHG, потому что CHG для разных предметных областей (дорабтки ИС, ЦОДы и сети, ПК, процессная регламентация и так далее) неизбежно будет разным. Эта разность будет выражаться либо в различных моделях изменений (если разница невелика), либо в различных подпроцессах в составе CHG (если разница более существенна). Но все это по сути – CHG.

      ну почему "планирование архитектуры", а не "управление архитектурой"?

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

      • Александр Тараторин

        Здесь скорее вопрос расстановки акцентов. В Change management вообще можно включить очень много разнообразного. Но если организация тратит порядка 40% бюджета ИТ на развитие (а таковы "лучшие" практики, на которые нам любят указывать консультанты), то запихивать всю деятельность внутрь одного очень универсального процесса по меньшей мере… неуважительно, что ли.

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

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

          Но если организация тратит порядка 40% бюджета ИТ на развитие, то запихивать всю деятельность внутрь одного процесса по меньшей мере… неуважительно, что ли.

          Возможно, Вы правы. Но тогда и Operations mgmt, который относится к оставшимся 60% бюджета, тоже придётся "разваливать" на отдельные составляющие 😉 Так можно думать, но для меня сейчас не принципиально – раскрывать или нет. Важнее, что у нас нет противоречий не по форме, а по содержанию.

          Но ещё важнее – получить ответы на свои вопросы:

          1. Актуальна ли для вас целостная процессная модель или в вашей практике пока достаточно перечня 4-5 базовых процессов?
          2. Если актуальна, на какие процессные модели вы сейчас опираетесь, и что вас в них не устраивает?

          Собственно, ради этих ответов и был написан пост. Александр, Ваше мнение особенно ценно. Каково оно?

          • Александр Тараторин

            1. Актуальна ли для вас целостная процессная модель или в вашей практике пока достаточно перечня 4-5 базовых процессов?

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

            2. Если актуальна, на какие процессные модели вы сейчас опираетесь, и что вас в них не устраивает?

            Используем свою. Все классические варианты как правило либо очень сложные, либо имеют другой фокус. Для того чтобы модель была позитивно воспринята аудиторией, ее надо подогнать под ожидания людей.

  • Станислав

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

    Для нас актуальна общая процессная модель по многим причинам, начиная от банального желания видеть целостную картину, чтобы ничего не упустить из виду, до таких практических моментов, как определение верхнеуровневых ответственных за процесс (владельцев), поскольку попытка группировки процессов позволяет легче определить наборы смежных процессов. Кроме того, общая картина способствует более легкому определению и обсуждению границ процесса, точек их соприкосновения и ролей. По поводу самой модели я бы сказал так: используем свою доморощенную, которая в детстве очень хотела стать космонавтом ITIL. Внутри она больше похожа на ITIL, но как мы недавно выяснили, верхнеуровнево на нее удобнее смотреть по примеру 5 групп из ISO20К, который, как многие вспомнят, во многом основан на ITIL. Возможно именно из-за этого все так удобно сложилось.

    Как общий комментарий к вопросам озвучу такую мысль: есть подозрение, что необходимость общей модели возникает не столько при наличии некоторого «критического» количества процессов (хотя конечно и это может стать триггером), сколько при определенном уровне зрелости даже небольшого кол-ва процессов (может быть и 4-5), особенно, если они имеют взаимодействие (например Event-INC-CHG или PRB-KNW). 

  • Наталия

    Дмитрий, добрый день. Возможно, немного припозднилась с ответом, так как только сегодня увидела эту тему, но все же отвечу.
    1. Для меня лично актуальна именно целостная модель. Так уж совпало, что последние несколько дней занимаюсь именно этим, рисую по возможности целостную модель. Эта тема в моей работе всплывает уже несколько лет, с той или иной стороны. Именно целостная модель, на мой взгляд, нужна потому, что если организация оказывает ИТ-услуги, то перечень (набор) процессов управления услугами будет одинаковый на 99.9%. Просто уровень зрелости и сложность у них может быть разная. Некоторые процессы могут быть и не формализованы совсем, вырождены до пары функций, выполнятся так, между прочим, но ОНИ ЕСТЬ. Для меня эта тема актуальна, так как моя цель – выстроить комплексную полноценную систему управления услугами в своей организации. Считаю, что и в арсенале настоящего консалтера такая модель однозначно должна быть.
    2. При разработке своей процессной модели я опираюсь на: ITIL3, MOF 4, COBIT 4 (5-й еще толком не пропустила через себя), Собственный опыт работы в ИТ (в различных должностях и сферах), Здравый смысл.
    В принципе, мне все модели нравятся, как справочный материал. В MOF 4, например, нравится, что выделен уровень процессов, которые взаимодействуют со всеми этапами ЖЦ услуги (он там уровнем управления называется), и в ITIL, и в Cobit свои плюсы есть. Мне, например, они помогают посмотреть на деятельность по управлению услугами с разных сторон. И вот здесь хочу высказать одну свою ценную банальную мысль: при построении процессных моделей все зависит от точки зрения того, кто модель строит и кто на нее смотрит. Если товарищ больше технарь – один расклад, если управленец – другой. Если управленец-«производственник» – свой взгляд, если управленец – «финансист» – опять же свой. Мне кажется, что указанные модели потому и не могут устроить «в чистом виде», что они с одной стороны несколько «однобокие», так как у создателей вероятно была определенная концепция с какой стороны они должны это отобразить, а с другой стороны они несколько противоречивы, так как это труд массы специалистов со своими точками зрения. Хотя возможно, эти противоречия возникают из-за вольностей перевода и если читать в оригинале, то все ок.

    P.S. Честно скажу, не знаю можно ли сделать одну единственную процессную модель и использовать ее во всех контекстах и разных точках зрения, но очень хочется. А потому попробовать приблизиться к идеалу (насколько позволит кругозор и опыт) можно и нужно . Не мир спасти, так свои собственные задачи решить. А посему идею вашу поддерживаю, жду публикации «внутренних черновиков».

  • Наталия

    Дмитрий, забыла упомянуть вашу процессную модель “Взаимосвязи процессов Cobit 4.1”, которая на вашем сайте размещена. Хорошая модель, однозначно дополняет Cobit 4.1.

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

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

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