Немного пиццы с доставкой в Минск

7 апреля 2016 компания Cleverics проводила в Минске деловую игру Grab@Pizza, участником которой мне посчастливилось стать.

Ниже хочу поделиться некоторыми наблюдениями по ходу игры и полученными результатами. наконец-то. Год прошёл))

Для начала пару слов о самой игре. В принципе, основная цель игры — получить понимание взаимодействия IT и бизнеса. Но для полной картины позволю себе привести выдержку с сайта Cleverics:

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

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

С точки зрения ИТ в игре создаются, реализуются, взаимодействуют, анализируются и совершенствуются следующие процессы ITSM: управление уровнем услуг, управление изменениями и релизами, управление инцидентами, управление проблемами, операционный мониторинг и контроль.

С точки зрения бизнеса Grab@Pizza — отличная возможность проверки лидерских качеств и организационных способностей.

Игра проводится в течение одного полного рабочего дня. Число человек в группе составляет от 8 до 12. Дополнительно до четырёх человек могут исполнять роль наблюдателей, которые не принимают непосредственного участия в игровых событиях, но могут видеть происходящее со стороны и в определённые моменты предоставлять обратную связь играющим. Всё время обучения (100%) можно отнести к практическим занятиям.

По ходу игры тренер делал пометки самых ярких высказываний участников, которые стали «выжимкой» всех полезных выводов, которые мы сделали за время игры.

Позволю себе немного анализа приведённого снимка.

 

  1. «А вдруг не будет«. Отменная фраза одного из участников, отвечавшего за… та-дааам, управление инцидентами)). Так вот нет. Будет. проверено игрой, да и на практике тоже. Если есть возможность защититься от каких-то рисков — это нужно сделать.
  2. «Какая вероятность что люди уволятся?«. Обсуждали момент связанный с тем, что на линию поддержки была очень высокая нагрузка и была вероятность того что не выдержат конечные исполнители и придётся понести определённые затраты связанные с поиском и адаптацией нового персонала. Что хочу сказать от себя. Если не справляется линий поддержки — ищите причины где угодно, но не на линии поддержки. Загружайте аналитиков, разработчиков, техническую службу. Не стоит бороться с ветряными мельницами и пытаться разгребать инциденты. В определённый момент становится критически важно иметь отлаженный процесс управления проблемами, и искать причины обращений, а не грузить специалистов линии поддержки.
  3. «SLA нужен? — Давайте через месяц«. Интересное наблюдение. В рамках игры (внимание, спойлер 🙂 ) данный вопрос ничего не решает. Но в рамках реального бизнеса очень даже актуален. SLA — это тот документ, в котором будут закреплены параметры предоставляемых услуг, а, следовательно, критерии оценки вашего подразделения. Когда в очередной раз придут жалобы на неудовлетворительный уровень услуг, SLA поможет отстоять свою правоту (если, конечно, параметры сервиса остаются в рамках соглашения) и избежать ненужных нареканий со стороны бизнеса. Чем раньше такой документ появится и будет согласован — тем спокойнее будет ваша работа.
  4. «Кто у нас в CAB? — По минимуму«. Вот тут в точку. Change Advisory Board, он же по-русски «совет по изменениям», номинальный (или реальный, и такое бывает) который помогает Change Manager-у принять решение о выполнении изменения и (или) авторизует его. В случае если CAB номинальный — туда должно войти настолько мало человек, насколько это необходимо, чтобы с высокой долей вероятности корректно авторизовать (или отклонить) запрос на изменение. Если орган этот в организации реальный (есть положение о совете, регулярно происходят заседания, закреплён секретарь, председатель и т.д.) то тут всё сложнее. Но тоже стоит избегать чрезмерного раздувания этого органа. Идеально — когда там будут присутствовать только владельцы бизнес-процессов самого высокого уровня и представитель от IT.
  5. «Вы же руководитель, у нас нет полномочий!«. Ну, тут вроде всё понятно. Есть ситуации когда определённые вещи должен делать руководитель подразделения, а не его линейные работники. Получить согласование на самом высоком уровне, принять решение по каким-то спорным вопросам — для этого руководители и нужны.
  6. «Это дорого, но мы всё равно возьмём«. В определённый момент встал вопрос о том, что наша собственная линия поддержки не справлялась и пришлось нанимать дополнительный персонал ос стороны (аутсорсинг) который разруливал бы часть запросов. Стоило это дороже содержания собственных специалистов, но после определённых расчётов пришли к выводу что лучше аутсорсингом пользоваться. Потому что стоимость простоя бизнеса в результате нерешённого инцидента выше стоимости аутсорсера. Поэтому, считайте, делайте выводы.
  7. «SLA на бизнес не влияет«. Ну, тут полностью не соглашусь. Потому что именно от этого документа зависит то, в каком объёме и качестве бизнес будет получать услуги от IT. Когда всё работает стабильно, и не происходит ничего экстраординарного, так и есть. Бизнесу всё равно, есть этот документ, или нет. А вот когда петух клюнет… Лично моё мнение, каталог услуг и SLA по каждому пункту — гарантия стабильных отношений между IT и основным бизнесом.
  8. «А сколько было инцидентов с диском продаж?«. Вопрос возник в момент принятия решения о необходимости проведения работ с диском продаж. Вопрос логичный. Если с оборудованием всё хорошо — лучше не трогать.
  9. «Аналитиков уволить, они создают слишком много работы». В рамках игры, так и есть. Да и в жизни частенько бывает так что аналитики находят узкие места процессов и предлагают варианты автоматизации, что приводит к повышенной нагрузке на разработчиков. Но тут уже совсем другая история. Потому что аналитики «зрят в корень» и видят проблемы на уровне процессов, а не конкретного рабочего места, поэтому часто их запросы имеют более высокую важность, чем запросы от рядовых пользователей.

На этом у меня всё. Если это кто-то всё-таки прочитал, буду рад обсудить и ответить на вопросы.

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

Ваш e-mail не будет опубликован.