7 апреля 2016 компания Cleverics проводила в Минске деловую игру Grab@Pizza, участником которой мне посчастливилось стать.
Ниже хочу поделиться некоторыми наблюдениями по ходу игры и полученными результатами. наконец-то. Год прошёл))
Для начала пару слов о самой игре. В принципе, основная цель игры — получить понимание взаимодействия IT и бизнеса. Но для полной картины позволю себе привести выдержку с сайта Cleverics:
Команда управляет ИТ-департаментом одного из крупнейших в мире производителей пиццы. Участники должны обеспечить поддержку основного бизнеса с помощью ИТ-услуг высокого качества. На рынке, где работает компания, сильна конкуренция, что заставляет бизнес разрабатывать новые продукты, выдвигать маркетинговые инициативы, и особенно внимательно следить за операционной деятельностью, затратами и качеством. ИТ играет важную роль в возможности основного бизнеса достигать своих стратегических целей.
ИТ-команде необходимо управлять отношениями с основным бизнесом, понимая его потребности, и организовывать возможности ИТ так, чтобы компания могла получать максимальную прибыль, занимать существенную долю рынка и сохранять высокую степень удовлетворённости клиентов.
С точки зрения ИТ в игре создаются, реализуются, взаимодействуют, анализируются и совершенствуются следующие процессы ITSM: управление уровнем услуг, управление изменениями и релизами, управление инцидентами, управление проблемами, операционный мониторинг и контроль.
С точки зрения бизнеса Grab@Pizza — отличная возможность проверки лидерских качеств и организационных способностей.
Игра проводится в течение одного полного рабочего дня. Число человек в группе составляет от 8 до 12. Дополнительно до четырёх человек могут исполнять роль наблюдателей, которые не принимают непосредственного участия в игровых событиях, но могут видеть происходящее со стороны и в определённые моменты предоставлять обратную связь играющим. Всё время обучения (100%) можно отнести к практическим занятиям.
По ходу игры тренер делал пометки самых ярких высказываний участников, которые стали «выжимкой» всех полезных выводов, которые мы сделали за время игры.
Позволю себе немного анализа приведённого снимка.
- «А вдруг не будет«. Отменная фраза одного из участников, отвечавшего за… та-дааам, управление инцидентами)). Так вот нет. Будет. проверено игрой, да и на практике тоже. Если есть возможность защититься от каких-то рисков — это нужно сделать.
- «Какая вероятность что люди уволятся?«. Обсуждали момент связанный с тем, что на линию поддержки была очень высокая нагрузка и была вероятность того что не выдержат конечные исполнители и придётся понести определённые затраты связанные с поиском и адаптацией нового персонала. Что хочу сказать от себя. Если не справляется линий поддержки — ищите причины где угодно, но не на линии поддержки. Загружайте аналитиков, разработчиков, техническую службу. Не стоит бороться с ветряными мельницами и пытаться разгребать инциденты. В определённый момент становится критически важно иметь отлаженный процесс управления проблемами, и искать причины обращений, а не грузить специалистов линии поддержки.
- «SLA нужен? — Давайте через месяц«. Интересное наблюдение. В рамках игры (внимание, спойлер 🙂 ) данный вопрос ничего не решает. Но в рамках реального бизнеса очень даже актуален. SLA — это тот документ, в котором будут закреплены параметры предоставляемых услуг, а, следовательно, критерии оценки вашего подразделения. Когда в очередной раз придут жалобы на неудовлетворительный уровень услуг, SLA поможет отстоять свою правоту (если, конечно, параметры сервиса остаются в рамках соглашения) и избежать ненужных нареканий со стороны бизнеса. Чем раньше такой документ появится и будет согласован — тем спокойнее будет ваша работа.
- «Кто у нас в CAB? — По минимуму«. Вот тут в точку. Change Advisory Board, он же по-русски «совет по изменениям», номинальный (или реальный, и такое бывает) который помогает Change Manager-у принять решение о выполнении изменения и (или) авторизует его. В случае если CAB номинальный — туда должно войти настолько мало человек, насколько это необходимо, чтобы с высокой долей вероятности корректно авторизовать (или отклонить) запрос на изменение. Если орган этот в организации реальный (есть положение о совете, регулярно происходят заседания, закреплён секретарь, председатель и т.д.) то тут всё сложнее. Но тоже стоит избегать чрезмерного раздувания этого органа. Идеально — когда там будут присутствовать только владельцы бизнес-процессов самого высокого уровня и представитель от IT.
- «Вы же руководитель, у нас нет полномочий!«. Ну, тут вроде всё понятно. Есть ситуации когда определённые вещи должен делать руководитель подразделения, а не его линейные работники. Получить согласование на самом высоком уровне, принять решение по каким-то спорным вопросам — для этого руководители и нужны.
- «Это дорого, но мы всё равно возьмём«. В определённый момент встал вопрос о том, что наша собственная линия поддержки не справлялась и пришлось нанимать дополнительный персонал ос стороны (аутсорсинг) который разруливал бы часть запросов. Стоило это дороже содержания собственных специалистов, но после определённых расчётов пришли к выводу что лучше аутсорсингом пользоваться. Потому что стоимость простоя бизнеса в результате нерешённого инцидента выше стоимости аутсорсера. Поэтому, считайте, делайте выводы.
- «SLA на бизнес не влияет«. Ну, тут полностью не соглашусь. Потому что именно от этого документа зависит то, в каком объёме и качестве бизнес будет получать услуги от IT. Когда всё работает стабильно, и не происходит ничего экстраординарного, так и есть. Бизнесу всё равно, есть этот документ, или нет. А вот когда петух клюнет… Лично моё мнение, каталог услуг и SLA по каждому пункту — гарантия стабильных отношений между IT и основным бизнесом.
- «А сколько было инцидентов с диском продаж?«. Вопрос возник в момент принятия решения о необходимости проведения работ с диском продаж. Вопрос логичный. Если с оборудованием всё хорошо — лучше не трогать.
- «Аналитиков уволить, они создают слишком много работы». В рамках игры, так и есть. Да и в жизни частенько бывает так что аналитики находят узкие места процессов и предлагают варианты автоматизации, что приводит к повышенной нагрузке на разработчиков. Но тут уже совсем другая история. Потому что аналитики «зрят в корень» и видят проблемы на уровне процессов, а не конкретного рабочего места, поэтому часто их запросы имеют более высокую важность, чем запросы от рядовых пользователей.
На этом у меня всё. Если это кто-то всё-таки прочитал, буду рад обсудить и ответить на вопросы.
Добавить комментарий