itsm

Уровень лояльности? Достаточный

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

Елена Колбей, 11 сентября 2017, последний комментарий 11 сентября 2017

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

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

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

ITSM, DevOps, и почему трехуровневая поддержка должна быть заменена на Swarming

DevOps приходит в ИТ-организации, независимо от того, готовы они к нему или нет. Автор этой статьи утверждает, что существующая организационная структура подавляющего большинства служб ИТ-поддержки в корне неверна. Недостатки организационной структуры затрудняют или делают невозможным для этих предприятий успешную интеграцию зарождающихся практик DevOps с уже существующими структурами технической поддержки. По мнению автора, развивающийся в настоящее время подход под названием Swarming[1] идеально подходит в качестве методологии организации технической поддержки в эру DevOps. Предыстория: ортодоксальная трёхуровневая поддержка Начнём с краткого обзора структуры управления, которая лежит в основе большинства функций ИТ-поддержки крупных предприятий. Классической организационной структурой управления ИТ-услугами является трёхуровневая иерархия поддержки: Уровень…

Новостной поток, 4 сентября 2017, последний комментарий 19 января 2022

Вам срочно или экстренно?

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

Артём Мукосеев, 1 сентября 2017, последний комментарий 6 сентября 2017

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

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

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

О пользе приключений

автор Каймар Кару (Kaimar Karu) Вчера завершилась моя работа в компании AXELOS, где я со своей командой три с половиной года отвечал за ITIL. ITIL принадлежит AXELOS наряду с другими сводами знаний, такими как PRINCE2. Эти методы и подходы используются десятками тысяч организаций по всему миру. И да, вопреки распространенному мнению, у ITIL всегда был хозяин, и большую часть своей почти тридцатилетней истории библиотека является коммерческим продуктом. Я пришел в компанию в качестве руководителя направления ITSM (Head of ITSM) во время серьезных изменений практик и методов управления ИТ и связанных с этим изменений в бизнесе. Мой предыдущий опыт управления ИТ-услугами,…

Две стороны одной медали

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

Денис Денисов, 26 июля 2017, последний комментарий 7 августа 2017

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

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

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

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

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

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

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

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

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

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

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

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

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

ITSM

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