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

Референтные визиты по ITIL

Мне, как далекому (увы) от средств автоматизации ITSM человеку, позволительно предположить, что  из всех частей ITIL самой важной для ИТ-специалистов является седьмая: Technology considerations – «Думы об автоматизации».  

Авторы пяти книг библиотеки фантазируют об этих самых автоматических процессах и услугах сильно по-разному. Тем не менее, если вы хотите быстро (за 5-10 страниц) понять, о чём же написана конкретная книга ITIL, и как написанное может выглядеть «на вашем мониторе», то смело открывайте Chapter 7 и читайте функциональные требования, рассматривайте  архитектуру решений и вдумывайтесь в рекомендации.

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

Я споткнулся лишь на одном из этих советов-практик. Буквально пол-абзаца (перевод и подчеркивание мои):

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

Как хотите, а я не могу представить себе референтного визита без присутствия представителей вендора или реселлера.

Догадываюсь, что многие читатели и авторы этого портала занимаются автоматизацией ITSM. Как, по вашему мнению: подчеркнутая практика «хорошая» или «лучшая»?

Реестр ESM- и ITSM-систем в России 2024
Из чего выбирать и на что мигрировать

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

  • Andrey Kapustin

    Наверно все-таки “лучшая”…

  • Pavel Solopov

    Если вендор готов организовать вам референс, да ещё и без своего участия, то вероятность услыщать какой-то негатив мала. Либо решение реально сильное, либо заказчик задобренный.
    Поэтому, если хотите получить реальную картину, надо организовывать референс подпольно.
    Вот, кстати, совершенно пустая ниша на рынке: Подпольные референс визиты. 🙂

  • zw

    Неправильно всё это. Надо внедрять агентуру к заказчику в ITSM отдел:D

  • Константин, ну почему же трудно? Мы с прошлого года стараемся использовать именно такие практики. Не массово, но идем в эту сторону.
    Отмечу при этом, что далеко не все клиенты готовы на вот такие самостоятельные визиты по незнакомым закоулкам.

  • Анатолий Павлюченко

    Цель данной рекомендации – достижение максимальной объективности. Если вы, как заказчик, можете получить _желаемую_ объективность в присутствии вендора и/или продавца – нет проблем. Всё зависит от степени доверия.

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

    • Анатолий, и как вел себя ваш заказчик в присутствии “коллеги”? Жаловался? Хвалил?

      • Анатолий Павлюченко

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

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

    • Анатолий Павлюченко

      1. [Внедренец стимулирует] Заказчик стимулирует Вендор стимулирует Демонстратор. Естественно, подготовка нужна.
      2. Прямые контакты – это очень хорошо, но, если их нет, то референс-визит позволяет получить ответы на вопросы с бОльшей объективностью.

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

    • Дмитрий, а кто такой ИТ-управленец? Если вы об уровне CIO, то это не по моей теме.
      CIO вообще не особенно заинтересован в удобстве и практичности инструмента и обычно в нем не разбирается. Ему интересно получить объективную управленческую информацию (отчёты, по-русски). А как она создаётся – его не должно волновать и обычно не волнует. Пусть подчиненныем (CIO-1, CIO-2) хоть руками рисуют статистику, до тех пор, пока не взвоют или не наврут.
      То есть в ходе контактов на таком уровне, обмен случится только подобными исключительными негативными ситуациями.

      • Думаю, инициация ITSM-проекта вообще и выбор ITSM-решения в частности влияет далеко не только на механизм формирования отчетности. Обычно в крупных компаниях этим занимается уровень CIO-1. А в небольших все зависит от того, что выбирают: если продукт, то CIO-1, если решение управленческих задач (бывает и такое), то больше CIO лично либо его зам.
        И нормальные контакты на этом уровне у ИТ-руководителей есть, особенно в пределах отрасли. Я, например, много раз сталкивался с такой реакцией, когда рассказывал о проектном опыте. Сразу спрашивают а там вы что конкретно делали? Понятно, ну я спрошу у такого-то. А там? Понятно, спрошу. И т.д. То есть эти связи есть и их использование, я думаю, даст больше, чем хорошо организованный поставщиком или плохо организованный покупателем референс-визит. Хотя, конечно, всегда есть исключения.

  • Grigory Kornilov

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

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

    Имхо можно рекомендовать следующее:
    1. Оценивайте то, что уже эксплуатируется более 2 лет. При этом общайтесь с широким кругом вовлеченных без ссылок на желание оценить ПО\внедренца\заказчика.
    2. Оценивайте текущее качество бизнес процессов по своим критериям.
    3. Полагайтесь больше на лично собранную информацию, факты … мнение\эмоции вендора\заказчика отделите.

    • Григорий, спасибо, советы реально дельные, особенно про два года после внедрения. У меня такое же ощущение.
      Только вот провести такие собеседования и лично собрать информацию получится только у парня “под прикрытием” (как выше написал уважаемый ZW).

    • “Оценивайте то, что уже эксплуатируется более 2 лет”

      А на мой взгляд это реально спорный совет. Вернее так – зависит. Сами посудите, что пытаются оценить на референс-визитах? В основном 2 вещи: продукт и поставщика.

      Если эти два года та же компания-внедренец осуществляет сопровождение клиента, то возможно вам удастся оценить поставщика (опуская тезис про серьезный личный вклад в услуги и то, что вам, весьма возможно достанутся другие люди, раз эти “не вылазят” из этого клиента). Но продукт – только если он два года не очень развивался, иначе вы уже оцениваете конкретную систему, которая от исходного продукта могла уйти очень далеко. И опять же с оговорками, ведь за эти два года могло выйти 2-3 новые версии, существенно отличающиеся от того, что вы увидите. Но если он два года не очень развивался, вы не оцените поставщика 😉

      Поэтому если идти на референс-визит, собирая информацию о поставщике, я бы шел в компанию, которая завершила проект внедрения недавно (3-6 месяцев). То есть уже и “ценность рецептов консультанта” проверена, и впечатления от работы с ним не остыли. Если же вы хотите собрать информацию о продукте, лучше идти в те компании, в которых возник сильный внутренний центр компетенции по этому продукту, но при этом не сильно отставших по версии от актуальной версии продукта.

      • Grigory Kornilov

        Дмитрий,

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

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

        Я не очень понимаю кто есть поставщик в вашем понимании (вендор продукта, продавец продукта, внедренец и далее саппортер внедренного решения). Но тут как раз возникает момент – что вы считаете ожидаемым результатом покупки\внедрения продукта.

        Зачастую заказчик подразумевает, что результат проекта это
        1. не только использование функциональности коробочного продукта
        2. и даже не только использование функциональности заточенного коробочного продукта на время реализации (пол года) работ по договору внедрения
        3. но и результат развития\эксплуатации внедрения в среднесрочной перспективе (что есть имхо 2 года) с заключением дальнейшей поддержки со стороны внедренца или собственными силами.

        Я бы советовал быть заказчиком с позиционированием по проекту согласно п3 и согласовывать эту позицию с вендором\внедренцем\руководством при подготовке\заключении договора на внедрение решения.


Добавить комментарий для zwОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM