В кризисное время много говорят о снижении затрат, в том числе на покупку и поддержку клиентского ПО. И один из способов снизить затраты по данной статье — переход на свободное ПО (СПО). По данным IDC, 15% всего эксплуатируемого в мире ПО является бесплатным или свободным, причем это число не включает собственные и заказные разработки, а также предварительные версии. Однако успешные проекты, связанные с более-менее масштабным переходом к использованию таких систем в корпоративном сегменте, пока единичны, хотя их число растет.

Казалось бы, ничего не должно мешать триумфальному продвижению СПО на настольные системы. Те же Linux, OpenOffice.org, GIMP, Blender стали хорошо знакомыми и узнаваемыми брендами. Эти продукты уже давно нельзя рассматривать в качестве дешевого эрзаца, который применяется лишь от полной безысходности. А то, что говорят об их сложности в обращении, — просто из области предрассудков. Однако процесс не идет, и одну только инерцию тут винить нельзя, все намного глубже и сложнее.

Объяснение в том, что проблема перехода на СПО сложна и многогранна. Здесь много всяческого рода препятствий, которые условно можно разделить на технологические, экономические и человеческие. О препятствиях мы и поговорим.

Технологические проблемы

Начнем с самых простых — технологических проблем. К ним мы отнесем те сложности, которые носят объективный характер и связаны или с невозможностью работы СПО на имеющемся оборудовании, или с отсутствием полноценных аналогов ключевых приложений. Ни для кого не секрет, что современные дистрибутивы Linux, хоть они и менее требовательны к оборудованию, чем последние версии ОС от Microsoft, тоже не будут работать на чем попало. Это признают и разработчики дистрибутивов, указывая, в частности, на то, что для комфортной работы в актуальной версии графического рабочего стола GNOME необходимо иметь минимум 512 Мбайт оперативной памяти, а лучше больше. Столько же нужно иметь для полноценной работы с OpenOffice.org. И в кризис это, естественно, не будет способствовать быстрому продвижению проекта.

Сюда же стоит отнести и раздробленность лагеря СПО. Известно, что только дистрибутивов Linux существует более 500, и выбрать нужный — это уже может быть проблемой. А еще процедура выбора графического рабочего стола, браузера, набора офисных приложений, которых минимум четыре, почтового клиента и много чего еще. И неправильный выбор чреват целым рядом проблем в дальнейшем.

Далеко не все в порядке и с поддержкой периферийного оборудования. Известно, что не все модели принтеров, сканеров, МФУ, всяческого рода специализированных устройств, например используемых для автоматизации торговых предприятий, удастся заставить работать в среде Linux. Но если поддержка и заявлена, то вполне возможны всяческого рода подводные камни вроде существенного снижения быстродействия или невозможности задействовать те или иные важные и востребованные функции. Впрочем, в этом вопросе и системы от Microsoft начинают выглядеть не лучшим образом. Уже не редкость ситуация, когда у нового устройства отсутствуют драйверы для Windows XP, а более старое не поддерживает работу в Windows Vista.

Много сложностей и с прикладным ПО. Причем даже если есть функциональный аналог того или иного программного продукта, то это не значит, что он сможет полностью заменить хорошо известный инструмент. Не все в порядке даже с такими средствами, как OpenOffice.org, который, как известно, далеко не всегда корректно открывает документы в форматах приложений Microsoft Office, особенно если там используются макросы и дополнения. Причем часто именно такие документы используют государственные органы, в частности налоговые инспекции. В результате приходится отказываться от этого офисного комплекса, по крайней мере в тех подразделениях, где такие «особенности» доставляют больше всего неудобств. Особенно много подобных неприятностей возникает с редактором презентаций Impress и СУБД BASE, несколько реже — с табличным процессором Calc. С текстовым процессором Writer проблем несколько меньше, но многое зависит от специфики документов. В некоторых случаях отмечаются проблемы со стабильностью его работы. Плюс ко всему, средства лингвистической поддержки OpenOffice.org на голову ниже тех, которые применяются в Microsoft Office. И это выражается не только в том, что пропускается больше ошибок и опечаток, хотя и это тоже плохо, но и в том, что хуже работают средства поиска. Так что даже при использовании Linux не так уж редко продолжают применять именно Microsoft Office, запуская его через WINE или с помощью технологий терминального доступа.

