СПО и импортозамещение: тернистый путь к независимости
Экономический кризис и сложная политическая ситуация заставляют российские компании искать альтернативу многим вещам с Запада, ставшим уже привычными за многие годы. Это относится и к программному обеспечению. Для одних заказчиков использование американских и европейских программных продуктов стало невозможным по причине санкционных ограничений, для других на первое место вышел ценовой фактор. Как бы то ни было, российским компаниям приходится искать альтернативные решения. Таковыми могут стать как разработки российских софтверных компаний, так и свободное программное обеспечение (СПО) с открытым исходным кодом, которое разрабатывается при участии мирового сообщества и распространяется без ограничений во всех странах. Насколько выгодным может быть использование СПО в российских компаниях? Какие подводные камни могут встретиться на этом пути? Об этом мы беседуем с директором по информационным технологиям компании Mango Office Дмитрием Метлиным.
Сейчас государством активно декларируется политика импортозамещения в ИТ. Насколько это в целом нужно и важно для компаний, не попавших под санкции?
Если есть факты, что компании в России уже испытывают неприятности, связанные с зарубежным ПО, то этот риск нужно учитывать. Любое нововведение должно быть обоснованно. Как правило, это можно выразить в деньгах. Если в деньгах выигрыша нет – должно быть, например, снижение рисков. Неважно, что будет больше, а что меньше – затраты на ПО или на команду. В итоге должно получиться дешевле или лучше. При оценке возможности замещения зарубежного оборудования или ПО отечественным руководителю каждой компании стоит объективно оценивать выгоды и риски и принимать решение по совокупности факторов. Среди возможных бизнес-выгод от перехода на российское ПО я могу назвать снижение стоимости владения ПО и затрат при масштабировании бизнеса, снижение финансовых рисков и уменьшение зависимости расходов от курса валюты и ценовой политики зарубежных вендоров. Например, в нашей компании мы реализовали проект по переносу базы данных с платформы зарубежного вендора на платформу открытого ПО PostgreSQL. Мы это сделали, чтобы, кроме финансовых выгод, обеспечить полный контроль за развитием ИТ-инфраструктуры Mango Office, сокращение сроков решения технических проблем без привязки ко времени отклика технической поддержки производителя софта.
Какое место СПО может занимать в качестве альтернативы западным проприетарным аналогам?
В нашем случае заменяет один в один. Отличие, которое сразу приходит на ум, заключается в отсутствии поддержки. Но давайте разберемся. Ни для кого не секрет, что крупные зарубежные вендоры в обновлениях своих продуктов ориентируются прежде всего на компании списка топ-100. Но существуют же и менее крупные компании, для которых свои проблемы гораздо важнее. Единственное, что они могут сделать при возникновении сложностей в работе или поддержке ПО, это обратиться к форуму пользователей данного вендора, который, к слову, тоже коммерческий. Возможно, там найдется решение. Или можно ждать, пока проблема не превратится в массовую или не затронет интересы крупных компаний. Открытое ПО, на первый взгляд, поддерживается лишь внутренними ИТ-специалистами, никакой поддержки извне просто нет. Но существует сообщество разработчиков и опытных пользователей данного ПО, куда всегда можно обратиться за решением своей проблемы. С большой вероятностью все варианты решения типовых задач вы легко там найдете. Если потребуется решение уникальных задач, с которыми не справились специалисты внутри вашей компании, можно прибегнуть к помощи интеграторов. Подобные компании сегодня работают не только с коммерческим, но и открытым ПО. Таким образом, можно сказать, что с поддержкой полный паритет, каким бы это ни показалось парадоксальным на первый взгляд.
Сегодня довольно много российских системных интеграторов на волне импортозамещения взялись за разработку собственных решений, чаще всего как раз на базе СПО. Как вы оцениваете этот подход? Смогут ли такие продукты стать реальной альтернативой дорогостоящим коммерческим программным продуктам западных разработчиков?
Действительно, интерес к теме альтернативного ПО стимулирует появление на российском рынке интеграторов, которые занимаются внедрением и поддержкой открытого ПО. Но в настоящее время разработка решений по большей части, к сожалению, ограничивается локализацией. Однако это долгий и тернистый путь. На мой взгляд, показателем появления на рынке действительно серьезного, системного подхода к интеграции в области СПО будет компания, которая возьмется за масштабный проект замены ПО в государственных учреждениях. Это задача как раз такого уровня, который продемонстрирует возможности, накопленный опыт, квалификацию российских системных интеграторов. Пока, как я уже сказал, интеграция очень узкоспециализированная. Тем не менее какое-то развитие в этой области не может не радовать.
Как на предприятии построить стратегию по миграции на СПО? Какие факторы необходимо принять во внимание?
Необходимо учитывать следующие факторы: а) экономический эффект от внедрения, б) уже вложенные средства в текущее ПО и обучение сотрудников, в) возможность найти команду для реализации данного проекта. Причем я рекомендовал бы оценивать эти факторы одновременно. В нашем случае экономическая выгода перевесила – Mango Office сэкономит в ближайшие четыре года пять миллионов долларов благодаря переходу на открытое ПО. В этом процессе следует руководствоваться принципом «от простого к сложному». Можно начать с перевода какой-нибудь одной информационной системы на открытое ПО. Например, если есть сопряженная деятельность отделов, необязательно ставить «1С», чтобы передать бумажку на соседний стол. Можно попробовать открытое серверное веб-приложение для управления проектами и задачами – скажем, Redmine. Это будет некой затравкой. Если интеграция пройдет хорошо, то можно продолжать двигаться в сторону других информационных систем. Принцип «от простого к сложному» позволит руководителю проанализировать, как в его компании будет приживаться открытое ПО, потому что иногда отторжение может возникнуть сразу в тех процессах и на тех уровнях, где даже не предполагали. Что касается поиска и развития персонала, то, пожалуй, для внедрения открытого ПО это самый проблемный и важный вопрос. Остальные вопросы лежат в инженерной плоскости – это анализ системы, сравнение различных решений, документация и прочее.
С какими рисками сопряжен переход на свободное ПО? Как этих рисков избежать или их минимизировать?
Повторюсь, что наиболее вероятный риск – поиск специалистов. Первое, что нужно оценить: сможете ли вы привлечь кадры для внедрения и поддержки свободного ПО? Сегодня на рынке в этой области действительно почти нет стоящих кадров, а те, что есть, могут банально оказаться дорогими для вашей компании. Увлеченных людей в принципе меньше. Они думают так: «Я инженер, я смогу решить проблему. Более того, я хочу решить проблему самостоятельно, а не сдать ее в поддержку вендора». Именно настроенные таким образом люди создают костяк специалистов, работающих со свободным ПО. Помните, в школе всегда находились те, кто брался и решал задачи со звездочкой. Пусть даже на это уходило больше времени и сил. Но таких людей действительно немного, что значительно осложняет поиск. Если уже на этапе планирования проекта вы не знаете, какая команда будет его реализовывать, то стоит затормозить проект и заняться поиском специалистов. Эта задача должна стать первостепенной, так как процесс поиска может сильно затянуться или не увенчаться успехом вообще. Другой риск заключается в людях, которые будут пользоваться открытым ПО. Каждый руководитель должен оценить свою команду. Важно то, как она отнесется к такому стрессу, потому что во многом такие решения более «угловатые». Для ИТ-специалистов зачастую это не проблема. Это люди определенного склада ума и характера. Любые сложности, связанные с поиском решения, перекрываются позитивом от его нахождения и ощущением, что ты полностью контролируешь ИТ-инфраструктуру. И не возникнет, например, внезапных фоновых обновлений системы. У сотрудников же, не связанных с ИТ, подобные решения в первое время могут вызвать отторжение.
А почему?
Свободное ПО не всегда бывает очень дружелюбным. Сам принцип, по которому оно создается, состоит в коллективном труде заинтересованных лиц, направленном на решение конкретных проблем, результаты которого потом публикуются и наслаиваются друг на друга. Оно изначально зарождалось не как продукт, а как инструмент, который может быть использован множеством людей, улучшен с учетом их проблем и возвращен в сообщество. Коммерческие же продукты нацелены в первую очередь на потребительские свойства, в том числе на восприятие пользователями, удобство использования и т. д. Все это уже включено в цену продукта. Поэтому на фоне коммерческого ПО у пользователей может возникнуть контраст. В нашей компании с СПО работают как раз ИТ-специалисты. А если это будут конечные пользователи, то желательно, чтобы кто-то из ИТ-отдела занимался внедрением и адаптацией ПО под ваши нужды. Еще один риск состоит в том, что даже квалифицированные кадры могут столкнуться с проблемой, решения которой они не знают. Очевидно, что у СПО круг пользователей пока более узок, чем у коммерческого. Могут возникнуть частные проблемы, и тут дело только за сплоченным закаленным составом команды. Так, уже во время реализации проекта по переносу базы данных на СПО мы столкнулись с рядом сложностей.
Например, результаты синтетического тестирования производительности оказались отличными от показателей, полученных во время реальной работы. Поэтому для эксплуатации потребовалось дополнить СПО PostgreSQL открытыми компонентами, которые пришлось адаптировать к нашему прикладному ПО. От руководителя требуется обеспечить постоянное развитие команды вместе с развитием ПО – обучение, участие в профильных конференциях, выступления на отраслевых мероприятиях, приглашение экспертов для обмена опытом и т. д. Наконец, нельзя не отметить риск, связанный с существованием в компании отлаженного механизма внесения изменений. В принципе обратная связь и отработка ошибок важны в случае как с открытым ПО, так и с коммерческим. Например, у нас в компании есть несколько сред для тестирования до того, как изменение попадает к конечным пользователям: среда разработчиков, тестовая, копия боевой, опытно-эксплуатационная и боевая. Этот процесс должен быть четко отлажен. Если что-то пошло не так, должна быть мгновенная обратная связь и работа над ошибками. Но, безусловно, есть плюс. Если в случае с коммерческим ПО руководитель и клиенты с большой вероятностью услышат от ИТ-специалистов «мы позвонили в поддержку вендора, ждем», то в случае с открытым ПО специалисты засучат рукава и попытаются устранить проблему своими силами.
В этой статье я поделюсь практическими наработками из опыта своей компании по организации эффективной коммуникации при создании ПО на заказ.
Опубликовано 15.10.2015