Коммуникативные задачи ИТ

от автора

Менеджмент процессов: коммуникации, цели, инструменты управления

Решение коммуникативных задач — это один из основных вопросов управления ИТ. Такая точка зрения у Роберта Гоутэма, довольно весомого специалиста в области проектного управления из Канады.

За типичной диаграммной гранта в ИТ скрывается множество коммуникативных проблем. Обсуждения, коммуникации—это время, человеческий фактор и высокий риск ошибки.

Проблемы коммуникаций связаны с необходимостью договариваться и согласовывать требования, разграничивать зоны влияния и ответственности за проблемы и риски‑это не просто.

Поразмышляем над системными решениями задач коммуникаций. Наиболее распространённый подход в управлении ИТ на данный момент‑это сервисно — ресурсная модель. В рамках данной парадигмы ИТ — предприятие предоставляет бизнесу сервис, который регулируется SLA, специальными соглашениями об уровне предоставления услуг. При таком подходе, консультация или ремонт в ИТ должны быть предоставлены в течении заранее согласованного времени. Вместе с тем, в исключительных случаях, ИТ — предприятие может использоваться бизнесом, как ресурс, которым можно распоряжаться по своему усмотрению прями сейчас.

Сервисно‑ресурсная модель управления опирается на процессный подход, который, в свою очередь, чаще всего реализуется на базе практик ITIL. ITIL можно трактовать, как набор рекомендаций по построению процессов управления ИТ.

Если присмотреться к этим процессам, то можно заметить, что большинство из них направлены на решение задач оптимизации и структурирования коммуникаций.

Управление изменениями решает такие коммуникативные вопросы, как согласование требований, планирование и информирование. Управление инцидентами информирует об оперативности устранения сбоев, о наиболее оптимальных обходных решениях, о том, что делать во время сбоя. Управление проблемами информирует о состоянии ИТ, оперативности устранения причин сбоев, о лучших практиках решения проблем, о готовых моделях проблем, о сценариях решения и порядке взаимодействия при решении проблем. Управление обращениями базируется на диалоге с пользователем.

Плохие коммуникации дорого стоят.

«Девяносто шесть процентов программного обеспечения в настоящее время находится в среде эксплуатации и тестирования. 96% этого программного обеспечения работает», ‑отчиталось в мае 2022 года руководство австралийской фондовой биржи о внедрении системы электронных субреестров клиринговой палаты (CHESS). К ноябрю 2022 года ситуация выглядела совсем иначе: независимая проверка, проведённая консалтинговой фирмой Accenture, показала, что только 63% программного обеспечения было поставлено, а 50% из них нужно было переписать. На стратегическом уровне были даны ложные обещания. Проект провалился, суммарные убытки составили порядка 500 млн. австралийских долларов. Ссылка. В данной ситуации очевидны, искажение информации и плохие коммуникации. Здесь видно, что в IBM не отработали процессы управления проблемами (отсутствовала информация о проблемах разработки) и управления изменениями (искажена информация о результатах и текущем состоянии проекта).

При внедрении процессов нужно учитывать, что коммуникации играют определяющую роль в управлении ИТ. Если при внедрении процессову игнорировать задачи коммуникаций, процессная модель будет нелепой, как пиджак с разными рукавами.

Задачи оптимизации управления ИТ. Технократический сегмент.

Цель внедрения процессов в ИТ—это снижение стоимости управления, которая измеряется в сроках, деньгах, результативности управленческих решений. Выстроить процессы так, чтобы «все цели были достигнуты» — это отдельная задача управления. Менеджмент процессов управления ИТ— это, отдельная, довольно серьёзная работа, которой часто занимаются люди, находящиеся в технократическом сегменте предприятия.

Технократический сегмент чаще всего оформляют в организационную структур, управляющую сервисом. Управление сервисом опирается на менеджмент процессов ИТ, которые, в свою очередь регулируют деятельность операционного блока и сегмента административного управления.

Результативность технократического сегмента измеряется в количестве устранённых несоответствий, отклонений, в количестве внедрённых улучшений организационного дизайна компании.

Итак, на примере австралийской фондовой биржи, мы увидели, как плохое управление (процессы, коммуникации) в стратегическом сегменте может принести значительные убытки.

На уровне административного управления, если игнорировать процессы и их показатели, то тоже могут возникнуть неприятности. В ИТ, как и везде возможна «кампанейщина».

