Евгений Шилов, Автор в Digital Enterprise

Конвейер в ИТ

Совсем недавно обсуждали распределение ресурсов в рамках работ по сопровождению систем автоматизации. Работы включают в себя, в том числе разработку новых функциональных возможностей по требованию заказчика. Сам я не специалист по производственным процессам, не так давно читал книгу "Цель" Э.Голдратта, поэтому сразу же в глаза бросилась схожесть задач, с которыми приходится сталкиваться в ИТ, с задачами, описанными автором в отношении производственных процессов на заводах. Вопросы узких мест, загрузки и простоев ценных ресурсов, выделения доп.ресурсов и соответствия спросу, цепочек работ со стохастическими колебаниями их длительности и т.д. Дмитрий уже как-то упоминал эту книгу применительно к процессу управления инцидентами. Если еще не…

Евгений Шилов, 28 января 2013, последний комментарий 28 января 2013

ServiceDesk для маленьких

Много раз сталкивался с ситуацией, когда в относительно небольшой компании, в которой трудится 5-10 ИТ-специалистов, организуется ServiceDesk. При этом всегда встает вопрос: "Каким он должен быть с учетом ограниченности ресурсов?". Во-первых, давайте поймем, есть ли вообще смысл выделять службу поддержки в небольшой компании. С одной стороны, ИТ-специалистов немного, скорее всего, у каждого своя специализация, пользователи знают всех поименно, и вводить дополнительное звено между ними и пользователями – значит усложнять простые процедуры. С другой стороны, недостаток ресурсов приводит к реализации рисков, например: обращения пользователей забываются/теряются в общем потоке пользователям сложно найти ИТ-специалистов для того чтобы сообщить о своих проблемах не всегда…

Обследования (основы)

Очередной проект показал, что мыслями на эту тему стоит поделиться. Давайте рассмотрим две наиболее распространенные ситуации, при которых обычно заказывается обследование: Есть проблемные области в управлении ИТ, ситуацию в которых хотелось бы улучшить. Есть непреодолимое желание проверить, что "все сделано правильно". Одним из ключевых факторов успеха является постановка задачи.Без этого никак: необходимо определиться, зачем делается обследование и что должно быть на выходе. Итак, начнем с проверки на "правильность". Понятие "правильно" у каждой компании свое, поэтому проверка на соответствие стандартам не всегда дает возможность правильно выбрать направление для совершенствования. В некоторых случаях разумное отступление от положений стандарта позволяет получить лучший результат. Несомненно, на…

Евгений Шилов, 30 ноября 2012, последний комментарий 27 декабря 2012

Для тех, кто не любит ждать

Есть такая практика – включать в число статусов обрабатываемых объектов (инциденты, обращения, задания/наряды на работы и т.д.) статус "Ожидание". Задача, которую решает этот статус, простая: обеспечить участникам процессов возможность отложить в сторону обрабатываемый объект в ситуации, когда по каким-то причинам его обработка пока невозможна. Например, ждем, пока пользователь вернется из отпуска или ждем, пока будет поставлена техника и т.д. В общем, найти разумное объяснение существованию этого статуса можно. Однако понятна и обратная сторона такой возможности: появляется способ отлынивать от работы. Традиционный способ сокращения халтуры – обязать переводящего в статус "Ожидание" указывать причину перевода. Однако при наличии богатой фантазии отдельные…

Евгений Шилов, 25 октября 2012, последний комментарий 13 ноября 2012

Безвыходные инциденты

Думаю ни для кого не секрет, что инциденты рано или поздно закрываются. Обычно это происходит после того, как найдено и применено решение, в некоторых случаях требуется подтверждение пользователя, в некоторых нет. Иногда это делает участник одной из ролей (например, менеджер процесса), иногда – система автоматизации, после получения подтверждения или по прошествии определенного времени после решения. При этом обычно указывается так называемый "Код закрытия", указывающий, на каком основании был закрыт инцидент. Справочник кодов закрытия – отдельная история. Обычно в нем присутствуют коды: "Решен", "Не удалось воспроизвести", "Отказ пользователя" и так далее. На днях обсуждали с одним из клиентов возможность ситуации, при…

Евгений Шилов, 26 сентября 2012, последний комментарий 4 октября 2012

Default SLA

При проектировании процесса SLM не раз сталкивался с вопросом со стороны заказчика: "как мы заставим бизнес подписывать с нами SLA? Это же за ними бегать надо, договариваться, убеждать …". В итоге в рамках одного из проектов родилось решение, которое уже проверено практикой и, как минимум, имеет право на жизнь. Хочу поделиться и узнать Ваше мнение. Что если на этапе старта процесса формируется SLA "AS IS", фиксирующий текущий уровень предоставления ИТ-сервисов на основании текущей практики и собственного видения ИТ на то, как надо предоставлять ИТ-сервисы. SLA вводится в действие без согласования с каждым Заказчиком, просто как неотъемлемая часть запускаемого процесса….

Евгений Шилов, 30 августа 2012, последний комментарий 10 сентября 2012

Разыскивается технический эксперт!

Уважаемые коллеги, в связи с расширением проектной практики мы предлагаем работу экспертам в области автоматизации процессов ITSM. В качестве сотрудника Cleverics ему предстоит изучать новые технологии и подходы к автоматизации, проектировать, создавать и развивать системы автоматизации процессов, не останавливаться на достигнутом. Детальные требования описаны у нас на сайте в разделе "Вакансии". Желающие могут присылать свои резюме по адресу: info@cleverics.ru

Евгений Шилов, 17 июля 2012, последний комментарий 8 августа 2012

Влияние сбоев на ИТ-услуги

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

Евгений Шилов, 1 июля 2012, последний комментарий 5 июля 2012

Доска аварий

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

Евгений Шилов, 30 мая 2012, последний комментарий 27 июня 2012

Допрос с пристрастием

На днях меня попросили показать примеры вопросов, которые можно задавать пользователям для оценки их удовлетворенности итогами решения инцидента. То есть по итогам решения инцидента пользователь не просто должен сказать: "да работает/нет не работает", а дать "развернутый" ответ о том, как все прошло и насколько он счастлив. Я решил заодно и на портале упомянуть эту тему и важные моменты: Нужно точно понимать, зачем проводится опрос, какие выводы предполагается сделать. Только так можно подобрать правильные вопросы и понять как затем обрабатывать ответы. Вопросов не должно быть много (2-3 достаточно) иначе есть риск вообще не получить ответов или получить случайные ответы Пользователя не…

Евгений Шилов, 14 мая 2012, последний комментарий 22 мая 2012

Оценка влияния инцидента

Ну наконец-то выходные и можно спокойно написать пару мыслей. Не раз уже обсуждали на семинарах проектирования подход к оценке уровня влияния инцидентов, поступающих от пользователей. Обычно влияние сказывается на приоритетах и нормативных сроках решения инцидентов, поэтому оценить влияние на начальном этапе чрезвычайно важно. Но, вспоминая, что на первой линии нам обычно доступны только сами пользователи с их суждениями о сложившейся ситуации, а объем диагностической информации минимален, приходится придумывать вопросы, которые специалист первой линии может задать пользователю и на основании ответов оценить влияние. К вопросам предъявляется ряд требований: пользователи могут дать ответ трактовка более-менее однозначна вопросов не много (обычно 2-4) Традиционную схему, которую часто приводят…

Евгений Шилов, 29 апреля 2012, последний комментарий 9 мая 2012

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

Евгений Шилов

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