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

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

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

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

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

То ли делать нечего, то ли коллеги застыдили, а я опять открыл умные книжки, и снова хочу на примере продемонстрировать, что в 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). Включите в политику процесса правило: ответственные лица обязуются проверять имеющиеся инструменты…

Доска аварий

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

Каких ИТ-специалистов найти труднее всего?

Джастин Джеймс в блоге TechRepublic опубликовал десять вакансий в ИТ, заполнить которые труднее всего. ИТ-тренер: уникальный набор навыков и редкий для большинства ИТ-шников разъездной характер работы – делают поиск кандидатов на эту вакансию самым сложным для кадровиков. Менеджер проектов: многие компании вносят в формальные требования к кандидатам сертификацию PMP, и становятся заложниками собственных высоких стандартов: ведь обладателей сертификатов PMI довольно мало и они дорого просят за свой высокий статус. ИТ-директор/Технический директор/CIO и т.д.: как и от тренера, от лидера ИТ-команды требуется нечто большее, чем технические знания. Сотрудник Sevice Desk: ведь те кандидаты, которых действительно хочется нанять на такую стрессовую работу,…

Техподдержка против ИТ-проектов?

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

Вопрос из зала: Нужно ли разделять оперативное и полное решение инцидента

Марина спрашивает: Подскажите, пжл, нужно ли разделять оперативное решение инцидента и полное решение инцидента? например: не формируется автоматически отчет (перестал работать функционал некой системы Х). например, пользователь может вручную создавать этот отчет (оперативное решение=обходной вариант), а исправление кода в системе Х (например, отчет не формируется из-за ошибки в коде) это уже полное решение инцидента? не смешиваются ли здесь понятия — решение проблемы?

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;