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

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Новые экзамены
по ITSM
Реестр ESM- и ITSM-систем в России 2024

Эксплуатация ИТ

Всё про операционный сегмент ИТ и службу эксплуатации ИТ

Инструкция по выбору ПО для Service Desk

Британский Service Desk Institute не только проводит виртуальные и очные конференции по управлению ИТ-услугами, собирая мировых ITSM-звезд и внушительные аудитории, но и выпускает интересные и полезные материалы для профессионалов. Один из таких материалов – вышедшее в ноябре руководство по выбору и покупке ПО для автоматизации Service Desk. Бесплатно доступный для просмотра в интернете и скачивания (в формате Yudu, похожем на djvu) справочник содержит обзоры 20 продуктов, три кейса, рекомендации по выбору вендора и построению взаимовыгодных отношений с ним и полезную главу How to Avoid Being Fools with Tools.  Документ немаленький –  52 страницы, а завершает его алфавитный справочник систем автоматизации…

Для тех, кто не любит ждать

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

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

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

Разрабатывать или покупать приложения: книжный ответ

То ли делать нечего, то ли коллеги застыдили, а я опять открыл умные книжки, и снова хочу на примере продемонстрировать, что в ITIL гораздо больше полезного, чем представляется скептикам. Эпиграфом к ITIL Service Strategy 2007 была цитата Вильяма Д. Грина из Accenture:  How do you become not optional? Её вольно можно перевести так: "Что нужно делать, чтобы без вас не смогли обойтись?". Фраза настолько откровенно и ёмко позиционировала саму библиотеку и описывала чаяния целевой аудитории, что в 2011 году Девид Кэннон, переписывая Стратегию Услуг, вычеркнул её со всем старым вступлением (а многие русскоязычные авторы – еще нет). Но далее по новому тексту…

ROI: 7148%, срок окупаемости: 1 неделя

В известную фразу про ложь, наглую ложь и статистику, похоже, пора добавить четвёртую составляющую: заявления вендоров программного обеспечения. Рецепт изготовления красивого отчёта прост: немного текста, пара-тройка диаграмм, большая таблица с расчётами. При этом таблицу важно красиво оформить, а заполнять можно и нулями. Доказательство гигантского возврата инвестиций при минимальном сроке можно уложить в четыре страницы, отведя примерно 40% ширины страницы под красивые белые поля. Так и поступила недавно некая компания. Хорошо, что с 2008 года в ITSM-индустрии работает специальный сервис, называемый Crap Factoid. Его представитель уже выполнил небольшой анализ упомянутого выше отчёта и присвоил ему высшую категорию: "Extreme Crap Factoid Alert"….

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

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

Эволюция ИТ от ИТ-скептика

Наш друг Роб Ингланд (ИТ-скептик) недавно разгромил в пух и прах очередного вендора, посмевшего отречься от ITIL. Интересна и сама критика и изложенная в качестве аргумента эволюция "ИТ на службе у бизнеса": В начале "ИТ" буквально означало "технологии". Большие компьютеры с мерцающими лампочками. Перфокарты. Большие ящики с бобинами. Гигантские магнитные катушки. Магнитофоны размером с холодильник. Заспанные операторы, контролирующие обработку очередного пакета данных.  Потом рынок осознал, что дело в информации. В моделировании данных. В базах данных. В отчетах. В хранилищах. В электронных таблицах. Технологии развивались, и уже не только верховные жрецы, но и простые смертные получили возможность пользоваться технологиями. Мы создали…

itSMF Russia 2012: “Линейки и градусники”: доклад Максима Зубахи

12 и 13 сентября в Москве пройдет третья всероссийская (и даже международная) конференция независимого форума по управлению ИТ-услугами itSMF Russia. Мы начинаем серию анонсов секции "Линейки и градусники", модератором которой, по сложившейся традиции, выступит заслуженный автор портала realitsm.ru Дмитрий Исайченко. Одним из главных докладчиков станет Максим Зубаха, Заместитель Директора ДИТ в банке "Санкт-Петербург". Максим расскажет о том, как метрики процессов ITSM применяются для решения насущных задач любого управленца. Речь пойдет о мотивации персонала, оценке результатов ИТ-подразделения и способах контроля и влияния на партнеров-контрагентов поставщика ИТ-услуг. Конечно же, тезисы доклада будут подкреплены реальными примерами из рабочей практики докладчика. Мы приглашаем всех…

Вопрос из зала: как организовать мониторинг, который никому не нужен?

Дмитрий, один из читателей нашего портала, предлагает обсудить непростую ситуацию и задаёт три конкретных вопроса: Передо мной стоит задача разработки системы мониторинга ИТ-инфраструктуры в крупной нефтяной компании. Уровеь ИТ-процессов – практически нулевой.  Ни процессы, ни службы (в т.ч. Service Desk) не обозначены, не регламентированы – живут своей дикой жизнью. Существующие нормативные и регламентные документы (в т.ч. SLA) носят формальный характер. Такая СИТУАЦИЯ ВСЕХ УСТРАИВАЕТ. И бизнес и ИТ считают: Применение западных стандартов не для нас; Затраты на стандартизацию, внедрение и поддержание процессного, а тем более сервисного подхода – необоснованными. Естественно, при таком раскладе, возникающие инциденты и проблемы решаются реактивно, в…

Готовые шаблоны документов ITSM

Мы в редакции RealITSM.ru постоянно отслеживаем полезные публикации по теме управления услугами. На прошлой неделе мы рассказали о материалах конференции itSMF в Новой Зеландии. Сегодня – новости из Сингапура. Приятно, когда коллеги добровольно делятся своими знаниями. Блоггер Алисия Чуу (Alicia Choo) поставила перед собой задачу: записать в своем блоге всё, что она знает про управление ИТ-услугами и корпоративное руководство ИТ. Например, на прошлой неделе, Алисия выложила в открытый доступ свои рекомендации по процессу управления событиями, а также шаблон описания процесса (и множества других документов, кстати, тоже – все в GoogleDocs). Включите в политику процесса правило: ответственные лица обязуются проверять имеющиеся инструменты…

Доска аварий

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

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM