Open Source на рынке ERP

Интерес к программным продуктам с открытым исходным кодом (Open Source) велик сегодня, как никогда ранее. Однако если применение системного ПО такого рода (ОС, СУБД, Web-серверов приложений) приняло довольно широкие масштабы и набирает обороты, то в области бизнес-приложений и, в частности, ERP-систем картина пока не столь радужная. В чем причина?

Думается, прежде всего в том, что концепция Open Source воспринимается многими чересчур упрощенно: я бесплатно получу программу вместе с исходным кодом и смогу без каких-либо ограничений модифицировать ее в соответствии со своими потребностями, к тому же огромное сообщество программистов-энтузиастов всегда поможет мне быстро исправить и усовершенствовать приложение. Некоторые заказчики, внедрившие у себя ERP-системы с открытым кодом, полагают, что тем самым они страхуются от последствий поглощения одного вендора другим и последующей “медленной смерти” (прекращения полноценного развития и техподдержки) честно купленного ими приложения. Разумеется, бесплатность Open Source — понятие довольно условное. Правильнее говорить о совокупной стоимости владения, а она включает оплату не только лицензий (некоторые продукты Open Source вовсе не бесплатны), но и технической поддержки, консалтинга, настройки приложения и его внедрения. А эти расходы в случае ERP-системобычно в несколько раз превышают стоимость лицензий.

За рубежом есть целый ряд компаний, предлагающих свои ERP-системы по лицензионной модели Open Source (см. PC Week/RE, № 30/2006). Среди них — Compiere, OpenMFG, Open For Business Project, Tiny ERP, OpenPro. Продукт Compiere с нынешнего года начала продвигать на российском рынке компания “АйТи”. Пять лет назад выйти на отечественный рынок с собственным ERP-решением Open Source попыталась российская фирма NAUMEN. Ее продукт NauRP был написан на языке высокого уровня Python, базировался на объектной СУБД ZoDB и сервере приложений Zope, также распространявшихся по лицензии Open Source, и функционировал на платформах Linux или Windows.

Эксперимент оказался неудачным. Вот как объясняет причины этого генеральный директор компании NAUMEN Александр Давыдов: “Попытка выхода на рынок в 2003 г. показала, что система в таком виде ему не интересна. Ключевой фактор успеха ERP-системы — возможность использования ее консультантами, а не программистами. Поэтому она должна быть “конструктором”, снабженным средствами программирования на DSL-языке (Domain Specifiс Language), который понятен и доступен для консультантов. Насколько хорош будет DSL, настолько удачной будет ERP-система с открытым кодом. Особенно заманчиво сделать DSL в виде надстройки над такими динамическими языками, как Python или Ruby. Коды на динамическом языке плохо “закрываются”, поэтому такой подход не пригоден для продуктов с проприетарными лицензиями, но очень даже годится для ERP с лицензиями Open Source. Он более конкурентоспособен, так как открыт для расширения и развития и к тому же позволил бы внедренческим компаниям создавать собственные “диалекты” языков DSL для разных отраслей. К сожалению, сегодня мне не известна ни одна такая реализация DSL. Кроме того, в 2003 г. мысль о том, что за поддержку следует платить, была в нашей стране совсем не популярна, зарплаты были еще не такие высокие, как сейчас, а программисты не столь дефицитны. Так что идея зарабатывать на поддержке сырой ERP-системы тогда себя не оправдала. Мы прекратили ее развитие и стали создавать на этой основе полноценные специализированные проприетарные продукты”.

Итак, для успеха ERP-системы с открытым исходным кодом в равной степени важны и ее востребованность со стороны заказчиков, и наличие достаточно мощного сообщества программистов, желающих ее поддерживать. Ведь в теории предполагается, что если производитель ПО с открытым исходным кодом по каким-либо причинам прекратит свою деятельность — например, если у него кончатся деньги, если его купит другая компания или если у него возникнут проблемы с менеджментом, — то сообщество разработчиков продолжит поддержку продукта. В то же время вендор далеко не всегда готов дать такому сообществу полную свободу действий. Так, клиенты и партнеры OpenMFG получают исходный код и приглашаются к обсуждению путей его развития и совершенствования, но вносить изменения в ПО может только сама компания. Да и компания Compiere, заключившая партнерское соглашение с “АйТи”, не позволяет вносить изменения в свой продукт всем без разбора.

Лицензия на продукт Compiere бесплатна, причем редакцию Community Edition (она имеет ограниченную функциональность) разрешается скачивать и использовать всем. Две другие — Standard Edition и Professional Edition — распространяются только через партнеров и требуют покупки ежегодной технической поддержки, под которой имеется в виду регулярное получение обновлений и исправлений.

“Редакцию Community разрешается модифицировать под свою ответственность кому угодно, а вот самую мощную — Professional — клиентам дорабатывать не позволяется: для них ее исходный код фактически закрыт, — рассказывает руководитель центра внедрений бизнес-приложений компании “АйТи” Алексей Сорокин. — Это может делать только сертифицированный партнер. Тем не менее и он сначала передает свою доработку в Compiere на тестирование, и только потом она возвращается либо в составе очередного релиза системы, либо в виде патча. Авторские права на такие доработки сохраняются за самой Compiere”.

Несколько иная ситуация с так называемыми модулями add-on, к числу которых относится локализация, включающая поддержку местного законодательства (в частности, по бухучету). В России ее осуществляет “АйТи”. “Авторскими правами на них обладает создавший эти add-on партнер, которому разрешается продавать и сами такие модули, и их техническую поддержку, — продолжает Алексей Сорокин. — Впрочем, в отличие от базовой версии продукта модуль add-on клиенты могут покупать и без технической поддержки: этой возможностью смогут воспользоваться те заказчики, которые захотят вносить настройки, отражающие изменения в российском законодательстве, самостоятельно на свой страх и риск. Фактически продажи расширений add-on осуществляет Compiere, а “АйТи” как разработчик локализованных модулей получает лицензионные отчисления. До конца 2009 г. в России будет действовать только один партнер Compiere — компания “АйТи”. Впоследствии, если продвижением этой ERP-системы захотят заняться другие российские консалтинговые фирмы, они смогут осуществлять техническую поддержку тех предприятий, которые купят локализованную специалистами “АйТи” российскую версию Compiere. Более того, таких локализованных модулей по российскому бухучету может быть несколько от разных разработчиков, но все они должны быть сертифицированы вендором. А выбор того или иного решения остается за заказчиком”.

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

“Ценовая политика для России в настоящее время только формируется, но с учетом обещанных со стороны Compiere преференций цена поддержки будет весьма конкурентоспособной по сравнению с аналогичными услугами по продуктам SAP Business One и “1С: Управление производственным предприятием, — поясняет Алексей Сорокин. — Кроме того, и услуги по развертыванию у нас будут не очень дорогими, поскольку мы намерены применять методологию дистанционного внедрения (через специальный Web-интерфейс), которая хорошо отработана в Compiere”.

Совершенно очевидно, что одним из самых важных факторов успеха того или иного ERP-продукта с открытым кодом является наличие его широкой поддержки со стороны сообщества разработчиков и клиентов, оказывающих непосредственное влияние на развитие продукта. Следует признать, что формированию такого сообщества далеко не всегда способствует политика вендора, мотивы которого тоже можно понять. “Участвовать в сообществе, поддерживающем развитие продукта, могут любые партнеры и клиенты Compiere, — говорит Алексей Сорокин. — Им разрешается отправлять вендору запросы на изменения, а для редакций Standard и Professional даже самим писать программный код. Если он нужен только заказчику, то никаких ограничений по его использованию нет. Если же тот хочет, чтобы его работа нашла отражение в базовых версиях ERP-системы, она должны быть передана на тестирование вендору. Подобный подход позволяет Compiere нести ответственность за базовую версию программы”.

Нельзя забывать о том, что формированием подобных сообществ или экосистем в последнее время очень активно занимаются и лидеры мирового рынка ERP, предлагающие проприетарное ПО. Успех решений Open Source во многом будет зависеть от того, сумеют ли их экосистемы стать более массовыми и активными, чем те, которые выстраиваются традиционными вендорами. В этом контексте эксклюзивный партнерский статус, предоставленный в нашей стране компании “АйТи”, возможно, и дает ей некие конкурентные преимущества, но поскольку он одновременно ограничивает возможности развития экосистемы Compiere, суммарный результат действия этих разнонаправленных факторов вполне может оказаться и негативным. Кроме того, перспективы в противостоянии двух-трех экосистем гигантов рынка ERP и десятка сообществ, формируемых вокруг мелких вендоров, выглядят для последних не очень радужно. Вполне вероятно, что единственная возможность для ERP-решения с открытым кодом противостоять на мировом рынке традиционным продуктам — это консолидация сообщества разработчиков вокруг одного проекта Open Source. Пример Linux в этом смысле как нельзя более красноречив.