Эволюционный подход к внедрению ERP-системы

Дмитрий Висков Родился в 1959 году, окончил МВТУ им. Н.Э. Баумана, кандидат технических наук. До 1991 года работал в НИИ "ЦЕНТР" и "ИнтерЭВМ", вел научную и производственную работу в сфере разработки и внедрения автоматизированных технологических и управленческих комплексов. С 1991-го по 1998 год занимался предпринимательской деятельность в сфере организации производства и сбыта пищевых продуктов, а также управленческой деятельностью в сфере финансов и страхового дела. Закончил институт повышения квалификации Финансовой академии при Правительстве РФ по специальности "Банковское и страховое дело". С 1998 года работал в МПС России на должности заместителя руководителя департамента финансов, руководил отраслевым проектом создания Единой Корпоративной Автоматизированной Системы Управления Финансами и Ресурсами (ЕК АСУФР) российских железных дорог. С 2003 года занимает должность заместителя Главного бухгалтера ОАО "РЖД", заместителя начальника Департамента бухгалтерского и налогового учета.

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

Дмитрий Висков: Да, именно тогда руководством было принято решение о старте проекта и был объявлен конкурс на выбор платформы. В основном предполагался выбор между двумя вендорами - Oracle и SAP, имевшими решения, соизмеримые по масштабу и ценовым показателям.

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

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

Решение Oracle, на мой взгляд, не обладало необходимой функциональной полнотой. Для всестороннего анализа и обоснования выбора мы привлекли консультантов из PricewaterhouseCoopers. Они сформировали систему критериев и предложили нам оценить степень важности каждого из них с помощью коэффициентов, а затем на основании этих данных провели оценку. Важно заметить, что такой подход действительно позволил получить комплексную и довольно точную оценку требуемой функциональности ERP-системы. Например, в своих критериях мы поставили максимальный коэффициент важности функциональности Центра фирменного транспортного обслуживания - структурного подразделения МПС по работе с клиентами в части грузовых перевозок. Однако с учетом специфики железнодорожного транспорта для таких функций система R/3 в то время была не самым лучшим решением. Тем не менее в итоге, с учетом оценок задач в финансах, управленческом учете затрат, в управлении материально-техническими ресурсами, решение SAP оказалось предпочтительнее, как набравшее большее количество баллов.

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

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

Самый большой проект R/3 в фактах Охват - департаменты центрального аппарата, управленческие службы территориальных и функциональных филиалов, более 2 тыс. предприятий, более 12 тыс. обособленных подразделений, более 25 тыс. пользователей. Инфраструктура - более 70 серверов Sun Microsystems, более 30 дисковых массивов EMC, более 20 ленточных библиотек StorageTek, установленных в ГВЦ и на 17 ИВЦ железных дорог, а также отраслевая сеть передачи данных Подготовка персонала - отраслевая система подготовки профессиональных кадров по системе R/3, в рамках которой прошли обучение более 500 специалистов проектных и внедренческих групп, а также более 7 тыс. пользователей Функциональность - на данный момент времени в системе реализовано управление финансами и материальными ресурсами, управление затратами, бухгалтерский учет, учет доходных поступлений, платежный баланс, сводная налоговая отчетность, сводная бухгалтерская отчетность, управление персоналом, нормативно-справочная информация. Планируемое развитие функциональности - оперативное бюджетное управление в разрезе видов бюджетов, управление инвестициями, управление имуществом, паспортизация оборудования, планирование и контроль ремонтных работ, интеграция с производственными системами, аналитическая отчетность.

Как выбирали партнера по внедрению и каким образом формировалась проектная команда?

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

На момент начала нашего проекта формирование внутренней проектной команды вызывало большие трудности. Ведь классический путь, рекомендуемый SAP, таков - взять лучших специалистов из функциональных подразделений, прекрасно знающих предметную область, обучить их системе, а потом из них сформировать костяк проектной команды. Однако у нас возможности пойти по такому пути не было. Несмотря на то что проект запускался приказом Министра путей сообщения, первоначально статус у проекта был невысокий. Речь шла не об отраслевом проекте, а только о первых шагах - пилотном проекте и выборе проектного решения. Подобных по объему проектов у МПС были десятки. Вопрос привлечения из структурных подразделений лучших специалистов и включения их в проектную команду даже не ставился. Кроме того, в МПС не было специалистов по R/3. По большому счету, с учетом фактора времени, формировать собственную проектную команду просто было не из кого. А надо было начинать проект, надо было показывать реальные результаты! В этом случае в то время единственно правильным решением было использование внешней команды внедрения.

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

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

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

С другой стороны, были компании, знавшие отрасль, реализовавшие несколько крупных отраслевых проектов, но не имеющиеимеющие экспертизы и специалистов по R/3. Последнее меня не пугало. Главным для меня было ответственное отношение людей к делу, способность предлагать нестандартные решения, учитывающие специфику отрасли, готовность взять на себя часть рисков и разделить ответственность за результат. Сначала в проекте были задействованы две компании -- "ТехноСерв А/C" и "Микротест" - на паритетных началах. Они выделили свои проектные команды, предложили свою корпоративную культуру и стиль работы, поставили во главе процессов своих ведущих менеджеров. Однако постепенно, в силу различных причин, команда "ТехноСерв А/C" стала принимать на себя все большую и большую нагрузку по проекту. В итоге сегодня в проекте активно работает лишь команда "ТехноСерв А/C".

