Digital Enterprise

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. Понятие "тормозит" весьма субъективно, для одного пользователя приемлемо подождать 5 минут, для другого – 1 минута ожидания, уже вечность. Операции тоже могут быть разными. Что делать: Зафиксировать, что есть нормальная производительность, то есть, что значит "не тормозит". При этом измерение должно производиться в терминах максимально понятных конечным пользователям, желательно, чтобы пользователи могли самостоятельно повторить операцию и оценить скорость ее выполнения….

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

Модель взаимоотношений с поставщиками

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

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

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

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

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