Отдам ERP в добрые руки
АрхивПредположим, что мы — группа разработчиков, решившая запустить проект корпоративного ПО с открытым кодом. Квалификации хватает: один из нас — управленец со стажем и обладатель степени MBA, двое много лет участвовали во внедрении проприетарных ERP-систем, двое других разрабатывали такие системы под заказ. Еще несколько опытных программистов согласны поработать волонтерами. Кадры есть. Что делать?
Предположим, что мы — группа разработчиков, решившая запустить проект корпоративного ПО с открытым кодом. Квалификации хватает: один из нас — управленец со стажем и обладатель степени MBA, двое много лет участвовали во внедрении проприетарных ERP-систем, двое других разрабатывали такие системы под заказ. Еще несколько опытных программистов согласны поработать волонтерами. Кадры есть. Что делать?
Вначале мы должны понять, кто будет пользоваться нашим продуктом. Кому интересны свободные ОС, веб-серверы, текстовые и графические редакторы, известно. Но кто заинтересован в корпоративных open source-продуктах — системах для управленческого учета, поддержки решений, оптимизации информационных потоков предприятия? Казалось бы, и здесь ответ очевиден: предприниматели, стремящиеся сэкономить на автоматизации или получить нечто уникальное, чего нет в продуктах проприетарных. Но не все так просто. Попробуем разогнать идеологический туман и выделить главные преимущества open source — только тогда мы поймем, как его можно продавать.
Нужные вещи
На первый взгляд корпоративные open source-продукты по функциональности не так уж сильно отстают от аналогичных проприетарных решений. Вот, к примеру, функциональные блоки одной из самых раскрученных свободных ERP-систем Compiere (взяты из описания на официальном сайте): выставление счетов, отношения с клиентами и заказы, отношения с поставщиками, дистрибуция, склад и закупки, управление кассовым оборудованием, обработка запросов на обслуживание, управление затратами и платежами, бухгалтерия, аналитические отчеты, поддержка корпоративного портала.
Однако open source-разработки в этом секторе все-таки не дотягивают до лидеров рынка. Во-первых, в большинстве случаев часть функций пока что в стадии реализации, а сейчас программа предлагает автоматизацию лишь основных управленческих процессов. Во-вторых, даже когда разработчики претендуют на то, что продукт покрывает до 90% функциональности лучших проприетарных систем[См., к примеру, www.ohioedge.com/kb/oesales/docs/product_benefit.pdf], за кадром остаются вовсе не мелочи, а множество тонких настроек и возможностей. Конечно, открытые корпоративные продукты выполнены на открытой же платформе, и всю эту подстройку и детализацию провести можно, но каждый раз это нужно делать заново.
С другой стороны, все эти тонкие подстройки и крупицы управленческого ноу-хау нужны только крупным корпорациям, готовым за них платить и их осваивать. Средний и малый бизнес неплохо обходятся и типовыми возможностями, а у мелких компаний потребности в настройке вообще минимальны.
Теперь мы понимаем, что средние и малые фирмы и есть наша целевая группа. Именно они способны оценить наше, как кажется, основное преимущество — возможность снизить затраты на автоматизацию. Значит, во-первых, продукт не должен быть слишком сложным: наш клиент не потянет долгого внедрения и донастройки. Во-вторых, наша система не сможет делать все. Не будем замахиваться на логистику, управление персоналом, управление производством и прочие проблемы крупных компаний, а сосредоточимся на том, чтобы в деталях описать бизнес-процессы небольшого предприятия[Не исключено, что по мере роста проекта им заинтересуются какой-нибудь Wal-san или Nismart (хорошие названия? специально для охотников за скрытой рекламой. — Л.Л.-М.). Но с самого начала делать полновесную ERP-систему для крупных корпораций — большая ошибка].
А чем мы лучше?
Проприетарных решений для SMB[Small and Medium Business. — Л.Л.-М]-сектора достаточно, причем многие из них отлажены, сопровождаются качественной техподдержкой, регулярно адаптируются и локализуются. Чем тогда клиенту приглянется наше решение? Тем, что мы — из лагеря open source. Тем, что наша система по умолчанию прогрессивнее и надежнее. Открытая платформа и возможности для расширения — разве не здорово? Здорово, но недостаточно. Заказчики слетаются стаями лишь на уникальные продукты, и тут мы натыкаемся на другое препятствие.
Сектор корпоративных продуктов в технологическом смысле довольно консервативен. Разумеется, и здесь случаются технические инновации, но обычно они носят глобальный характер: появилась, к примеру, идея интеграции на основе веб-сервисов, и вот каждый второй объявляет эти сервисы главным конкурентным преимуществом своего решения[Из свободных систем интересна, в частности, OhioEdge CRM — чисто серверная разработка, не предполагающая вообще никакого клиентского ПО]. Основные ноу-хау и идеи кроются не в коде, а в управленческих схемах, которые стоят за информационной системой, — но теория управления не обновляется дважды в день. Перестройка продуктов происходит, однако революции бывают редко. Короче говоря, шансы предложить нечто новое в смысле практики менеджмента у нас невелики.
Возможности эксплуатировать сильный брэнд у нас — за неимением оного — тоже нет, а значит, остается два варианта: уходить в отраслевую специализацию или предлагать услуги, ориентированные на национальный рынок. Именно в этом — наше спасение. Теперь мы можем бить конкурентов сразу на двух фронтах: во-первых, наш продукт уникален сам по себе, а во-вторых, мы предлагаем его еще и на уникальных условиях, по открытой лицензии со всеми вытекающими.
Подведем итог. Наши клиенты — не гиганты мирового уровня, и запланированная нами ERP нового поколения им, вероятно, и не нужна. Адаптируем ее «для самых маленьких», оставив основное — интеграцию всех процессов, или нацелимся на отдельное функциональное решение — CRM-систему, модуль управления заказами или закупками, call-центр. Если наш выбор — специализация, почему бы не сделать CRM-комплекс для рекрутинговых компаний? Интегрированную систему для турагентств? Главное — не перестараться, попав на такой отраслевой рынок, где и проприетарным решениям тесно. Как использовать национальную специфику? Легко: предлагаем первую в России open source-систему для автоматизации бухучета.
Наше решение построено на веб-технологиях и на единой программной платформе, позволяет легко подключать дополнительные модули и расширения, без труда сопрягается с существующими проприетарными решениями. Мы много и красиво говорим о том, что лицензия на систему клиентам ничего не стоит[Хотя не факт, что это снижает стоимость проекта в целом. Подробнее см. статью Михаила Елашкина на соседних страницах]. Более того, они могут просто скачать систему с сайта, самостоятельно установить и настроить, регулярно заглядывая к нам за апдейтами.
Деловые люди
На самом-то деле мы вовсе не заинтересованы в том, чтобы они так делали. Если мы решили вместо благородной раскрутки свободного софта делать бизнес, то нужно найти точки, в которых клиенту без нас не обойтись и в которых он будет расставаться со своими деньгами. Наша ставка — на бесплатное распространение, а деньги зарабатывать будем другим путем (хотя и коробками приторговывать не погнушаемся).
Первая точка соприкосновения — внедрение. Нам выгодно, чтобы как можно больше клиентов установили систему и взахлеб рассказывали окружающим, как она хороша. Однако нам крайне невыгодно, если клиент внедряет решение как придется, что приводит к ошибкам и сбоям: кроме дурной репутации, мы так ничего и не получим. Таким образом, клиенты должны знать, что в большинстве случаев оптимально настроить систему можем только мы, и это ноу-хау мы оставляем за собой. Для желающих мы сможем обеспечить и системную интеграцию — сопряжение нашего продукта с уже установленными в компании программными средствами.
Второй пункт — техническая поддержка, и это, пожалуй, главный источник дохода для «опенсорсных» проектов. Решений, которые, будучи однажды внедренными, потом всю свою жизнь работали бы как часы, не бывает. Любая система нуждается в обновлениях, дополнениях, исправлениях. Однако в идеале поставщик должен не реагировать на фактические претензии и запросы клиентов, а предугадывать их и выполнять еще до того, как они были высказаны. В этом смысле свободное ПО имеет очевидные преимущества: так как код открыт, к развитию системы можно привлечь пользователей и независимых разработчиков, ускорив поступление апдейтов и заплаток. Исправлять индивидуальные недоработки и давать консультации будет наша основная группа.
Третий пункт — расширение системы по запросам клиента (feature request). Это один из обильных источников дохода при внедрении проприетарных продуктов, и он вполне может сработать на свободном софте. Схема может быть развернута и иначе: лицензия на базовую комплектацию продукта — свободная, самостоятельные доработки и их распространение разрешены, но созданные нами (в том числе по индивидуальным заказам) дополнительные модули поставляются за плату. Мы не откажемся и от заказов на портирование приложений на другие платформы.
Четвертая группа услуг — обучение и консалтинг. Наша система — не запредельной сложности, но освоить ее самостоятельно под силу не каждому, особенно если (что характерно для мелких бизнесов) предприятие не имеет опыта работы с управленческими системами. Здесь же — консультации по подбору и модернизации оборудования, управленческий консалтинг, исследования по вопросам автоматизации управления.
Наконец, есть и другие способы заработка — предустановка системы на новые компьютеры, продажа сопутствующих товаров и т. д.[Подробный обзор этих и некоторых других моделей см.: www.libertarium.ru/libertarium/121515. Советы по выбору бизнес-модели также приведены в книге: Chris DiBona, Sam Ockman, Mark Stone. Open Sources: Voices from the Open Source Revolution. O’Reilly, 1999 (пробный бесплатный доступ к тексту есть на safari.oreilly.com). Однако ни в том, ни в другом источнике речь не идет о специфике корпоративного софта] Все перечисленные выше сервисы с успехом применяются при внедрении проприетарного софта. Однако в open source-проектах эти услуги могут быть обыграны с пользой для обеих сторон контракта. Самое главное — можно вкладывать больше усилий во внедрение и сопровождение, не опасаясь завысить общую стоимость проекта; лицензия-то бесплатна.
Кто в семье главный
Как добиться, чтобы все это заработало? Мы не будем делать ставку на классическое сообщество разработчиков «базарного» типа. С одной стороны, нам нужна группа специалистов, способных в сжатые сроки выполнять технические задания для клиентов — внедрения, заказы на доработку, портирование, написание дополнительных модулей и т. д. Эта группа может работать только вместе и только под единым руководством. С другой стороны, полноценное сообщество на базе разработки корпоративного ПО возникнуть и не может. Что заставит клиента дорабатывать свою систему и передавать наработки в открытое пользование? Что побудит профессионала, работающего где-нибудь в PeopleSoft или SAP, в обеденный перерыв строчить в ноутбуке код открытой CRM-системы? Не спорю с тем, что и такие энтузиасты найдутся[К примеру, датская компания Pharma Nord разработала для себя модуль обработки кредитных карт, подключаемый к Compiere, а потом передала его разработчикам системы], но основную работу на них переложить не удастся.
Поэтому в бизнес-модели для корпоративного open source центральное место отводится компании-разработчику. Она может заниматься внедрением и техподдержкой как самостоятельно, так и передавая их сертифицированным партнерам, однако всегда отвечает за базовый цикл разработки. Да, порой привлекаются и сторонние разработчики, члены сообщества, но обычно в узких областях: для оперативного исправления технических проколов или внедрения отдельных полезных функций[Исследование, проведенное двумя итальянскими экономистами, показало, что многие фирмы, работающие на рынке open source, стремятся привлечь к работе сторонних программистов, опираясь на свои декларации об активном развитии свободного софта вообще. См.: Cristina Rossi, Andrea Bonaccorsi. Intrinsic motivations and profit-oriented firms in Open Source software. Do firms practice what they preach? (www.opensource.mit.edu/papers/rossi_motivations.pdf )]. Чаще всего их участие выгодно основному разработчику на ранних этапах проекта, когда нужно накопить критическую массу кода и наработок по архитектуре ПО.
Любая сколько-нибудь известная ERP-система с открытым кодом поддерживается неким вендором, который занимается как минимум маркетингом и продажами, а зачастую и координирует разработку, обеспечивает внедрение, доработку, расширение, техподдержку системы[Michael Ryman. Open Source ERP-systems: An investigating study on open source development in ERP-systems (www.informatik.gu.se/~jonas/osfs-vt2004/Open_Source_ERP_systems.doc)].
Свободный корпоративный софт может создаваться вообще без обращения к сообществу, так как это само по себе дает фирме-разработчику ряд преимуществ. К примеру, можно свободно использовать наработки других групп программистов, созданные под открытой лицензией, и не волноваться по поводу их юридического сопряжения со своим ноу-хау. Открытая архитектура проекта позволяет минимизировать издержки интеграции с решениями других поставщиков.
В конце концов, нередки случаи, когда выбор в пользу свободной лицензии оказывается неожиданным для самой компании и происходит, когда ядро проекта уже готово. Так случилось с уже упомянутыми Fisterra и Compiere. Первая из них разрабатывалась для авторемонтной фирмы Auto Arte, а затем по обоюдному согласию была выпущена под лицензией GPL(www.igalia.com/en/casos_de_exito/grupo_autoarte_development_on_fisterra). Compiere ориентировалась на разработку проприетарной системы, но потом подсчитала, что не вытянет полный цикл продаж и дистрибуции, и перешла на open source-вариант(www.adaxa.com.au/downloads/More%20to%20Open%20Source%20than%20Linux.pdf).
Исходя из всего этого и решается вопрос с лицензированием. Есть два пути обеспечить контроль центра разработки над всем процессом создания софта: технический и юридический. В первом случае продукт выпускается под одной из стандартных лицензий, но скачать его можно только с сайта разработчика — иначе софт не признаётся аутентичным. Во втором случае необходимость сертификации изменений главными разработчиками оговаривается в самой лицензии (так называемый gated source); всем участникам разработки дается право свободно изменять продукт, но потребители таких версий должны знать, что их системы не сертифицированы основной фирмой. Поскольку сообществ по разработке корпоративного ПО в open source-среде практически нет, авторы ныне существующих систем склоняются к первому варианту.
Национальная специфика
Теперь осталось оценить наши шансы на успех в том случае, если мы будем следовать избранному пути. В корпоративном секторе пиратство не разрушает конкурентоспособность открытого софта, поскольку пиратить дорогие проприетарные продукты здесь бессмысленно. Поэтому перспективы свободного корпоративного ПО в России в принципе не отличаются от его перспектив на Западе — разве что мы, как всегда, отстаем.
В то же время, делая свободный софт для автоматизации управления, мы в большинстве случаев ограничиваем себя отечественным потребителем, поскольку проводить внедрения за границей и обеспечивать там техподдержку вряд ли сможем. А у нас модель open source в чистом виде может и не сработать(См., в частности, интервью с Александром Давыдовым в этом номере).
Мы могли бы извлекать из open source гораздо больше выгод, если бы у отечественных компаний появился выбор в этой области. Однако свободных корпоративных систем на нашем рынке почти нет, а зарубежный продукт нужно локализовать и адаптировать, чем пока практически никто не занимается. Причины осторожности понятны, и в их числе — банальное недоверие отечественного потребителя к программам со свободной лицензией, а также идеологическое доминирование поставщиков проприетарного ПО. Но никто ведь и не говорил, что будет легко.