Инфраструктуру внедрения мы строили по двухуровневой схеме: был создан "Отраслевой центр разработки и внедрения" (ОЦРВ) и семнадцать "Дорожных центров внедрения" (ДЦВ) - на каждой железной дороге. К обоснованию этой структуры я еще вернусь, а сейчас хочу сказать о том, как шел набор сотрудников. Это очень важный вопрос, потому что, на мой взгляд, успех ERP-проекта во многом базируется на личных качествах каждого члена проектной команды.

Специалистов для ОЦРВ искали в основном на рынке, рассматривая кандидатов "поштучно", принимая во внимание не только профессиональные качества, но и опыт, умение работать в коллективе, отношение к работе. У нас были случаи, когда люди работали трое суток подряд, не уходя домой. Это никаким контрактом не описывается и деньгами не измеряется!

ДЦВ создавались как структурные подразделения при Управлениях железных дорог на базе ИВЦ и комплектовались в основном за счет специалистов дорожных служб. Здесь нам удалось успешно решить одну большую проблему. Дело в том, что этих специалистов необходимо было обучить инструментарию SAP. Если идти стандартным путем - направлять сотрудников в учебный центр SAP, - то при наших масштабах это выливалось в весьма значительные суммы, выходившие за рамки бюджета проекта. И здесь очень помогла конструктивная позиция компании SAP, которая пошла нам навстречу и помогла в организации курсов по R/3 в нашем учебном центре при ГВЦ. Это позволило нам создать полномасштабную систему подготовки профессионалов по системе R/3, причем за вполне приемлемые деньги.

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

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

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

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

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

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

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

Но такой подход к внедрению ведет к большому количеству переделок…

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

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

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

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

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

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

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

Но при эволюционном подходе существенно возрастают риски… При каких условиях с таким подходом можно добиться успеха?

Конечно, такое внедрение тяжелее, дольше и дороже. А это требует известного кредита доверия от руководства и финансовой устойчивости компании.

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

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

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

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

Давайте теперь перейдем к архитектуре решения. Эволюционный подход к проекту и здесь потребовал специальных решений?

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

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

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

Каким образом организована модель централизованной разработки? Естественно инфраструктура внедрения ERP-системы на дорогах получилась двухуровневая: центральный отдел (ОЦРВ) и 17 центров на дорогах (ДЦВ). На центральном уровне силами консультантов ОЦРВ разрабатывается версия системы и тиражируется на каждую из 17 железных дорог. От разработчиков ДЦВ, пользователей и специалистов дорожных служб в реальном времени поступает информация об обнаруженных ошибках, замечаниях, претензиях, запросах на изменения. Эта информация практически сразу анализируется и обрабатывается специалистами центра, выполняется доработка системы, тестируется. Затем обновления уходят на дороги, где тестируются и устанавливаются в систему. Конечно, не все требования заказчиков реализуются в системе. Ведь на каждое изменение настроек мы имеем иногда 17 различных мнений, часто противоречивых. Решение о том, какое же из них правильное, принимают специалисты по методологии, разработчики системы и, в конечном счете, функциональный заказчик системы.

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

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

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

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

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

Не совсем так. Так или иначе, пилотные проекты велись на нескольких дорогах. Первой пилотной зоной выступила Красноярская железная дорога. Дело в том, что решение о внедрении SAP R/3 на Красноярской дороге было принято еще до старта общеотраслевого проекта. Кстати, оно велось по стандартной методике с привлечением консультантов московского офиса SAP.

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

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

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

Давайте теперь поговорим об итогах и эффекте от внедрения системы.

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

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

Ведь, по большому счету, для меня ERP-система, в частности SAP R/3, ценна тем, что она является своеобразной "копилкой" корпоративного управленческого опыта. Здесь уместна такая аналогия - для любого общества очень важно, чтобы опыт предыдущих поколений не пропадал, а сохранялся, систематизировался и наследовался. И для информационной системы главное то же самое - сохранение наработанных данных, алгоритмов, бизнес-процессов. Именно на это делает упор эволюционный подход. Ведь на российских предприятиях нет большой и успешной истории в области организации бизнес-процессов. Чаще встречаются неполно документированные бизнес-процессы, которые иногда больше ориентированы на предпочтения руководителя, чем на рекомендации best-practice. Внедренная ERP-система на предприятии становится реальным рабочим инструментом накопления опыта в области корпоративного управления. Более того, ERP-система на предприятии позволяет трансформировать корпоративный менталитет - пусть не сразу, пусть небольшими шажками, приблизить его к современным стандартам бизнеса.

Алексей Асафьев, директор сектора транспорта SAP СНГ и Страны Балтии Проект внедрения SAP в «РЖД» действительно является одним из крупнейших, по крайней мере в регионе Центральной и Восточной Европы. Следует заметить, что проблемы, с которыми столкнулось ОАО «РЖД» в этом проекте, в определенной степени типичны для всех внедрений интегрированных информационно-управляющих систем на крупных предприятиях. Причем не только у нас в стране, но и за рубежом. Наша методика ASAP, изначально положенная в основу всех проектов в ОАО «РЖД» и предусматривающая как одномоментное, так и пошаговое внедрение, позволяет успешно преодолевать эти проблемы. В настоящее время проект SAP в ОАО «РЖД» успешно развивается. К управлению финансами уже добавилось управление материально-техническим снабжением, интенсивно развивается проект по управлению трудовыми ресурсами (кстати, один из крупнейших в мире), начинается внедрение и другой функциональности.