Почему проекты цифровой трансформации вылетают в трубу?

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

Школа управления Сколково еще в 2020 году выпустила статью «Цифровые неудачники: почему диджитал-трансформации заканчиваются провалом». По мнению авторов, 70% инициатив по цифровой трансформации не достигают своих целей, и одна из причин — проблемы на уровне корпоративной культуры. Мы в Comindware, как участники цифровой трансформации, это отлично видим на опыте внедрения BPM-систем в крупных компаниях. Если проект влияет на организационную культуру компании, то возникают риски не довести его до прода из-за большого сопротивления со стороны менеджеров среднего звена и нереалистичных ожиданий руководства. Обе проблемы, на наш взгляд, связаны с корпоративной культурой, которую нельзя изменить без воли руководителей разного уровня. Надеемся, наш взгляд на ситуацию поможет лучше понять, что мешает развитию вашей компании.

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

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

Люди, которые не привыкли к изменениям, не будут осваивать навыки «гражданской разработки» или другим образом участвовать в проекте. Мы говорим, что вовлеченность сотрудников в BPM-инициативу на уровне разработки бизнес-логики приложения и интерфейсов, повышают шансы проекта на успех. Но если руководство отстраняется от проекта, то все усилия будут потрачены напрасно.

Формы низового сопротивления могут быть разными — пассивными и активными. Компания внедряет систему для управления закупками по указанию руководства, но продолжает работать в Excel и почте. Руководство в проекте не участвует, а сотрудникам удобно работать по-старому. Проект заходит в тупик. Другой пример, уже активного сопротивления. Региональное подразделение ориентируется на плановые показатели, а средства их достижения определяет самостоятельно. Руководство решает вмешаться во внутренние процессы и требует внедрить систему ЭДО от конкретного вендора, что вызывает максимальное неприятие со стороны руководства регионального подразделения, которое методически начинает саботировать проект. Нередки случаи, когда внутренние конфликты между начальниками отражаются на проекте, когда каждое подразделение тянет инициативу на себя, а руководство в ситуацию не вмешивается.

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

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

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

Система может бесконечно находиться на этапе разработки, потому что участники постоянно хотят что-то улучшить, переделать и добавить. Нарушается одно из правил управления проектами — можно менять функциональность, но нельзя менять сроки.

В итоге разработка тянется годами, не принося результатов. Если с проектами внедрения ERP длительные сроки еще можно оправдать, то в случае внедрения CRM, SRM и тех же BPM-систем, ситуация кажется странной. Как создать идеальный продукт без пользовательского опыта, без обратной связи? Low-code вроде бы снимает эту проблему на уровне разработки бизнес-приложений, но как показывает опыт, не всегда руководство готово к экспериментам, а хочет сразу получить идеальную во всем систему. Такой подход губителен для BPM-инициатив. У нас был проект по автоматизации процесса открытия новых магазинов в розничной сети. Процесс с большим количеством шагов и специфической бизнес-логикой, которую пришлось дополнительно уточнять на этапе внедрения. Так получилось потому, что сотрудники не акцентировали внимание на многих деталях процесса до тех пор, пока не начали работать в новой системе. Только тогда мы услышали: «А почему этого нет? А вы можете здесь переделать?». Если бы руководство захотело получить идеальную систему для открытия торговых точек, проект никогда бы не выстрелил.

Иногда проект импортозамещения превращается в попытку создать SAP и Oracle на российских платформах без учета специфики самих платформ и состояния текущих процессов в компании. Заказчик не пытается раскрыть потенциал Low-code разработки, а слепо копируют функциональность предшествующих решений. В итоге проект сводится к повторению старых ошибок, но на новой платформе, которая была создана не для того, чтобы копировать SAP и Oracle. Подмена целей средствами приводит к закрытию проекта, так как SAP и Oracle могут создать только SAP и Oracle, а российские вендоры могут предложить альтернативу, но не точную копию.

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

Кто чаще всего выступает агентом изменений? Самый очевидный союзник — ИТ-отдел, который просто устал бесконечно доводить до ума очень мощные корпоративные системы от именитых разработчиков. Если начальник ИТ-отдела понимает, что может часть операционных и вспомогательных процессов перенести из ERP на Low-code платформу, чтобы получить больше времени на развитие ядра ИТ-архитектуры, то такой проект с вероятностью 98% будет доведен до конца.

Второй, и наверное, главный союзник — тот самый менеджер среднего звена, который обычно выступает в роли могильщика BPM-проектов и, наверное, любых проектов цифровизации. Если инициатива исходит именно от среднего слоя руководителей, например, менеджера по развитию, то проект 100% будет доведен до конца и 100% принесет результат. Такой сотрудник, во-первых, сам заинтересован в изменениях, во-вторых, обладает властью, в-третьих, он видит процесс изнутри, в-четвертых, встроен в систему корпоративных связей. Он может как умело саботировать проект, так и мастерски им управлять даже без навыков проджект-менеджмента. Во всяком случае, утверждение верно по отношению к разработке на Comindware Business Application Platform, которую часто ведут «гражданские разработчики» — менеджеры среднего звена или штатные бизнес-аналитики заказчика.

#цифроваятрансформация #bpms #lowcode