Дмитрий Исайченко, Автор в Digital Enterprise

Поддержка пользователей и удаленное управление ПК

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

Дмитрий Исайченко, 17 декабря 2012, последний комментарий 22 декабря 2012

Концентрируйся или …?

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

Дмитрий Исайченко, 14 ноября 2012, последний комментарий 3 декабря 2012

Как это по-русски?

Русский язык богат и разнообразен. Профессиональная область ITSM существенно более ограничена, да и к тому же наполнена множеством терминов и аббревиатур из английского языка. Получается этакий словарь Эллочки-людоедки. То есть научиться говорить правильно – не так сложно. Но не тут-то было. Вот мой хит-парад довольно распространенных и уже порядком надоевших ошибок. 3-е место. Использование «ИТ» вместо «ИТ-подразделения» или аналогов. Хотя «ИТ» – это не люди и не организационная единица, а технологии (то есть не субъект, а объект). Иногда получается довольно забавно. Например: «Бизнес заключил соглашения с ИТ» фактически значит, что бизнес договорился с технологиями. Сразу вспоминается известная картинка из идиотеки…

Дмитрий Исайченко, 3 ноября 2012, последний комментарий 4 декабря 2012

ORBIT или методика обоснования ITSM-проекта снизу вверх

То, что ITSM в целом и ITIL в частности являются инструментами управленца, а не самоценными результатами «внедрения» известно многим. То, что из этого следует, что подходить к организации каких-либо процессов ITSM надо с задач, а не с перечня процессов, так же известно многим. Тем не менее, «знаю» не превращается в «делаю» само собой. Например, мы регулярно получаем на вход RFP с формулировками типа «Цель проекта – внедрение управления изменениями и конфигурациями». И далее, конечно «пришлите коммерческое предложение» или «сколько будут стоить ваши услуги по внедрению?». Иногда постановка незначительно варьируется и цель проекта формулируется как «Повысить качество управления ИТ» (без «излишних» деталей, разумеется) и…

Дмитрий Исайченко, 28 октября 2012, последний комментарий 2 ноября 2012

Управление проблемами и время решения инцидентов

Задача сокращения среднего времени решения инцидентов стоит перед многими руководителями. На традиционный вопрос «Как сделать так, чтобы инциденты решались быстрее?», есть не менее традиционный ответ «Давайте проанализируем, где теряется время». Здесь работает простая аналогия с подходом к сокращению затрат: начать надо с выявления наиболее затратных областей. Именно там усилия по сокращению затрат могут принести наибольшие результаты. Где же искать ответ? В книге ITIL Service Design в главе про управление доступностью есть любопытный раздел «Expanded incident lifecycle». Это метод, описывающий основные этапы решения инцидента с целью последующего анализа, за счёт чего можно сократить время обработки на каждом из этапов – быстрее…

Дмитрий Исайченко, 20 октября 2012, последний комментарий 25 октября 2012

Разрушители легенд: управление конфигурациями невозможно без процесса управления изменениями

Недавний разговор об управлении конфигурациями и изменениями опять напомнил мне извечный вопрос о курице и яйце. А разговор, в сущности, был на тему, правда ли необходимо внедрение управления изменениями для обеспечения актуальности CMDB? Распространённое мнение гласит: «Да, управление изменениями необходимо, иначе мы не сможем отслеживать изменения и, следовательно, CMDB утратит актуальность». Я не согласен. Даже если апеллировать к каноническим текстам (книжкам ITIL), назначение процесса управления конфигурациями – «is to ensure that the assets required to deliver services are properly controlled, and that accurate and reliable information about those assets is available when and where it is needed». В то время,…

Дмитрий Исайченко, 6 октября 2012, последний комментарий 15 октября 2012

Роботизированная поддержка

