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

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

Обо всём на свете

Разговоры обо всём, за что “зацепился взгляд”.

«Культура съедает стратегию на завтрак»

В теперь уже далеком 2005 году известный социолог и консультант, автор книг, Питер Друкер произнес эту фразу на заседании по развитию компании Ford. Он подразумевал, что можно иметь любую формализованную стратегию, но если у людей не принято соответствующее поведение, то никакой стратегии не будет, а значит никаких высоких (или не очень) стратегических целей компании не достичь.  Это про то, насколько люди готовы жить по тем или иным правилам, готовы к тем или иным переменам, способны их реализовать. Как сказал один психолог: «…для бирюзовой организации должны быть бирюзовыми люди». Корпоративная культура — совокупность моделей поведения, которые приобретены организацией в процессе адаптации к…

Две стороны одной медали

На днях со мной произошли два события, которые оказались причудливо связаны друг с другом по своей сути. Первое из них – прохождение теста по ситуационному поведению Херси-Бланшара, второе – знакомство с соседом по дому, который тоже оказался ИТ-ником. Сразу вспомнились старые-добрые времена, когда системные и почтовые администраторы, администраторы баз данных были чуть ли не богами в ИТ-мире. Честно говоря, я давно уже такого не видел. Кажется, это было недавно, лет 15 всего прошло. Тогда без их помощи трудно было что-то сделать, на них многое держалось. И понятно почему: инфраструктура состояла из физических серверов, каналов связи, хранилищ. Её нужно было холить…

Цифровое рабочее место – трансформация современного предприятия

Цифровая трансформация – горячая тема для многих предприятий. Это больше, чем просто внедрение новых технологий для рабочего места, и зачастую, следовать ей необходимо, чтобы оставаться конкурентоспособными в быстроменяющемся мире. Переход к цифровому рабочему месту – важный шаг для современного бизнеса. Новые исследования, посвященные тому, как организации проходят путь от традиционной офисной среды к цифровому рабочему месту, показывают, что получение конкурентных преимуществ и совершенствование бизнес-процессов являются главными целями их стратегий цифровой трансформации. Так считают 40% опрошенных  из 800 компаний из 15 стран на пяти континентах, согласно опубликованному на днях отчёту Digital Workplace Report: Transforming Your Business. Ещё одно открытие этого отчёта состоит в том,…

Кто бреет брадобрея?

Рассмотрим два из трёх принципов, которые, по мнению Gene Kim, определяют DevOps. Они сформулированы в его статье «Три пути: Принципы, поддерживающие DevOps» («The Three Ways: The Principles Underpinning DevOps») и подробно описаны им в книге «The DevOps Handbook». Так называемые второй и третий пути DevOps: создание постоянного быстрого потока обратной связи, что позволяет максимально рано выявлять проблемы и устранять их максимально быстро, не допуская передачи дефекта по потоку создания ценности (в сторону эксплуатации/потребления) и предотвращая повторения проблем (рис.1 [с сайта itrevolution.com, Copyright © 2017 IT Revolution]) создание креативной культуры высокого доверия, поддерживающей экспериментирование и извлечение уроков как из успеха, так…

Problem Management: эскалация инцидента на вторую линию

В редакцию портала поступил вопрос: Коллеги, добрый день! Прочитал много материалов, касающихся Problem Management. Совсем не прочувствовал идею, что Управлению проблемами сложно внедрять и до него нужно "дорасти". Возьмем на примере. Звонит пользователь, и говорит, что не может на компьютер зайти — заблокирована учетная запись. Причем утверждает, что это происходит каждый день. Проверяю по тикетам — так и есть. Каждый день мой сотрудник первой линии успешно решает данный инцидент. То есть налицо наличие проблемы. Но Problem Management не выстроен. Я хочу, чтобы ITSM система мне позволила на основе данного инцидента создать проблему, которую перевести на вторую линию, к которой можно приклеить прошлые такие…

Как мотивировать пользователей подавать заявки в Service Desk через портал?

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

Shift Left и трансформация службы поддержки

Интересными наблюдениями и рекомендациями, по результатам двухлетнего проекта трансформации службы поддержки, делится Ричард Сикора (Richard Sykora) (оригинал статьи A Support Center Transformation to Shift Left). Основная цель проекта была обеспечить «shift left» организации поддержки. Ричард пишет: "Cтратегия сдвига влево, на самом деле, очень проста. В левой части спектра у вас есть наименее затратная модель поддержки ваших конечных пользователей. В ней обычно нет людей, которые помогают пользователям, он широко известен, как нулевой уровень или самообслуживание. В центре спектра у вас может быть вспомогательный персонал, однако, это скорее сценарий «много-к-одному», например, чат. Дальше вправо по спектру соотношение уже «один-к-одному» между конечными пользователями…

12 «лучших практик» в ИТ, которых следует избегать любой ценой

Начиная от слов «вы – наши заказчики» и заканчивая «облачной» стратегией – эти «лучшие практики отрасли» погубят вас. В чем причина неудач ИТ-компаний? Очень часто – это использование так называемых «лучших практик», описанных людьми, которые могли бы знать побольше о предмете, но не знают, возможно, потому, что никогда этим не занимались. Начиная от определения «внутренних заказчиков», и заканчивая внедрением практики внутреннего выставления счетов для обеспечения рентабельности инвестиций. Большинство этих советов внушают доверие с расстояния более ста километров. Однако стоит стереть верхний слой и вы поймете, что многие из них на самом деле – верный путь к провалу. 1. Все вокруг…

“… многоликий Вы наш”

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

Давайте будем осторожны, когда тратим деньги, и другие мифы о технической поддержке

Оригинал заметки Let’s Be Careful How We Spend Our Money: And Other Tech Support Myths, автор Рой Аткинсон (Roy Atkinson) Не так давно у меня был разговор с человеком из очень большой компании, очень-очень большой компании с сотнями тысяч сотрудников. Они сбрасывают пароли вручную. За прошлый год их служба технической поддержки проделала это 600 000 раз. Давайте быстро и, не сильно вдаваясь в детали, посчитаем. Средняя стоимость каждого тикета, если верить отчету HDI 2016 Technical Support Practices & Salary Report составляет $ 18,50. Но сброс пароля всё-таки относительная простая и быстрая операция, поэтому давайте оценим его в половину стоимости: $…

Правильная последовательность внедрения ITSM-процессов

В редакцию портала поступил вопрос: Добрый день, коллеги! Наша компания находится на этапе внедрения процессов ITSM. В качестве первоочередных к внедрению процессов остановились на 6: управление обращениями, управление инцидентами, управление запросами на обслуживание, управление изменениями, управление конфигурациями, управление проблемами. Возник спор: в какой последовательности внедрять процессы. Я считаю, что правильнее было бы сперва смоделировать и описать регламенты всех шести процессов, а уже после этого формировать требования для разработчиков системы автоматизации, автоматизировать и обучать персонал новым правилам работы, т.к. часть изменений в системе автоматизации по одному процессу затронет и другие. Коллеги придерживаются мнения, что внедрять каждый из процессов нужно последовательно. Подскажите, есть…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM