Практического опыта нету, а кое-какие теоретические познания о правильных и неправильных подходах есть.
1) Определяешь цели внедрения (для чего все вообще делается, что является критерием успеха проекта)
2) Согласовываешь цели с руководством и приступаешь к составлению плана
3) Помашинно описываешь текущее используемое ПО, какие функции оно выполняет, какую роль
играет в бизнес-процессах
4) Отдельно описываешь протоколы обмена данными между сотрудниками и с внешним миром, уточняешь границы возможностей по пересмотру и смене этих протоколов, если они не открытые.
5) Классифицируешь ПО по принципу:
*) имеет родные версии под обе платформы
*) имеет функциональные аналоги (с точки зрения не твоей а в первую очередь пользователей)
*) можно запустить под wine
*) можно запустить под терминальным сервером винды
*) ничего из перечисленного (т.е. business-critical, windows-only приложения, которые нельзя ни эмулировать ни выносить на терминал -- например, работающие с экзотическим железом). Такие машины из миграции будут исключены.
6) Классифицируешь протоколы обмена по следующим критериям:
*) открытый-закрытый
*) полнота поддержки протокола в ПО, на которое собираешься мигрировать
*) используется в конторе, либо для связи с внешним миром -- реально ли сменить если что
*) каким ПО используется (с учетом классификации из п.5)
7) Собственно из пп 5-6 тебе уже должна быть видна картина, что получится перевести, что не получится, и сколько ресурсов это затребует. Дальше уже можно рисовать план миграции.
План миграции рисуется как для любого обычного реформирования инфраструктуры и должен учитывать режимы работы отделов, конкретные бизнес-процессы, которые нельзя останавливать, возможные риски, затраты на обучение пользователей, план отката в случае провала и т.д.
9) У всяких европейцев принято миграцию по возможности сегментировать. Т.е. если контора делится на отделы, работающие по разным схемам, и миграцию в них теоретически можно организовать в несколько этапов -- то начинают с отделов, чья работа наименее критична для организации и делают паузы по несколько недель, оценивая результаты. Такой подход позволяет в случае провала миграции "откатиться" к предыдущему состоянию с наименьшими потерями.
10) План миграции согласовывается с руководством, выделяются средства -- и вперед.
, тут два варианта: либо никто не пробовал это самое свободное ПО в офисе внедрить, либо пробовал, но не получилось ... хотя мне кажется должно получиться - если постораться ... откликнитесь у кого есть интерес к этому делу!!!
, но хотелось бы знать - есть ли такие приценденты в Минске?? причем имею ввиду обычную контору с сетью от 20 до 50 компов ...
... или по другим причинам .... но все таки вдруг такой найдется!!!! или может уже нашелся ....