Как прорваться через первую линию техподдержки?
В редакцию портала поступил вопрос: Как прорваться через первую линию техподдержки и гарантированно решить проблему?
Всё про управление персоналом в ИТ
В редакцию портала поступил вопрос: Как прорваться через первую линию техподдержки и гарантированно решить проблему?
В редакцию портала поступил вопрос: Добрый день, вводим в эксплуатацию отдел технической поддержки, один из вопросов, который меня беспокоит: как "заставить" пользователей обращаться только в техподдержку? Культура компании сложилась так, что долгие годы пользователи звонят понравившимся им специалистам или просто знакомым. Поделитесь опытом, кто как с этим боролся и как прививали единую точку входа.
Автор заметки 10 of the Best ITSM and Service Desk Blog Sites отмечает, что, несмотря на то, что в блогах можно найти много полезной информации об ITSM, но, как и в Интернете в целом, стоит с осторожностью относиться к тому, что вы читаете, чему верите и на что тратите своё время. Осторожно! Не все (ITSM) блоги равноценны К сожалению, как вы по своему опыту уже наверняка знаете, большинство блогов (в данном случае, ITSM-блогов), можно отнести к одной или нескольким из следующих категорий: Никогда не принесёт пользы читателю. Лучшие ITSM-блоги дают полезные советы или просто пищу для ума. Но некоторые блоги по…
На прошлой неделе летал в Нидерландию, к любимым партнёрам в GamingWorks. Проходил тренинг для тренеров по новой игре "Проект Феникс". Не претендуя на путевые заметки, готов поделиться наблюдениями. Поездка оказалась в высшей степени полезной и воодушевляющей. Про тренинг Первый раз Пол и Ян нас учили году в 2005 или 2006 – тогда это было про игру "Apollo 13". Помню, как помимо стандартной программы мы их мучали бесконечным количеством вопросов: голландцы терпеливо отвечали, разъясняли, показывали. С тех пор и они провели не один десяток сессий ТТТ, и мы освоили не одну деловую игру. Тем не менее, именно обучением Ян владеет виртуозно….
Барклай Рэй (Barclay Rae), соавтор ITIL Practitioner Guidance, в недавней записи в блоге AXELOS утверждает, что мы вступаем в пору, когда следование процессам и наличие у специалистов сертификаций не будут иметь такого значения, как прежде. В свою очередь важность навыков эффективной коммуникации, лидерства и понимания бизнеса возрастет многократно. Такие явления как консьюмеризация ИТ, не просто рост, а ускорение тема роста спроса в ИТ со стороны бизнеса и потребителей, ставят во главу угла гибкость и снижают важность следования процессам. Достижение целевых значений в SLA и выполнение KPI уже не достаточно, что только подтверждает растущий интерес к Agile и DevOps. Мы в ИТ все больше нуждаемся в…
Очень часто на курсах слышишь фразы «заказчик не заинтересован в нас», «он не видит в нас тех, кто может обеспечить его нужды», «как донести заказчику свою значимость и состоятельность», «заказчику в SLA интересна только одна строчка». Бывает, что ИТ-департамент выступает с инициативой улучшить что-то в своей деятельности: оптимизировать шаги получения конечных результатов, сократить расходы, увеличить производительность, но терпит неудачи. Казалось бы, основательно подготовились – освоили какие-то подходы, методики, получили много знаний. Но не взлетает. Или быстро падает. В чем же дело? В зависимости от того, у кого созрела идея улучшений, то есть на каком уровне вертикальной организационной иерархии, нужно прояснить много…
В редакцию портала поступил вопрос: Коллеги, добрый день! Скажите, кто-нибудь имеет опыт увязывания результатов работы конкретных сотрудников по выполнению запросов/нарядов с их премиями? Понятно, что корреляция не 100%-я, мы хотим, чтобы был коэффициент для каждой должности, кто на сколько процентов вовлечен в обработку запросов — столько процентов премии и будет зависеть от выполнения запросов… интересует сама методика и опыт. Спасибо!
Обращаем ваше внимание на то, что дата вебинара "Управление ИТ: каким оно будет завтра?" с Романом Журавлёвым, менеджером по развитию ITSM-продуктов в AXELOS, перенесена на 1 июня 2017. Если вы уже отметили этот день в своём календаре, внесите, пожалуйста, соответствующие изменения Если вы еще не зарегистрировались для участия в вебинаре, можно сделать это прямо сейчас, пройдя по ссылке. Ссылки на регистрацию на остальные вебинары весеннего сезона 2017 на сайте Cleverics. Пользуясь случаем, хотим поздравить Владимира Андреева, который поставил 800-й лайк нашей странице на Фейсбук. Традиционно, каждому, кто поставит лайк, кратный 100, мы дарим нашу книгу. В этом году – это "RealITSM:…
…куда планировали, куда ожидали. Речь о курсах по управлению ИТ. Бывает, что человек приходит и с первых (или не с первых) слов, понимает, что материал курса слишком сложный, что это не совсем то, чем он занимается. Что же делать? Во-первых, лучше провести предварительные подготовительные работы – а именно, выяснить как можно больше информации о курсе у наших менеджеров по продажам, зайти на наш сайт и ознакомиться не только с описанием курса, но и с подробной программой. В случае, если вас направляет на курс руководство – сделайте те же предварительные приготовления, а также уточните, какие цели перед вами ставятся, что то…
Есть такая тенденция – хороший сервис-провайдер пытается стать сервис-интегратором. Наверное, как солдат – генералом. Не всегда, конечно, но часто. Особенно если это провайдер коммерческий и расширяет таким образом свою долю рынка. И от этого может быть польза и клиентам, и самому интегратору, и участникам интеграции. Не обязательно будет, и не обязательно всем, но может. Есть еще одна тенденция, гораздо более печальная. Интеграторы плохо умеют и не очень хотят отвечать за качество услуг. То есть на витрине у них, конечно, единые стандарты, тщательный контроль и единая поддержка. Но на практике – сплошной уход от ответственности и перевод стрелок. Болезненный и актуальный…
В редакцию портала поступил вопрос: Добрый день всем! У меня с нашим проблем-менеджером возник спор, кто же все-таки должен контролировать решение ИТ-проблем? Он утверждает, что инцидент-менеджер, он же инициатор проблемы, должен вести непрерывный контроль за решением проблемы, при необходимости "пинать" инженеров или change-менеджемент, который решает проблему, так ли это? В моем понимании инцидент-менеджер безусловно является инициатором проблем, но далее он передает это на уровень проблем-менеджмента, и в его зоне остается лишь окончательная проверка и подтверждение устранения проблемы.