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

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

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

Установленное ПО можно условно разбить на три категории:

  • программы, имеющие равноценные свободные аналоги;
  • программы, не имеющие равноценных свободных аналогов;
  • уникальные программы, используемые внутри предприятия.

Проще всего с первыми двумя категориями. Очевидно, что в первом случае замена программ на свободные аналоги возможна, а во втором — нет. А вот в третьем случае предстоит серьезная подготовительная работа.

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

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

Дело в том, что некоторые приложения, написанные для Windows, прекрасно работают в среде WINE. Причем, чем древнее программа, тем больше вероятности, что она запустится без проблем. Однако заранее что-то сказать невозможно, поэтому потребуется тестирование.

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

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

Определившись с прикладными программами, следует заняться рабочими станциями. А именно — определить возможный предел миграции.

Рабочие станции можно разбить на три категории по используемому ПО:

  • используются только программы, не имеющие свободных аналогов;
  • часть используемых программ не имеют свободных аналогов;
  • все используемые программы имеют свободные аналоги.

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

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

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

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

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

Например, анализ показал, что рабочую станцию секретаря можно полностью переводить на СПО. Но это в теории. На практике все может оказаться несколько сложнее. Например, сотрудник пользуется МФУ. Он привык, что факсы отправляются очень просто — посредством “печати” на специальный принтер. В Linux это тоже можно сделать, но потребуются дополнительные усилия и соответственно расходы. А уж сколько крови могут попортить системным администраторам жалобы пользователей на то, что из трея пропала иконка, показывающая, кто именно звонит по телефону...

Отсюда вывод. Считать результат этого небольшого исследования значимым можно только тогда, когда он отрицательный. То есть говорит о том, что в миграции нет никакого экономического резона. Если он окажется иным, то это означает только то, что можно смело двигаться дальше, будучи готовым остановиться в любой момент.