Найти в Дзене

Пример процесса «на грани хаоса» по У.Шухарту в создании IT-инфраструктуры

Пример процесса в области создания ИТ-инфраструктуры, который по критериям Шухарта находится «на грани хаоса» (то есть, статистически неуправляем), но при этом может выдавать 100% хорошую продукцию, — это процесс "героической" ручной настройки и развертывания уникальной инфраструктуры для каждого нового проекта высококвалифицированными специалистами. Согласно концепциям Шухарта, процесс находится в статистически управляемом состоянии, когда его вариабельность обусловлена только обычными (случайными) причинами (common causes), и все данные лежат в пределах контрольных границ на контрольных картах. Особые (специальные) причины (assignable causes) указывают на неуправляемость процесса. В данном примере процесс является статистически неуправляемым (на грани хаоса) по следующим причинам: Несмотря на хаотичность процесса, продукция может быть 100% хорошей благодаря "героизму" и сверхусилиям команды: Такой процесс является ярким примером ситуации, когда результат достигается не благодаря про
Оглавление

Пример процесса в области создания ИТ-инфраструктуры, который по критериям Шухарта находится «на грани хаоса» (то есть, статистически неуправляем), но при этом может выдавать 100% хорошую продукцию, — это процесс "героической" ручной настройки и развертывания уникальной инфраструктуры для каждого нового проекта высококвалифицированными специалистами.

Описание процесса

  • Процесс: Создание ИТ-инфраструктуры для нового проекта с нуля (например, развертывание серверов, настройка сетей, установка и конфигурация программного обеспечения, систем безопасности) силами небольшой команды экспертов-универсалов.
  • Результат (продукция): Готовая к работе, полностью функциональная и соответствующая всем требованиям бизнеса ИТ-инфраструктура проекта. Допустим, каждый раз система успешно проходит приемочные испытания и работает безотказно (100% "хорошая" продукция).

Анализ по критериям Шухарта

Согласно концепциям Шухарта, процесс находится в статистически управляемом состоянии, когда его вариабельность обусловлена только обычными (случайными) причинами (common causes), и все данные лежат в пределах контрольных границ на контрольных картах. Особые (специальные) причины (assignable causes) указывают на неуправляемость процесса.

В данном примере процесс является статистически неуправляемым (на грани хаоса) по следующим причинам:

  1. Отсутствие стандартизации и зависимость от человеческого фактора: Процесс не описан формальными процедурами или автоматизированными скриптами. Результат зависит от уникального набора навыков, настроения, опыта и текущего состояния конкретного инженера, выполняющего работу. Это вносит особые причины вариаций в каждый цикл процесса.
  2. Непредсказуемость времени и ресурсов: Время, затрачиваемое на развертывание, может сильно варьироваться от проекта к проекту (от нескольких дней до недель) без видимой закономерности, поскольку каждый раз проблемы решаются "по ходу дела", а не системно. Контрольные карты для таких параметров (например, "время развертывания" или "количество ошибок в процессе настройки до ввода в эксплуатацию") показали бы наличие точек за пределами контрольных пределов или нестабильные тренды.
  3. Невозможность воспроизведения: Если тот же самый процесс попытается выполнить другой специалист (или даже тот же самый, но в другое время и с другими внешними условиями), последовательность действий и результаты могут отличаться. Процесс невоспроизводим в статистическом смысле.
  4. "Теневые" ИТ-процессы: Значительная часть "ноу-хау" существует только в головах инженеров, а не в документации или инструментах автоматизации. Это скрывает истинные источники вариаций.

Почему продукция 100% хорошая?

Несмотря на хаотичность процесса, продукция может быть 100% хорошей благодаря "героизму" и сверхусилиям команды:

  • Постоянный контроль качества на выходе: Инженеры тратят значительное время на тестирование, отладку и ручное устранение любых проблем до момента передачи инфраструктуры в эксплуатацию.
  • Высокая квалификация: Сами специалисты обладают достаточным опытом, чтобы "спасти" проект от провала, компенсируя отсутствие системного подхода своими знаниями.
  • Использование "буферного" времени: Временные рамки проектов часто закладываются с большим запасом, чтобы дать возможность инженерам устранить все "особые причины" до дедлайна.

Вывод

Такой процесс является ярким примером ситуации, когда результат достигается не благодаря процессу, а вопреки ему за счет человеческих усилий. С точки зрения управления качеством по Шухарту, это крайне неэффективная и рискованная ситуация, поскольку успех не гарантирован в долгосрочной перспективе, а при изменении команды или нагрузки процесс неизбежно приведет к сбоям и браку. Улучшение требует перевода процесса в статистически управляемое состояние через стандартизацию и автоматизацию (например, использование IaC - Infrastructure as Code).

Пример перехода к идеальному процессу по У.Шухарту при создании IT-инфраструктуры