Примечание редактора: это вторая часть серии из пяти статей. См. другие статьи developerWorks из этой серии: "Клиентское решение IBM Open Collaboration: обзор", а также статью по техническому планированию (Часть 3) и о переводе приложений для бизнеса на настольные Linux-системы (Часть 4).

Введение

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

Эта статья отчасти опирается на раздел по организационному планированию статьи “Linux Client Migration Cookbook, Version 2: A Practical Planning and Implementation Guide for Migration to Desktop Linux," из серии IBM® Redbooks® и дополнена многими примерами из реальной жизни. Если вы хотите углубиться в изучение процесса клиентской миграции, мы рекомендуем эту статью IBM Redbooks.

Перед началом любой миграции на клиентские Linux-системы необходимо определить наиболее подходящую стратегию и сегментацию пользователей, базируясь на следующих факторах:

• ваших конечных целях и графике работы,
• размере клиентской среды, подлежащей миграции,
• доступном персонале и/или рабочей силе,
• других факторах, применимых к вашему имеющемуся проекту, таких как закон Сарбейнса-Оксли и соглашение Basel II для финансового сектора.

В современной литературе, ссылки на которую даны в разделе ресурсов, обсуждаются три общие стратегии миграции:

• «большой взрыв» (также известная как "всё или ничего" – одномоментная миграция ("Point-in-Time"')),
• постепенная (она же "пошаговая", "цыплячья» ("Chicken Little")),
• параллельная (она же "экомиграция»).

Эти стратегии имеют совершенно различные характеристики с точки зрения затрачиваемых усилий и сроков миграции, как показано на рисунке 1.

Основные характеристики, а также отдельные преимущества и недостатки каждой стратегии приведены в таблице 1.

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

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

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

1. Для каждого пользователя должна сохраняться функциональная преемственность (объяснено далее в статье).
2. Необходимо убедиться в возможности взаимодействия между всеми пользовательскими группами и сегментами, принимающими участие в пробной реализации (объяснено в следующей части этой серии статей).

Первый пользовательский сегмент, принимающий участие в пробном внедрении, может быть определен, например, следующими характеристиками:

• типом пользователей,
• их должностями,
• расположением офиса,
• отделом,
• проектом, над которым работают пользователи,
• работой с определенными продуктами — например, Microsoft® Office,
• сочетаниями представленных выше факторов.

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

• Самостоятельные и простые для миграции. Этот подход позволяет вам начать с миграции самого простого пользовательского сегмента. Здесь важный результат состоит в том, что вы получаете немедленную экономию средств, что освобождает фонды, которые можно направить на оставшийся процесс миграции. Это можно рассматривать как подход «foot in the door" ("просунуть ногу в дверь ").
• Разрозненные. Этот подход не принесёт немедленной экономии, но охватывает большую часть типов пользователей, и пробная миграция имеет больше общего с последующей основной миграцией. Этот подход можно рассматривать как тренировочный и направленный на сбор информации.

Независимо от выбранного варианта после миграции пробный проект должен продемонстрировать следующее:

1. Пользователи имеют возможность выполнять все свои обязанности и работать с приложениями так же, как они это делали до миграции.
2. Пользователи по-прежнему имеют доступ к инфраструктуре организации.
3. Все администраторы по-прежнему могут выполнять прежние задачи.
4. Новые компоненты работают так, как запланировано (требуется проверить серверное и клиентское аппаратное и программное обеспечение и их интеграцию).
5. Каждый по прежнему может следовать имеющимся правилам, распорядку и процессам (или требуется внести изменения?).

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

Основной процесс организационного планирования, частью которого является сегментация пользователей, начинается со сбора информации, как показано на рисунке 2.

Теперь обсудим эти шаги более подробно.

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

Три следующих раздела описывают анализ сегментов рынка настольных систем, определения сегментов пользователей и функциональную сегментацию. Основная цель последнего раздела — собрать подробности для функциональной сегментации, которая позволит нам распределить всё множество пользователей по их ролям и функциям.

Рынок настольных систем гораздо шире, чем рынок серверных решений. Количество доступных приложений намного больше, и многие пользователи используют свой собственный набор приложений, настроенных под свои нужды. Как показано на рисунке 3, в соответствии с используемыми программными продуктами, рынок настольных систем можно грубо распределить по следующим сегментам: фиксированные функции, технические и деловые рабочие станции, базовый и продвинутый офис, малый и домашний офис и потребитель.

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

Такие организации, как IBM и аналитическая компания Gartner, основывают свои определения сегментов пользователей на известных сегментах рынка настольных систем и дополнительных промышленных отраованиях. На рисунке 4 определение пользовательских сегмент принятое IBM, сравнивается с определением Gartner.

В обоих подходах используется схожее соотношение сегментов по численности, различается только количество и значимость сегментов. Эта схожесть не удивляет, так как данные были собраны при помощи различных исследований и последующего статистического отсева. Цель IBM, особенно в том что касается клиентского решения IBM Open Collaboration, — охват всех сегментов, в том числе некоторых частей сегмента расширенного офиса.

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

Подробное описание типов клиентов (первая строка на рисунке 5) и их функций, в том числе примерные области приложений для оставшихся строк, можно найти в приложении A.

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

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

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

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

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

Пример опроса по аппаратному обеспечению

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

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

Пример опроса по программному обеспечению

Программная часть опроса обычно громоздка из-за большого числа клиентских приложений; однако вопросов для каждого приложения меньше. Возможный опрос по программному обеспечению показан на рисунке 7.

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

Этот анализ текущего состояния ИТ-инфраструктуры дает исходные данные для задачи упрощения, описанной в следующем разделе и далее в качестве основы достижения функциональной преемственности, что, опять же, подчеркивает важность данных о пользователях и, в частности, данного опроса.

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

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

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

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

Упрощение графических приложений

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

Сначала извлеките электронную таблицу по функциональной группе «Графика» из программной части таблицы на рисунке 3 (см. рисунок 8).

Теперь дополните эту таблицу данными, отвечающими на следующие вопросы:

• Является ли указанный продукт мультиплатформенным приложением, которое также поддерживает новую целевую операционную систему Linux?
• Существует ли переходное приложение, способное заменить указанный продукт?
• Существует ли альтернативное приложение, предоставляющее функциональную замену?

Типичное мультиплатформенное приложение — IBM Lotus® Notes®, которое, начиная с версии 7, основывается на Eclipse и, соответственно, не зависит от платформы. Поэтому 8-я версия Lotus Notes изначально доступна для Microsoft Windows, Linux и Macintosh OS-X.

Переходные приложения позволяют провести миграцию приложения раньше миграции самой платформы. Преимущества — пользователи мигрируют более постепенно и не сталкиваются со многими изменениями сразу; они знакомятся с новыми приложениями до того, как происходит сама миграция. Пример такого приложения — OpenOffice.org Writer и вообще весь пакет OpenOffice.org. Если вам требуется перейти с настольной системы Microsoft Windows на систему под управлением Linux, и вы используете Microsoft Office для создания документов, то вы можете еще до миграции перейти на OpenOffice.org.

Пользователи, соответственно, будут иметь возможность познакомиться с OpenOffice.org и после основной миграции смогут сосредоточиться лишь на новой платформе и не заботиться одновременно об изменениях в средствах для создания офисных документов. Переходные приложения с необходимостью являются мультиплатформенными, но при этом еще не используются в организации; в таком качестве может выступать и Lotus Notes.

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

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

Электронную таблицу 4 необходимо дополнить тремя колонками для трех типов приложений (см. рисунок 9) и заполнить дополнительные ячейки в соответствии с ранее показанными примерами.

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

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

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

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

• Веб-ориентированные альтернативы. Некоторые производители ПО поддерживают для своих приложений лишь ограниченное количество операционных систем. Однако рост популярности Linux в качестве дополнительной настольной операционной системы привело этих разработчиков к тому, чтобы сделать приложения также доступными и для Linux. Примеры подобных приложений — управление взаимотношениями с клиентами (Customer Relationship Management, CRM), планирование корпоративных ресурсов (Enterprise Resource Planning, ERP) и работа с человеческими ресурсами (Human Resources, HR). Чтобы перенести свои приложения (по крайней мере клиентскую часть) на новую операционную систему, такую как Linux, разработчики часто выпускают новый клиент в качестве Web-приложения. С таким решением, основанным на Web-браузере, они избегают необходимости постоянной поддержки множества различных клиентских операционных систем, в то же время предоставляя заказчикам большую гибкость и частично избавляясь от жесткой привязки к продуктам (по крайней мере, в части клиентской операционной системы).
• Альтернативы на терминальном сервере. В этом подходе первоначально используемый продукт для исходной операционной системы продолжает использоваться, но теперь размещается на терминальном сервере, а не на клиентской стороне. Терминальный сервер предоставляет удаленный доступ к продукту, который опять же может использоваться на другой стороне при помощи специального клиента терминального сервера, а иногда просто через Web-браузер. Такие клиенты терминального сервера обычно являются простыми продуктами, которые доступны для множества различных клиентских платформ, иногда в качестве расширения для браузера. Примеры решений с терминальными серверами:
  
  
  • Терминальные сервисы Microsoft Windows. Используют протокол удаленного рабочего стола (RDP).
  • Citrix Metaframe. Использует архитектуру независимых вычислений (Independent Computing Architecture, ICA), простой клиентский протокол от Citrix Systems.
  • NoMachine NX. Использует метапротокол NX, который поддерживает туннелирование и сжатие, а также работу с некоторыми другими протоколами, такими как X, RDP и Remote Framebuffer (RFB, используется в VNC), и поддерживает защищенные соединения SSH с секретными и публичными ключами.
  • Виртуализация в настольной системе. Например, инфраструктура виртуального настольного ПК VMware (Virtual Desktop Infrastructure, VDI) позволяет исполнять приложения для локального или удаленного использования на внутренних виртуальных машинах, к которым можно обращаться по общим протоколам, таким как RDP. Некоторые решения по виртуализации, нацеленные только на рабочие станции, такие как VirtualBox, также предлагают функциональность «прозрачного встраивания Windows».

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

В таблице на рисунке 11 показаны пример Web-ориентированной альтернативы Microsoft Outlook Express, а также клиент для управления взаимодействием с клиентами Siebel, доступный через терминальный сервер Citrix Metaframe.

Теперь можно оценить реалистичность реализации миграции с точки зрения приложений, изучив полностью заполненную таблицу (см. приложение B). Миграция также может быть удобным моментом для изменения парадигм. Так, возможно, для вашей организации имеет смысл ввести новый подход, полностью перейдя на приложения, основанные на Web-браузере. На рисунке 12 показан общий обзор вопросов стоимости, гибкости и управляемости для целевых приложений, которые перечислены в двух новых колонках с правого края таблицы.

Здесь мы упомянем некоторые нетехнические аспекты, которые не обязательно очевидны и часто недооцениваются техническими специалистами: социальные факторы. Эти факторы в особенности важны в проекте клиентской миграции, поскольку он напрямую затрагивает пользователей.

Человеческий фактор

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

Всё это направлено против отрицательных сторон кривой принятия для пользователей, показанной на рисунке 13.

Вопросы переобучения

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

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

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

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

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

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

В этой статье обсуждается следующий перечень типов клиентов:

• Фиксированные функции. Пользователи этих клиентских систем работают только с одним определенным приложением, настроенным для конкретных целей.
  Примеры: терминалы общего доступа или терминалы в точках продажи; приложения, основанные на WebSphere® Portal.
• Техническая рабочая станция. Пользователи этих клиентских систем работают в специфических для своей отрасли приложениях. Им могут требоваться специфические программные пакеты, созданные для конкретного сектора или области задач.
  Примеры: проектирование (например, приложения CAD/CAM) или приложения развлекательной индустрии (создание анимационных фильмов).
• Деловая рабочая станция. Пользователи этих клиентских систем используют приложения, основанные на формах; также они
  
  
  Источник: http://www.ibm.com/developerworks/ru/library/ls-occs-pt2/index.html