В рамках форума выступило 9 экспертов и топ-менеджеров из ведущих российских и международных компаний (РЖД, «ВымпелКом», NIS, «Альянс-Энерджи», BauerMedia, «Азбука вкуса» и других).

Чтобы приобрести материалы конференции, звоните по телефону +7 (495) 971-92-18 или пишите по электронной почте events@cfo-russia.ru

Форум открыло выступление Алексея Урусова, заместителя генерального директора, финансового директора компании NIS (группа «Газпром нефть») на тему «Внедрение ERP-системы как ключ к наведению порядка: кто за что отвечает». По словам Урусова, проект внедрения SAP в компании был начат еще в 2006 году. На первом этапе был автоматизирован бэк-офис, в том числе финансы и контроль. Был реализован и проект по созданию отдельной ИТ-структуры – своеобразной бизнес-поддержки, сотрудники которой понимают процессы и то, что можно сделать для улучшения эффективности компании. «Но попытка ввода системы в эксплуатацию провалилась: в ней поработали несколько дней и решили вернуться к проверенной Excel.

После вхождения компании в группу «Газпром нефть» проект внедрения SAP был вновь запущен. На последней стадии было автоматизировано управление реализацией нефтепродуктов и интеграция этого модуля SAP с промышленными системами», – говорит Алексей Урусов.

Здесь же были расписаны процессы логистики, заказа, создания фактуры и товарной накладной. Основной беспорядок в этих бизнес-процессах касался количества учтенного и неучтенного, реализованного фактически и на бумаге продукта. «Когда мы наводили порядок, то столкнулись с серьезной коррупцией; к примеру, в бензовозы пытались залить на полтонны больше нефтепродуктов. Сербы это называли “скрытыми возможностями”», – отметил Алексей Урусов.

На методах определения экономической эффективности от инвестиций в ИТ акцентировал внимание в своем докладе Алексей Нестеров, директор по ERP-решениям 1С.

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

Нестеров также рассказал, как можно повысить инвестиционную привлекательность и капитализацию предприятия благодаря ERP-системе. Этому способствуют следующие факторы:

• построение качественной системы управления бизнесом;
• обеспечение прозрачности для инвесторов;
• обеспечение сохранности конфиденциальных данных;
• поддержка стратегии развития бизнеса и др.

Автоматизация таких крупных предприятий, как РЖД, непременно требует пересмотра бизнес-процессов. По словам Бориса Аксенова, заместителя департамента бухгалтерского учета РЖД, в месяц в компании проходит более 40 млн операций.

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

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

О риск-менеджменте ERP-проекта рассказал Владислав Беляев, руководитель департамента систем управления предприятием компании «ВымпелКом».

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

Помимо рисков Беляев акцентировал внимание на необходимости всячески детализировать проект. К примеру, отражать в уставе проекта его рамки или расписывать детали плана с точностью до часа. «Очень важно документировать все, что происходит в процессе реализации проекта. Также необходимо отслеживать и контролировать ситуацию и выявлять новые риски, связанные со сроками, изменением картины проекта, проблемами бизнеса», – подытоживает Владислав Беляев.

Своим опытом создания эффективной команды внедрения поделилась Александра Феоктистова, директор департамента контроллинга и автоматизации компании «Мир Детства».

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

По мнению Феоктистовой, чтобы создать максимально эффективную команду, нужно ответить на несколько вопросов:

• какие структурные подразделения участвуют в автоматизируемом бизнес-процессе?
• кто знает о начале, конце, «реперных точках» бизнес-процессов в этих подразделениях?
• кто в подразделении был инициатором атоматизации тех или иных функций?
• как давно работает сотрудник в компании и знает ли особенности бизнеса и управления компанией?
• насколько он опытен в своем функционале?
• насколько он лоялен к группе внедрения?

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

Владислав Норкин, президент компании «Альянс-Энерджи», затронул проблему управления изменениями при внедрении ERP-системы «1C:УПП 8.0».

По словам Норкина, первая попытка внедрения системы оказалась неудачной, система не была готова к работе, не были учтены многие моменты, также невозможно было получать оперативную информацию. Поэтому в 2008 году проект был пересмотрен и на его продолжение были выделены денежные средства, несмотря на начавшийся кризис. «Первое, что было сделано – проведен аудит входящих остатков по складу и договорам, а это 30 тысяч ТМЦ и 5 тысяч контрагентов. Эту работу взял на себя подрядчик. Мы же выделили команду, которая стала на регулярной основе контролировать проведение работ и сокращать объем нерешенных проблем. В итоге мы получили реальную и актуальную аналитику счетов, с которой было удобно работать», – замечает Владислав Норкин.

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

Третим важным моментом были переход к планово-управленческому учету и установка физических величин. «Это позволило вовлечь в работу системы производственный персонал, поскольку такие величины были им более понятны, нежели финансовые. В результате проведенной работы у нас появилась возможность не только пользоваться ежедневной информацией, но и вывести услуги на прибыльность, запустить приостановленные проекты при дефиците ОС и использовать систему для управления собственниками компании», – говорит Владислав Норкин.

Об опыте перехода к эффективному менеджменту в результате внедрения ERP-системы рассказали Муза Монамс, исполнительный директор BauerMedia, и Алексей Попов, руководитель проекта. По словам Монамс, компания хотела получить качественный продукт, чтобы его можно было дальше развивать под потребности бизнеса. Поэтому до старта внедрения большое внимание было уделено предпроектной стадии. А через год после начала работ, система была успешно запущена. «Мы первыми в России внедрили модуль продажи рекламы. Это был сложный процесс, автоматизация которого позволила свести к минимуму трудовые усилия в этом направлении бизнеса. И теперь бронирование рекламного места, создание контракта и т.д. полностью автоматизировано», – отмечает Алексей Попов.

Кроме того, система позволила не только более точно рассчитывать KPI для сотрудников, но и пересматривать политику продаж. «Мы можем в оперативном режиме отследить, сколько контактов у конкретного менеджера было за месяц, таким образом видим его продуктивность. Нам виден и результат этих контактов – заключена ли сделка. Если сделка не заключена, мы можем выявить причины и, возможно, пересмотреть политику продаж конкретного издания в регионе», – говорит Муза Монамс.

