Кто такой консультант и нужны ли они в IT-проектах

Екатерина Николаева, сооснователь группы IT-компаний AMEGA, объясняет, зачем нужны консультанты в IT-проектах, какие задачи они выполняют и когда их участие необходимо.

Екатерина Николаева, город — Ташкент, сооснователь группы IT-компаний AMEGA

Современные проекты используют разные ролевые нагрузки участников — все зависит от того какой класс программных решений внедряется, по какой проектной методике, в какие сроки, кто считается заказчиком и многих других факторов.

Кто такой консультант

Нет и единого устойчивого мнения в понятии «консультант» в IT-проекте: кто-то так называет бизнес-аналитика и/или интегратора системы, кто-то так называет менеджера по продажам, а кто-то менеджера по технической поддержке. 

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

Почему консультант важен

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

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

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

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

Размер такой консалтинговой команды зависит от периметра проекта: от 1 до 20 человек. В первую очередь влияет периметр бизнес-процессов, например, под проект ERP системы обычно команда осуществляет работу по блокам бизнес-процессов «продажи», «складской учет», «закупки», «активы», «казначейство», «бухгалтерский и налоговый учет» и так далее. Под проект внедрения системы управления активами будут попадать процессы снабжения, профилактики ремонтов, планирования ремонтов, реализации ремонтов, взаимодействия с подрядчиками, управления персоналом и так далее.

Основные задачи консультанта

Влияет также и список задач, которые возлагаются на консалтинговую команду. Часто консультант или команда консультантов осуществляют в проекте следующие задачи:

1. Анализ бизнес-процессов As is.

2. Построение бизнес-процессов To be.

3. Формализация функциональных требований к системе. Помощь в постановке задач автоматизации и цифровизации процессов.

4. Пересмотр алгоритмов расчетов, например, по заработной плате, расчету себестоимости товаров/работ/услуг, раздельному учету, автоматическому заказу материалов и сырья и многие другие.

5. Пересмотр, актуализация, создание методик ведения учета, например, по международным стандартам ведения учета, по бюджетированию, управлению персоналом, управления ремонтами и многое другое.

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

7. Систематизация, структуризация, очистка, обогащение данными нормативно-справочной информации, например, справочника «Партнеры», справочника «Активы/основные средства», справочника «товаров/работ/услуг/сырья/материалов/полуфабрикатов».

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

9. Унификация к методам и форматам оформления отчетности в организации, например, заголовки, шапки таблиц, шрифты, цвета и так далее.

10. Формирование, обновление принципов сквозной нумерации документов в компании, которые передаются в цифровизацию, например, принцип присвоения порядковых номеров договорам аренды или договорам на поставку товара клиентам.

11. Участие в приемке результатов кастомизации и/или внедрения учетной системы с целью подтвердить корректность работы бизнес-процессов и алгоритмов в системе.

Конечно, изучив список выше, мы можете сделать вывод, что действительно для программного решения все эти требования должен проанализировать/сделать интегратор. Ну, а IT-команды уверены, что им вышеперечисленный список должен дать заказчик. Однако зачастую команда заказчика заняты своей основной работой согласно своим должностным обязанностям. А еще данная команда наверняка давно работает в компании и уже привыкла к действующим бизнес-процессам и не способна посмотреть на них «из вне» и понять, что у них «не так». Может быть и никогда никто из них и не задумывался как вообще правильно. И это не потому, что специалисты они плохие, а потому что, погружаясь в среду, все играют по правилам внутри данной среды и меняться они могут только коллективно. Многие, даже понимая, что надо что-то менять в компании, просто не готовы взять на себя смелость и ответственность заявить это. Зато с этой ролью отлично справляется внешний эксперт — консультант. У него есть и внешнее видение, и опыт лучших практик, и время на то, чтобы заняться описанием, генерацией идей и оформлением документации. 

Ключевые навыки консультанта

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

Средняя заработная плата консультантов составляет от $2000 до $15 000 в месяц, возраст от 27 до 50 лет. В данную профессию приходят часто с руководящих постов крупных компаний, либо начинают со стажеров и медленно растут по карьерной лестнице. Но есть еще один популярный вход в профессию — через IT. Часто бывшие функциональные архитекторы или ведущие бизнес-аналитики переходят в консалтинг, потому что понимают, что им больше нравится наводить порядок, чем его просто оцифровывать.

Вывод

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