Практика и опыт Archives – Страница 44 из 53

Почему организационные изменения настолько трудны?

Любое масштабное мероприятие, связанное с улучшением эффективности работы компании, является организационным изменением. Небольшие улучшения (к примеру, "давайте добавим ещё один способ взаимодействия с нашим Service Desk") реализовать на практике, как правило, не очень сложно. Более масштабные инициативы даются во многих случаях непросто. Почему? Крупное организационное изменение от небольшого отличается тем, что влияет на всю организацию или её существенную часть, а также в большинстве случаев серьёзно затрагивает и внешних контрагентов. Для традиционного ИТ-подразделения это означает, что более половины ИТ-сотрудников должны будут так или иначе изменить привычный способ выполнения работы, да и сотрудники бизнес-подразделений, взаимодействующие с ИТ-отделом или зависимые от него, получат…

Олег Скрынник, 11 ноября 2012, последний комментарий 14 ноября 2012

ORBIT или методика обоснования ITSM-проекта снизу вверх

То, что ITSM в целом и ITIL в частности являются инструментами управленца, а не самоценными результатами «внедрения» известно многим. То, что из этого следует, что подходить к организации каких-либо процессов ITSM надо с задач, а не с перечня процессов, так же известно многим. Тем не менее, «знаю» не превращается в «делаю» само собой. Например, мы регулярно получаем на вход RFP с формулировками типа «Цель проекта – внедрение управления изменениями и конфигурациями». И далее, конечно «пришлите коммерческое предложение» или «сколько будут стоить ваши услуги по внедрению?». Иногда постановка незначительно варьируется и цель проекта формулируется как «Повысить качество управления ИТ» (без «излишних» деталей, разумеется) и…

Дмитрий Исайченко, 28 октября 2012, последний комментарий 2 ноября 2012

Вопрос из зала: штрафы за неработающее ПО

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

Вопрос из зала, 23 октября 2012, последний комментарий 31 октября 2012

Троянские проекты – лукавство или позитивный побочный эффект?

Недавно на одном мероприятии довольно большие консультанты рассказывали про довольно большой ITSM-проект в довольно большой компании. Я, увы, на мероприятии не был, доклада не слышал, и потому не хочу называть никого по имени. Не в конкретном проекте дело. В презентации о проекте был, конечно, слайд про цели проекта (случайно попался на глаза). И цели там были такие: Предоставление результативной и рациональной ИТ-поддержки для конечных пользователей Повышение рациональности действий ИТ-персонала при предоставлении поддержки …а также (не заявлены официально): снижение зависимости качества ИТ-услуг от квалификации ИТ-персонала снижение сложности поддержки ИТ-систем создание надежного источника данных для принятия решений в ИТ повышение адаптивности ИТ…

Роман Журавлёв, 13 октября 2012, последний комментарий 23 октября 2012

Ошибка, которую провайдер может сделать лишь однажды

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

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

Вопрос из зала: упрощение эскалации

Наш коллега Евгений запросил совета у профессионалов. Вам, уважаемые читатели realitsm.ru, мы и адресуем следующий кейс: Добрый день! Хотелось бы спросить совета у профи. Наша компания занимается IT аутсорсингом. Из персонала мы имеем следующее: команда технической поддержки (первая линия – операторы, вторая линия – инженеры руки-ноги, третья линия – умные инженеры), команда сетевиков, которая занимается монтажом кабелистики, шкафов, ИБП, электрики и т.д., команда связи, которая занимается организацией работы IP телефонии на базе CISCO и команда виндовых серверов и сервисов, которая занимается серверами, почтой, фаерволами и прочими серверными компонентами. Суть проблема вот в чем: например, поступило обращение от пользователя: не звонит IP…

Вопрос из зала, 1 октября 2012, последний комментарий 11 октября 2012

Тесты интеллекта как инструмент поддержки пользователей.