«Мы можем оперативно получать и анализировать данные по уровню продаж того или иного издания в разных регионах России по месяцам», – добавляет Алексей Попов.

Виктория Лубнина, финансовый директор продуктовой сети «Азбука вкуса», открыла круглый стол на тему «Оценка эффективности внедрения и использования ERP-системы». Как отметила Лубнина, в компании работает четыре информационные системы. Финансовый блок, помимо ключевой системы MSDynamicsNAV и 1С использует в своей работе OracleBIEE и JedoxPALO. «Оракл – это система бизнес-аналитики, позволяющая быстро и эффективно получать агрегированную информацию для принятия решений, а также выполнять adhoc запросы. В нашем варианте работает на хранилище SybaseIQ. PALO – это гибкий OLAP сервер с клиентом MicrosoftExcel. Он достаточно легко настраивается и администрируется, кроме того это гибкий продукт. Здесь же реализовано прогнозирование», – говорит Виктория Лубнина.

Как отметила Лубнина, в результате внедрения ERP-системы компания полностью отказалась от ручного труда в части платежных операций. В то же время проект сопровождался определенными трудностями. Это и отсутствие навыка пользователя у вновь нанимаемых сотрудников. Дороговизна массового обучения, которое необходимо проводить регулярно. А также проблемы коммуникации IT-специалистов и пользователей. «Поэтому мы внедрили KPI и автоматизировали расчет зарплаты. Благодаря этому у людей растет заинтересованность в обучении и в более точном отражении информации», – заключает Лубнина.

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

Чтобы приобрести материалы конференции, звоните по телефону +7 (495) 971-92-18 или пишите по электронной почте events@cfo-russia.ru

Текст: Снежана Дормидонтова

Фото: Дарья Полунина

В кризис компания вошла несколько позже, чем другие российские организации. Если по итогам 2008 года большинство предприятий уже ощутили снижение доходов, «Роникон» почувствовал спад только к концу 2009 года.

Объяснялось это довольно просто. Ниша, которую компания занимает на рынке, привязана к объемам сдаваемых новостроек. И поскольку в конце 2008 года люди еще обставляли новые квартиры, производство и продажи были на стабильно высоком уровне. Но в это время кризис в других отраслях уже наступил, и строительство новых домов было либо прекращено, либо заморожено. Однако в начале 2009 года люди еще обналичивали свои депозиты. Средства многие тратили на покупку мебели для квартир, купленных перед началом кризиса. Когда банки перестали выдавать физическим лицам кредиты, делать приобретения стало невозможно. Именно тогда в «Рониконе» наступил спад. Способствовала этому и валютная политика государства.

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

Несмотря на падение финансовых показателей, компания продолжала выполнять свои социальные обязательства – ни в кризис, ни после него сокращений персонала не было. Наоборот, в 2009 году штат был увеличен на 10%. И только в 2011 году руководство «Роникона» пересмотрело ряд функций, которые выполняются сотрудниками на местах, и от некоторых из них решило отказаться. Вследствие этого была проведена оптимизация численности персонала – примерно такой же процент сотрудников, на который пополнилась компания в кризис, был уволен. Под сокращение попали маркетологи, описатели бизнес-процессов и т.п. – то есть те, от кого российские компании отказывались в 2008 году в первую очередь.

Кредиторка по отсрочке

Специфика работы среднего мебельного бизнеса заключается в практически полном отсутствии дебиторской задолженности. Это связано с тем, что основные продажи ведутся в розницу. Поэтому такие предприятия, как «Роникон», и в кризис не испытывают проблем с дебиторской задолженностью. По-другому складывается ситуация с кредиторской задолженностью. Часть собственных оборотных средств компания финансировала в кризис и финансирует сейчас за счет кредиторской задолженности. Условия договоров, которые заключает «Роникон» с поставщиками, позволяют ему платить с отсрочкой платежа после поставки продукции. Такие условия вызваны сезонным характером бизнеса. Закупка сырья, к примеру, производится в сентябре, через месяц начинаются продажи, соответственно, увеличивается объем заказов. Именно из вырученных средств спустя месяц производится погашение кредитных обязательств. Поставщики на такие условия идут – стабильное положение компании на рынке, большие объемы производства и закупки сырья являются гарантом исполнения «Рониконом» своих обязательств.

ERP без заморозки

Когда в кризис большинство компаний замораживало или прекращало свои инвестпроекты, «Роникон» продолжил вкладывать средства в два своих основных проекта – внедрение ERP-системы и закупку нового оборудования. Как говорит директора по ИТ «Роникон» Алексей Батраков: «Рост объемов производства потребовал расширения производственных площадей. Поэтому в 2006 году фабрика переехала на новое место в городе Щелково. Сейчас ее цеха укомплектованы самым современным оборудованием. Еще в кризис, когда все терпели убытки, многим пришлось отказываться от своих наработок в части мебельного оборудования. Мы тогда воспользовались возможностью и полностью обновили технологический парк. Благодаря этому мы увеличили объемы производства и расширили технологические возможности. Кроме того, у нас есть стратегия. Есть видение, чего мы хотим достичь в течение пяти лет и больше. Но эта стратегия в конкретный инвестиционный проект еще не воплощена. Поэтому можно сказать, что в период, когда компания испытывала трудности, мы отложили реализацию этого проекта. Это, пожалуй, единственный проект, который мы заморозили».

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

«При выборе продукта учитывались несколько факторов, включая стоимость внедрения, распространенность среди подобных предприятий и соответствие возможностей системы отраслевой специфике компании и ее бизнес-процессам. Кроме того, необходимо было учесть и размер компании – объемы продаж «Роникона» не позволяют иметь слишком дорогую ERP-систему, которая требует существенных затрат на обслуживание. К тому же и возможности больших систем компании не нужны – она просто не будет их использовать. Учитывая все перечисленные факторы, мы остановились на одной из популярных отечественных систем», — говорит Алексей Батраков.

Главной задачей внедрения было полностью отразить в системе основной бизнес-процесс – производство мебельной продукции. Эта задача в дальнейшем декомпозировалась на подзадачи, охватывавшие те или иные подразделения предприятия.

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

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

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

Однако почти каждый этап работ был сопряжен с теми или иными трудностями. «Не все задачи сразу же были четко сформулированы, более того, внедрение не шло последовательно от начала и до конца. Менялись цели, менялись и результаты работ. Поскольку наша компания молодая и активно развивается, первоначальное представление о том, что мы хотим получить, в процессе внедрения системы менялось. Причем менялось в сторону расширения наших пожеланий. Сначала мы хотели обойтись малыми усилиями и получить простой продукт, чтобы увидеть в целом, что из себя будут представлять автоматизированные процессы. А когда получили первый результат, поняли, что для управления бизнесом необходимо уже больше», – продолжает Алексей Батраков. После первого тестирования в конце 2008 года команде внедрения пришлось дорабатывать техническое задание (в том числе прописывать расширение задач) и саму систему. Во второй половине 2009 года было проведено очередное тестирование, устранение ошибок и окончательный запуск системы.

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

Но главная трудность заключалась в том, что сначала были автоматизированы все процессы, и только после этого происходило их описание. Связано это было с тем, что до внедрения системы компания не успела описать процессы. К тому же на момент запуска проекта служба ИТ была укомплектована полностью, а блока описания процессов не было вовсе. И только в конце 2009 года в «Рониконе» было описано то, что имелось на тот момент.

Не стоять на месте

Параллельно с внедрением ERP-системы, «Роникон» как компания, ориентированная на розничные продажи мебели, продолжала расширять сеть своего присутствия. Хотя кризис повлиял на темпы открытия новых салонов – они замедлились, к тому же более осознанным стал подход к выбору расположения магазина. Многие торговые точки, хоть и находятся в проходимых местах, не приносят существенной прибыли. Возможная причина – рядом нет конкурентов. Когда человек приобретает мебель, он нередко едет в крупные мебельные центры, где может посмотреть все предложенные образцы. И сейчас отдел продаж компании целенаправленно открывает магазины именно в таких специфических торговых центрах – мебельной направленности. Новые салоны открываются быстро, обычно в течение двух недель. По принятому плану магазины должны окупаться в течение полугода. Те, которые не окупаются, компания столь же быстро старается закрыть. За период с 2008 года в абсолютном выражении количество магазинов уменьшилось на 10.

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

Изменения к лучшему

Каковы дальнейшие шаги по развитию систему управления в компании? Сейчас внедренное ERP-решение полностью охватывает весь функционал, который в «Рониконе» есть или появляется. С ростом бизнеса возникают те или иные нововведения, которые необходимо сразу учесть в системе. Например, расширилась аналитика отчетов, это потребовало несложных настроек. На определенном этапе руководство компании решило ввести штрих-кодирование производимой продукции. «Изначально такая задача не стояла, однако специализация производства привела к тому, что это оказалось необходимым. Поэтому в системе был дополнительно настроен соответствующий модуль. В ближайшем будущем планируется наладить получение консолидированных данных для формирования управленческой отчетности», — отмечает Алексей Батраков. Кроме того, при внедрении системы производство было автоматизировано без вспомогательных бизнес-процессов. В настоящий момент в этом направлении ведется соответствующая работа.

http://www.cfo-russia.ru

Группа компаний «ПРОМСТРОЙ ГРУП» – строительно-монтажный холдинг по проектированию и строительству крупных промышленных объектов энергетического сектора экономики (объекты добычи, транспорта, переработки нефти и газа, большой и малой энергетики, металлургии).

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

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

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

В качестве платформы для автоматизации названных задач был выбран продукт компании 1С «Управление производственным предприятием 8». Предпосылками такого выбора стали: во-первых, простота обучения (по сравнению с другими программами) бухгалтеров и экономистов, имевших опыт работы с другими продуктами 1С; во-вторых, стоимость владения (первоначальные инвестиции, техническая поддержка и развитие системы), в третьих, географическая распределенность объектов и текучесть кадров, связанная с «кочевым» характером бизнеса компании.

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

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

Централизованное решение с организацией терминального доступа к учетной системе лишено этих проблем. Суть его заключается в том, что единственная общая база хранится на центральном сервере, а доступ к ней удаленными пользователями осуществляется в реальном времени. Но данный вариант более требователен к ИТ-инфраструктуре. В первую очередь – к каналам связи, что может привести к проблемам при наличии множества точек доступа, расположенных в регионах. Дело в том, что внутренние стандарты компании в области информационных технологий предусматривают минимальные требования к скорости доступа на уровне не ниже 1 Мбит/сек.

Следующим шагом после определения подхода к созданию ИТ-инфраструктуры стал выбор интегратора. Подрядчик был выбран в результате конкурса с участием четырех компаний – им стала фирма «1С: Бухучет и торговля» (позже – «БИТ»). Внедрение системы началось в августе 2006 года, а 1 января 2007 года мы уже приступили к опытно-промышленной эксплуатации. Безусловно, нет ничего хуже, чем внедрять программу в середине года – в любом случае ее эксплуатация начнется не раньше следующего года, да и то наверняка останутся существенные недоработки, которые потом придется спешно исправлять и доделывать.

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

Формирование финансового результата и отчетности, а также другие модифицированные участки системы впоследствии пришлось переделывать согласно архитектуре программного продукта таким образом, чтобы возможно было автоматизировать отчетность и операции по закрытию периодов. Так, в 2008 году «ПРОМСТРОЙ ГРУП» собственными силами начала автоматизацию налогового учета и отчетности. В своей работе мы используем положение ПБУ 18/02, поэтому было очень важно правильно автоматизировать эту процедуру – несоблюдение требований Минфина влечет существенные налоговые риски, а выполнение данных правил в ручном режиме является очень трудоемким процессом.

Более того, в стандартной конфигурации платформы на момент внедрения отсутствовали некоторые модули, которые требовались для отражения в учете операций, предусмотренных учетной политикой предприятий, например учет внутрихозяйственных расчетов через 79 счет. Этот блок пришлось дорабатывать сначала силами «БИТ», а затем совершенствовать для автоматического закрытия самостоятельно.

«Прелести» внедрения

При автоматизации возник целый ряд трудностей.

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

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

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

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

Все выше, и выше, и выше

В результате реализации стратегии развития «ПРОМСТРОЙ ГРУП» приобрела шесть предприятий в конце 2007 – начале 2008 годов. У нас появился другой бюджет, другие задачи, и мы поняли, что для управления этими компаниями необходимо модернизировать информационную систему.

В одном из приобретенных предприятий («СУ-6 Нефтегазмонтаж», г. Ставрополь) было очень мощное решение на платформе «1С:Бухгалтерия 7.7». Если бы эта компания внедрила у себя нашу конфигурацию, ей пришлось бы отказаться от действующей в ней на момент покупки учетной политики и специфики учета. Однако в конфигурации 1С 7.7 в «СУ-6» не было бюджетных и казначейских модулей, поэтому эти процессы были автоматизированы в первую очередь и начали успешно функционировать, хотя бухгалтерский учет все еще велся в версии 7.7. В отличие от этого предприятия, в другой приобретенной нами организации – екатеринбургской «Уралмонтажавтоматике» – в силу сложной многофилиальной структуры существовал учет внутрихозяйственных расчетов, отличный от принятого в «ПРОМСТРОЙ ГРУП», что крайне затрудняло работу как им, так и нам. Для того чтобы сформировать консолидированные отчеты, главные бухгалтера семи филиалов приезжали в головной офис со своими бумагами и вручную формировали все данные, после чего проводили их сопоставление.

Поэтому мы решили унифицировать систему для всех предприятий группы с учетом специфики каждой организации. За основу была взята существующая на тот момент структура системы в «восьмерке», приняты во внимание особенности ставропольского предприятия (оно было лучше всех готово к внедрению и имело большой опыт общения с разработчиками), а также принято решение доработать наш продукт. В «СУ-6» внедрили бюджетирование и казначейство и в 2009 году перешли на ведение бухгалтерского и налогового учета в корпоративной системе восьмой версии. А в «Уралмонтажавтоматике» в 2008 году начали внедрять все функциональные блоки.

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

Особенности бюджетирования

При внедрении системы мы стремились добиться, с одной стороны, максимально простых и понятных принципов бюджетирования, а с другой – обеспечить контролепригодные процедуры. Кроме того, принятая нами стратегия развития, в рамках которой мы планируем выход на IPO, подразумевает актуальность и достоверность прогнозов. Это еще один фактор, потребовавший унификации и улучшения бюджетных процедур. Большое влияние оказало также и принятие нового стандарта ПБУ 2/2008 «Учет договоров строительного подряда», где выручка отражается не по актам выполненных работ, а исходя из степени завершенности проекта и его маржинальности, базирующихся на бюджетах проектов.

Как выглядит процесс бюджетирования в «ПРОМСТРОЙ ГРУП»? У нас есть ключевые показатели на 5 лет, которые корректируются в конце каждого года: это выручка, прибыль, операционно-денежный поток и т.д. В конце года утверждается бизнес-план на следующий год, состоящий из 15 ключевых статей, в числе которых материалы, фонд заработной платы, производство, амортизация. Далее принимается производственная программа на первый квартал. Она состоит из проектов, которые буду реализованы в этом периоде. На основании принятой производственной программы верстается квартальный бюджет предприятия. Бюджетирование в компании ведется по проектам в разрезе центров финансовой ответственности (ЦФО).

По мере появления новых проектов вносятся корректировки в бюджет – отсюда и пошло утверждение плана только на квартал. Также мы, с оглядкой на производственную программу, можем заложить в бюджет проект «Х». Для этого у нас уже должны быть некие предпосылки, к примеру близящийся тендер и высокая вероятность победы в нем. Соответственно, мы принимаем этот проект и формируем его бюджет.

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

В «ПРОМСТРОЙ ГРУП» существует градация бюджетов в зависимости от стоимости проекта. С ее учетом определен круг ответственных за утверждение плана. Это мы и называем лимитом ответственности. Допустим, если проект предполагает бюджет до 30 млн рублей, то утвердить его может директор филиала. Проекты свыше 30 млн рублей утверждает управляющий директор дочернего общества. Все, что превышает 300 млн рублей, согласовывается и утверждается исключительно президентом группы. После утверждения бюджет ставится на контроль в информационной системе.

Интересное, с нашей точки зрения, решение мы нашли для предконтрактной стадии проекта. Получив документальное подтверждение победы в тендере, проектный менеджер начинает обсуждать с заказчиком ключевые условия будущего контракта и основных приложений к контракту (графиков строительства, комплектации, финансирования). Данные для планирования бюджета пока отсутствуют, но в системе уже открывается лимит под этот проект. В бюджет договора/проекта он войдет позднее, но уже на данном этапе позволяет нести компании определенные затраты. Например, делать авансовые платежи (до 30%), а также расходовать средства на первичную перебазировку и развертывание сил на объекте. Таким образом мы допускаем риски на минимальную сумму.

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

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

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

Нет договора – нет оплаты

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

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

Во-вторых, каждый платеж проходит процедуру контроля, включающую в себя:

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

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

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

Ликвидность и дисконтирование

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

По мнению многих экспертов, кризис миновал, однако мы продолжаем следовать процедурам, установленным два года назад, хотя и допускаем некоторые послабления. Сейчас платежный календарь выступает в качестве одного из инструментов управления ликвидностью. Он формируется в системе «1С:Предприятие» предприятиями группы на месяц с недельной разбивкой. И позволяет нам не только управлять собственной ликвидностью, но и выявлять периоды кассового разрыва как на уровне дочернего общества, так и на уровне всей группы. Типовой платежный календарь был в решении «1С», однако он не подходил нам по ряду параметров, поэтому мы его серьезно модифицировали. Как мы работаем с ним? К примеру, регулярно перед первым числом нового месяца планируем поступления и выплаты в недельной разбивке по месяцу. Мы определили порог существенности ­(80% от суммарных платежей на месяц), и, таким образом, наблюдаем только крупные статьи и платежи по операционной, инвестиционной и финансовой деятельности.

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

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

Дальнейшее развитие: интеллектуализация

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

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

Хотелось бы сделать акцент еще на одном моменте. В «ПРОМСТРОЙ ГРУП» управление бюджетированием и ликвидностью привязано к управлению проектами. В настоящий момент мы работаем с двумя системами управления проектами: Primavera и Spider Project. Первая находится в опытной эксплуатации, вторая – в промышленной. Оба продукта могут быть интегрированы с решением на платформе «1С:Предприятие 8».

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

Кирилл Поляков, исполнительный вице-президент – финансовый директор, ЗАО «ПРОМСТРОЙ ГРУП»

1С:Консалтинг

Форум, проводимый под эгидой портала CFO-Russia.ru и Клуба финансовых директоров, поможет Вам:

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

Среди спикеров Третьего Международного ERP-форума:

• Андрей Соловьев, административный управляющий директор, Метсо Минералз СНГ
• Игорь Ковалев, директор по ИТ, Ford
• Борис Аксёнов, ОАО «РЖД»
  

Отчет о первом дне Второго ERP-форума

Отчет о втором дне Второго ERP-форума

Отчет о ток-шоу «Распределение ролей при реализации ERP-проекта»

СПЕЦИАЛЬНОЕ ЗИМНЕЕ ПРЕДЛОЖЕНИЕ!

• Стоимость участия в конференции: 44 900 руб. (НДС не облагается)
• При регистрации и оплате до 15.12.10 стоимость участия: 34 900 руб.
• При регистрации и оплате до 31.12.10 стоимость участия: 39 900 руб.
• Стоимость для представителей консалтинговых компаний и компаний-вендоров: 52 900 руб.

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

По вопросам участия в Третьем международном ERP-форуме, возможностей выступления и спонсорской поддержки обращайтесь по телефону: +7 (495) 971-92-18 или по электронной почте events@cfo-russia.ru.

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

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

«Отдел поддержки пользователей обслуживает десятки тысяч сотрудников ВТБ. Именно поэтому повышение эффективности его работы напрямую отражается на качестве обслуживания клиентов банка, – комментирует Дмитрий Недачин, начальник Отдела поддержки пользователей УВиСИС ОАО «Банк ВТБ». – Решение TopS BI, в рамках которого была выстроена работа внутреннего контакт-центра, позволило сократить время устранения технических проблем, возникающих у пользователей компьютерных систем, в том числе сотрудников банка, непосредственно работающих с клиентами. В результате, нам удалось не только снизить издержки, но и повысить качество обслуживания сотрудников банка».

Специалисты компании TopS BI обладают многолетним опытом реализации проектов для банковского сектора по интеграции контакт-центров Avaya, Genesys, CISCO с бизнес-приложениями таких ведущих мировых поставщиков как, Microsoft, Oracle, HP, SAP и др.

Именно благодаря высокому уровню компетенций специалистам компании TopS BI удалось разработать наиболее подходящее техническое решение по интеграции контакт-центра Avaya и системы управления процессами поддержки на базе HP Service Manager. В рамках проекта эксперты TopS BI провели обследование инфраструктуры Avaya, разработали проект технического решения и внедрили новые автоматизированные рабочие места (АРМ) операторов Отдела поддержки пользователей банка ВТБ.

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

«Внедрение подобного сервиса не только позволяет проводить постоянный мониторинг и анализ системы поддержки пользователей, но и вносить своевременные изменения в бизнес-процессы обслуживания с минимальными временными затратами, — комментирует Эдуард Лысенко, руководитель дирекции инфраструктурных решений компании TopS BI. – Стоит также отметить, что за счет стандартизации интерфейсов работы с информацией достигнуто сокращение временных и финансовых затрат на ввод в работу новых сотрудников и площадок обслуживания».

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

Расскажите, как складывалась ИТ-инфраструктура Ford в России?

Ford в России – это завод во Всеволжске, производящий модели Focus и Mondeo, плюс центральный офис продаж, находящийся в Москве. Строительство завода началось в 1999 году, а запущен в эксплуатацию он был в 2002 году. Когда зашла речь об автоматизации бухгалтерии и связанных с ней процессов, выбор продукта осуществлялся в условиях отсутствия готового централизованного решения. Богатая и долгая история бизнеса, его региональная разветвленность, многочисленные слияния и преобразования — все это наложило отпечаток на системный ландшафт корпорации. Даже количественную оценку портфеля используемых по всему миру систем дать достаточно трудно, могу лишь сказать, что портфель этот превышает две сотни различных продуктов. На основе опыта функционирования завода в Белоруссии и рекомендаций российского части менеджмента завода в качестве ERP-платформы для автоматизации российского бизнеса был выбран продукт «1С», и на сегодняшний день эта система является одним из основных узлов системного ландшафта Ford в России. Система не однородна и представляет собой несколько взаимосвязанных модулей этого вендора, доработанных под требования компании.

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

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

Кроме того, существовал негативный опыт внедрения западного продукта в белорусской «дочке» Ford: после первого годового отчета, поданного в налоговую инспекцию, выяснилось, что европейский стандарт отчетности абсолютно не соответствует требованиям белорусского законодательства. В результате компания заплатила значительный штраф. Мало того, все транзакции отчетного года пришлось вручную переносить в «1С», что запомнилось очень прочно. Поэтому, выбирая продукт для России, мы помнили, что необходимо гарантировать соответствие отчетности российским нормативным требованиям. Продукт «1С» дает такую гарантию, что стало дополнительным аргументом в пользу российской платформы.

По прошествии 10 лет система по-прежнему справляется со всеми возложенными на нее задачами, поддержка решения требует минимальных человеческих ресурсов. В группе поддержки – три штатных аналитика и пять программистов со стороны компании-интегратора. Когда в 2008 году осуществлялся реинжиниринг системы, группа программистов была временно расширена до десяти человек, но потом снова сократилась до пяти специалистов.

Проводился ли аудит системы на соответствие корпоративным стандартам? И как эти стандарты повлияли на функциональность решения?

Все модули решения прошли полную сертификацию на соответствие требованиям глобальной штаб-квартиры Ford, причем затраты – как на поддержку, так и на запуск – оказались на порядок ниже тех, которые сопутствовали бы внедрению глобальных ERP-решений, используемых компанией за пределами России. Действующая система успешно поддержала все инициативы бизнеса, включая расширение производства и запуск российской кампании продаж для марок Land Rover и Volvo. Внутренние и внешние аудиторы не выявили каких-либо недостатков в системе. При этом необходимо понимать, что внутренние аудиторы проводят весьма жесткие и скрупулезные проверки, и сам аудит может занимать до шести недель. Если будет найдено малейшее несоответствие системы и формируемых в ней отчетов корпоративным требованиям, то её исправление будет тщательно контролироваться из штаб-квартиры компании в США. Система также должна полностью соответствовать требованиям закона Sarbanes-Oxley.

Что касается объема доработок, то могу сказать, что система была переписана примерно на 90%, и это обусловлено тем, что в компании действуют складывавшиеся годами жесткие стандарты в части бизнес-процессов. Менять эти стандарты для сравнительно небольшого российского рынка никто, естественно, не собирался, а потому менять пришлось систему. Здесь мало что зависело от выбранной платформы. Масштаб доработок оказался бы примерно таким же, если бы даже мы выбрали SAP. Такова специфика крупных компаний с длительной историей: аудиторы «Большой четверки», с которыми мне приходилось общаться, подтверждали, что при внедрении SAP или Oracle в любой крупной международной компании, существующей на рынке несколько десятилетий, от стандартной конфигурации остается максимум 20%.

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

Существует несколько легенд или мифов, касающихся организации крупных ИТ-проектов, и мне бы хотелось эти мифы развенчать. Например, принято считать, что оформление заявок, будучи бюрократической процедурой, задерживает развитие не только системы, но и бизнеса. Так ли это? Для начала можно посмотреть на темпы развития Ford: в 1999 году российским подразделением компании было продано порядка 1300 автомобилей, а в 2008 году – больше 250 тысяч автомобилей.

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

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

Еще один ошибочный стереотип: закрытие месяца невозможно без участия ИТ-отдела. Опыт компании Ford говорит об обратном. Более того, участие ИТ-специалистов в закрытии периода прямо противоречит не только требованиям закона Sarbanes-Oxley, но и требованиям политики внутреннего контроля.

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

Крупные проекты редко обходятся без споров внутри команды внедрения – в части распределения обязанностей, соблюдения сроков и поиска виновников задержек. Как разрешались подобные споры в Ford?

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

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

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

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

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

В 2008 году проходил реинжиниринг системы. Насколько изменился функционал, например, бухгалтерского модуля?

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

Что бы вы могли посоветовать тем, кто планирует начать масштабную автоматизацию бизнеса?

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

Во-вторых, ведите документацию проекта. Это особенно важно, когда уровень кастомизации системы высок. При наличии документации намного проще ознакомить с принципами работы системы новых сотрудников как функциональных департаментов, там и самого ИТ-отдела. Если документации нет, это означает, что отсутствует источник компетенций, из которого можно было бы получить необходимую информацию – ни в одном учебнике по «1С» не описано, как работает система, в которой сохранено только 10-20% стандартного функционала.

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

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

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

Вы долгое время работали в Oracle, позднее внедряли ERP-системы в качестве консультанта, и вот уже семь лет сотрудничаете с «Вымпелкомом». Располагая большим опытом внедрения систем, как бы вы определили общие критерии успешного ERP-проекта?

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

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

Каковы основные мотивы, которыми руководствуется бизнес-заказчик, принимая решение о начале ERP-проекта?

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

Каковы качественные показатели, о которых вы упомянули?

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

Все перечисленные показатели внедрения ERP-системы объединяет то, что их невозможно или крайне сложно оценить экономически. Пусть все они интуитивно значимы, однако, раз их нельзя материализовать, то надо признаться себе в том, что для расчета бизнес-кейса эти показатели неприменимы.

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

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

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

За счет чего может быть достигнуто повышение производительности по итогам внедрения ERP-системы? И как подсчитать изменение производительности?

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

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

В качестве основного мотива для внедрения вы назвали оптимизацию бизнес-процессов. Каковы примерные количественные параметры оптимизации?

Оптимизация за счет изменения бизнес-процессов – задача интересная, хотя и связана с большими рисками. Опасность связана с огромной сложностью управления изменениями. С другой стороны, положительные эффекты оптимизации могут быть очень значительными. Здесь уместно сослаться на одно из исследований AMR Research, в котором приводятся интересные статистические данные. Так, в результате оптимизации уменьшение складских запасов достигает 20-40%, затраты на материалы сокращаются на 10-20%, стоимость закупаемых услуг и материалов снижается на 2-5%, а простои производственных мощностей сокращаются на 10-30% за счет лучшего планирования.

В исследовании AMR приводится значительно больше показателей, и я упомянул только те эффекты ERP-внедрений, с которыми мне действительно приходилось сталкиваться на практике. Так, в результате внедрения в «Вымпелкоме» системы Oracle e-Business Suite 11i в России было достигнуто снижение уровня запасов ТМЦ в два раза, средние закупочные цены удалось снизить на 5-10%, так, что общий экономический эффект за период 2005-2008 годов оценивается в колоссальную сумму.

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

Впрочем, в реальности все может обстоять намного хуже, и существует другая, довольно мрачная статистика, собранная Gartner Group и охватывающая опыт крупных ERP-внедрений в 90-х годах. По данным Gartner, до 90% всех проектов проходило с превышением бюджетов и с нарушением первоначально намеченных сроков, а 60% внедрений и вовсе заканчивались неудачей – проекты просто закрывались, а затраты списывались на убытки. Цифры пугающие, но я счел необходимым их привести: решаться на ERP-проект нужно с открытыми глазами, понимая, насколько высоки ставки и какими тяжелыми могут оказаться последствия неудачного внедрения.

Улучшилась ли ситуация в 2000-е годы и если улучшилась, то благодаря чему?

Да, ситуация улучшилась – отчасти потому, что наученные горьким опытом, многие компании все же нашли верный подход к внедрению, и смогли компенсировать неудавшиеся эксперименты повторными успешными проектами. Кроме того, сильно вырос не только профессиональный уровень консультантов, но и число квалифицированных специалистов. И все же ERP-проекты по-прежнему остаются затратными и долговременными: стоимость внедрения – мы говорим о системах таких вендоров, как SAP, Oracle или PeopleSoft – составляет от 0,5% до 3% годовой выручки компании, а срок реализации проекта варьируется от одного года до трех лет. Эту статистику приводит Gartner, признавая в своем исследовании, что ERP-проект – самая сложная и рискованная ИТ-задача, с которой только может столкнуться бизнес.

Каковы причины, чаще всего приводящие к провалу ERP-проекта?

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

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

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

