В рекордно короткий срок, за девять месяцев, в ОАО "СУАЛ" создана интегрированная система учета и отчетности на базе mySAP Business Suite. Система внедрена на восьми заводах холдинга и в головной управляющей компании. Для успеха подобного проекта потребовалось детальное планирование, многоуровневый контроль качества и управление изменениями. Константин Зимин беседует с заместителем вице-президента по учету и налогам ОАО "СУАЛ-Холдинг" Александром Караваевым.

Образование экономическое. В 1998 году закончил экономический факультет Сибирской аэрокосмической академии по специальности "Стратегическое планирование и управление".
С 1997 по 2001 год - старший эксперт департамента аудита компании "Артур Андерсен". Руководил аудиторскими проектами по РСБУ, МСФО и US GAAP компаний Северо-Западного региона, а также проектами по консультированию в области финансовой отчетности. Руководил проектом разработки и внедрения системы трансформации финансовой отчетности в соответствии с МСФО ОАО "Связьинвест" (включая около 30 дочерних компаний).
В 2002-2003 году назначен директором нефтегазовой группы департамента бизнес-консалтинга компании "Эрнст энд Янг СНГ". Курировал многие проекты для крупных российских нефтегазовых компаний, в том числе в ТНК (управление проектом внедрения системы управленческого учета затрат, бюджетирования и планирования на одном из добывающих предприятий, управление проектом внедрения системы управленческого учета в конгломерате из шести нефтесервисных компаний), "Лукойл Оверсис Холдинг" и "КазМунайГаз"
В 2003 году назначен заместителем вице-президента "СУАЛ-Холдинга" по учету и налогам. Управлял проектом развития системы учета и отчетности компаний группы СУАЛ, а также службой заказчика по внедрению системы SAP R/3 на всех филиалах ОАО "СУАЛ" (восемь заводов), включая постановку задачи, контроль качества, приемку работ и обеспечение методологической целостности.

Intelligent Enterprise: Давайте начнем с самого начала. Какова была ситуация в холдинге до внедрения ERP-сиcтемы?

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

Производственная структура ОАО "СУАЛ" достаточно разнородна. В СУАЛ входят и алюминиевые заводы, и алюминиево-глиноземные комплексы. На всех заводах, которые входили в состав ОАО "СУАЛ" в виде филиалов, была собственная структура ведения учета и составления отчетности, свои программные продукты, причем на некоторых заводах достаточно высокого уровня. Так, на Иркутском алюминиевом заводе SAP R/3 была внедрена за два года до старта этого проекта. Однако были и менее благополучные в этом отношении заводы. Существовал, например, вариант системы автоматизации учета на основе набора разрозненных АРМов.

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

Исходя из целей, сформулированных руководством группы, мы пришли к выводу, что старая структура учета не могла выполнить все требования компании. Мы на каком-то этапе развития непременно уперлись бы в определенные ограничения. Поэтому была инициирована программа по совершенствованию системы учета и отчетности. Первоочередная ее цель - создание единой информационной среды ОАО "СУАЛ" по всем направлениям отчетности, которая нам необходима: составление отчетности по международным стандартам, российская бухгалтерская отчетность, налоговый учет и управленческая отчетность. Раньше все эти виды отчетности создавались разными службами по разным принципам. Вторая главная цель - это сроки представления отчетности. При работе со многими разнородными системами филиалов, учитывая наш масштаб, невозможно было существенно снизить сроки закрытия периода. И третья основная цель - реформирование процессов финансового контроля.

Почему вы остановили свой выбор на mySAP Business Suite? На это решение повлияло внедрение системы SAP на Иркутском алюминиевом заводе?

Безусловно. Да, значительное количество решений, разработанных на ИркАЗе, были опробованы и доказали свою правильность. Там уже произошла притирка между системой и предприятием. К моменту инициации проекта довольно позитивный опыт, накопленный на ИркАЗе, мы могли в той или иной степени переносить на другие заводы. Это явилось одной из предпосылок выбора mySAP Business Suite.

Но процесс выбора продолжался немало времени. Мы обсуждали различные варианты: должна ли это быть централизованная или децентрализованная система, можно ли сделать какие-либо локальные системы на базе недорогих российских решений, например "1С" или "Парус", или ориентироваться на ERP-решения второго эшелона, такие как Axapta? И в конечном итоге пришли к выводу, что поскольку наша группа растет и наша философия управления требует существенной степени стандартизации многих процессов, нам необходимо создавать систему централизованной архитектуры - одну систему, к которой все балансовые единицы (филиалы или юридические лица) подсоединяются как удаленные пользователи.

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

Каких принципов вы придерживались при выборе партнеров для этого проекта?

Для проекта такого масштаба нужна была не просто сильная, а уникальная команда как со стороны заказчика, так и со стороны подрядчика. Потому что внедрение такого объема в такие сроки - это уникальный опыт.
У нас уже был опыт взаимодействия с компанией "БДО Юникон". Именно она, совместно с нашей командой, осуществляла проект на Иркутском алюминиевом заводе. Тем не менее мы объявили тендер, пригласили практически все компании, которые занимаются внедрением mySAP Business Suite. И "БДО Юникон" выиграла этот тендер. Это произошло по нескольким причинам. Во-первых, успешные проекты. "БДО Юникон", сегодня, наверное, может похвастаться наибольшим количеством успешных внедрений mySAP Business Suite такого масштаба в СНГ. Есть компании, которые обладают отличными специалистами и очень успешными методиками внедрения, но они работали на проектах меньшего масштаба. Ведь нам нужно было в пиковые периоды до 200 консультантов. На рынке лишь единицы компаний могут предоставить такое количество специалистов по SAP.

И во-вторых, "БДО Юникон" предложила нам наиболее удобные финансовые условия. Был еще один немаловажный фактор - компетенция генерального подрядчика в части координации работ. Потому что управление изменениями в таком проекте является крайне важной функцией. Здесь мы не можем работать по канонам. Например, есть каноны SAP, которые говорят, что на время управления нужно запретить все организационные изменения, изменения бизнес-процессов. Но бизнес движется, и остановить его мы не можем. Поэтому у нас возникало колоссальное количество изменений в ходе проекта. Один только пример - уже после старта проекта к нему были подключены еще три завода.

Почему вы пошли на такое быстрое внедрение? Для подобных объемов проекта девять месяцев - очень жесткий срок. Можно ведь было составить и менее жесткий план проекта?

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

Кроме того, есть еще один чисто технический момент. При реализации проекта мы существенным образом меняли учетную политику. Мы пытались приблизить все наши политики учета к международным стандартам. Поэтому было крайне желательно изменить учетную политику с начала финансового года. Кардинальная смена учетной политики в середине года, безусловно, возможна, но возникают сложные аспекты. Необходимо было бы приводить первое полугодие к новой политике, либо наоборот, что породило бы достаточно большое количество технических проблем. Поэтому, когда решение о внедрении ERP-системы было принято, стал прорабатываться объем проекта и технические задания. Первая дата, которая подходила, - 1 января 2005 года. Мы посмотрели по методике АSAP и сделали вывод: для проекта такого масштаба минимальный срок - девять месяцев. И решили пойти на быстрое внедрение. Мы справились за семь с небольшим месяцев, уложились в наилучшие графики SAP.

Подобный проект требует специальной проектной команды. Как она была организована? Часто говорят о поддержке проекта топ-менеджерами компании. Как обстояло дело у вас на проекте?

Прежде всего был сформирован управляющий комитет проекта. Его возглавил генеральный директор Иркутского алюминиевого завода, член совета директоров ОАО "СУАЛ-Холдинг" Игорь Самсонович Гринберг, который уже имел опыт внедрения SAP. Он непосредственно курировал проект внедрения системы на этом заводе, поэтому его пригласили на роль председателя управляющего комитета. Заместителем председателя управляющего комитета стал первый вице-президент по финансам ОАО "СУАЛ-Холдинг" Иосиф Абрамович Бакалейник, который был основным заказчиком системы, основная функциональность находилась в его ведении. Кроме того, стать членами управляющего комитета проекта пригласили директоров всех заводов. С точки зрения координации проекта это был фактор колоссальной важности, потому что все основные работы, все основные проблемы возникали на уровне заводов. Именно там идут основные процессы, сбыт, снабжение, формирование себестоимости. При этом управляющий комитет принимал решения только после достижения консенсуса, не было никакого голосования, решения принимались только тогда, когда все приходили к соглашению. Он собирался семь раз за весь период проекта, примерно раз в полтора месяца.

Проектную команду можно разделить на четыре основных функциональных блока.

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

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

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

Существует мнение, что это дополнительный риск, и все инфраструктурные вопросы должны быть решены до старта проекта по внедрению ERP-системы…

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

Возвращаясь к вопросу о проектной команде, отметим третью группу - технологов, которые настраивают и внедряют систему. Это самая многочисленная группа, в пиковый период количество внедренцев доходило до 200 человек. На 70% группа состояла из специалистов "БДО Юникон". Остальные 30% - наши специалисты, та самая команда (около 40 человек), созданная на Иркутском алюминиевом заводе, которая занималась настройкой системы и ее сопровождением.

И последняя группа - это группа контроля качества. Контроль качества у нас был ступенчатый. Внутренним контролем качества занимались специалисты департамента внедрения SAP в "БДО Юникон", не входившие в команду внедрения. Как наш аудитор, компания "Эрнст энд Янг" осуществляла контроль качества и сроков, а также проектных решений и соответствия их международным стандартам.

Кроме того, в том, что касается ресурсной поддержки, крайне важная роль принадлежала рабочим группам филиалов. На каждом филиале, в зависимости от его размеров и сложности процессов, мы создали рабочие группы от 7 до 25 человек, которые примерно на 70% были задействованы в проекте. Как правило, мы пытались набирать эти рабочие группы из специалистов по функциональным направлениям: бухгалтеров, экономистов, финансистов, то есть тех, которые должны будут функционировать в системе. Они работали с проектной командой, готовили нормативно-справочную информацию, занимались рассмотрением проектных решений, адаптировали процессы в системе к ситуации на своих заводах, в той степени, в которой это было необходимо, занимались координацией всех работ по закрытию периода, когда система была запущена, обучали пользователей и т. д. В целом на разных этапах работ на всех заводах СУАЛа привлекалось около 400 функциональных и ИТ-сотрудников. Это достаточно большие ресурсы, которые были, безусловно, необходимы.

Насколько детально вы в такой ситуации планировали работы по проекту?

На самом деле планирование нашего проекта - отдельная тема. Мы уделили этому очень много внимания. Во-первых, мы воспользовались методиками PMI. У нас был мастер-план, который умещался на двух страницах, по которому мы отчитывались перед правлением компании и советом директоров. На этом уровне детали не так важны, здесь надо видеть общий ход проекта. Из этого плана вытекал огромный каскад планов. В первую очередь, основной план проекта, впервые составленный в начале проекта в апреле. Он было достаточно подробный (около 4000 строк), с интервалом планирования приблизительно на неделю.

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

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

Вы упомянули про управление изменениями. У вас на проекте произошло практически "чрезвычайное происшествие": через три месяца после начала проекта, уже после проведения концептуального проектирования, объем проекта был увеличен еще на три завода. Как вы справились с этим?

От изменений застраховаться на 100% невозможно. Например, в декабре 2004 года, прямо перед запуском системы в промышленную эксплуатацию, нам пришлось принять решение о переходе с января 2005 года к новой схеме товарно-материальных потоков. Поэтому мы проводили работы, которые снижают эти риски. Во-первых, мы отслеживали внутреннюю среду предприятия, прогнозировали, какие могут быть изменения, и к ним готовились. Во-вторых, изначально в проектных решениях было заложено то, каким образом мы сможем реагировать на изменения.

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

И этот подход полностью оправдал себя в ситуации с расширением проекта еще на три завода. Понимание возможности такого изменения у нас возникло в начале июля. К тому времени по плану проекта (без этих заводов), все проектные решения должны были быть готовы к концу июля, в августе - разработка системного прототипа и в сентябре-октябре - интеграционный тест. В середине июля подтвердилась информация, что эти заводы станут частью СУАЛа. Нам пришлось срочно предпринимать все необходимые шаги. Во-первых, мы в течение двух-трех дней собрали совместную команду методологов, консультантов и наших специалистов по внедрению, которая выехала на заводы. Буквально за две недели мы объехали все заводы и проанализировали их бизнес-процессы. Отличались они на самом деле очень сильно, на заводах была другая классификация оборудования, несколько иное формирование себестоимости. Поэтому шаблонировать наши проектные решения мы не могли.

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

Как сильно вы изменили сроки проекта?

Практически не изменили. Дело в том, что в нашем мастер-плане еще в начале проекта была предусмотрена "подушка", резерв примерно, недели две-три. Так, мы должны были закончить все проектные решения к концу июля, а с 15 августа начать настройку системы. И нам удалось за это время сделать и утвердить новые проектные решения для новых заводов. Дальше уже шли по старому плану. По сути говоря, за полтора месяца эти заводы подняли на борт проекта, не теряя темпа. И несмотря на то, что мы изначально на каждый этап оставляли небольшой резерв, к официальному запуску системы 1 января 2005 года мы подошли с нулевыми резервами. Еще бы два-три дня задержки, и мы могли бы сорвать первый банковский день - 11 января.

Насколько вы опирались на "лучшие практики", зашитые в систему? И насколько вы кастомизировали систему?

С самого начала мы ориентировались на использование максимального количества стандартного функционала и наименьшее количество изменений. И нам удалось эту стратегию выдержать. Мы прекрасно понимаем, что в определенных случаях стандартный функционал не удобен, например, в российской бухгалтерской отчетности. Что иногда он не очень удобен для пользователей. Естественно, были определенные модули, определенные процессы, которые нам приходилось дорабатывать под нашу специфику. Тем не менее эта позиция нами была выдержана, и объем доработок оказался небольшим. Например, пришлось делать собственные разработки в части управления финансами или налоговой отчетности по НДС. Но и здесь есть наработки, которые уже можно считать стандартными функциями, потому что эти решения предложены консультантами, проверены и опробованы на опыте. Это своеобразные стандартные add-on к системе.

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

Вы упомянули про адаптацию процессов в системе к ситуации на заводах. Насколько ситуации с методологией учета на заводах различалась, и как это выглядит после запуска системы?

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

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

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

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

Кроме того, для определенных, достаточно масштабных вопросов, например по архитектуре, нужна была третья сторона, которая могла бы нас проконсультировать. Это делали консультанты "Эрнст энд Янг", тем более что им как нашим аудитором в конечном итоге тоже работать с этой системой. Поэтому нам необходимо было понимать все требования, которые будут предъявляться к учетным политикам. Более того, сейчас законодательная среда в мире меняется в сторону большего количества ограничений и мы должны видеть, каким образом система должна соответствовать изменениям в законодательстве. В общем, такой консультант был, безусловно, необходим.

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

Один из критических моментов - решение о запуске системы в продуктив. Как вы принимали это решение?

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

Основное решение о запуске системы в продуктив принималось после проведения интеграционных тестов, на управляющем совете в конце декабря. Здесь надо сказать, что сжатые сроки проекта не позволили нам делать интеграционные тесты такими, как требуют PMI, контрольные примеры, живой месяц работы системы и т.д.. В реальной жизни эти тесты редко проводят. Мы обсуждали вопрос, не прогнать ли нам в системе реальный месяц, но не пошли на это. 24 декабря мы делали прогон платежного дня, весь департамент финансового планирования работал в системе с самого утра, мы проигрывали все операции (оплата, платежные поручения, связь с банком, формирование заявок, контрактов), чтобы понимать, как утром 11 января, когда откроется первый банковский день, мы будем работать. И хотя тогда еще не было все готово на 100%, мы понимали, какие проблемы будут, и знали, что за оставшееся время мы можем с ними справиться.

Кроме того, на интеграционном тесте мы обкатали help desk и уже имели определенную статистику, сколько запросов по ошибкам закрыто, сколько находится в работе и т. д. К концу декабря, к завершению интеграционного теста, статистика показала положительную динамику - у нас был большой процент закрытых запросов (около 70%). Это же подтвердили и заводы после анализа результатов интеграционного теста.

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

Уже полгода система находится на стадии стабилизации. Оправдались ли прогнозы по ее готовности к работе?

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

Но основная проблема в том, что для такой массы людей старт был определенным организационно-культурным шоком. Правда, привыкание произошло достаточно быстро, примерно до конца февраля. Закрывая март, мы уже уложились в законодательно установленные сроки по налогу на прибыль (28 апреля). Затем работа существенно ускорилась, и к сегодняшнему дню мы вышли на 15-е число. Это время расчета себестоимости продукции по заводам. Для нас здесь целью являются себестоимость, выручка, все основные отчеты по МСФО, и их мы закрываем 15-17 числа по всем заводам.

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

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