Digital Enterprise

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

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

Денис Денисов, 26 июля 2017, последний комментарий 7 августа 2017

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

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

Новостной поток, 25 июля 2017, последний комментарий 2 августа 2017

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

Рассмотрим два из трёх принципов, которые, по мнению 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 система мне позволила на основе данного инцидента создать проблему, которую перевести на вторую линию, к которой можно приклеить прошлые такие…

Вопрос из зала, 18 июля 2017, последний комментарий 2 августа 2017

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

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

Вопрос из зала, 17 июля 2017, последний комментарий 2 августа 2017

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

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

Новостной поток, 17 июля 2017, последний комментарий 17 июля 2017

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

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

Новостной поток, 16 июля 2017, последний комментарий 17 июня 2019

Шесть правил построения модели аллокации ИТ-затрат

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

Дмитрий Исайченко, 16 июля 2017, последний комментарий 17 июля 2017

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

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

Дмитрий Хруслов, 12 июля 2017, последний комментарий 13 июля 2017

Адаптивные модели изменений

"Жизнь многообразна, бумага не бесконечна!" )) "Ну хорошо, а сколько их нужно сделать?" Этот весьма насущный вопрос возникает, когда начинаешь проектировать модели изменений. Мы уже делились на нашем портале разными мыслями по поводу моделей изменений. Например, здесь и здесь. А здесь даже лежит вебинар по данной теме. Но если мы говорим, что модели позволяют учесть различную специфику проведения изменений в зависимости от того, как это изменение классифицировано, то каков должен быть масштаб проработки этой специфики? Какова должна быть детализация того самого классификатора? И какие конкретно параметры изменений должна настраивать модель? Как обычно, следует искать рациональный баланс. Чётко прописать всю специфику вплоть до…

Артём Мукосеев, 9 июля 2017, последний комментарий 13 июля 2017

Продаём DevOps высшему руководству

В последние месяцы в общении с коллегами, клиентами и партнёрами регулярно наблюдаю примерно такой диалог: — Эх, всё так стремительно меняется! Конкуренты запускают новые продукты, клиенты становятся всё более придирчивыми и продвинутыми. Прямо чувствуется, как мы всё больше и больше отстаём. — Что же мешает вам двигаться быстрее? Есть же новые подходы, успешно применяемые в разных организациях. Тот же DevOps, к примеру. — Это да, было бы круто. Но это же большая перестройка! — Разумеется. Но ведь дорогу осилит идущий. С чего-то надо начинать. — Нет, у нас не выйдет, руководство не поддержит. То, которое в бизнесе. Ведь им тоже…

Олег Скрынник, 8 июля 2017, последний комментарий 10 июля 2017

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

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