«Сибирский химический комбинат» является одним из крупнейших предприятий атомной промышленности со штатом более 15 тыс. человек. Уникальный комплекс производств, включающий восемь заводов, ТЭЦ, научно-исследовательский институт, ряд вспомогательных подразделений, не имеет аналогов в мировой практике. В 2004-2007 годах на комбинате выполнены основные работы в рамках масштабного проекта поэтапного внедрения ERP-системы. О проекте рассказал Владимир Клевцов, начальник управления информационных технологий и связи «Сибирского химического комбината».
-Проект внедрения ERP-системы на «Сибирском химическом комбинате» изначально планировался как длительный, состоящий из последовательности шагов, каждый из которых, фактически, представлял собой завершенный подпроект автоматизации какого-то участка. Как, в таком случае, удалось изначально очертить рамки общего проекта – сроки, бюджет, трудозатраты, оценить получаемые на выходе результаты? Насколько цели автоматизации, заложенные изначально, отличались от фактически достигнутых через три с лишним года?
Владимир Клевцов: Как и перед любым длительным ERP-проектом, перед началом внедрения «Системы Alfa» было проведено предварительное обследование. В результате были выделены ключевые проблемы и создана укрупненная схема эксплуатации (эскизный проект), в которой, в том числе, были даны оценки по срокам, бюджету и другим аналогичным вопросам. Там описывалось разбиение всего проекта на участки работ, были сформулированы цели и задачи по каждому участку, ключевые взаимосвязи всех участков между собой и с информационной инфраструктурой «СХК». Кроме того, по каждому участку в рамках технического задания был определен круг работ, включавший методическую проработку, собственно внедрение и настройку системы, обучение пользователей и т.д.
Это позволило динамически управлять ходом работ по каждому участку, контролировать результаты на соответствие задачам, обозначенным в рамках укрупненной схемы. Такой подход позволил достичь всех основных целей проекта (как по проекту в целом, так и по каждому участку в отдельности).
-Рационально ли, по Вашему мнению, после выбора платформы для автоматизации, запускать сначала «пилотный» проект, который подтвердил бы правильность выбора и ERP-системы, и исполнителя проекта? Будет ли такой «пробный шар» полезен, чтобы иметь возможность вовремя вернуться на исходные позиции, или же после принятия решения «мосты сожжены» и затраты на дополнительные проверки нецелесообразны?
Владимир Клевцов: Идея с «пилотным» проектом очень хороша. Однако, для проведения полноценного «пилотного» проекта необходим либо отдельный замкнутый функционал, который можно (и нужно) автоматизировать независимо от всего остального, либо отдельная балансовая единица предприятия, на которой можно внедрить полнофункциональное решение «в миниатюре». В условиях «СХК», по состоянию на начало проекта, ни того ни другого не было. Поэтому мы пошли по пути тщательного выбора технологической платформы и поставщика с точки зрения опыта, репутации и технологии. Компания «Информконтакт» отвечала всем предъявляемым требованиям, имела опыт внедрения на предприятиях аналогичных нашему, в том числе предприятиях «Росатома». А открытая архитектура выбранной системы позволила решить наши задачи наиболее приемлемым способом.
-Значительная часть проекта (по времени, по стоимости и по затраченным усилиям) на «СХК» была потрачена на методическую проработку и перестройку бизнес-процессов и принципов учета. С одной стороны это можно сделать строго по методу «сверху вниз», последовательно спускаясь от глобальных принципов учета к более и более детальной проработке отдельных участков и процессов. С другой стороны, можно отталкиваться от того, что сейчас наиболее реально оптимизировать, а что лучше оставить как есть, и как потом это все можно между собой увязать. Первый путь - более длительный и затратный, но более «правильный», а второй – более быстрый и экономичный (по крайней мере, на первый взгляд), и требует меньших «встрясок».
Что Вам кажется более целесообразным для предприятия, которое работает уже давно и обладает своими особенностями и наработками? Не станет ли первый путь «нескончаемым»? Не приведет ли второй путь к «расползанию» системы на отдельные, слабо связанные между собой блоки, не дающие общей картины?
Владимир Клевцов: На предприятиях, подобных нашему, возможно использовать как первый путь, так и второй: все зависит от сложности перестройки и от ее экономической целесообразности (ведь не секрет, что «методически правильное» решение не всегда экономически оправдано). В нашем случае мы, с одной стороны, четко знали, чего хотим, и к этому целенаправленно шли по всем участкам работ. В этом мы ближе к стратегии первого пути.
В то же время, чтобы избежать серьезных встрясок, мы применяли технологию последовательного внедрения по участкам. И в этом мы ближе к тактике второго пути. Таким образом, мы взяли то лучшее, что есть в обоих подходах, и минимизировали присущие им недостатки, а выбранная система позволяла это сделать.
-Когда новая методология уже продумана и принята, какие усилия требуются от руководства предприятия и от участников проектной команды, чтобы «донести» все эти рекомендации до конечных пользователей (экономистов, бухгалтеров, технологов, учетчиков, бригадиров и т.п.)?
Владимир Клевцов: От руководства, прежде всего, требуется решимость завершить проект, достичь поставленных целей. От участников проектной команды требуется самоотверженность (работать приходится гораздо больше обычных 8-ми часов в день) и умение находить контакт с предметными специалистами.
Что касается «донесения» методологии, то здесь проблем почти не возникало, так как в ее выработке и согласовании участвовали все профильные руководители и ключевые специалисты. Если и возникали какие-то вопросы, то они, в основном, решались на уровне руководителей соответствующих подразделений.
-Какие методы Вы считаете наиболее действенными и необходимыми, чтобы реализация не «забуксовала»: дополнительное обучение персонала, составление подробной пользовательской документации, длительный период опытной эксплуатации, дополнительное материальное стимулирование сотрудников или что-то еще?
Владимир Клевцов: Наиболее действенные меры, позволяющие добиться нужного уровня качества при внедрении, – это четкое проведение опытной эксплуатации (иногда довольно длительное, чтобы устранить все выявленные проблемы, адаптировать пользователей к новой системе), максимальное исключение двойного ввода информации и материальное стимулирование исполнителей, ориентированное на достижение конечного результата. Дополнительное обучение персонала и разработка подробной пользовательской документации являются неотъемлемой частью любого подобного проекта, но оказывают меньшее влияние на результат.
-В ходе последовательно реализуемого проекта возможно возникновение ситуаций, когда на очередном этапе обнаруживаются какие-то недоработки, допущенные ранее, или меняется ситуация, или взгляд на проблему. И тогда приходится либо возвращаться назад и переделывать уже запущенные в эксплуатацию участки, либо идти на компромисс и приспосабливаться к тому, что уже есть. Удалось ли комбинату избежать таких ситуаций? Что для этого необходимо? И как выходить из положения, если избежать таких «мин замедленного действия» все же не удалось?
Владимир Клевцов: Такие ситуации возможны при любой методике реализации проекта, только при единовременном запуске все проблемы всплывают одновременно, и тогда очень часто приходится «приспосабливаться к тому, что есть». В нашем же случае, мы имели возможность выявить и по возможности устранить «подводные камни» во время работ по каждому участку. А благодаря изначальной общей проработке внедряемого функционала и его связей была возможность «не потерять за деревьями лес».
Другой вопрос, что рано или поздно в любой настроенной системе приходится что-либо менять: изменяется законодательство, да и бизнес-процессы на предприятии время от времени могут меняться. Поэтому, для нас было важно выбрать такую систему и так ее внедрить, чтобы внесение изменений (как в ходе реализации проекта, так и после его окончания) не превращалось бы в новый полномасштабный проект.
Приведу пример: еще в ходе проекта, осенью 2005 года были опубликованы изменения в законодательстве, существенно изменявшие порядок учета НДС. И до 1 января 2006 была перенастроена практически готовая к эксплуатации система.
-Целесообразно ли на таких масштабных проектах привлекать субподрядчиков, сторонних консультантов? Или же, чтобы не дробить ответственность и обеспечить единообразие подходов, лучше выбирать исполнителя проекта с таким расчетом, чтобы он мог «закрыть» все участки только силами своих специалистов?
Владимир Клевцов: Для меня важен единый центр ответственности – человек, с которого можно спросить за все. А уж какая у него конфигурация выполнения работ – с субподрядчиками или без – для меня, по большому счету, не важно. Правда, с одной оговоркой: если при этом нет возражений со стороны нашей службы безопасности.
-Какова в проекте роль собственных ИТ-специалистов заказчика? Выросла ли или сократилась в результате ERP-проекта численность ИТ-отдела на комбинате? Почему так произошло и считаете ли Вы сейчас, что это правильно?
Владимир Клевцов: Каждый участник ERP-проекта должен заниматься тем делом, в котором он наиболее компетентен. Если консультанты компании-подрядчика являются специалистами по внедряемому продукту и технологии внедрения, то ИТ-специалисты заказчика являются экспертами в существующей ИТ-инфраструктуре и работающем на предприятии информационном обеспечении. Таким образом, практически сразу наши специалисты начали активно участвовать в написании конверторов из старых ИС, быстро подключились к уже более специфичным задачам: разработке отчетов и несложной настройке. Естественно, что с ходом проекта свои специалисты начинают лучше разбираться в новой системе, перенимают опыт у консультантов и к завершению проекта уже могут большую часть работ проводить самостоятельно, что показал и пример нашего проекта (один из участков в конце проекта сделан полностью самостоятельно специалистами «СХК»).
Однако специалисты выросли не только технически, изменился и характер работы. Если раньше, когда все ИТ-задачи разрабатывались собственными силами, это были квалифицированные программисты, то после внедрения это уже специалисты по развитию КИС широкого профиля, ориентирующиеся в предметной области и поддерживающие тесный контакт с пользователями. К сожалению, не всем нашим инженерам-программистам удалось перестроиться и команда, при сохранении общей численности, частично обновилась. Но я уверен, что это правильно.
-Целесообразно ли обучать собственных ИТ-специалистов , чтобы они могли наравне с компанией-интегратором участвовать в настройке и внедрении ERP-системы, а по окончании проекта – полностью взять на себя ее сопровождение? Или же на ИТ-подразделение заказчика лучше возложить совсем другие функции – единого центра администрирования и технической поддержки?
Владимир Клевцов: Обучать своих ИТ-специалистов однозначно целесообразно. Во-первых, это позволяет сократить затраты на внедрение. Во-вторых, даже если мы не собираемся полностью брать на себя сопровождение внедренной системы, мы хотим быть квалифицированным заказчиком, говорящим на одном языке с подрядчиком и четко разбирающимся в том, что у нас делается.
Прежде всего ИТ-подразделение заказчика является единым центром администрирования и поддержки пользователей. При этом очень квалифицированным центром, хорошо ориентирующимся в ERP-системе и в схеме ее эксплуатации на предприятии. Хочу отметить, что в ходе проекта внедрения ERP-системы мы как раз выстроили свою работу в этом направлении, используя стандарты ITIL. А техническую поддержку (в смысле обновления версий и обработки проблем в программном обеспечении) лучше оставить поставщику КИС.
-Что может стать тем «цементом», который свяжет автоматизацию отдельных блоков крупного предприятия в сложный, но единый ERP-проект?
Владимир Клевцов: Подходить к внедрению КИС на «СХК» как к автоматизации отдельных блоков – неверно. Мы изначально создавали единую систему, но внедряли ее поэтапно, не «большим взрывом». Поэтапный подход позволил нам на каждом участке максимально полно проработать функционал, учесть все требования, необходимые для достижения общих целей проекта.
А единым «цементом» при автоматизации, несомненно, является общее информационное пространство, общая технологическая платформа, подразумевающая набор единых сервисов для всех функциональных составляющих системы, единая логическая модель данных и процессов и единая информационно-справочная система.
http://www.tadviser.ru 