Серьезные трудности могут возникнуть, если к проекту привлечена слабая команда внешних консультантов. Эта проблема была особенно актуальна для России в 90-е годы, когда квалифицированных внедренцев было просто мало. Например, когда я вел расчеты, касавшиеся внедрения Oracle e-Business Suite в крупном холдинге фиксированной связи, выяснилось, что для обучения всех потенциальных пользователей понадобится привлечь больше тысячи тренеров. В то время суммарный штат консультантов, работавших во всех компаниях, являвшихся официальными партнерами Oracle, не превышал триста человек. Было понятно, что обеспечить внедрение в разумные сроки и бюджет мы вряд ли сможем.

Провал проекта очень вероятен, если заказчик не понимает лучших практик, заложенных в систему, и в компании нет сотрудников, имеющих опыт аналогичных внедрений. Если нет понимания решений, встроенных в систему, то систему начинают дорабатывать под существующие «уникальные» процессы, а объем доработок нарастает лавинообразно. Как следствие, при запуске система выдает массу сбоев в критических процессах для бизнеса, а кроме того, поддержка глубоко кастомизированного решения обходится в астрономические суммы. Наглядным примером неудачной кастомизации служит опыт одной известной аптечной сети: из-за колоссальных проблем в модуле логистики компания за несколько месяцев работы потеряла треть рыночной доли, и положение не удалось полностью исправить до сих пор. В этом смысле «Вымпелком» находился в выигрышном положении: команда управленцев уже однажды прошла через внедрение ERP-системы, а главный финансовый директор, будучи ключевым спонсором проекта, имел опыт развертывания Oracle в другой компании. Поэтому все текущие вопросы удавалось решать максимально оперативно, в режиме еженедельных совещаний. Участники команды внедрения со стороны заказчика и интегратора говорили на одном языке, и это заметно упрощало коммуникации в ходе проекта.

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

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

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

Впрочем, есть случаи, когда внесение изменений в систему оправдано и необходимо. Доработки стандартной системы допустимы, если заказчик абсолютно уверен в том, что в компании есть уникальный процесс, обеспечивающие бизнесу значительные конкурентные преимущества. Общепринятый ориентир по соотношению стандартной и доработанной функциональности таков: бизнес-процессы и требования заказчика выполняются на 80% настройками системы и только на 20% – программной кастомизацией кода.

Типовые модули ERP-системы – финансы, логистика, бухгалтерский и управленческий учет. Что можно сделать на подготовительном этапе, чтобы добиться согласованной работы всех элементов решения?

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

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

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

У вас за плечами – не один завершенный проект. Существует ли некий «рецепт» успеха?

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

Ну а если серьезно, то все же есть наверное некие общие советы, которые помогут компаниям, планирующим начать ERP-проект.

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

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

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

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

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

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

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

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

Александр Зубанов

Как давно вы работаете в структуре РЖД?

Вся моя карьера так или иначе связана с железнодорожной отраслью. Моя профессиональная деятельность началась с МПС, куда меня пригласили после получения диплома на кафедре бухгалтерского учета в Университете путей сообщения. В МПС я пришел в качестве специалиста департамента инвестиционной деятельности, позднее стал начальником отдела в том же департаменте, а в РЖД – тоже в инвестиционный департамент – я перешел в 2003 году, когда была образована компания. Ну и наконец, с 2005 года я работаю в Департаменте бухгалтерского учета РЖД.

В каких проектах вам довелось участвовать?

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

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

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

Кроме того, была образована единая консалтинговая служба, важным элементом которой стал корпоративный портал, объединивший всю методологическую документацию в единую «базу знаний», а также систематизировавший документооборот методологических документов. Можно сказать, что у нас есть свой собственный аналог системы «Консультант Плюс»: бизнес РЖД настолько сложен, что без такого решения просто не обойтись. Дело в том, что в компании представлены практически все виды хозяйственной деятельности, описанные в российском законодательстве. У меня иногда возникает ощущение, что все без исключения ПБУ написаны специально для РЖД. Больше того, нам иногда не хватает действующих правил бухгалтерского учета, и компания активно старается сотрудничать с Минфином в части создания нормативной базы: практически по всем министерским проектам, находящимся в работе, специалисты РЖД готовят свои замечания и предложения. Причем мы видим, что наши замечания учитываются, наши потребности отражаются в итоговых документах.

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

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

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

Разработка единой методологии предполагает объединение бухгалтерского и управленческого контуров учета в единое информационное пространство. Какой из двух видов учета первичен?

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

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

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

Как решается задача интеграции бухгалтерского и управленческого учета в РЖД?

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

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

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

Легко ли было выстраивать коммуникации между различными службами внутри проекта?

Быстрее всего нашли общий язык с экономистами, поскольку именно они – одна из сторон, кровно заинтересованных в достижении результата. С производственным блоком было тяжелее, но к производственникам у нас никаких претензий нет: бизнес – и не только в РЖД, но и вообще в стране – исторически так складывался, что производство и экономическая отчетность были отдельными, слабо связанными процессами. Если подойти к работнику производственного участка и спросить, как его деятельность отражается в отчетности, он вряд ли сможет ответить, да и не должен. При этом мы понимали, что производство и другие основные виды деятельности, конечно, являются основой компании, а отчетность – это лишь зеркало, которое должно правильно отражать особенности бизнеса.

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

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

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

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

Какие способы мотивации вы использовали, чтобы заинтересовать сотрудников бухгалтерии?

В РЖД, как и во многих других компаниях, действует стандартный механизм: есть базовый оклад, и есть премиальная часть, которая варьируется в зависимости от того, насколько эффективно выполняются дополнительные обязанности. Весь методологический проект был разделен на несколько подпроектов, по каждому из которых были определены ответственные сотрудники. Анализируя результаты работы, мы принимали решение о премировании того или иного сотрудника бухгалтерии. Размер премии зависел от соблюдения сроков, качества работы и т.д. Отдельные сотрудники получали грамоты и благодарности от руководства, причем в РЖД этот вид премирования не является простой формальностью – все подобные поощрения заносятся в трудовое дело и влияют на карьерные перемещения.

Как пользователи из других отделов оценивают результаты проекта?

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

Александр Зубанов

Позицию ИТ-департамента озвучил Максим Белоусов, управляющий директор «КИТ Финанс Инвестиционный банк». Взгляд финансового директора представил Михаил Подлазов, заместитель генерального директора по экономике и финансам компании «Нидан». Видение ERP-проекта с позиций главного бухгалтера изложил Борис Аксенов, заместитель начальника департамента бухгалтерского учета РЖД. Сегодня мы предлагаем аудитории нашего портала ознакомиться с этими выступлениями.

