Digital Enterprise

Checklist: хороший менеджер процесса

В некоторых организациях время от времени возникает задача оценить, насколько хорошо или не очень назначенный на роль менеджера процесса специалист справляется с этой ролью, обладает ли он необходимыми личностными качествами, знаниями, умениями и навыками для ее исполнения. Мы составили список, который может помочь при проведении такой оценки и сделать соответствующие выводы. Мы включили в него, на наш взгляд, самое главное, на что необходимо обратить внимание. Этот checklist может быть также использован при подборе кандидата на роль менеджера процесса при условии, что Вы зададите кандидату правильные вопросы, соберете свидетельства соответствия кандидата приведённым ниже пунктам. На практике обеспечивает достижение целей и задач, поставленных…

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

ServiceDesk: 10 вещей, которых надо избегать

Йотсна Харихаран (Jyotsna Hariharan), аналитик компании FreshDesk, предупреждает о вреде определённых вещей, которых стоит избегать при организации и работе ServiceDesk. У неё получился список из 10 пунктов. Слепо следовать ITIL. ITIL – не набор строгих правил и норм, обязательных к исполнению. То, что важно для одной организации, может быть не востребовано в другой. Слепое копирование рекомендаций и их бездумное применение заведёт вас, скорее всего, в тупик. Ищите и подкрепляйте материалами из ITIL решаемые вами задачи. Принимать все метрики как важные. Перефразируя Оруэлла, можно сказать, что все метрики важны, но некоторые метрики важнее других. Каждая организация уникальна, перед каждой стоят свои задачи. Подбирайте релевантные метрики, определив требования…

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

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

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

Новостной поток, 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

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

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