Говорят, для того, чтобы разгрузить перегруженных операторов поддержки, можно перехватывать часть обращений разными средствами автоматизации – порталами, IVR и тому подобными. Но мало кто знает, что эти же средства прекрасно подходят для тестирования интеллектуальных способностей (и, вероятно, других особенностей личности), чтобы потом на основе результатов тестов… делать что-нибудь. Чем больше процедура обращения в службу поддержки похожа на квест, тем больше поставщик услуг узнает о пользователях. А они – о поставщике, кстати. Позвонил я недавно в службу поддержки клиентов одного банка. Там, конечно, ответила механическая женщина, которая предложила мне зайти в систему автоматизации. Я согласился, и она попросила меня ввести номер карты….

Роман Журавлёв, 1 октября 2012, последний комментарий 13 октября 2012

Мини-кейс: выбираем приоритеты

Подискутировал тут со слушателями спец-курса «Управление инцидентами» про выбор приоритета инцидентов. Общие слова про то, что правила назначения приоритета призваны помочь исполнителям скорее выбрать, какую задачку делать первой, и про то, что приоритет – это всего лишь алгоритмически определяемый признак, который всё равно нужно дополнять живой головой, принимающей решения, были сказаны. Дело в том, что в этой организации есть регламент процесса, где, во-первых, приоритет однозначно определяет целевой срок устранения инцидента, а еще заданы признаки выбора приоритета. Примерно такие: Приоритет «Высокий» – сбой затронул работу всех пользователей Приоритет «Средний» – сбой затронул значительное число пользователей (более 80% по оценке ИТ-специалиста»). Приоритет…

Константин Нарыжный, 28 сентября 2012, последний комментарий 21 октября 2012

Проверено временем, ещё раз

Сообщение от редакции портала: только что произведено плановое обновление раздела "Проверено временем", который содержит подборку ссылок на самые читаемые, обсуждаемые и интересные записи различных авторов, независимо от даты публикации. В результате обновления количество полезных ссылок удвоилось и теперь равно семидесяти. Материалы добавлены почти во все рубрики, но особенно – в рубрику "Проектная практика", которая стала самой большой. Редакция желает вам приятного чтения и обретения новых знаний. (кстати, все старые записи доступны для комментирования)

Вопрос из зала: есть ли плюсы в портале самообслуживания?

Анна Лобова, IT Manager и постоянный читатель нашего портала, а также регулярный участник ITSM-вебинаров, задаёт вопрос в виде развёрнутого кейса. Анна просит наше сообщество помочь ей и раскритиковать кейс в пух и прах. Давайте поможем. Не секрет, что без каталога услуг, SLA, базы знаний, системы регистрации и учета запросов сотрудникам ИТ живется нелегко: пользователи просят все что хотят и прямо сейчас. Очевидность необходимости всех этих и других «айтиловских примочек» объяснять в очередной раз не стану. Но как предоставить пользователям эти данные в удобном формате и более того: как собрать их вместе и залинковать между собой таким образом, чтобы не…

Вопрос из зала, 17 сентября 2012, последний комментарий 19 сентября 2012

Функциональная эскалация

Недавно в свете выпуска нового релиза CleverENGINE обсуждали внутри тему функциональной эскалации в управлении инцидентами. Этот, на первый взгляд, несложный вопрос на практике имеет очень важное значение, а принятые по нему решения определяют не только принципы разграничения ответственности за поддержку пользователей, но сказываются и на структуре каталога ИТ-услуг, и на содержании SLA. Так вот можно выделить два принципиально различных способа функциональной эскалации: с произвольным маршрутом и с фиксированным маршрутом. В случае произвольного маршрута специалист, отвечающий за обработку инцидента, выбирает следующий шаг эскалации самостоятельно, в зависимости от результатов диагностики. Например, инцидент, связанный с отказом информационной системы по результатам диагностики может быть…

Дмитрий Исайченко, 11 сентября 2012, последний комментарий 22 сентября 2012

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

Практика и опыт

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