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

Проблемные зоны цифровой трансформации

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

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

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

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

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

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

Кого охватывают изменения?

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

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

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

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

Как сбалансирован переход?

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

В реальности же далеко не каждый может быть командным игроком или же перестройка сознания в этом направлении идёт медленно. Это известная проблема масштабирования гибкого управления на крупные коллективы. Особенно если сложившаяся корпоративная культура изначально была жёсткой и иерархичной.

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

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

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

Является ли рабочий процесс зрелым и управляемым?

Выстраивание рабочего процесса гибкими командами, должно быть поддержано развитой методологической базой. Для достижения успеха необходимо задействовать множество различных практик. Помимо более распространённых гибких практик (Scrum, пользовательские истории и т.д.), сюда входят практики для развития архитектурных решений, сервис-ориентированная разработка, система непрерывного совершенствования качества, улучшение процессов и многое-многое другое.

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

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

Оценка состояния технической зрелости

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

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

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

Состояние стандартов работы

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

Например, наша диагностика не редко выявляет ситуацию, когда показатель от 15% до 50% дефектов в общем объёме работ у многих команд считаются нормой. То есть половина всей работы исправляется или делается заново, и в этом никто не видит проблему.

Или до 80% трудового ресурса сотрудников расходуется впустую. Этих дорогих специалистов можно было бы перераспределить между командами, традиционно испытывающими дефицит кадров, но никто не занимается оценкой эффективности ресурсов, поскольку нет соответствующих стандартов и KPI.

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

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

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

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

«Flow Metrics: управление потоковым производством на основе данных»
Учебный курс про метрики на реальных примерах

Комментариев: 2

  • Булат

    Сложно, мудрёно, неструктурировано формалистским языком написаны очевидные вещи. В итоге получилась вода. Дочитал 80%, клюнул головой 6 раз.

  • ВяЧЕСлав

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


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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
    • 6 худших вещей, которые продакт-менеджеры говорят инженерам
      Каждый хороший продакт-менеджер — полиглот. Он говорит на нескольких языках. Конечно, вы можете не говорить бегло на французском, итальянском или мандаринском. Но вы
    • На какой курс пойти, чтобы узнать про практику Х?
      Этот вопрос вы, наши слушатели, задаёте довольно часто. К тому же появились новые курсы категории VAP. Так что было бы удобно иметь под рукой справочник. Ну что же, вот оно:
    • Понимание ваших данных: Kanban Analytics
      Какие бы решения вы ни принимали в своей организации, они должны основываться на данных. Со временем у вас появится глубокое понимание вашего процесса и производительности. Перестаньте полагаться на догадки - аналитика станет вашим надежным советчиком для предсказуемого успеха. В этой статье мы рассмотрим, как можно использовать аналитику для понимания данных, выявления проблем и повышения эффективности процесса.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT