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

Как правило, крупные западные холдинги имеют не только опыт внедрения ERP в своих подразделениях до прихода на российский рынок, но и стабильные связи с консалтинговыми компаниями, осуществляющими для них это внедрение на местах. Такие консалтинговые компании можно условно назвать основными партнерами в рамках roll-out терминологии.

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

Организационная структура roll-out

Источник: Консультационная группа АТК, 2007

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

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

Запросы на «локальные доработки» проходят проверку и утверждение в штаб-квартире заказчика, а также основного партнера. После чего они реализуются локальными партнерами. Руководитель проекта со стороны клиента и ключевые пользователи являются, таким образом, «проводниками» внедрения, например, ERP-системы от заказчика.

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

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

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

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

Схема взаиморасчетов на roll-out проектах может варьироваться в зависимости от конкретных контрактных условий и прочих договоренностей между участниками проекта.

Типичная схема контрактных отношений на roll-out проекте

Источник: Консультационная группа АТК, 2007

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

Разработка единого решения

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

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

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

Во-вторых, стандарты консолидации данных: регламентируется процедура консолидации финансовых данных подразделений холдинга на уровне общекорпоративного плана счетов для получения полной картины финансового состояния всей компании. Однако подходу к консолидации на уровне глобального плана счетов существует альтернатива: на одном из моих проектов консолидация проводилась посредством автоматической выгрузки из системы данных в отчет о прибылях и убытках на базе MS Excel заданного формата. Данная процедура также входила в состав единого информационного решения, тиражируемого в рамках roll-out.

В-третьих, стандарты интеграции с внешними системами и источниками данных: разрабатывается функционал для интеграции используемой системы автоматизации с «внешними» программными продуктами. Например, при автоматизации гостиничного бизнеса системы класса ERP используются преимущественно сотрудниками back-office (бухгалтерией, финансовым отделом). В то же время front-office использует свои программные продукты (учет размещения постояльцев в номерах, статистика пребывания гостей, управление гостиничным рестораном и т. д.). Если для front-office  в данном случае важнее специфическая информация о времени пребывания, уровне удовлетворенности сервисом и проч., то бухгалтера интересует денежное отражение всех хозяйственных операций, которые были зафиксированы в системах, используемых сотрудниками front-office. Следовательно, необходим обмен данными между системами, используемыми этими двумя категориями сотрудников.

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

Тиражирование

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

Во-вторых, анализ специфических требований местного законодательства и их реализация в системе. На данном этапе основная роль по кастомизации системы возлагается на локального партнера и ключевых бизнес пользователей заказчика, которые решают, какие именно требования законодательства критичны для автоматизируемой бизнес логики и обеспечивают их реализацию в системе по согласованию с основным партнером и штаб-квартирой заказчика. Реализация требований законодательства может проходить двумя путями: либо закупкой дополнительных кастомизированных модулей системы, либо разработкой необходимой функциональности силами локального партнера за дополнительный бюджет, либо в рамках общего бюджета проекта (если такие статьи предусмотрены). Исходя из опыта внедрения систем на roll-out проектах, представляется, что более глобальные задачи (налоговый учет по 25 главе НК РФ, учет основных средств и проч.) целесообразней решать закупкой готовых дополнительных модулей к системам, в то время как относительно небольшие по объему доработки (например, реализация печатных форм  документов, утвержденных к использованию Минфином) чаще выполняются силами локальных партнеров.

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

Обобщенная блок-схема процесса создания и тиражирования решения в roll-out проектах

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

Кто и чем рискует?

Одной из наиболее значимых частей любого проекта внедрения является оценка его рисков, которые зависят от специфики поставленных задач и избранных для их решения методик. Исходя из реального опыта участия в roll-out проектах, В АТК выделяют несколько основных категорий рисков для данного вида проектов.

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

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

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

Методы снижения этого риска - четкая ориентация в организационных структурах, понимание сфер ответственности и полномочий различных участников проекта. Составление регулярной отчетности о ходе проекта в различных разрезах, ориентированных на клиента и партнеров по внедрению. Увеличение сметы на руководство проекта.

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

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

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

Методы снижения риска - введение в проект промежуточных стадий и документов, разработка которых не занимает много времени, но, вместе с тем, восполняет пробелы общей roll-out методологии основного партнера. Увеличение сметы на этап анализа функциональных требований.

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

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

Методы снижения риска - рганизация дополнительных встреч и совещаний с западными партнерами по разъяснению российской специфики ведения финансового учета с привлечением российских финансовых специалистов со стороны клиента.

Отсутствие достаточных ресурсов для ведения проекта со стороны российского представительства клиента. Часто roll-out проекты по внедрению ERP-систем проходят в параллели с началом основной деятельности представительства клиента. В данном случае весьма ощутимым становится риск того, что на задачу внедрения будет уделено недостаточно времени со стороны основных бизнес пользователей клиента.

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

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

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

Безусловно, в данных обстоятельствах при условии наличия всего двух сотрудников со стороны Заказчика для реализации всех вышеуказанных задач рассчитывать даже на 60%-70% занятость на проекте внедрения пользователей не представляется возможным.

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

Преимущества roll-out

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

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

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