Digital Enterprise

Инциденты, требующие доработок ПО

Кажется, что процесс управления инцидентами – одна их немногих глав ITSM, в которой с точки зрения теории, да и практики не осталось пробелов. Было приятно удивиться, что некоторые вопросы организации столь знакомого процесса не имеют у меня готовых ответов. Может быть, они найдутся у тех, кто читает эти строки. Итак, процесс обеспечивает своевременность решения инцидентов. Инциденты регистрируются, решаются, закрываются. Не успели вовремя – просрочка и штраф группе поддержки, задержавшей решение (иногда всем группам пропорционально вкладу). Справедливо? Безусловно. Но что если инцидент не может быть устранен силами ИТ-подразделения и требует доработки ПО на стороне подрядчика? Книжный ответ простой: ИТ-подразделение несет ответственность и…

Павел Дёмин, 22 августа 2016, последний комментарий 17 сентября 2021

Координатор проблем в слабой матрице

В процессе управления проблемами есть такая роль: координатор проблем. Как правило, эта роль предполагает ответственность за диагностику и решение проблем в какой-то предметной области, в том числе, с привлечением специалистов из смежных областей. И иногда я слышу от заказчиков вопрос: «А кто, собственно, должен быть координатором той или иной проблемы»? Например, время от времени начинает тормозить приложение. Вполне логично координатором данной проблемы становится один из ведущих специалистов app-саппорта. Далее, предположим, в результате диагностики он выясняет, что тормоза возникают на СХД. Почему? Причин может быть множество, способов решения еще больше. А наш координатор проблемы в СХД не специалист. Как быть? Кто…

Дмитрий Исайченко, 22 августа 2016, последний комментарий 29 августа 2016

Пропасть незнания

Работа консультанта в проекте по внедрению и автоматизации бизнес-процессов всегда играет яркими красками. Совсем недавно я писал о том, как мне пришлось выступать в роли тренера, и вот снова наступил момент, когда приходится выходить за рамки привычной деятельности. Очень часто в проектных командах интеграторов присутствует два тесно взаимодействующих лагеря: проектировщики/архитекторы и разработчики. Первые разрабатывают архитектуру и принципиальную схему решения, документируют процессы, логику, интерфейсы. Вторые участвуют в проектировании и впоследствии занимаются непосредственной разработкой, настройкой средств автоматизации. В настоящем проекте я выступаю не только в роли аналитика и проектировщика, но и в роли технического эксперта и разработчика. Так исторически сложилось, что хоть я и не…

Пять “А” руководства ИТ

