Практика и опыт Archives – Страница 19 из 53

Управление ИТ-финансами

За последние годы мы многому научились, в том числе в вопросах сервисной экономики. Мы умеем корректно рассчитывать стоимость услуг и распределять её по потребителям (причем, любых услуг – не только в ИТ). Мы умеем формировать плановую стоимость услуг на основе бизнес-планов. И все это мы делали на практике, то есть правда умеем, а не просто «читали». Но одной простой вещи я понять пока не могу: почему тема сервисной экономики так не востребована ИТ-руководителями? Например, пару недель назад по теме сервисной экономики мы делали рассылку ИТ-менеджерам. Результаты таковы: отправленных писем – около 4 000, из них открыто – около 2 200, количество переходов…

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

Расчет норматива по числу обращений за рабочую смену для первой линии

В редакцию портала поступил вопрос: Добрый день! Возник следующий вопрос. Как правильно рассчитывается норматив по количеству обращений за одну рабочую смену на 1FTE первой линии? И может ли вообще такой норматив быть рассчитан, и главное применим ли к 1 линии? Сейчас у нас эта цифра есть, но правильно ли она рассчитана, хотел бы разобраться с вашей помощью.

Вопрос из зала, 5 сентября 2017, последний комментарий 22 августа 2018

Ресурсно-сервисные модели (РСМ). Упражнение.

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

Андрей Труфанов, 31 августа 2017, последний комментарий 9 января 2019

Хороший сервис

На нашем портале кто-либо из коллектива авторов, бывает, сетует на провайдеров тех или иных услуг. Где-то раз в год у нас выходит по подобной заметке, выдержанной в умеренно-негативном ключе. В них мы описываем, что за проблема приключилась, в чём провайдер допустил ошибку, что не так было с услугой, предлагаем конструктивные меры, что мы бы предприняли для исправления ситуации. А я вот на днях, считаю, прикоснулся к хорошему сервису, хорошему обслуживанию. Мне всё понравилось. Пусть мой случай будет позитивным моментом в подобных темах. Начало стандартное – заказ в интернет-магазине компании. Выбрал товар из предложенного ассортимента, разместил заказ. Отзвонился менеджер, подтвердил его….

Денис Денисов, 23 августа 2017, последний комментарий 1 сентября 2017

Как мотивировать сотрудников фиксировать свои изменения

В редакцию портала поступил вопрос: Как мотивировать сотрудников фиксировать свои изменения в рамках процесса Change Management? Периодически выявляются случаи проведения изменений в ИТ-инфраструктуре, проведенных за рамками соотвествующего процесса. При этом сотрудники в свое оправдание дают пояснение вида: не оформил RFC потому, что – это тестовая среда/ это по SR от заказчика/ работы в рамках стандартного функционала услуги/ конфигурация самой системы не затрагивается и т.д. Традиционные доводы (почему необходмо фиксировать изменение) в стиле "повышается прослеживаемость цепочки событий при решении инцидентов/ поиска причин проблем", или "повышается качество планирования работ, формирование ожиданий потребителей ИТ-услуг", "проводить изменения с минимальным негативным воздейстием на ИТ-услуги" — работают скорее для ИТ-руководителей или процессных менеджеров, нежели для…

Вопрос из зала, 8 августа 2017, последний комментарий 5 октября 2017

Сопротивление организационным изменениям – миф

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

Олег Скрынник, 2 августа 2017, последний комментарий 15 августа 2018

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

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

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

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

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

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

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

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

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

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

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

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

Оценка эффективности сотрудника ИТ-службы

В редакцию портала поступил вопрос: Уважаемые коллеги! Вопрос следующего свойства: По книге "ITSM. Руководство по измерению" успешно внедряем индикаторы для процессов Inc mng и rf (Service request) mng, выбрали 2 индикатора TPI и TCR, как сбалансированные. Вопрос в следующем: Как однозначно оценить "эффективность сотрудника"? Т.к. если сотрудник 1 решил за месяц 200 обращений — у него TCR 0.78 и TPI 0.80, а второй решил 10 обращений и у него оба индикатора равны 1 (Идеальный). В описании измерений процессов не нашёл информации как сие реализовать, чтоб было честно с точки зрения сотрудника 1. Свой вариант: Ввести "нормирование" количества обращений, выполненых за период, но данный вариант не предусматривает…

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

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

Практика и опыт

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