За последние полтора года компания GMCS выполнила множество интересных проектов, потеснив некоторых из своих более известных коллег-конкурентов. А недавняя сделка Infor - SSA Global привлекла особое внимание к партнерам этих вендоров в нашей стране. Так как GMCS является официальным центром локализации, внедрения и поддержки системы SSA ERPLN (Baan 6.1) для России, СНГ и стран Балтии, нам было интересно мнение ее президента Сергея Сульгина о перспективах этой ERP-системы и видении общей ситуации с внедрением систем данного класса.

Родился в 1973 году. Закончил Московский государственный университет имени М. В. Ломоносова в 1995-м. Свою карьеру в отрасли ИТ начал в компании Platinum Russia, где с 1995 по 1997 годы работал в должности ведущего консультанта, руководителя проекта и наконец директора департамента Platinum SQL. В сентябре 1997-го перешел в Baan Russia на должность директора по локализации и разработкам. С января 1999-го стал директором по развитию GMCS. В 2003 году возглавил руководство этой компании. В настоящий момент является ее президентом.

Intelligent Enterprise: Как меняется отношение собственников и топ-менеджеров компаний к ERP-системам в последнее время?

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

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

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

Но в реальности внедрение ERP-систем в большинстве случаев не приводит к созданию единого пространства, о полномасштабных внедрений в России практически не известно.

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

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

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

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

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

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

Известно, что SSA ERP (Baan) -- одна из оптимальных ERP-систем для производственных компаний. Какова ситуация с ее распространением в России, можно ли ожидать, что скоро она станет значительно популярнее?

Пока рано говорить о том, что ERP-ландшафт в России может существенно и быстро измениться в пользу SSA ERP (Baan). Все же нужно учитывать соотношение сил на мировом рынке. Теперь, после покупки SSA Global компанией Infor, ситуация будет постепенно меняться: возник третий после SAP и Oracle cильный ERP-вендор. Изменения коснутся и России, вопрос только в том, когда именно они станут заметны. Между тем стратегия GMCS по развитию и сопровождению SSA ERP (Baan) остается неизменной -- у нас заключены с клиентами многолетние контракты на поддержку и развитие этого решения.

Безусловно, если бы вендор был представлен на российском рынке, то интерес к этой ERP был бы более массовым, что и наблюдалось, когда SSA Global (в то время еще Baan Russia) имела свое представительство в стране. Ведь заказчики судят о серьезности намерений поставщика по тому, какие вложения он делает в свой российский бизнес.

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

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

Это связано с тем, что вендоры не занимаются разработкой решений для отдельной страны. Их задача - глобальная поддержка и развитие систем. Поэтому реальная ответственность за результаты конкретного проекта лежит на компании-интеграторе. А "головная боль" заказчика всегда ложится на самого заказчика и на тех, кто с ним непосредственно работает. От того, какого партнера выберет заказчик и с кем он сможет лечить эту "головую боль", напрямую зависят и успех, и сроки внедрения. Поэтому заказчику необходимо выбирать надежного партнера и конкретную команду, которая будет с ним работать. Мы, например, всю проектную команду согласовываем с заказчиком, каждого сотрудника представляем лично.

К составу проектных команд интеграторов клиенты предъявляют много претензий. Например, по поводу того, что подрядчик не в состоянии управлять такой командой…

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

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

Может быть, они просто связаны с неумением грамотно управлять проектами?

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

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

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

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

Один из примеров хорошей организации управления проектом -- холдинг "СИБУР", с которым мы сейчас активно сотрудничаем. Там с точки зрения управления проектами очень профессионально все поставлено. Прописаны механизмы взаимоотношения заказчика и подрядчика, а для контроля качества работ нанята отдельная компания. Если возникает проблема, то хотя бы понятно, по какой лестнице идти, чтобы решить ее, не нужно бегать по всем кабинетам в поисках человека, который тебя поддержит. Регламентация отношений играет очень большую роль во время работы над проектом.

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

В отраслевых решениях не просто описаны некоторые характерные для конкретной отрасли процессы. В них есть дополнительная функциональность в виде специальных модулей или расширения модулей продукта. Скажем, в нашем решении для телекоммуникационных компаний на базе Microsoft Dynamics AX (бывшая Microsoft Axapta) учтена масса тонкостей, которые очень важны для компаний -- операторов связи. Причем такое решение - это самостоятельный программный продукт, живущий собственной жизнью. Он функционирует на промышленной платформе. У нас, например, есть целый спектр решений на базе Microsoft Dynamics AX, и это именно продукт, а не заказная разработка. По мере выхода версий и патчей основной платформы соответствующие изменения попадают и в отраслевое решение. Конечно, такие продукты всегда "выращиваются на клиенте", учитывают его потребности, но имея несколько таких клиентов, мы можем постоянно проводить апгрейды: наработки и улучшения, выполненные для одного из них, включаются в стандартную поставку и попадают к другим.

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

А как же конкурентные преимущества, ноу-хау отдельных клиентов? Вы же не можете сделать их достоянием всех других клиентов в этой же отрасли?

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

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

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

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

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

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

В чем еще особенности подхода вашей компании?

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