Максим Белоусов: «ИТ-директор – это лишь часть большого бизнес-оркестра»

Несмотря на том, что сейчас я занимаю должность управляющего директора банка, практически вся моя профессиональная карьера была так или иначе связана с ИТ-сферой: внедрение систем, ИТ-консультирование, информационная поддержка бизнеса и т.д. ИТ-служба в «КИТ Финанс Инвестиционный банк» также подчинена мне.

Постараюсь взглянуть на роль ИТ-директора изнутри, обратив внимание на «белую» и «черную» сторону этой специализации. Как ИТ-директор с пятнадцатилетним стажем я считаю, что информационная служба – обязательное подразделение в любой компании, поскольку без ИТ-поддержки бизнесу достаточно сложно развиваться. Однако, как управленец я также знаю, что можно работать с бумагой и ручкой, обходясь до какого-то момента без высоких технологий. Поэтому первый вопрос, который мне хотелось бы задать и себе и вам, коллеги: кого мы обманываем и обманываем ли? Можно ли прожить без ИТ-директоров и без технологий? Вряд ли. У каждого из нас на рабочем месте есть персональный компьютер, мы не представляем свою деловую жизнь без интернет-коммуникаций и сотового телефона. Поэтому мой «внутренний» ИТ-директор говорит: я нужен бизнесу, без меня компания не сможет обойтись. Именно я помогаю сотрудникам компании использовать необходимые им технологии. С другой стороны, мы, айтишники, зачастую видим себя кем-то, кем мы никогда не будем, и присваиваем себе роли, которые на самом деле нам не принадлежат.

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

Нередко айтишники считают себя бизнес-аналитиками. Да, моя «черная» сторона тоже так считает. Мне довелось работать в разных отраслях, от госсектора до нефтяной промышленности, и я многое знаю о бизнесе из собственного опыта. И если сейчас кто-то из вас задаст мне вопрос по одной из неизвестных мне бизнес-специализаций, то уже через пять минут я смогу начать автоматизацию с полным пониманием вашего бизнеса. Так считает моя «черная» сторона. Моя «белая» сторона говорит совершенно другое. Никакой я не бизнес-аналитик, потому что я не анализирую business value – ценность для бизнеса, которую может получить компания, внедрив то или иное решение. Да, когда я пишу технико-экономическое обоснование для проекта, я думаю, что я анализирую бизнес, но на самом деле это не так. Ведь я не показываю бизнесу, какое количество денег в расчете на одну акцию он получит. Мне неизвестно, удастся ли с помощью ИТ-решения извлечь дополнительную прибыль, изменить продуктовую линейку или повлиять на политику регионального расширения. Поэтому я не бизнес-аналитик. Я скорее системный аналитик: будучи математиком, вооруженным двумя высшими образованиями, хорошо поставленным системным мышлением и калькулятором, я могу быстро произвести необходимые расчеты. При условии, что мне предоставят исходные данные для этих расчетов.

Иногда нам кажется, что мы – источник компетенций. Моя «черная» сторона радуется тому, что и бизнес иногда считает так же. Мне нередко доводилось слышать: ты и сам все знаешь, так что напиши постановку задачи, техническое задание, какие-то требования, а потом сам все это автоматизируй. Это грубейшая ошибка, которую допускают многие собственники. По крайней мере, допускали в 90-е годы. Сейчас так происходит крайне редко: собственники и топ-менеджмент понимают, что постановка задачи должна исходить от них, поскольку именно они являются источником ключевых компетенций. ИТ-директор – только отраслевой консультант, который знает, какие решения для той или иной задачи компании существуют на рынке, и может помочь с выбором оптимального решения. Здесь уместно вспомнить один из принципов IBM: машина считает, человек думает. Я никогда не смогу внедрить систему, которая будет думать за топ-менеджеров или их подчиненных, принимать за них решения.

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

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

Михаил Подлазов: «Мы часто забываем об операционных подразделениях, а соблюдение их интересов очень важно для бизнеса»

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

Расскажу о своем опыте внедрения ERP-систем. Мне доводилось внедрять в различных компаниях системы самых разных разработчиков: Scala, SAP, Axapta и 1С. Однако по своему опыту могу сказать, что ключевой принцип, который должен соблюдаться при внедрении любой системы, заключается в том, что идти надо всегда от цели. Мы внедряем систему не для того, чтобы кто-то повесил себе медаль, а для того, чтобы бизнесу было проще решать стоящие перед ним задачи. Успех проекта всегда зависит от того, насколько четко сформулированы эти задачи. Иными словами, потребность в установке ERP-системы должна быть осознанной. В этом случае не возникает проблем с мотивацией участников проекта – они знают, для чего им нужна система. Как следствие, участникам проектной команды не обязательно выплачивать какие-то дополнительные бонусы за то, что они занимаются внедрением системы. Ведь они делают это для себя.

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

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

Борис Аксёнов: «При внедрении ERP-системы нельзя отделять задачи бухгалтерского учета от задач управленческого учета»

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

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

В РЖД сейчас осуществляется два комплекса проектов в области учета. Первый комплекс – это организация учета по российским стандартам, второй – организация составления МСФО-отчетности. Это именно комплексы, поскольку используются различные системы, однако в качестве основного корпоративного решения выбран SAP. Еще одна сложность определяется характером бизнеса РЖД. Порой у меня возникает ощущение, что все двадцать два ПБУ созданы именно для нашей компании, поскольку в РЖД представлены практически все возможные учетные ситуации и виды хозяйственных операций, предусмотренные в ПБУ.

Что касается моей роли в проекте, то я считаю, что от бухгалтерии и от главного бухгалтера вообще в первую очередь требуется четкое понимание тех задач, которые необходимо реализовать в системе. А интеграторы, включая собственную ИТ-команду компании, не должны ждать, когда к ним обратятся за помощью: одного выполнения функций help desk мало. От интегратора требуется активная позиция — он должен предлагать наиболее оптимальные решения, а не только реализовывать алгоритмы, предложенные заказчиком. В противном случае полученная система окажется неэффективной, и придется вносить в нее множество изменений.

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

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

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

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

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