Digital Enterprise

Трущобы или точечная застройка?

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

Роман Журавлёв, 15 апреля 2015, последний комментарий 21 апреля 2015

AXELOS запустила Career Path для ITSM-специалистов

AXELOS объявила о запуске инструмента планирования карьеры Career Path для ITSM-специалистов. С марта инструмент уже доступен для профессионалов в области проектного управления, и им, по данным AXELOS, воспользовались более 1300 человек. С помощью Career Paths можно узнать об основных позициях, востребованных в индустрии, познакомиться с подробным описанием и типовыми задачами, присущими каждой должности. Для каждой позиции определены ключевые навыки и способности, а также сертификации ITIL, которые могут оказаться полезны для формирования необходимых компетенций. Кроме того, представлен список возможных последующих шагов в зависимости от текущей позиции – предполагается, что опираясь на эту информацию и собственные предпочтения, ITSM-специалисты получат возможность выбирать карьерный путь и планировать…

Все на портал самообслуживания!

Недавно один из клиентов поделился достижением: "теперь у нас около 90% обращений регистрируется пользователями на портале самообслуживания, почта и телефон почти не используются". За счет этого разгрузилась первая линия, сократилось время обработки обращений, т.к. они маршрутизируются на вторую линию или во внешние компании автоматически, а данные, которые поступают от пользователя, содержат достаточно деталей из-за применения специализированных форм для разных типов обращений. Пример действительно интересный, многие к этому стремятся, но вот вопрос: везде ли достижимо такое состояние, какие условия должны быть выполнены и что нужно предпринять для того чтобы это случилось и принесло пользу, а не добавило работы? Начнем с условий, которые…

Евгений Шилов, 13 апреля 2015, последний комментарий 19 мая 2015

Всероссийская викторина по ИТ-менеджементу – в поисках гуру

На этой неделе началась Всероссийская викторина по ИТ-менеджменту. Организаторы – компания NAUMEN и издательство "Открытые системы". Участие открыто для любого желающего, однако, очевидно, интересна она будет причастным к профильной отрасли: специалистам ИТ, ИТ-руководителям, CIO, менеджерам процессов, консультантам. Что необходимо: желание, знания в предметной области, не менее пяти минут свободного времени для ответов на вопросы. Вопросов в викторине 26 штук. И разбиты они на несколько областей: история, автоматизация, методология. Победителям викторины полагаются именные сертификаты с гордым "гуру" в названии. Самым удачливым из них – смартфоны и гаджеты. Среди всех участников будут разыграны подписки на электронные издания. Закончится викторина 15 мая. Спешите поучаствовать…

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

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

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

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