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

Выступление Романа Журавлева на форуме ITM

На видеосервере YouTube появилась запись выступления Романа Журавлёва на прошедшем Форуме ITM. Этот короткий доклад уже разобрали на цитаты, поэтому мы разместим его здесь, на суд наших читателей:

Не надо увлекаться ИТ-услугами

А что думаете вы?

Кстати, интересующимся данной темой мы также можем предложить:

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

  • Последовавшие дискуссии показали, что части слушателей нужны дополнительные комментарии.

    Чтобы предотвратить/устранить непонимание, уточняю:

    1. Я не против сервисного подхода. Он передовой и полезный. Просто не все к нему готовы, и в частности – не все из тех, кто старательно его внедряет. Об этом см., например, здесь: http://www.realitsm.ru/2011/03/usluzhlivyj-podxod/ и здесь http://www.realitsm.ru/2012/04/eshhe-para-slov-o-strukture-it-uslug/
    2. Организация процессов ИТ-менеджмента не требует в качестве обязательного условия сервисной ориентации. Наводить порядок, сокращать затраты и контролировать риски можно и безотносительно услуг. От этого будет польза.
    3. Для того, чтобы наводить порядок, важно определить объект управления. Если таких объектов много, важно их каталогизировать. Это может быть каталог услуг, а может – каталог систем, каталог ресурсов…
    4. Если мы таки собрались управлять именно услугами, очень важно разобраться с тем, что они такое. Об этом недавно было написано здесь: http://www.realitsm.ru/2012/05/mnogolikie-uslugi-chego-izvolite/
    5, самое главное. Решение о реализации сервисного подхода в отношениях ИТ и бизнеса – сложное, рискованное и недешевое. Принимать его надо осознанно, на трезвую голову, и решающим аргументом в его пользу точно не может быть публикация каких-либо слов в каких-либо книжках. Собственно, именно об этом я говорил на форуме.
    6. Чтобы никто не обижался: в презентации на каждом (почти) слайде упоминается некое “большинство компаний”. Это, разумеется, не ваша компания. Это другие. У вас, скорее всего, все хорошо и правильно.

    • Лучше и не скажешь.

      Я рад, что ты работаешь именно в нашей компании 🙂

    • Grigory Kornilov

      Если вы, будучи “специалистом\консультантом\опытным внедренцем” можете понять что (не)подходит компании – значит у вас должна появиться “услуга\вид деятельности”:
      “Консультация\оценка\подготовка ТКП” по “готовности\стоимости\возможных результатов” для компании к внедрению SM как в целом, так и в отдельных частях\процессах ITIL\COBIT.

      • есть такая услуга.
        http://www.cleverics.ru/ru/services/assessment

        • Grigory Kornilov

          Хорошо, увидел:
          “Предложения по развитию обычно формулируются в виде целевой программы (последовательности проектов) с определёнными целями и задачами, ключевыми результатами, основными ограничениями, оценкой сроков реализации.”

          Этот результат содержит в себе предложения\офферинги по внедрению\реализации целевой программы или ее части?

          Например, если в отчете будет сказано – “Рекомендуется внедрение за пол года в таком-то виде, что позволит сделать то-то”, то может ли на основании этого компания начать контрактовать проект по внедрению предложений сразу или потребуются существенные дополнительные переговоры\исследования\уточнения?

          • Григорий, мы всегда стараемся быть как можно более конкретными. В моей практике был случай, когда ровно по предложенной по итогам обследования программе и шло контрактование и выполнение проектов, причём несколько лет. С другой стороны, далеко не всегда рекомендация проведения тех или иных работ значит “позвать внешнего исполнителя”.

    • Вадим

      не могу не озвучить пару своих мыслей:
      – плохо организованный менеджмент в ИТ не спасет переход на оказание услуг (т.е. типа “сервисный подход”), соответственно, думать об этом можно лишь начиная с определенного уровня зрелости.
      т.е. в “плохом” случае замена на ITSM не поможет. тут бы надо “вопросы гигиены” сначала решать.
      – достаточно хорошо организованному менеджменту совсем необязательно переходить на оказание услуг (в терминах сервисного подхода), не столь важно, что при этом у него несколько другие объекты (а возможно и способы) управления и по-другому определены роли.
      важно: достигает ли этот подход установленных целей? как в том анекдоте: “работает – ничего не трогай”.
      а вот когда цели меняются, то тут и начинается….

  • Роман, думаю, что у тебя есть большое и правильное желание оценивать ВСЕ с “вершин” сервисного подхода.
    1. Да, достичь совершенства трудоемко и дорого… НО, даже простая таблица, которая помогает понимать бизнесу, ЧТО делает ИТ-подразделение, – крайне ВАЖНА. Именно это и есть первый шаг на правильном пути.
    2. Как всегда, ты очень хорошо выступил и твое выстуление было последним в секции и я думаю, что было велико “искушение взбодрить” слушателей и привлечь внимание. Тебе это удалось, НО, “горячиться НЕ надо…” :-(. Услуга – это полезно и нужно :-).
    3. Здорово, “разбирать на читаты” красивое выступление. Фильм, “Операция Ы и другие приключения Шурика”, то же разобрали на цитаты… 🙂

    • отчего-то не получилось устранить непонимание 🙁
      Владимир, я написал пп.1, 3 и 5 в первом комментарии к этой публикации по мотивам дискуссии, которая возникла у нас с вами сразу после моего выступления. В частности, п.3 – как раз про простую таблицу, которая помогает понимать. Но самый важный – п.5.

      Есть компании, в которых нет бизнес-кейса для организации сервисных отношений между бизнесом и ИТ. У нас в стране таких компаний много, рискну еще раз сказать, что их большинство. Для них попытки управлять услугами – это ускоренный бег на месте. Они не способны к культурным изменениям, необходимым для ориентации на клиента, они не способны интегрироваться в бизнес-процессы, они не способны управлять полным жизненным циклом услуг… в общем, вы слышали и видели презентацию, зачем повторяться. Они не способны и чаще всего не нуждаются. Поэтому строить каталоги, заключать SLA и назначать service owner’ов в этих компаниях – бессмысленно. Как “бессмысленно внушать представление об аромате дыни человеку, который годами жевал сапожные шнурки” (с) С. Довлатов “Соло на ундервуде”

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

      • NB: После прочтения этого комментария настоятельно рекомендуется перечитать п.6 выше. Nothing personal…

  • Максим Тищенко

    Я один из критиков Вашего доклада. И не разделяю позицию вот почему – вопрос не в том как в катологе сервисов/систем или еще чего то там называется – важна цель деятельности, если нас интересуте работает или не работает сервер или прикладная софтина это одно, но если нас интересует есть какая то польза от этого сервера или этой софтины это и есть уже сервисное мышление, а уж как оформленно это всего лишь вопрос пройденного пути. Вот в наличие такого понимание и весь секрет, тогда и все внутренние процессы будут выстраиваться под эту цель. А так раньше смеялись над функциональным подходом – к пуговицам притензии есть?, так же можно смеяться и над процессным подходом – можно бегать с инцидентами, только идет ли это на пользу…

  • Есть формальная сторона сервисного подхода, есть культурная. Об этом уже писал Дмитрий в посте про услужливый подход.

    Если смотреть с формальной стороны сервисного подхода я полностью согласен с докладом Романа. Есть множество примеров проектов, где “внедрение сервисного подхода” начиналось и заканчивалось набором документации по своей сути бесполезной. Более того, если люди не готовы к культурным изменениям, то заморочки в виде «Сервисного подхода» для них вредны.

    Если смотреть с культурной стороны сервисного подхода, то с докладом я не согласен. Мы всегда должны стремиться приносить пользу нашим заказчикам и понимать, что есть польза для них. Но мне почему-то показалось, что в докладе речь идёт о формальной стороне вопроса.

    Считаю, что для культурного подхода не обязательны все те артефакты, которые продают консультанты и космические книжки. Главным фактором успеха всё равно остаются люди.

    Вот два реальных примера культурного подхода на мой взгляд:

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

    2. Компания Сандвик http://en.wikipedia.org/wiki/Sandvik, больше 10 лет развивает у себя ITSM, были у них на рефернс визите. Смотрели организацию каталога услуг, процесса управления финансами и построение ИТ билинга. В ходе обсуждения углубились в SLM. Так на просьбу продемонстрировать соглашения об уровне услуг, они очень удивились, а затем удивили нас. 🙂 У них нет никаких формальных соглашений. Они уверены, что каждый их ит специалист работает на благо компании, что он понимает как его работа приносит ценность бизнесу компании, что никакие соглашения и контроли им не нужны.
    За 10 лет, не было никаких серьёзных конфликтов с ИТ(по их словам). У меня это до сих пор не укладывается в голове, они кстати назвали это менталитетом. 🙂 Для меня это яркий пример сервисного подхода с точки зрения культуры.

    • То, что крупные шведские компании уровня Sandvik (не все, конечно) порой работают без SLA – могу подтвердить по собственному опыту.
      А отсутствие серьезных конфликтов с ИТ внутри компании действительно заслуга менталитета и бизнес культуры, и вовсе не является индикатором пользы сервисного подхода или свидетельствует о высоком уровне развития ITSM вкомпании.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM