Обсуждения на учебных курсах Archives – Страница 6 из 7

Абсолютный результат не имеет значения

Когда участвуешь в деловой игре, конечно же, хочется выиграть. Выиграть у команды, играющей в соседней аудитории, или у виртуального соперника, установив новый рекорд согласно нашей статистике. И если сильно на этом зацикливаться, невысокий итоговый результат может не самым лучшим образом повлиять на настроение участников. Но после ряда проведённых игр (или симуляций) у меня сложилось устойчивое мнение, что в данном случае “проигрыш” (сознательно беру в кавычки) оказывает более сильное влияние на дальнейшее развитие участников игры, чем высокий итоговый KPI. Если правильно воспользоваться ситуацией, не замыкаться на мнении “это просто игра такая”, а вместо этого вспомнить про принцип постоянного совершенствования, то становится…

Артём Мукосеев, 30 апреля 2018, последний комментарий 4 мая 2018

Функция

Одна из самых интересных вещей в проведении тренингов, на мой взгляд, заключается в возможности обсудить темы, которые, казалось бы, уже много раз обсуждались, и о которых, вроде бы, все уже поспорили и договорились. Но собственный взгляд, личный практический опыт, которые могут сильно различаться у участников одной группы позволяет посмотреть на привычное через призму новых вопросов и дискуссий. На одном из последних курсов ITIL® OSA (Operational Support and Analysis) собралась довольно сильная группа с весьма разнообразным практическим опытом. Представители внутренних ИТ-служб и внешних провайдеров ИТ-услуг (системных интеграторов и ИТ-дочек крупных компаний). У каждого есть своя сложившаяся картина мира. Если говорить о…

Плановый простой в контексте SLA

Интересно наблюдать, как под воздействием накопленного опыта развиваются интересы и трансформируются приоритеты коллег, с кем выпадает удовольствие работать и не меньшее удовольствие обмениваться опытом в рамках курсов обучения, периодически проходящих у нас в Cleverics. Недавно вышло так, что близкие по содержанию вопросы поднимались слушателями курса “Управление изменениями и релизами ИТ-услуг” (ITIL RCV) и коллегами по проекту. Вопросы касались планирования простоев услуг, необходимых для внедрения изменений. Один из вопросов был следующий: нужно ли, согласно хорошим практиками, учитывать внеплановые простои, во время которых внедрялись изменения, трактуемые бизнесом как “безотлагательные”, в отчётности? Отвечу в соответствии со своим пониманием. Если коротко – в отчётность нужно…

Артём Мукосеев, 4 декабря 2017, последний комментарий 4 декабря 2017

Запросы или потребности?

Во время обсуждения взаимодействия ИТ и бизнеса на одном из последних курсов возникла дискуссия на тему бизнес-ориентированности ИТ. По мере обсуждения были выявлены две точки зрения на то, что такое готовность ИТ помогать бизнесу. ИТ-подразделение должно качественно отрабатывать запросы бизнеса ИТ-подразделение должно удовлетворять потребности бизнеса «Мы (ИТ) должны выявлять потребности бизнеса, те задачи, которые бизнес пытается решить, и попытаться помочь ему в этом» – говорили одни. «Мы (ИТ) должны чётко отрабатывать ТЗ (техническое задание). Мы не можем «фантазировать». Да и как, скажите на милость, в случае отсутствия чёткого ТЗ фиксировать целевую картину в договоре?» – возражали другие. В этой связи…

Игорь Гутник, 26 ноября 2017, последний комментарий 27 ноября 2017

Вам срочно или экстренно?

Срочно, безотлагательно, экстренно… Все эти синонимы с точки зрения англо-русских словарей могут быть использованы для перевода слова “emergency”, которое в ITIL используется для именования особой группы изменений. Изменения этой группы должны внедряться “как можно скорее”. Формулировка, на первый взгляд, несколько размытая и не дающая чётких указаний, в каких конкретно случаях изменение следует обрабатывать в соответствии с некой специальной процедурой. Но в ITIL эта формулировка сопровождается чётким ограничением охвата и соответствующими примерами. В частности, там сказано, что “процедура обработки emergency-изменений должна применяться только для изменений, направленных на устранение ошибок в ИТ-сервисах, которые серьёзно влияют на бизнес”. А в разделе, посвящённом типам…

Артём Мукосеев, 1 сентября 2017, последний комментарий 6 сентября 2017

Мысли на тему подслушанного: о смешении ролей

Мы в Cleverics внимательно относимся к проведению сертифицированных курсов по ITIL, поэтому периодически стараемся наблюдать друг за другом со стороны. Причём, довольно подробно – на протяжении всего отдельно взятого курса в аудитории присутствует другой тренер. Из такого упражнения, несмотря на его очевидную дороговизну, есть очень важные выходы. Причём, не только для тренера, который получает обратную связь применительно к своим тренерским навыкам, но и для самого наблюдателя, который, в том числе, имеет возможность подслушать и зафиксировать интересные мысли и вопросы, поступающие на курсе от слушателей – то есть от вас, уважаемые коллеги. Так вот, на недавно прошедшем курсе ITIL RCV, где мне довелось…

Артём Мукосеев, 14 мая 2017, последний комментарий 16 мая 2017

Как оценить трудозатраты на сопровождение CMDB?

На прошедшем недавно курсе ITIL ® Release, Control and Validation (RCV) обсуждали со слушателями вопрос, как оценить трудозатраты на сопровождение базы конфигураций (CMDB). Вопрос становится насущным, если охват учёта достаточно широк и подразумевает привлечение к сопровождению не только выделенных специалистов (“библиотекарей”), но и специалистов, непосредственно выполняющих какие-либо задачи, затрагивающие конфигурационные единицы отдельных категорий. В зависимости от зрелости учёта в CMDB могут быть представлены конфигурационные единицы широкого спектра категорий, которые можно условно разделить на следующие четыре группы: ИТ-системы бизнес-приложения технологические элементы бизнес-приложений инфраструктура Именно такое деление обусловлено принципиальными различиями в характере выполняемых задач в отношении этих групп. Очевидно, что отдельные группы категорий, скорее всего, обслуживают разные специалисты. Поскольку…

Артём Мукосеев, 20 марта 2017, последний комментарий 4 апреля 2017

Ключевой компонент сервисных отношений

Все курсы, которые проводит наша компания, содержат большое количество практических упражнений, призванных закрепить полученные знания, превратить их в навык или выйти на какую-либо проблему для её дальнейшего совместного углублённого изучения. Какие-то из изученных тем находят своё применение достаточно быстро и легко, и трудностей при выполнении упражнений не возникает. В каких-то теория трансформируется в практику далеко не сразу. Даже если речь идёт об идеях совершенно банальных. Даже если теорию разобрали только что. По моему субъективному мнению наибольший разрыв между теорией и практикой применения наблюдается в области взаимодействия людей. Может быть потому, что мы в большинстве своём ИТ-шники? Особенно, когда речь идёт…

Игорь Гутник, 30 января 2017, последний комментарий 11 февраля 2017

Правильные вопросы

Недавно, в очередной раз обсуждая техники анализа проблем, используемые в рамках процесса управления проблемами (Problem Management), спорили по поводу количества вопросов, которые нужно/можно задавать, реализуя методику «Пять «Почему?» («5-why»). Суть метода, напомню, заключается в том, что мы берём какое-то явление (проблему) и задаём себе вопрос: «Почему это происходит?». Найдя ответ на этот вопрос («Это происходит, потому что, происходит то»), мы задаём тот же самый вопрос «почему?» про «то» («А почему происходит то?»). И т.д. и т.п. Утверждается [ITIL SO, 4.4.4.3], что, следуя по этой цепочке, мы «обычно на пятой итерации добираемся до корневой причины». На самом деле то, как быстро…

Игорь Гутник, 25 декабря 2016, последний комментарий 27 декабря 2016

Всегда ли Known Error – ошибка?

Согласно ITIL® процесс «Управление проблемами» (Problem Management) направлен на минимизацию негативного влияния на бизнес инцидентов, вызванных ошибками в ИТ-инфраструктуре и предотвращение повторного возникновения таких инцидентов [SO, 4.4.1.1]. Часть работы процесса заключается в поиске корневой причины, вызывающей инцидент(ы) или, если не забывать и про проактивную составляющую процесса, корневой причины, которая может вызвать инцидент(ы) и устранению данной причины, либо, если это по какой-либо причине невозможно и/или не рационально, предложению обходного решения (workaround). При этом нужно понимать, что в общем случае ошибка – это не всегда ошибка в прямом смысле слова. Это может быть сложное сочетание конфигурационных единиц и условий их эксплуатации, которое…

Нужен ли процесс “Управление запросами на обслуживание” процессу “Управление инцидентами”?

За последнее время несколько раз на курсах по ITIL(с) обсуждался вопрос использования процесса управления запросами на обслуживание (Request Fulfillment Management [RFF]) для решения задач, лежащих в области интересов других процессов из процессной модели ITIL. Последнее обсуждение было вчера (Да. В корпоративном формате мы проводим тренинги и в выходные). В качестве примера подобного обсуждения вопрос: «В каком процессе должен отрабатывать запрос на получение информации об инциденте, находящемся в работе (например, о текущем статусе инцидента)? В процессе «Управление инцидентами» [Incident Management , INC] или в RFF?» Сначала зафиксируем очевидное. Во-первых, источником информации (в т.ч. о текущем статусе) является, конечно же INC, поскольку…

Игорь Гутник, 5 сентября 2016, последний комментарий 8 сентября 2016

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

Обсуждения на учебных курсах

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