Digital Enterprise

Problem Management: эскалация инцидента на вторую линию

В редакцию портала поступил вопрос: Коллеги, добрый день! Прочитал много материалов, касающихся Problem Management. Совсем не прочувствовал идею, что Управлению проблемами сложно внедрять и до него нужно "дорасти". Возьмем на примере. Звонит пользователь, и говорит, что не может на компьютер зайти — заблокирована учетная запись. Причем утверждает, что это происходит каждый день. Проверяю по тикетам — так и есть. Каждый день мой сотрудник первой линии успешно решает данный инцидент. То есть налицо наличие проблемы. Но Problem Management не выстроен. Я хочу, чтобы ITSM система мне позволила на основе данного инцидента создать проблему, которую перевести на вторую линию, к которой можно приклеить прошлые такие…

Вопрос из зала, 18 июля 2017, последний комментарий 2 августа 2017

Как мотивировать пользователей подавать заявки в Service Desk через портал?

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

Вопрос из зала, 17 июля 2017, последний комментарий 2 августа 2017

Shift Left и трансформация службы поддержки

Интересными наблюдениями и рекомендациями, по результатам двухлетнего проекта трансформации службы поддержки, делится Ричард Сикора (Richard Sykora) (оригинал статьи A Support Center Transformation to Shift Left). Основная цель проекта была обеспечить «shift left» организации поддержки. Ричард пишет: "Cтратегия сдвига влево, на самом деле, очень проста. В левой части спектра у вас есть наименее затратная модель поддержки ваших конечных пользователей. В ней обычно нет людей, которые помогают пользователям, он широко известен, как нулевой уровень или самообслуживание. В центре спектра у вас может быть вспомогательный персонал, однако, это скорее сценарий «много-к-одному», например, чат. Дальше вправо по спектру соотношение уже «один-к-одному» между конечными пользователями…

Новостной поток, 17 июля 2017, последний комментарий 17 июля 2017

12 «лучших практик» в ИТ, которых следует избегать любой ценой

Начиная от слов «вы – наши заказчики» и заканчивая «облачной» стратегией – эти «лучшие практики отрасли» погубят вас. В чем причина неудач ИТ-компаний? Очень часто – это использование так называемых «лучших практик», описанных людьми, которые могли бы знать побольше о предмете, но не знают, возможно, потому, что никогда этим не занимались. Начиная от определения «внутренних заказчиков», и заканчивая внедрением практики внутреннего выставления счетов для обеспечения рентабельности инвестиций. Большинство этих советов внушают доверие с расстояния более ста километров. Однако стоит стереть верхний слой и вы поймете, что многие из них на самом деле – верный путь к провалу. 1. Все вокруг…

Новостной поток, 16 июля 2017, последний комментарий 17 июня 2019

Шесть правил построения модели аллокации ИТ-затрат

Как известно, «опыт – это то знание, которое приходит сразу после того, как оно было так нужно». Попробую поделиться своим опытом реализации проекта по построению модели аллокации ИТ-затрат, который я сформулировал в виде короткого набора правил. Зафиксируйте конечную цель аллокации до начала проектирования. От неё будет, в том числе, зависеть выбор объектов отнесения затрат и правила классификации затрат на прямые и косвенные. Особенно остро это касается разработки ПО и другой проектной деятельности. Разберитесь в текущей практике учета. В идеале – выполните обследование источников данных до объявления сроков и ценника. Вам скажут, что договоров на внешние услуги всего штук пятьдесят. Не…

Дмитрий Исайченко, 16 июля 2017, последний комментарий 17 июля 2017

“… многоликий Вы наш”

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

Дмитрий Хруслов, 12 июля 2017, последний комментарий 13 июля 2017

Адаптивные модели изменений

