Эксплуатация ИТ Archives – Страница 14 из 17

Перенос сроков

Уже несколько раз всплывала тема сроков, неважно чего: решения инцидентов, выполнения работ и т.д. И каждый раз когда мы обсуждаем эту тему на семинарах проектирования обязательно возникает вопрос переноса сроков. В основном причина переноса в том, что кто-то не хочет портить статистику/отчетность из-за задержек "по объективным причинам". Особенно ожесточенно вопрос обсуждается, если на горизонте маячит привязка системы мотивации к метрикам, связанным со сроками. На досуге задумался о том, что необходимо предпринять, чтобы избежать произвольных переносов сроков до бесконечности. Для примера возьмем наши любимые инциденты. Как мне кажется, есть два основных вопроса на которые надо ответить: Кто? Когда (при каких условиях)?…

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

Вопрос из зала: Перспективы диагностики инцидентов «на лету»

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

Вопрос из зала, 21 марта 2013, последний комментарий 27 марта 2013

Вопрос из зала: доступность и её команда

Алексей Тюрин спрашивает на нашей страничке в Фейсбуке: Добрый день! Помогите пожалуйста разобраться в чем разница между reliability и dependability (нет в глоссарии). И то и другое согласно ГОСТУ – надежность – т.е. свойство объекта сохранять во времени в установленных пределах значения всех параметров… Тем не менее в другом контексте говорится, что depentability – это reliability и availability. В этом случае, если reliability – надежность, то что такое dependability? Безотказность? Т.е. безотказность это надежность и доступность (способность объекта выполнять согласованную функцию, когда это требуется). Правильным ли будет такой вывод? Спасибо! Давайте распутаем эту терминологическую красоту в комментариях.

Вопрос из зала, 4 марта 2013, последний комментарий 11 марта 2013

Личные мобильные устройства на работе: как быть?

Ну что ж, пришла, видно, пора поговорить про BYOD на этом портале. Дело в том, что эту тему поднял один из слушателей на последнем курсе про CMDB, управление конфигурациями и активами. На курсе разразился традиционный спор: как правильнее учитывать условные мониторы на рабочих местах – индивидуально, по инвентарным номерам или как прототип. Никто никого не переспорил (надеюсь), а в конце всплыл еще один кейс. Сотрудникам компании моего слушателя разрешили носить на работу и использовать в служебных целях личные планшеты, смартфоны и плафоны. Мол, как в Гугл. А ИТ-команде – головная боль. Кроме традиционных для подхода Bring Your Own Device рисков,…

Константин Нарыжный, 15 февраля 2013, последний комментарий 27 февраля 2013

Конвейер в ИТ

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

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

Самое лучшее в ITSM по-русски

Этот декабрь выдался богатым на анонсы книжного рынка. Параллельно с книгой Романа Журавлёва коллектив авторов портала Real ITSM подготовил к изданию сборник собственных статей. Самое лучшее и практичное из мира ITSM уже доступно для загрузки в формате PDF. В сборнике вы найдёте: фундаментальные статьи: и напечатанные в альманахах itSMF, и выходившие в печатной прессе, и не издававшиеся ранее дотошные вопросы к западным ITSM-экспертам и их робкие точные ответы картинки и опечатки идеальную вёрстку линейки и градусники модели и формулы итоги многодневных дискуссий с вами на портале Real ITSM Читайте на здоровье. А свои отклики и замечания оставляйте здесь, в комментариях.

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

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

Новостной поток, 2 декабря 2012, последний комментарий 3 декабря 2012

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

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

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

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

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

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

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

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

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

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

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

Новостной поток, 9 октября 2012, последний комментарий 12 октября 2012

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

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

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