5 сентября 2024 г.

Олег Логвинов

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

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

Попробуем разобраться.

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

Причины?

Первая — слабость или отсутствие реальной бизнес-экспертизы у большинства интеграторов. И вторая — глобальное отсутствие навыков управления изменениями.

Об отсутствии реальной бизнес-экспертизы у большинства интеграторов

Начнем с первой. Я нередко сталкивался с тем, как российский интегратор запрашивает у заказчика ТЗ, а тот просто не в состоянии его сформировать качественно. Иногда попросту не может внятно сформулировать, а что, собственно, он хочет. Ведь прежде, в благополучные времена, он «слаще морковки» ничего и не ел, вот и выдает по-прежнему ТЗ слабое, мало детальное, едва ли проработанное. Ну и интегратор, соответственно, привычно работает по этому ТЗ с удовольствием. Потом заказчик смотрит на промежуточный результат, и вдруг выясняется, что это совсем не то, что он себе «видел», чего ожидал. А интегратор тут же показывает ему ТЗ — мол, там так написано, «прикрывает» тылы. Тем времен бюджет уже «проели», и начинаются войны «заказчик — подрядчик». И это если не суды, то как минимум тихая растущая ненависть.

Еще хуже, когда не понимающий реальных задач бизнеса сотрудник интегратора, будь то консультант, архитектор или программист интервьюирует на стадии «обследования» клиента, даже не владея понятийным аппарата в этой тематике. А потом, естественно, много раз переспрашивает (сам-то, повторю, совсем в предмете не разбирается). Заказчика это бесит. И тот самый «клинч» возникает уже на старте проекта.

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

Профессионалы рынка знают, чем хороша была «большая четверка». Ее подход, называемый Pizza Approach, предполагает, что клиент получал не ингредиенты (муку, помидоры, сыр), а готовый продукт. При таком подходе люди думали о повышении эффективности бизнеса именно за счет трансформации, и как раз под трансформацию тех или иных процессов предлагали оптимальную технологию. Но самое интересное — какую базу знаний они собрали! Я помню, у нас на одном из проектов была в распоряжении база, где можно было найти описание и документацию всех проектов, которые когда-либо и где-либо делал PwC. То есть, когда было нужно, я мог выбрать и изучить лучшее, что было сделано; использовать эти наработки (так называемые deliverables). Консультанты-эксперты, которые это писали, были разбросаны по всему миру. Но каждый из них был доступен для обмена знаниями и обучения. Так они хранили знания, «шерили» их. Хранят они эти знания о решениях для индустрий и являются переносчиками, проводниками лучших практик и сейчас. Это есть подлинно системный подход.

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

А вот другой подход. Нанимаешь не за полмиллиона, а за 100 тысяч талантливого парня — непосредственно от заказчика, переводишь его на фултайм в проектную команду и бросаешь «в бой» с параллельным обучением системе. И вот — «бинго»! Через полгода у тебя и система работает, и в команде есть боевой производственный консультант внедрения SAP. Я много раз так делал. Поверьте, работает.

О глобальном отсутствии навыков управления изменениями

Теперь об управлении изменениями.

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

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

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

Но это еще полбеды, что интеграторы не имеют методологии и навыков производить бизнес-трансформации. Важнее, что они ничего не знают о психологии изменений.

Известно, что менять себя тяжело. Например, если у людей есть информационная система, к которой они привыкли и в которой давно работают, то их крайне сложно «пересадить» в любую другую, зачастую даже наиболее функциональную и удобную. Они сопротивляются. Попробуйте сами перейти с Windows на MAC :).

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

О методологии SCARF

Однажды я вычитал короткую концепцию или методологию с очень легко запоминающейся аббревиатурой ШАРФ — чуть модифицированное английское SCARF. Что это такое? Это практика, многие годы помогающая мне в проектах внедрения. Изменения сложны; люди неохотно соглашаются с новыми схемами процессов и непривычными технологиями. Приходится убеждать. Склонять оппонента к ответу «да» на ваши идеи.

Существуют 5 социально эмоциональных аспектов (чувств), которые в значительной степени влияют на выбор оппонента, на его «да» или «нет». Не роняйте этих чувств в оппоненте, и он будет делать то, что вы хотите.

  • Status (от. англ. — статус) — ваша относительная важность для других, независимо от координат развития (деньги, должность). Поднимая статус собеседника, вы получаете расположение, и наоборот. Прийти и начать рассказывать, что и как нужно делать, — значит поднимать свой и опускать статус собеседника. Результат вероятнее будет «нет».
  • Certainty (от англ. — определённость) — определённость, уверенность. Если собеседник не уверен в ваших намерениях или сомневается в том, что вы ему говорите, он будет склоняться к отрицанию ваших слов, и наоборот. Попробуйте, например, замотивировать на работу сотрудника, которого планируете уволить, не объяснив ему перспективу на 3 и более месяца.
  • Autonomy (от англ. автономия) — чувство контроля и возможность принимать решения самостоятельно. Если говорить собеседнику, что и как делать, не оставляя выбора, он окажется в состоянии отрицания. Человек чувствует себя комфортно, когда у него есть выбор.
  • Relatedness (от англ. причастность). Если изолировать сотрудника от психологически значимых событий (праздники, игры, проекты), ему будет обидно, это введёт его в состояние отрицания.
  • Fairness (от англ. справедливость). Пожалуй, наиболее мощное чувство, влияющее на состояние «расположенности/отрицания». Ради справедливости люди готовы терять свои состояния и даже жизни. Невозможно расположить к себе человека, который считает, что вы несправедливы к нему.

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

Резюме

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

Источник: Олег Логвинов, эксперт по цифровой трансформации