На сайте ассоциации ISACA опубликована интересная заметка автора Peter T. Davis, посвящённая построению системы руководства ИТ (Enterprise Governance of IT) на базе рекомендаций COBIT5. По мнению автора, при внедрении методологии COBIT5 недостаточно применять подход "adopt & adapt" (применение и адаптация), а следует предпринимать определённые действия ещё и по следующим трём направлениям: alert (оповещение), align (обеспечение соответствия), assure (самопроверка). Итогом сформулированной идеи является концепция пяти "А" (Five A's), охватывающая ключевые виды деятельности, направленные на построение эффективной модели руководства ИТ. Автор выстраивает перечисленные виды деятельности в определённую цепочку, которую мы рассмотрим далее. Alert (оповещение). На данном этапе необходимо оповестить всех о необходимости…

Процессный подход. Быть или не быть?

Разговорились на днях из одним из представителей заказчика. Собеседник поделился своим опытом работы в предыдущей компании, где он познакомился с процессным подходом воочию. Слово за слово, завязалось обсуждение. В результате чего пришли к тому, что процессный подход неизбежен. Вывод сделан непосредственно собеседником, я всего-то задавал наводящие вопросы. Добавлю лишь вопросительный знак в заголовок заметки, оставляя поле для дискуссий. Сначала немного в сторону для небольших уточнений и определений. Функциональный подход – а именно с ним сравнивался в ходе обсуждения процессный – способ организации деятельности компании посредством определённых функций. Укрупнённые примеры: производство, маркетинг, бухгалтерский учёт, юрисконсульство и т.д. – высокопрофессиональные и узкоспециализированные…

Денис Денисов, 13 августа 2016, последний комментарий 16 августа 2016

Разорванные коммуникации

Мы ставим цели, выстраиваем процессы, рассуждаем о зрелости, описываем процедуры, формулируем и используем какие-то принципы, разрабатываем и анализируем метрики. Но, бывает, забываем об одной очень важной составляющей – коммуникациях. Один из уважаемых мной сериалов начинается со слов «все вокруг – числа…». Нисколько не преувеличу, если скажу «все вокруг – коммуникации». О них проведено много исследований, написано много литературы, собраны статистические данные. И все же, при таком объеме информации о коммуникациях, представленной в разных ракурсах, мы зачастую наступаем на те же грабли. Статистика: – 73% американских, 63% английских и 85% японских руководителей считают коммуникации главным препятствием на пути достижения эффективности их…

Елена Колбей, 12 августа 2016, последний комментарий 13 августа 2016

Иллюстрированный ITIL Practitioner Guidance

Владелец библиотеки ITIL, компания AXELOS, этим летом начала публиковать серию заметок о девяти руководящих принципах ITSM (guiding principles) из публикации ITIL Practitioner Guidance. Заметки написаны ведущими экспертами в области ITSM, каждая заметка иллюстрирована видеороликом, где на примере вполне жизненной истории раскрывается суть и важность каждого принципа, а также возможные нюансы. На данный момент обзоры вышли по первым двум принципам: Сохранять фокус на ценности (Focus on Value) от Стюарта Рэнса (Stuart Rance) Работать на людей (Design for Experience) от Карен Феррис (Karen Ferris) А пока по остальным принципам аналогичных заметок и роликов нет, с ними можно познакомиться, прочитав, например, заметку Павла…

Вопрос из зала: роли в проекте и их задачи

В редакцию портала поступил вопрос: Добрый день! Задача: произвести модернизацию ИС при помощи подрядной организации. Очень часто в ТКП на модернизацию указываются не должности работников, а их роли в проекте (аналитик, программист, архитектор и т.д.). Каждый их указывает по-своему и также их по-своему описывает. Вопрос: Есть ли нормативный документ или какой-то справочник, перечисляющий весь список ролей в проектах, а также расшифровывающий список задач, который возложен на каждую роль? Или может у кого из опыта уже составлен такой справочник (для себя)? Спасибо.

Вопрос из зала, 10 августа 2016, последний комментарий 20 августа 2016

Ключевые практики управления доступностью и непрерывностью

Последнее время меня занимает вопрос оценки процесса управления доступностью и непрерывностью ИТ-услуг. И если с измерением результативности процесса, на мой взгляд, все более или менее понятно – она определяется степенью достижения согласованных показателей доступности и непрерывности услуг[1], то с измерением ключевых практик не все однозначно. Собственно, вопросы есть уже к списку ключевых практик, которые необходимы для реализации назначения процесса. Здесь необходимо сделать оговорку, что я рассматриваю вариант ISO/IEC 20000, согласно которому управление доступностью и непрерывностью совмещены. Однако суть упражнения не поменяется и при разделении процессов. С оглядкой на ITIL и COBIT5 Enabling Processes получается следующий список ключевых практик: Планирование доступности и непрерывности…

Павел Дёмин, 8 августа 2016, последний комментарий 12 августа 2016

Борьба за своевременность решения

Правда, здорово, когда своевременность решения инцидентов в вашей организации составляет более 95%? Даже отраслевая статистика ниже – средний уровень своевременности решения находится на уровне 82%, и только 13% компаний добрались до лидерских 96-100% («IT Service Management Metrics Benchmarks», Pink Elephant, 2013). Так что больше 95% – это действительно круто. Или нет? Многие конечные пользователи считают, что нет. И вполне обоснованно, потому что высоких показателей своевременности несложно добиться просто увеличением целевого времени решения. И вот ИТ-отчетность вся в зеленой зоне, а пользователи жалуются – инциденты решаются неприемлемо долго. Своевременность – это косвенный показатель. Он вполне годится для процессного контроля, но с…

Дмитрий Исайченко, 7 августа 2016, последний комментарий 19 августа 2016

Когда нужно нарушать правила

Прошлым летом мы уже рассказывали про "разумное непослушание" (например, здесь и здесь). В этот раз Стюарт Рэнс (Stuart Rance) продолжает рассуждать на тему в своей заметке на портале SysAid. Недавно он стал свидетелем небольшой истории – примера неудачного взаимодействия. Делая покупки в торговом центре, Стюарт увидел, как молодая девушка, строго и неброско одетая, с укрытой платком головой, подошла к примерочным комнатам и спросила у парня консультанта, есть ли в этом отделе продавцы-консультанты девушки. Парень очень вежливо и корректно объяснил, что да, есть, но они сейчас все очень заняты, при этом настолько, что он не может кого-либо из них позвать. Продавец-консультант…

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

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