Digital Enterprise

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

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

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

First Time Resolution (FTR) в разбивке по группам

В опубликованной нами книге «ITSM. Руководство по измерению» есть метрика First Time Resolution (FTR) для инцидентов, выраженная формулой 18 (страница 42). Метрика представлена в разрезе по рабочим группам, однако способ расчёта в разрезе по рабочим группам в книге подробно не рассматривается. Недавнее обсуждение показало, что это непростой вопрос, требующий некоторых пояснений. Напомним, что формула для расчета имеет вид: со следующим определением операндов: Sj — количество объектов, возвращённых на доработку в j-тую группу, Nj — общее количество объектов, обработанных за период силами j-той группы. А пояснений, собственно, всего два: по способу учёта возвратов на доработку; по определению операндов Sj и Nj….

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

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

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

Checklist: Верные способы провалить проект

Как знают многие читатели нашего портала, каждый год мы выпускаем книжку. О чём – почти всегда было предметом интриги, только в 2014 году мы раскрыли тему и авторов незадолго до выхода книги в свет. В этом году всё будет иначе, и многое будет впервые. Во-первых, мы готовим к печати внеочередную книжку – летнюю, а не новогоднюю. Во-вторых, ее авторы не работают в нашей команде. И очень хорошо, что так. В-третьих, это будет сборник worst practice – описание самых грубых, самых тяжелых и болезненных ошибок, допущенных авторами в своей (теперь уже оставшейся в прошлом) проектной и ITSM-деятельности. Редкая возможность учиться на…

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

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

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

Вы эксперт? Вы нужны форуму!

itSMF России постепенно начинает новый сезон – обновляются органы управления и тематические комитеты, проводятся первые мероприятия… Не остался в стороне от весеннего обновления и экспертный совет форума. В этом году его возглавила Наталья Новосёлова, и вот она приглашает всех желающих и способных к участию в работе совета. Участие в Экспертном совете — это способ заявить о своей компетенции и опыте не только на российском, но и на зарубежном рынках! Кроме того, это замечательная возможность реализовать свои знания и навыки Подать заявку на участие в экспертном совете форума очень просто: ознакомиться с Положением об Экспертном совете; подготовить заявление по установленной форме; отправить заявление по адресу n.novoselova…

Плохой сервис как стратегическое решение

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

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

Как обосновать бюджет

Кто как не ИТ-руководитель знает, как сложно бывает добиться выделения необходимого бюджета. Многим из нас знакома ежегодная битва за средства, сотрудников и т.д. Эту интересную тему поднял автор на портале The ITSM Review в статье "How to Get Bigger Budgets". Автор напоминает, что если как следует не подготовиться к защите бюджета и собственных интересов перед руководством, то можно запросто лишиться части команды, не выполнить запланированные работы по модернизации и в итоге снизить качество предоставления ИТ-услуг. При этом важно научиться измерять потребности в ресурсах, т.к. без измерения сложно обеспечить должное обоснование. В качестве одного из примеров хорошо измеримой деятельности, автор приводит службу клиентской…

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

Граница между доступностью и непрерывностью

Граница между двумя процессами – управление доступностью и управление непрерывностью ИТ-услуг – неочевидна, и часто вызывает сложности, особенно у тех, кто только знакомится с ITIL. Действительно, процессы используют схожие техники. В основе обоих процессов лежит понятие риска: мы должны идентифицировать нежелательные события, угрожающие вывести из строя услуги, затем думать, как с этим справляться. И в том, и в другом случае требуется понимание критических бизнес-функций (VBF) и анализ влияния отказов услуг/систем на бизнес-процессы (BIA). Оба процесса, в конечном счете, решают задачу обеспечения устойчивости организации к отказам. Так ли важно разделять эти процессы? На прошедшем недавно курсе PPO мы с группой составили небольшую табличку, иллюстрирующую различия, которую я…

Павел Дёмин, 28 марта 2015, последний комментарий 2 апреля 2015

Checklist: хороший сотрудник поддержки пользователей

Какими качествами должен обладать хороший специалист поддержки? Давайте сначала определим о ком пойдет речь. В данном случае имеется ввиду сотрудник, непосредственно взаимодействующий с пользователями и решающий определенный круг задач в части поддержки (при этом предметная область может быть любая, в зависимости от специфики организации и структуры службы поддержки). Мы составили короткий список, включив в него, на наш взгляд, самое главное, чем должен обладать такой специалист. Если есть пункты, вызывающие у Вас вопросы, либо Вы с ними категорически не согласны, либо считаете необходимым внести уточнения или добавить что-то важное, пишите. Обсудим вместе. Обладает необходимыми знаниями и навыками в своей области ответственности…

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

Не так просто управлять изменениями, но оно того стоит

В блоге портала AllThingsITSM появилась поучительная заметка о пользе внедрения процесса управления изменениями. Автор на примере показывает, что кажущиеся простыми изменения, реализованные за рамками процесса, могут приводить к непредсказуемым последствиям. Экономия времени при отказе от обработки изменения в рамках процесса на практике влечет еще большие затраты на восстановление работоспособности. Например, отказ от согласования может привести к реализации изменения, которое уже передумали внедрять, или решили делать иначе. Кроме того, изменение прошедшее мимо процесса не оставляет о себе информацию столь необходимую для диагностики и выявления причин сбоев. Автор предлагает задуматься о влиянии той работы, которую вы делаете на деятельность других людей в компании, на продукты/услуги, которые ваша компания предоставляет своим клиентам. Пренебрежение…

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

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