На днях был в командировке в Краснодаре. Тамошние коллеги рассказали удивительную историю о том, как на одной из выставок им был продемонстрирован бот, который умеет самостоятельно общаться с пользователями по MS Lync, выполняя функции … первой линии поддержки. В частности, со слов очевидцев, он умеет требовать от пользователей более конкретные формулировки, чем «помогите» или «у меня всё не работает», в том числе посредством уточняющих вопросов по диагностическому дереву. По итогам диалога, если пользователю не удалось помочь, но собрана достаточная диагностическая информация, бот самостоятельно регистрирует от пользователя заявку в MS SCSM. То есть я уточню: пользователь обращается в службу поддержки по…

Дмитрий Исайченко, 27 сентября 2012, последний комментарий 4 октября 2012

Функциональная эскалация

Недавно в свете выпуска нового релиза CleverENGINE обсуждали внутри тему функциональной эскалации в управлении инцидентами. Этот, на первый взгляд, несложный вопрос на практике имеет очень важное значение, а принятые по нему решения определяют не только принципы разграничения ответственности за поддержку пользователей, но сказываются и на структуре каталога ИТ-услуг, и на содержании SLA. Так вот можно выделить два принципиально различных способа функциональной эскалации: с произвольным маршрутом и с фиксированным маршрутом. В случае произвольного маршрута специалист, отвечающий за обработку инцидента, выбирает следующий шаг эскалации самостоятельно, в зависимости от результатов диагностики. Например, инцидент, связанный с отказом информационной системы по результатам диагностики может быть…

Дмитрий Исайченко, 11 сентября 2012, последний комментарий 22 сентября 2012

Transформация

По итогам встреч с заказчиками на прошлой неделе, двух текущих и нескольких прошлых проектов могу лишь в очередной раз подтвердить теорию ITSM: организация процесса управления уровнем ИТ-услуг действительно кардинально влияет на практику операционного управления ИТ. Это очень серьёзное изменение в управлении ИТ, не просто «внедрение ещё одного процесса». Мне кажется, многие компании недооценивают уровень организационных изменений (что также подтверждается очередными предпроектными переговорами). Смотрите сами: У управления инцидентами появляются более обоснованные и чёткие нормативы. Серьёзно меняется подход к классификации обращений пользователей, что, в частности, требует переподготовки первой линии поддержки. Усиливается потребность в эффективной координации устранения крупных инцидентов (major incidents), в регистрации…

Дмитрий Исайченко, 27 августа 2012, последний комментарий 3 сентября 2012

Who is incident manager?

Во многих ITSM-проектах менеджером процесса управления инцидентами назначают начальника отдела поддержки пользователей (Service Desk). Такой вариант обладает рядом понятных минусов. Основной – риск вытеснения функций менеджера сквозного процесса функциями руководителя отдела поддержки. Как следствие, сложности во взаимодействии со второй линией, риск появления изолированных самостийных видов поддержки, с поступлением обращений мимо первой линии, без регистрации в системе автоматизации. Особенно вероятна такая «параллельная реальность» в отделах сопровождения прикладных систем. Причина: первая линия относительно редко бывает достаточно компетентной, чтобы оказывать полноценную начальную поддержку по прикладному ПО. А значит и пользователями, и «прикладниками» может восприниматься как лишнее звено, только увеличивающее общее время обработки обращений….

Дмитрий Исайченко, 19 августа 2012, последний комментарий 12 сентября 2012

Value network и сервисный подход

Классическое понятие Value chain описывает «линейную» модель взаимодействия нескольких субъектов, каждый из которых в общем случае может выступать как потребителем, так и поставщиком услуг. Замечательная простота этой модели заключается в том, что некоторый субъект у одних приобретает услуги, другим – оказывает (рисунок 1, часть «а»). При этом если «увеличить» одно из звеньев цепи (рисунок 1, часть «б»), то мы увидим одно прямое следствие такой линейности: один субъект (в данном случае – организация «B») принимает решение и о требованиях к содержанию / объёму потребления услуг, и о расходах на потребляемые услуги. Однако жизнь вокруг нас сложнее. Всё более адекватным описанием реальных…

Дмитрий Исайченко, 13 августа 2012, последний комментарий 18 августа 2012

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

Дмитрий Исайченко

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