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

У нас к вам вопросы. Мы их спрятали.

— Но, мистер Дент, план строительства висел в муниципалитете целых девять месяцев. — Да, конечно, как только я об этом вчера услышал, я пошел посмотреть на этот план. Вы ведь не стали утруждать себя тем, чтобы привлечь к нему внимание, и не довели это до сведения населения. — Но план висел на доске объявлений. — На какой доске? Чтобы найти его, мне пришлось спуститься в подвал! — Да, доска объявлений находится именно там. — С фонарем! — Наверное, лампочка сгорела. — А лестница в подвал тоже сгорела? — Но ведь вы же нашли объявление, правда? — Да, — сказал Артур,…

Новостной поток, 6 апреля 2015, последний комментарий 10 апреля 2015

О важности границ

Несколько недель назад довелось ознакомиться с несколькими договорами на оказание услуг. Поставщики – большие, крупные компании. Мой профессиональный интерес вызвали разделы про параметры качества услуг и ответственность поставщика. Что удивило. Во-первых, критерии с единственными фиксированными значениями. Например, говорится о гарантированной доступности в 99% или о пропускной способности каналов, измеряемой в чётко зафиксированном количестве штук пропускаемых за единицу времени элементов. Ни больше, ни меньше. При этом ни слова о том, что произойдёт либо должно произойти, если та же доступность составит за отчётный период не указанные в договоре 99%, а, например, 98% или 95%. В книгах ITIL говорится о том, что SLA должны быть составлены…

Денис Денисов, 3 апреля 2015, последний комментарий 6 апреля 2015

Кто последний, тот и…

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

Вопрос из зала, 31 марта 2015, последний комментарий 11 апреля 2015

Checklist: планирование запуска процесса

Сколько бы вы не потратили сил и времени на проектирование и автоматизацию процесса, рано или поздно вы приступите к планированию запуска. Так как успешная работа процесса зависит от множества факторов, желательно при планировании уделить внимание всем областям. Мы подготовили список вопросов, которые можно задать себе для того чтобы убедиться в том, что ничто не будет забыто при планировании запуска процесса. 1. Процесс документирован? a. Есть утвержденный регламент процесса? b. Регламент доступен участникам процесса? 2. О процессе знают люди? a. Назначение на роли в процессе выполнено? b. Ролевые инструкции предоставлены участникам процесса? c. Участники процесса прошли обучение? d. Другие сотрудники компании…

Вопрос из зала: веса KPI при расчете интегральной оценки

Читатель нашего портала Вадим Древин, изучив книгу "ITSM. Руководство по измерению", задаёт следующий вопрос: Добрый день, коллеги. В книге "ITSM Руководство по измерению" на странице 28 приведена формула (4) по расчету интегральной оценки. Есть такое ощущение, что она работает не корректно. Поясню: Рассмотрим простейший пример. У меня есть два KPI, и оба находятся ровно посередине между целевым и пороговым значением, то есть в середине ЖЕЛТОЙ зоны и т.о. оба равны 50% (или 0.5). Рассмотрим несколько примеров применения этой формулы: (а), (б) и (в). а) Если веса у них одинаковы и равны 1, то интегральная оценка у них равна BS=0.5*0.5=0.25 (или…

Вопрос из зала, 16 марта 2015, последний комментарий 21 марта 2015

Проект как подвиг

«Дело помощи утопающим — дело рук самих утопающих» Текст лозунга в зале клуба «Картонажник» Хорошо спланированные проекты далеко не всегда проходят гладко. Бывает, что сроки горят, бюджеты расползаются, результаты не похожи на ожидаемые, а область охвата то сжимается, то расширяется. Это вполне типичная рабочая ситуация: команда проекта зачастую понимает что нужно делать, чтобы нагнать-ужать-ускорить-вместить-убедить, и принимает соответствующие меры. Иногда, правда, проект настолько плохо идёт, что становится понятно, что его уже не вытянуть. Что делать в таком случае (принимая во внимание, что "второго шанса" не будет)? На этой неделе мы проводили деловую игру "The Challenge of Egypt" в прекрасном Минске (постоянные читатели портала знают,…

Олег Скрынник, 14 марта 2015, последний комментарий 16 марта 2015

О пользе красивых порталов обслуживания

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

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

Автоматическая функциональная эскалация?

Дальше действовать будем мы! Виктор Цой. В недавних обсуждениях с заказчиками опять всплыла тема автоматической функциональной эскалации заявки на следующие линии поддержки при окончании срока, отведённого на обработку на текущей линии. В нашей практике мы такое решение не использовали никогда. Попробую объяснить, почему: прежде всего, автоматическая функциональная эскалация возможно только в схеме с фиксированными маршрутами эскалации (иначе, пока не завершена диагностика на предыдущем шаге, просто неизвестно, куда эскалировать). А это само по себе нечастое явление; далее, если, например, специалист L2 работает с инцидентом, а он, тем временем, автоматически переназначен на L3, то как об этом узнает специалист L2 и бросит начатую…

Дмитрий Исайченко, 7 марта 2015, последний комментарий 10 марта 2015

Checklist: регламент процесса

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

Новостной поток, 5 марта 2015, последний комментарий 10 марта 2015

Вопрос из зала: как классифицировать инциденты по ИТ-услугам?

Посетитель нашего портала Дмитрий задаёт следующий вопрос: Коллеги, добрый день. Интересует как правильно связывать инциденты с затронутыми ими бизнес-сервисами. Пример 1: клиент не смог перевести средства на счет телефона через интернет-банк и обратился в поддержку -> зарегестрировали инцидент с привязкой к бизнес сервису "Платежи и переводы в ИБ". Тут всё понятно. Пример 2: Ответсвенный специалист обнаружил сбой в процессинговой системе (либо пришел алерт от системы мониторинга). Этот сбой влияет / может влиять не только на проведение платежей в ИБ, но на операции в банкоматах / ТСП / интернете и т.п. – В данном случае, первая линия должна связять инцидент со всеми затронутыми / потенциально затронутыми бизнес-сервисами или каким-то…

Вопрос из зала, 4 марта 2015, последний комментарий 10 марта 2015

Портрет менеджера ИТ-услуги

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

Денис Денисов, 1 марта 2015, последний комментарий 13 апреля 2020

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

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

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