Победившая команда: опыт автоматизации в «Группе E4»

Александр Зубанов, Леонид Мальцев - 26.08.2010

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

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

Ярким примером сложного и многогранного проекта, потребовавшего от участников (пользователей, консультантов, разработчиков) полной отдачи и нестандартных действий, может служить автоматизация учета в «Группе Е4» – вертикально-интегрированном холдинге со штатом в 20 000 человек, предлагающем современные инжиниринговые решения для тепловой и атомной энергетики, металлургии, химической и нефтегазовой отраслей, ЖКХ и госсектора.

Рискованный старт

«Группа E4» объединяет несколько бизнес-направлений, представленных множеством предприятий со сложными схемами внутригруппового взаимодействия, расположенных во всех регионах России и за рубежом. Подобный корпоративный ландшафт уже не сулит легкой автоматизации, однако масштаб Компании – далеко не основной фактор, предопределивший сложность проекта.

Особенность внедрения состояла в том, что оно стартовало в 2007 году, когда активы Е4, недавно выделившиеся из состава РАО «ЕЭС России», еще находились на стадии формирования организационной структуры холдинга. Создание единых стандартов учета, адаптация и внедрение корпоративной учетной системы - эти задачи предстояло решать параллельно с формированием организационной структуры группы. Дополнительную трудность составляло и то, что для ключевых финансистов «Группы E4» – финансового директора и главного бухгалтера управляющей Компании – это был первый опыт ведения совместных проектов, а значит, подходы заказчика к командной работе, как и сама команда, создавались в ходе автоматизации.

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

В качестве программной платформы было выбрано решение «1С:Управление производственным предприятием 8», а партнерами выступил консорциум «HLB ПАКК-Аудит» и «Деснол Софт Проджект». Консультанты «HLB ПАКК-Аудит» отвечали за концепцию учета в системе и за создание единой методологической базы, специалисты «Деснол Софт» взяли на себя реализацию разработанной методологии на уровне ИТ-решения. Надо еще упомянуть, что ранее подрядчики не сотрудничали друг с другом на проектах подобного масштаба.

Для чего понадобилась именно такая структура проекта, объясняет Максим Шмаков, заместитель генерального директора «Группы Е4» по экономике и финансам: «Проект был сознательно разделен на две составляющие: разработку методологической части и реализацию на платформе 1С. Мы несколько раз проводили конкурс по выбору подрядчиков, и быстро поняли, что Компании, которая сможет одинаково качественно выполнить и то, и другое, нам не найти».

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

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

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

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

Баланс ожиданий: три переломных момента

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

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

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

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

«Когда мы договаривались о том, что будут работать две Компании, - поясняет Максим Шмаков, - мы подписывали контракт с одной – вторая шла как член консорциума. И юридическая ответственность продолжала лежать на контрактодержателе, Компании HLB ПАКК-Аудит, даже когда они передали разработанную методологию в «Деснол Софт». Это позволило снизить возможный уровень конфликтности в проекте».

Далее мы остановимся подробнее на каждом из трех моментов, когда судьба проекта оказывалась под угрозой.

Рождение концепции: кот в мешке

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

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

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

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

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

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

Работаем параллельно

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

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

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

Лишь к ноябрю 2007 года проектная группа перестала существовать в режиме закрытой лаборатории и представила первые результаты своей деятельности широкому кругу будущих пользователей системы. Всех бухгалтеров «Группы Е4» пригласили на семинар, где Надежда Горчукова представила методологию своим подчиненным. Это был ключевой момент, поскольку главный бухгалтер ясно обозначила свою позицию, обнародовав правила, по которым предстояло работать всем учетным подразделениям холдинга. Что очень важно, методологическая база была представлена именно как результат совместной работы главного бухгалтера и специалистов Компании-консультанта.

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

Работа над ошибками: бюро приема жалоб

Когда улеглись страсти по методологии, пришло время пилотного внедрения. В качестве площадки был выбран «Е4-Центрэнергомонтаж» (ЦЭМ), крупнейший актив группы, холдинг внутри холдинга: в составе этого предприятия находилось 14 филиалов, не объединенных единым учетным решением. Хотя все филиалы использовали различные продукты 1С, эти локальные системы не были интегрированы друг с другом, и технология взаимодействия была в основном «бумажной». Заказчик ставил задачу перейти от этого достаточно рыхлого ИТ-ландшафта к единой корпоративной учетной системе при соблюдении жесткой централизации. Необходимо было добиться, чтобы все предприятия, входящие в Е4, подчинялись строгим правилам учета, соответствующим целям управляющей Компании.

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

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

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

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

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

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

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

Проблему удалось решить, организовав централизованный help desk. Эти функции взяли на себя консультанты и разработчики. В «Деснол Софт» создали подсистему сбора и сортировки ошибок, оперативного реагирования на запросы пользователей. Был составлен регламент обращений пользователей, процедура обработки замечаний, заведена отдельная база данных для регистрации и устранения ошибок. Помимо технических мер реагирования были предприняты и организационные: «Деснол Софт» выделил четырех кураторов, каждый из которых отвечал за устранение ошибок в 3-4 филиалах ЦЭМа. Когда подсистема help desk заработала, приходило до 100 обращений в неделю. Случались и курьезы: у одного из бухгалтеров вызвало беспокойство сообщение на дисплее «обновление системы прошло успешно». Однако в большинстве случаев вопросы были серьезными и требовали квалифицированной помощи. По необходимости кураторы подключали к поиску решений технических специалистов «Деснол Софт» или – в тех случаях, когда причины ошибок лежали в методической плоскости, – обращались за помощью в «HLB ПАКК-Аудит». Это позволило устранить технические и методологические недоработки, допущенные в ходе проекта, а главное – выявить наиболее типичные ошибки пользователей и создать инструкции, позволяющие избегать стереотипных неверных действий.

Роман Пилькин раскрывает некоторые подробности: «На этапе опытной эксплуатации обычно всплывают все ошибки, которые были допущены во время разработки концепции, проектирования системы и ее адаптации. Причем в реальности все выглядит еще хуже, чем на словах. Поскольку ошибок возникает множество, и устранить их все за день-два невозможно, приходится с ними работать внимательно и системно. Здесь важно ранжировать возникающие проблемы и обеспечивать не только техническую поддержку, но и методологическое сопровождение. Большинство вопросов нам удавалось снимать ссылками на стандарты учета, иногда приходилось взаимодействовать не только с пользователями, но и с аудиторами дочерних предприятий “Группы Е4”».

«Побочный» эффект проекта

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

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

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

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

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

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

Исходя из перечисленных соображений финансистами «Группы Е4» было принято разумное решение: по завершении болезненного этапа опытной эксплуатации дать возможность ведения менее значительных справочников специалистам на местах.

В одной лодке

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

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

Говорит Вадим Финогенов: «Допускаю, что некий идеальный проект возможен, но для этого должно совпасть множество условий, что на деле случается редко. Конечно, комфортнее работать, если у заказчика и подрядчиков есть за плечами успешный опыт нескольких совместных внедрений. Бесспорно, было бы легче, если бы мы пришли в группу Компаний со сложившейся командой управленцев, которые уже сработались друг с другом. Гладко проходил бы проект в холдинге с устоявшейся методологией учета, с обкатанными политиками и стандартами. Но «Группа Е4» – тот случай, когда всего этого не было, и все же команде проекта удалось добиться успеха. Это делает приобретенный опыт бесценным – многие задачи, которые мы раньше считали бы сложными, теперь воспринимаем как стандартные».

Каков же главный урок проекта?

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

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

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

При публикации материала ссылка на http://consulting.1c.ru обязательна

Мы помогаем бизнесу
быть эффективным!