Трансформация VS Профанация

Трансформация VS Профанация

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

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

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

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

Отсюда и растут ноги этой статьи: коллеги всячески зазывают меня в свой проект, при этом не могут дать ответ на вопросы:

  1. В чём суть трансформации?
  2. Зачем им архитектор?

Ответом на мои вопросы служит список задач, проектов, ИТ-систем, проблем, но это не ответ на мой вопрос.

Трансформация VS Профанация

Это ответ типовой операционной команды, которая занимается внедрением ИТ-решений, на вопрос руководства: «Ну что там?» Руководство получает вот такой отчёт о деятельности.

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

  1. Интервью ключевых экспертов;
  2. Уточнение требований;
  3. Анализ ТЗ;
  4. Приёмка систем и участие в демо;
  5. Внесение данных;
  6. Заведение багов.

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

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

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

Для самого простого примера возьмём «ману небесную» подразделений операционной деятельности — системы электронного документооборота. Сейчас эти системы внедряются повсеместно, компании рапортуют об этом на больших отраслевых конференциях и заседаниях министерств, но результат, как правило, следующий:

  • Аналоговый бардак переносится целиком «как есть».
  • Частичный перенос бардака — документы в электронном виде, часть в бумажном.
  • Произведена оптимизация документации.

Вот пара примеров из моей практики. Я увольнялся из одного крупного банка, мне выдали электронный обходной лист. Но несколько подписей нужно было получить на бумаге и съездить в два места для этого.

Этот кейс замечателен сразу двумя особенностями:

  1. В обходном листе было 38 человек, которые должны были его подписать. Видя мои округленные глаза, девушка из HR сказала: «Не переживай, большую часть этих подписей можно получить электронно, тебе никуда не нужно будет ходить». Ходить и в самом деле не пришлось, но 38 человек, хоть и электронно, приняли участие в моём увольнении.
  2. Во второе место пришлось ехать за справками для нового работодателя. Их можно было получить только в печатном виде и передать из рук в руки. Хотя все эти данные давно были у налоговой, и их можно было бы передавать между налоговой и новым работодателем без моего участия. Но в тот момент за ними пришлось ехать мне.

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

Это было больше 6 лет назад, теперь этой информацией обмениваются в электронном виде, но справки продолжают выдавать.

И таких примеров можно привести ещё большое количество; многие такие вот реализации входили в программы цифровой трансформации.

Закон сохранения энергии гласит:

Энергия не появляется из неоткуда и не исчезает в никуда. Энергия переходит из одной формы в другую.
Общее описание закона сохранения энергии

При переходе энергии из одной формы в другую возникают её потери в виде выделения тепла.

Применив этот закон к системе, можно сказать, что система трансформируется и не трансформируется одновременно. Система меняет своё состояние на новое, при этом гарантированно часть ресурсов тратится впустую.

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

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

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

Если опираться на классификацию ТРИЗ, существуют 5 уровней задач:

  1. Первый уровень. Решение таких задач не связано с устранением технических противоречий и приводит к мельчайшим изобретениям.
  2. Второй уровень. Задачи с техническими противоречиями, легко преодолеваемыми с помощью способов, известных применительно к родственным системам. Приводит к мелким изобретениям.
  3. Третий уровень. Противоречие и способ его преодоления находятся в пределах одной области знаний. Полностью меняется один из элементов системы, частично меняются другие элементы. Приводит к средним изобретениям.
  4. Четвертый уровень. Синтезируется новая техническая система. Технические противоречия на первый взгляд отсутствуют, но на самом деле технические противоречия относились к старой системе и были преодолены путём создания новой. Приводит к крупным изобретениям.
  5. Пятый уровень. Изобретательская ситуация представляет собой клубок сложных проблем, решение которых приводит к возникновению новой отрасли. Приводит к крупнейшим изобретениям.

Трансформация — это решение задачи 4 или даже 5 уровня.

В отличие от простых и понятных задач, критериями трансформации являются:

  1. Наличие визионера (человека, имеющего образ будущего и стремящегося к нему, а не бедолагу, назначенного искать незнамо что, незнамо где).
  2. Отсутствие чётких границ результата.
  3. Отсутствие готовых решений.
  4. Наличие набора непреодолимых противоречий.
  5. Необходимость большого количества экспериментов.

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

4
Начать дискуссию