"Жизнь многообразна, бумага не бесконечна!" )) "Ну хорошо, а сколько их нужно сделать?" Этот весьма насущный вопрос возникает, когда начинаешь проектировать модели изменений. Мы уже делились на нашем портале разными мыслями по поводу моделей изменений. Например, здесь и здесь. А здесь даже лежит вебинар по данной теме. Но если мы говорим, что модели позволяют учесть различную специфику проведения изменений в зависимости от того, как это изменение классифицировано, то каков должен быть масштаб проработки этой специфики? Какова должна быть детализация того самого классификатора? И какие конкретно параметры изменений должна настраивать модель? Как обычно, следует искать рациональный баланс. Чётко прописать всю специфику вплоть до…

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

Продаём DevOps высшему руководству

В последние месяцы в общении с коллегами, клиентами и партнёрами регулярно наблюдаю примерно такой диалог: — Эх, всё так стремительно меняется! Конкуренты запускают новые продукты, клиенты становятся всё более придирчивыми и продвинутыми. Прямо чувствуется, как мы всё больше и больше отстаём. — Что же мешает вам двигаться быстрее? Есть же новые подходы, успешно применяемые в разных организациях. Тот же DevOps, к примеру. — Это да, было бы круто. Но это же большая перестройка! — Разумеется. Но ведь дорогу осилит идущий. С чего-то надо начинать. — Нет, у нас не выйдет, руководство не поддержит. То, которое в бизнесе. Ведь им тоже…

Олег Скрынник, 8 июля 2017, последний комментарий 10 июля 2017

Давайте будем осторожны, когда тратим деньги, и другие мифы о технической поддержке

Оригинал заметки Let’s Be Careful How We Spend Our Money: And Other Tech Support Myths, автор Рой Аткинсон (Roy Atkinson) Не так давно у меня был разговор с человеком из очень большой компании, очень-очень большой компании с сотнями тысяч сотрудников. Они сбрасывают пароли вручную. За прошлый год их служба технической поддержки проделала это 600 000 раз. Давайте быстро и, не сильно вдаваясь в детали, посчитаем. Средняя стоимость каждого тикета, если верить отчету HDI 2016 Technical Support Practices & Salary Report составляет $ 18,50. Но сброс пароля всё-таки относительная простая и быстрая операция, поэтому давайте оценим его в половину стоимости: $…

Новостной поток, 7 июля 2017, последний комментарий 12 июля 2017

Правильная последовательность внедрения ITSM-процессов

В редакцию портала поступил вопрос: Добрый день, коллеги! Наша компания находится на этапе внедрения процессов ITSM. В качестве первоочередных к внедрению процессов остановились на 6: управление обращениями, управление инцидентами, управление запросами на обслуживание, управление изменениями, управление конфигурациями, управление проблемами. Возник спор: в какой последовательности внедрять процессы. Я считаю, что правильнее было бы сперва смоделировать и описать регламенты всех шести процессов, а уже после этого формировать требования для разработчиков системы автоматизации, автоматизировать и обучать персонал новым правилам работы, т.к. часть изменений в системе автоматизации по одному процессу затронет и другие. Коллеги придерживаются мнения, что внедрять каждый из процессов нужно последовательно. Подскажите, есть…

Вопрос из зала, 4 июля 2017, последний комментарий 8 июля 2019

Роль и место процесса управления конфигурациями в современном IT

Процесс управления конфигурациями является одним из наиболее спорных процессов библиотеки ITIL с точки зрения практической полезности. Не буду вступать в полемику по этому поводу, т.к. практический опыт показывает, что те, кто поставили себе задачу получить от этого процесса пользу и приложили к этому определенные усилия – эту пользу получают. На практике, процесс управления конфигурациями – набор активностей, выполнение которых гарантирует наличие актуальной информации о значимых для нас сервисных активах. Этот же процесс обеспечивает то, что эта информация предоставляется целевому адресату в удобной для него форме. Важным для процесса понятием является термин "базовое состояние" (baseline), которое отражает некоторое эталонное, авторизованное значение конифгурационной единицы. Таким…

Андрей Труфанов, 3 июля 2017, последний комментарий 5 июля 2017

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

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