Компания IBM, в период с 2010 по 2014, в рамках инициативы «Дорожная карта 2015» поставила целью повышение акционерной стоимости компании (EPS). Цена акций выросла с менее чем 130 долларов в начале 2010 года до почти 215 долларов к 2013 году. Несмотря на отличный краткосрочный результат, в 2014 году стоимость акций упала до 160 долларов и ниже. Погоня за прибылью шла за счёт снижения инвестиций в продукты и людей. Информация об увольнениях сотрудников, их низком моральном духе и конфликтах в коллективе просочилась за пределы компании.

Как ни странно, но не было измеримых индикаторов (показателей), которые бы говорили о проблемах у потребителей ИТ‑услуг IBM. В связи с финансовыми успехами, на административном уровне не контролировались факторы рисков деградации качества продукта. в 2014 году компания IBM остановила гонку за акционерной прибыльностью и организовала контроль производственных показателей.

Данная история подчёркивает необходимость видеть предприятие и его операционные показатели, производственные процессы. В IBM признали, что забывать про людей в ИТ — это очень дорогое удовольствие. Неумение видеть важное превращает коммуникации в обсуждения бабушек у подъезда. Очевидно, что задачей коммуникации в данном случае является задача согласования ценности призводственных и кадровых требований.

Поговорим о некоторых инструментах управления ИТ, позволяющих позволяют видеть производственные процессы, не забывать о них и вовремя корректировать.

Инструменты управления при процессном подходе в управлении

Хорошо настроенный процесс, является основным инструментом управления. Процесс первичен, тюнинг процессов — это искусство. Такие инструменты, как Service/Help Desk, Дашборды, аналитические BI‑системы и т. п. вторичны.

Одним из мощнейших инструментов управления ИТ является процесс «Управление проблемами».

На операционном уровне ИТ (Контакт‑центр, техподдержка, администрирование. разработка и т. п.) данный процесс обеспечивает снижение затрат на управление при диагностике и решении проблем. Он организует взаимодействие между участниками процесса. Первые лица предприятия так же участвуют в процессе при решении масштабных проблем. На уровне административного управления процесс регламентирует оперативность решения организационных проблем, повышает качество управления обычными проблемами. На стратегическом уровне осуществляется управление стратегической проблематикой, связанной с внешним миром, ресурсами, организационным дизайном и т. п.

Свяжем с нашим процессом BI‑систему Apache SupreSet (бесплатное ПО для аналитической работы с разнородными данными). Данные о процессе «Управления проблемами» обычно хранятся в какой‑нибудь Service Desk (ITSM) системе. Свяжем эти две системы, благо Apache SupreSet гибок. Для хороших коммуникаций требуются хорошие данные и агрегированные и декомпозированные в разных разрезах. Обеспечение управления качественными(актуальными, достоверными и объёмными) данными—это одна из задач коммуникаций.

Создадим дашборд на какую‑либо услугу, чтобы видеть её проблематику. Умелыми руками можно сделать так, чтобы руководитель будет знать количество проблем услуги, разбивку проблем по причинам, их стоимость, и детали, которые получаются через пару кликов по диаграммам.

Тот, кто занимается настройкой процессов (менежер процессов) исследует проблемы, на всех уровнях, как на операционном, так и на организационных. Он изучает инциденты и изменения, связанные с проблемами. Их можно увидеть в деталях, привязанных к диаграммам. У меня для инцидентов отдельная вкладка на дашборде.

Инциденты исследуются по следующим направлениям: состояние проблемной и смежной ИТ‑инфраструктуры, оперативность устранения инцидента, готовность к сбою (действовали по сценарию или как в первый раз), качество взаимодействия при устранении, информирование, коммуникации и т. п. Технологии работы с инцидентами регулирует процесс Управление инцидентами.

При анализе состояния ИТ важно видеть изменения, происходящие в ИТ, их влияние на проблематику: есть изменения решающие проблемы, а есть изменения, которые приводят к инцидентам. Дашборд для анализа изменений может выглядеть так:

Очень важно правильно классифицировать изменения ИТ‑инфраструктуры. Изменение может выполняться в рамках внедрения, эксплуатации, устранения инцидента, проблемы или тестирования. Успешность, оперативность, риски изменений — это важные нюансы. Технологии управления изменениями регулирует процесс Управление изменениями.

Хорошо настроенная BI‑система позволяет различным сегментам ИТ‑ предприятия видеть одну и ту же картинку. Это очень удобно за несколько щелчков мышью видеть детали общей картины ИТ‑ предприятия. Увидеть детали того или иного показателя в пару кликов‑ это великолепнейшая фантастика!

ПОКАЗАТЕЛИ.

