Игорь Ковалев: «Если пользователь непосредственно участвует во внедрении ERP-решения, создается система, которая удобна именно пользователю»

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

Расскажите, как складывалась ИТ-инфраструктура 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-проектов, ограниченных рамками одного отдела: во внедрении всегда участвует ИТ-отдел, финансы, бухгалтерия, производство и т.д. Необходимо не только сообщить, что с такого-то числа мы переходим на новую систему. Важно объяснить, чем эта система будет лучше для каждого отдела, почему она нужна представителям разных департаментов. В конце концов любая система создается не для ИТ-службы, а для бизнеса.

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

---

Материалы по теме: