Внедрение любых ИТ-решений, включая системы бюджетирования, редко проходит совсем без трудностей. Наиболее типичные проблемы — увеличение объема работ, сдвиг сроков и сопротивление со стороны пользователей.
О том, почему возникают эти риски и как их минимизировать, расскажем в статье.
Работа с рисками должна начинаться не в тот момент, когда уже возникли серьезные проблемы, а с самого начала проекта. Степень формализации процедур и способы фиксации результатов могут различаться. Однако вне зависимости от того, в какой форме организовано управление рисками, их все равно нужно выявлять заранее.
После идентификации риска и определения степени угрозы происходит выбор оптимальной стратегии, планирование и реализация мероприятий по минимизации возможного ущерба. Завершающий этап — оценка эффективности принятых мер. В одних случаях для выполнения такой оценки используется простой аналоговый подход (реализовался риск или нет), в других — применяются количественные показатели.
Например, оценить, удалось ли избежать риска избыточности при внедрении системы бюджетирования, можно через анализ статистики использования различных отчетов. Бывают случаи, когда заказчик настаивает на включении в проект ряда дополнительных, порой достаточно сложных форм, однако спустя полгода работы с системой выясняется, что к ним так и не обращались.
Другой пример — риск неприятия системы со стороны пользователей. Если собирать обратную связь только в виде текстовых отзывов, то объединить их в целостную картину будет непросто. Для оценивания удовлетворенности лучше использовать балльные шкалы.
Реагирование на риски зависит от степени их угрозы, но это не всегда означает, что риски с крайне низкой степенью нужно игнорировать, а на риски с крайне высокой направить все ресурсы. Если проект в целом проходит спокойно, а риски оцениваются как не слишком значительные, их все равно стоит принимать во внимание и работать с ними, если у вас есть такая возможность.
Рассмотрим пример противоположной ситуации: ближе к завершению проекта появляется информация о новом законодательном акте, вступление в силу которого потребует серьезных изменений в уже внедренной системе. Степень угрозы — крайне высокая, но повлиять на ситуацию невозможно.
Поэтому при выборе стратегии работы с рисками важно учитывать не только степень их значимости, но и возможность влияния на них со стороны проектной команды.
Существуют три основных стратегии работы с рисками:
Далее рассмотрим основные риски при внедрении систем бюджетирования, их причины, последствия и способы минимизации.
Одной из основных причин увеличения объемов работ является незрелость или недостаточная детализация требований на старте проекта. У заказчика может иметься общее представление о ключевых аспектах будущей системы, но в силу нечеткости требований высок риск того, что участники проекта интерпретируют их по-разному.
Ни один консультант, даже самый опытный, не может «прочитать мысли» другого человека. Так что не стоит экономить время на этапе обследования, лучше сразу максимально прояснить все детали.
Причиной роста объемов проекта также может стать неправильная постановка цели. Важно сообщить подрядчику не только, какой должна быть целевая система, но и какие задачи планируется решать с ее помощью. Часто заявляются такие цели, как повышение эффективности или снижение объема ручного труда, но в них нет конкретики.
Чем точнее будут сформулированы цели, тем выше вероятность, что результат будет соответствовать ожиданиям. Например, если среди ваших целей будет заявлено снижение уровня затаривания складов, то в бюджетной модели появится бюджет закупок и запасов или бюджет рабочего капитала.
Неполнота требований на старте проекта — еще один распространенный риск. Если дополнительные потребности всплывают на этапе ввода системы в эксплуатацию, это может привести к доработкам, которые будут болезненными для уже настроенной системы. Подрядчик вправе расценивать не заявленные ранее требования как новые и отнести их к запросам на изменение рамок проекта.
Не стоит также забывать о возможных потерях информации на разных этапах ее обработки. Например, из-за нечеткой фиксации требований при обследовании или отсутствия единого глоссария.
Нередкой является ситуация, когда участники совещания слышат одно и то же, но понимают по-разному. В результате приходится возвращаться к уже обсужденным вопросам, а иногда и переделывать уже выполненную работу. Чтобы этого избежать, необходимо сразу же выровнять понимание ключевых терминов. Кроме того, нужно тщательно фиксировать все требования в протоколах и внимательно подходить к их согласованию.
Схожая проблема — неполнота или низкое качество входной документации, передаваемой исполнителям для проведения обследования. Под низким качеством понимается частичная утрата актуальности, избыточность, наличие ошибок или несогласованность информации внутри самих документов. Все это может запутать консультанта, ввести его в заблуждение.
Здесь можно провести аналогию с визитом к врачу. Когда пациент обращается к новому специалисту и заинтересован в получении точного диагноза и эффективного лечения, он должен подробно рассказать о себе и своих симптомах. Так же и при запуске проекта: чем более открытым и внимательным к мелочам будет заказчик, тем выше окажется качество конечного результата.
Отсутствие понимания, для какой ИТ-платформы создается методология, тоже порождает риск лишней работы. Если у вас есть сомнения в выборе платформы, можно начать с формирования функционально-технических требований и передать их потенциальным исполнителям, чтобы получить обратную связь по покрытию требований и оценить объем доработок.
Также полезно запросить демонстрацию возможностей сравниваемых платформ. Если требования превышают типовую функциональность, можно скорректировать их или рассмотреть альтернативные способы решения задачи. Это займет время, но существенно снизит риск неуспеха.
На объем проекта влияют и изменения внешних обстоятельств. Это может быть реструктуризация компании, приобретение нового бизнеса или вступление в силу нормативных актов. Все предусмотреть невозможно. Однако если заранее известно, что, например, стратегия компании предполагает неорганический рост, важно заранее проинформировать подрядчика о возможных рисках.
Опытный исполнитель сможет учесть такие изменения и заложить в архитектуру возможности для масштабирования создаваемой автоматизированной системы.
Результат проекта во многом зависит от людей. Неполнота или избыточность проектной команды негативно влияют на его успешность. У каждого процесса, который планируется автоматизировать, должен быть владелец. Кроме того, нужно определить ключевых участников проекта, которые будут привлекаться на соответствующих этапах. Чаще всего это владельцы смежных систем.
При этом лишние члены команды тоже вредны для проекта. Любой сотрудник, добавленный «на всякий случай», размывает ответственность и затягивает процесс согласования. За каждую функцию должен отвечать только один человек.
Среди причин, которые приводят к росту объема проекта, стоит также назвать несогласованность в процессах и методиках, а также незрелость смежных процессов. Часто система бюджетирования внедряется не отдельно, а в рамках комплексного проекта, включающего несколько предметных областей. Любая несогласованность между функциональными областями приводит к разрыву в процессе или потоке данных.
Типичный пример — отсутствие нормализованной НСИ, когда справочники плохо сопоставляются или перегружены лишними данными. Решением может стать единая модель данных компании.
Риск срыва сроков чаще всего возникает из-за недооценки сложности или объема задач. Обычно сроки проекта определяются заказчиком в ТЗ, исходя из текущего момента и какой-то точки в будущем, когда система должны быть внедрена. Например, ко времени формирования бюджета на следующий год. Когда проект запускается поздно, сроки могут оказаться слишком сжатыми.
Если в ходе конкурса большинство ИТ-компаний указывает на нереалистичность сроков и предлагают альтернативные варианты, стоит к ним прислушаться. Если же сроки решено оставить прежними, стоит обратить внимание на раздел с ограничениями и допущениями в технико-коммерческих предложениях — это поможет избежать необоснованных ожиданий.
Еще одной причиной срыва сроков является недостаточная вовлеченность сотрудников заказчика в ключевые моменты проекта. Текущая нагрузка, экстренные запросы руководства, отпуска и болезни — все это отвлекает от работы над проектом. Важно трезво оценить свои ресурсы и заранее сообщить исполнителю, сколько времени вы можете выделить на проект.
Это поможет составить более реалистичный график. Кроме того, руководители могут делегировать часть функций своим заместителям.
Причины срыва сроков могут находиться не только на стороне заказчиков. Иногда у исполнителя может не хватать ресурсов. Поэтому еще на этапе конкурсных процедур важно познакомиться с потенциальными командами и зафиксировать требования к их составу и уровню экспертизы на весь срок проекта.
Большое количество согласующих — еще один источник риска. Часто это связано со стремлением избежать личной ответственности за принимаемые решения. Такая ситуация может свидетельствовать о незрелости требований: когда заказчик точно понимает, что хочет, ему проще сформулировать задачу и оценить результат.
Следующий источник риска — отсутствие положительных результатов нагрузочного тестирования. Нередко сложное методологическое решение на небольших тестовых объемах работает корректно, но при выходе на промышленные масштабы система теряет производительность, и проект останавливается.
Поэтому важно с самого начала подключать технического архитектора. Он поможет рассчитать сайзинг бюджетных форм, определить требования к оборудованию и, главное, будет выполнять техническую экспертизу решений на их оптимальность и реализуемость.
После завершения проекта можно столкнуться с недовольством полученным результатом. Отторжение новой системы может объясняться разными причинами.
Это может быть недостаточная информированность сотрудников о проекте и его целях, а также некачественное обучение. Люди склонны отвергать то, что не понимают. Чтобы будущие пользователи не противились новой системе, важно заранее знакомить их с ее интерфейсом и преимуществами, а после проведения обучения убедиться, что знания действительно усвоены.
Недовольство результатами проекта может быть связано с завышенными ожиданиями.
Иногда сопротивление проекту вызвано неприятием изменений в принципе. Люди склонны придерживаться привычного. Это особенно заметно, когда коллектив сопротивляется новым идеям, предложенным руководством.
В таких случаях важно подходить комплексно. Однако акцент лучше делать на популяризации проекта и мотивации сотрудников к использованию его результатов, чем на дисциплинарных мерах.
При реализации проекта не исключена и такая экстренная ситуация, как смена менеджмента компании-заказчика. Новой управленческой команде можно порекомендовать не отказываться сразу от имеющихся наработок, выполненных по заказу своих предшественников.
Система бюджетирования в любом случае является финансово-экономической моделью бизнеса, и основные процессы, скорее всего, не потребует кардинальных изменений. Поэтому вместо поспешных решений лучше начать с диалога с внедренческой командой и оценить актив, который можно получить.
Риски — это неотъемлемая часть жизни, бояться их не стоит. Главное — трезво оценивать ситуацию, продумывать варианты реагирования на угрозы и придерживаться выбранной стратегии. При планировании проекта важно заранее определить, кто будет отвечать за управление рисками в каждой области, и наделить этих людей достаточными полномочиями.
Однако это не означает, что заниматься рисками будут только они. Участие в проекте можно сравнить с путешествием на корабле: любой, кто заметил трещину в корпусе, должен сообщить о ней тем, кто может ее устранить. В этом смысле работа с рисками — это нахождение в одной лодке со всей командой, где влияние каждого может оказаться важным.