Бывает и так, что полноценный аналог того или иного приложения просто отсутствует. Это относится, например, к такому довольно востребованному классу ПО, как комплексы САПР. Далеко не все в порядке и в том случае, если ту или иную программу удалось запустить с помощью WINE (заметим, что, судя по отзывам, лучше использовать для запуска продуктов «1С» WINE от компании Ethersoft, он коммерческий, но стоимость копии намного ниже, чем у Microsoft Windows). Здесь довольно велика вероятность сложностей с технической поддержкой вендора или его партнера. Например, некоторые партнеры «1С» охотно внедряют решения под Linux и помогают в миграции, а с некоторыми приходится вести непростые переговоры. Обсуждая одну из статей в нашем редакционном блоге, некоторые участники дискуссии дали такой совет на случай затруднений: «Вопрос с франчайзи «1С» решает, запрашивая письменное обоснование отказа о поддержке. Обычно они это сформулировать не могут». Стоит иметь в виду и то, что использование WINE чревато возникновением проблем, связанных с вредоносным ПО: вирусы для Windows работоспособности не теряют.

Проблемы, как мы видим, неприятные, но все же не смертельные. Рекомендации здесь простые — нужно готовиться к тому, что переход на СПО будет проводиться поэтапно, а возможные проблемы станут очевидными уже на стадии пилота. Нужно только «помогать» этому процессу, заменяя несовместимое оборудование и дожидаясь появления нативных версий тех или иных прикладных систем.

Проблемы экономические

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

  • затраты на замену или модернизацию оборудования до конфигурации, пригодной для комфортной работы;
  • затраты на администрирование (установка, постинсталляционная настройка, сопряжение с другими информационными системами, поддержание работоспособности в период эксплуатации, установка патчей и обновлений);
  • затраты на обучение пользователей (сюда стоит также включить издержки, связанные со снижением производительности труда на период, необходимый для адаптации к непривычному продукту);
  • затраты на коммерческую техническую поддержку.

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

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

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

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

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

Проблемы, связанные с человеческим фактором

Проблемы, связанные с сопротивлением персонала, могут привести к провалу любого проекта, в том числе связанного с переходом на СПО. Поскольку такой проект затрагивает большую часть персонала, эти сложности вполне могут стать непреодолимым препятствием для проведения проекта. Тем более, что такой переход нужен ИТ-руководству, которое хочет снизить затраты на лицензии, а отнюдь не пользователям, которым, и это вполне естественно, сложно ломать свои привычки. Вот как описана эта проблема в одном из блогов: «Для них (пользователей — ред.) Linux — просто новое иностранное слово. Люди привыкли к определенному «порядку вещей». Просто так и по доброй воле никто ничего менять не будет».

Поэтому в лучшем случае, о чем уже было сказано выше, снижается производительность труда. В худшем — пользователи начинают проявлять недовольство. И чем хуже обстановка в коллективе, тем негативнее сценарий драмы «Сопротивление пользователей проекту внедрения СПО». Особенно если не разъяснять, почему то или иное подразделение оказалось вовлеченным в проект раньше, а какое‑то вообще им не затронуто.

Как показывает опыт успешных проектов, стоит начинать внедрение СПО с руководства. Это полностью снимает риск появления разговоров «себе поставили хорошее ПО, а нас заставляют работать на плохом». Кроме того, не рекомендуется говорить о бесплатности того или иного решения, поскольку это может усилить недовольство со всеми вытекающими последствиями. И наконец, следует стараться сделать так, чтобы новое ПО максимально, насколько это вообще возможно, выглядело похожим на старое. Тем более что это вполне реально, хотя и требует приложения некоторых усилий. Сюда же стоит отнести и включение ряда опций, позволяющих работать в новой среде так же, как в старой. Это, например, переопределение в случае необходимости формата файлов в OpenOffice.org с ODF на DOC и XLS.

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