Если вы убедились, что переход на Linux экономически оправдан, то можно двигаться дальше. А именно — принять ряд решений, которые будут в общих чертах определять весь ход проекта.
Во-первых, следует решить, какой дистрибутив (или какие дистрибутивы) надо использовать. Во-вторых — оценить необходимость обращения к системному интегратору, да и вообще разобраться с услугами, которые предлагают компании по внедрению и поддержке. Наконец, в-третьих, предстоит понять, нужен ли пилотный проект или проще обойтись без него.
Дистрибутив и интегратор
Одна из самых серьёзных ошибок — рассматривать две стороны этого вопроса независимо друг от друга. Безусловно, нельзя дословно применять к корпоративному сектору известный тезис о том, что самый лучший дистрибутив — тот, которым пользуется сосед, но учитывать это все равно необходимо.
Важно понимать, что установка системы и ее настройка с учетом требований пользователя — это даже не полдела. В ряде случаев с этим может справиться грамотный студент без всякой инфраструктуры. Но на практике потребуется и обучение сотрудников, и техническая поддержка, и многое другое.
Вполне может получиться так, что вариант, который казался наиболее выгодным при поверхностном рассмотрении вопроса, в действительности приведет к серьезным дополнительным расходам. Например, отдав предпочтение какому-нибудь экзотическому дистрибутиву, внедряемому небольшой компанией за небольшие деньги, вы рискуете, что через некоторое время интерес этой фирмы к СПО иссякнет и вам придётся искать замену. А это связано с новыми затратами.
С другой стороны, можно выбрать Red Hat, соблазнившись их фирменной технической поддержкой, и заплатить серьезные деньги на подписку и ее ежегодное обновление. Но потом окажется, что аналогичного результата можно было достичь и при меньших затратах. Например, установив Ubuntu и заключив договор с каким-нибудь местным интегратором.
Вероятнее всего, самый правильный путь должен начинаться с выяснения истинного положения вещей в регионе. Для этого можно обзвонить всех интеграторов и узнать, какие именно дистрибутивы Linux они готовы поддерживать.
Разумеется, если интегратор ответит, что Linux — он и есть Linux, и ему безразлично, какой именно дистрибутив обслуживать, то к таким заявлениям следует относиться со значительным скепсисом. Дело в том, что у каждого продукта есть своя специфика. Понятно, что опытный специалист сможет в ней разобраться, но это потребует времени. Значительно лучше, если подрядчик уже имеет практический опыт решения проблем конкретной системы, а не собирается учиться “на вас”.
Таким образом, вопрос о дистрибутиве и интеграторе решается так: “лучший дистрибутив” — тот, который поддерживает больше всего интеграторов; “лучший интегратор” — тот, кто поддерживает больше всего дистрибутивов (с учетом вышесказанного — не просто декларирует поддержку, а может сослаться на практический опыт).
Кстати говоря, вполне может оказаться, что наиболее эффективной для вашего предприятия окажется некая гибридная модель, в которой используется несколько дистрибутивов. Опытный интегратор вполне может предложить такую схему, и не стоит от нее сразу отказываться.
Пилотный проект
Очевидно, что только безрассудные люди могут принять решение о переводе на СПО сразу всего предприятия. Даже если теоретически все должно получиться хорошо. Как известно, гладко бывает только на бумаге, а на практике придется шагать по вполне реальным оврагам.
Поэтому большую миграцию разумно начать с небольшого пилотного проекта. В его рамках исполнитель лучше узнает специфику вашего предприятия. А вы, в свою очередь, сможете оценить работу интегратора: если он явно не будет справляться, то лучше отказаться от его услуг, пока еще дело не зашло слишком далеко.
Но тут возникает серьезный вопрос: надо выбрать зону пилотного проекта. Принимая решение, следует учитывать несколько моментов.
Прежде всего нужно сразу предусмотреть вероятность неудачи. Поэтому не следует включать в пилотную зону критически важные с точки зрения бизнеса подразделения. Более того, на время проекта желательно реализовать дублирование функций на тот случай, если по тем или иным причинам какие-то рабочие станции окажутся выключенными из работы.
И, разумеется, системный интегратор обязан проводить пилотный проект таким образом, чтобы в любой момент его можно было остановить, вернув систему в первоначальное состояние в разумные сроки. В противном случае может пострадать бизнес, а это неприемлемо.
Но самое главное — избежать одной неприятной ошибки. Кстати, это не получилось даже у государства в известном пилотном проекте по внедрению СПО в систему образования. Дело в том, что Linux устанавливался аж в трех регионах России (то есть число рабочих станций было очень большим), но только в кабинетах информатики.
И несмотря на то, что проект завершился успешно, внедрить СПО в школы стало не намного проще, чем до него. Ведь компьютеры стоят не только в кабинетах информатики, они используются довольно широко. Например, в административной деятельности, где нужны совершенно другие прикладные программы.
Очевидно, что было бы лучше для пилотного проекта выбрать меньше школ, но переводить их на СПО целиком, а не только один кабинет. В этом случае вряд ли появилось бы заявление компании “Линукс ИНК” (одного из участников проекта), в котором говорилось, что созданные в соответствии с условиями проекта дистрибутивы отвечают только требованиям обеспечения образовательного процесса, да и то ограниченно, но не других сторон деятельности учебного заведения.
Следовательно, пилотную зону надо выбирать таким образом, чтобы были охвачены все бизнес-процессы предприятия. В идеальном случае это может быть некий удаленный филиал или представительство, все структуры которого точно такие же, как в головном подразделении. Если такой возможности нет, то придется выделять рабочие станции из каждого отдела, но именно так, чтобы опять же затронуть все аспекты работы фирмы.