Технократический сегмент ИТ определяет показатели, обеспечивая измеримость деятельности. Измеримость—важна при коммуникациях контроля и оценки требований, к примеру. Любопытная задача коммуникаций со множеством ловушек.

Часто возникают комичные ситуации.

В одной из ИТ‑компаний в качестве мотивирующего KPI внедрили показатель количества программных модулей и микросервисов информационных систем. Количество модулей и микросервисов резко увеличилось, архитектура, наполнившись неоправданными деталями, стала нечитаемой, производительность информационных систем снизилась.

Показатели‑носители информации о предприятии, ключевые элементы цифрового двойника организации. Процессный подход в управлении использует большое количество показателей: метрик, КПЭ. Часто после выполнения своей задачи, показатели «забывают» утилизировать и они ложатся неприятным грузом на подразделения. Я выстраиваю жизненный цикл показателей (создание → использование → утилизация) в контексте жизненного цикла организационных проблем (выявление → решение → утилизация).

Здесь мы видим, что подразделение контролируется с помощью показателей в течении короткого времени, на период решения той или иной организационной проблемы. Остальное время показатель мониторится аналитиком в фоновом режиме.

Данный подход обеспечивает постоянное развитие предприятия с точки зрения сервиса. Такой формат управления требует очень высоких компетенций от технократов, разработка показателя должна происходить множества стейкхолдеров, что так же является довольно интересной коммуникативной задачей.

Это простая, на первый взгляд, архитектура управления показателями сложна в реализации, но приносит довольно фантастические эффекты.

Приведу пример процесса Управления Проблемами.

Мы видим, что вопросы дисциплины исполнения процесса решены, решаются вопросы качества решения проблем и планируется внедрение механизмов управления проактивными проблемами и обходными решениями.

Показатели — это ключевой элемент коммуникаций: совещаний, мозговых штурмов, игр.

Коммуникации

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

На различных уровнях предприятия различное понимание терминологии, результатов и ответственности. Если говорить о больших ИТ‑бюрократиях, то даже у подразделений со схожими функциями различное понимание и видение технологий управления. Обеспечение единой трактовки смыслов — это так же задача коммуникации, довольно необычная, на первый взгляд.

В больших ИТ‑бюрократиях часто возникают противоречия при определении ответственности за те или иные события. К примеру, пусть у нас организационно разделены разработка и эксплуатация информационных систем. Непросто определить кто должен отвечать за оперативность устранения сбоя (MTTR), который произошел из‑за некачественного программного обеспечения: администратор или разработчик? Задача формализации решения спорных вопросов—это так же вопрос коммуникаций, который решается определением правил спорных вопросов, в рамках регламентов, к примеру.

В 2005 году компания по утилизации отходов Waste Management подписала с SAP договор о приобретении программного обеспечения. SAP утверждала, что у неё есть готовое решение для Waste Management. президент и генеральный директор SAP Americas Билл Макдермотт, участвовали в демонстрациях. Когда программное обеспечение было приобретено, оказалось, что в нём отсутствовали многие базовые функции. Две компании по‑разному понимали, что такое «готовое программное обеспечение». Убытки, возникшие из‑за разночтений требований к программному продукту, составили порядка 100 млн. долларов.

Очень важно в процессе коммуникаций говорить на максимально схожем языке. Хорошо проработанный процесс‑всегда задаёт параметры взаимодействия, в том числе параметры. Процесс, регулирующий приёмку программных продуктов‑это процесс управления поставщиками, который определяет порядок приёмки, тестирования, проведения испытаний и т. п..

Результатом решения проблем коммуникаций в ИТ‑являются сценарии решения спорных вопросов, которые оформляются в виде регламентов процессов, соглашений и т. п. В сформированных документах фиксируется ответственность, последовательность действий, сроки, требования к промежуточному и финальному результату…

Решение проблем коммуникаций происходит на совещаниях, которые проводятся в форме мозговых штурмов, игр, коммуникаций.

В умении видеть ИТ сквозь призму коммуникаций, пожалуй и заключается основной залог успеха построения успешной модели управления. Зачастую проекты внедрения ITSM, сервисно‑ориентированных подходов не приносят ожидаемых результатов именно по причине недостаточной организации коммуникаций. Возникают неудачи и убытки, когда одни не могут услышать и понять других…

Да и не только в ИТ возникают неудачи, когда одни не могут услышать и понять других.

Доклад закончен. Успехов вам хорошем управлении, товарищи!


ссылка на оригинал статьи https://habr.com/ru/articles/862128/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *