Отсутствие управляющего плана
Иногда реализация SharePoint затруднена или заканчивается неудачей из-за плохого управления. Чрезвычайно важно назначить политики, определить роли и ответственность и организовать процессы, в рамках которых компания будет использовать SharePoint для достижения бизнес-целей. Не сделать этого — значит подвергнуть предприятие огромному риску. Без плана управления у сотрудников компании (конечных пользователей, менеджеров, разработчиков, административного персонала), скорее всего, не будет реалистичных ожиданий. Необходимо определить политики и весь ход процесса доставки служб SharePoint.
Если план управления отсутствует, выделите время и ресурсы для его подготовки, даже при условии, что в компании уже внедрено несколько проектов SharePoint. Пусть разработка плана управления будет следующим проектом SharePoint. Если план уже существует, повторно обратитесь к нему. Несколько лет назад многие компании, развернувшие Active Directory (AD), прошли через этап осознания ошибок первого внедрения. Начиная пересматривать свою реализацию AD, эти компании понимают, что потребности бизнеса удовлетворяются не полностью или не задействованы все возможности продукта.
В эту же фазу входят многие компании, применяющие SharePoint. Любопытно, что в цикле эксплуатации SharePoint данный этап наступает гораздо раньше, чем в цикле продукта AD. Многие компании обращаются к своим системам SharePoint и обнаруживают, что:
- SharePoint используется гораздо активнее или совершенно иначе, чем предполагалось;
- меры безопасности и управление содержимым плохо согласованы с политиками компании;
- не используются определенные преимущества SharePoint, которые не следовало упускать;
- нужно провести чистку, так как SharePoint «на свободе» немного «одичал». Неуправляемые экземпляры необходимо привести в соответствие со стандартами, а так как никто не управлял циклом жизни контента, произошло чрезмерное накопление данных.
Если этих проблем не существует, значит, внедрение SharePoint было продумано хорошо или вам очень повезло. Но если компания испытывает затруднения, не отчаивайтесь. Бизнес часто развивается не так, как ожидалось, и по ходу дела компаниям приходится корректировать курс.
Использование MOSS в случаях, когда достаточно WSS
Эту картину приходится наблюдать вновь и вновь: компании заглатывают приманку Microsoft и начинают использовать MOSS преждевременно или слишком интенсивно. Сегодня многие компании ориентируют свои экземпляры SharePoint на коллективную работу, чтобы повысить эффективность служащих информационной сферы. Другими словами, они направляют усилия на эффективный обмен файлами, автоматизацию документооборота и реализацию функциональности Web 2.0 (например, социальные сети). Для многих компаний дополнительные возможности, обеспечиваемые MOSS, не оправдывают высокой цены, на фоне бесплатных, в сущности, служб WSS.
Даже в крупных компаниях и географически распределенной среде службы WSS могут с успехом использоваться для коллективной работы сотрудников филиалов и удаленных офисов, а MOSS — для поиска, общекорпоративного портала и других служб корпоративного уровня в головном офисе. Выгоднее удовлетворить как можно больше потребностей бизнеса с использованием WSS, прежде чем обращаться к MOSS. Это не значит, что MOSS бесполезен, ни в коем случае, но продукт удобнее применять в системе поиска, крупном портале и других службах, дополняющих коллективную работу.
Значение удобства работы конечного пользователя
У SharePoint есть реальный потенциал для увеличения производительности труда пользователей. В зависимости от особенностей бизнеса, ежедневную работу конечных пользователей можно облегчить благодаря улучшениям в одной или нескольких функциональных областях SharePoint (коллективная работа, поиск, портал, автоматизация бизнес-процессов, управление контентом и бизнес-аналитика). Для многих компаний важно улучшить коллективную работу и поиск. Поэтому все, что удастся сделать для конечных пользователей, например упростить коллективную работу или усовершенствовать поиск, будет способствовать повышению производительности труда. Более эффективное выполнение конечными пользователями своих обязанностей обычно приводит к сокращению затрат и росту доходов компании.
К сожалению, большинство компаний не прилагают усилий, чтобы оценить стоимость времени сотрудников, рассчитывая экономию от проекта SharePoint. Для этого сначала необходимо определить расходы, связанные с каждым сотрудником. Это не только зарплата, но и общая сумма, которую компании приходится тратить, чтобы сотрудник выполнял свою работу. Сюда входят льготы, обучение, налоги и др. Общие затраты обычно более чем вдвое превосходят зарплату сотрудника. После подсчета общих затрат эту величину нужно разделить на число отработанных за год часов, чтобы найти уровень расходов для данного сотрудника.
Нельзя не признать, что подсчет уровня расходов для каждого сотрудника, производительность труда которого повысится в результате развертывания SharePoint, займет много времени, особенно в случае масштабного проекта развертывания SharePoint. Но можно определить уровень расходов для каждой категории сотрудников (например, представителя по обслуживанию заказчиков, менеджера проекта, инженера) и разделить результат на вероятное число рабочих часов в году. В США часто используется величина 2000 часов (40 часов в неделю на 50 недель). Например, общие затраты на инженера составляют 150 000 долл. Почасовой уровень расходов для этой категории сотрудников составит 75 долл. (150 000 долл./2000 ч).
С помощью уровней расходов можно получить реальную величину прибыли на инвестиции в проект SharePoint. Например, одна компания, с которой я работал, выяснила, что благодаря конкретному проекту SharePoint удастся сэкономить пользователям 10 минут в день. На первый взгляд это немного, но расчеты показали, что компания сэкономит несколько миллионов долларов в год, так как повысится производительность труда нескольких тысяч пользователей. Такая прибыль на инвестиции показалась фантастической, и ее пришлось приуменьшить, чтобы она выглядела правдоподобнее.
В прошлом было трудно сопоставить такую «расплывчатую» экономию с «твердыми» затратами на программные лицензии и внедрение. Но в существующем экономическом климате компании, возможно, наконец, начнут учитывать все затраты в поисках путей, как делать больше за счет меньших средств.
Отказ от борьбы с сопротивлением
SharePoint — новый товар на рынке, по сравнению с такими конкурентами, как IBM Lotus Notes и Xerox DocuShare. Поэтому возможно сопротивление со стороны приверженцев старых инструментов. Проект SharePoint может из-за этого так и не начаться или оказаться сорванным.
Как преодолеть подобные барьеры? Все сводится к тому, чтобы уделить время сбору информации о требованиях к проекту. Поняв все требования, можно подготовить показатели измерения успеха. Представление этих требований и измеряемых величин руководителям компании, вероятно, приведет к дискуссии о прибыли на инвестиции для проекта. Преодолеть барьеры субъективизма легче, если проект поддерживают руководители компании.
Не принимается в расчет корпоративная культура
Проект SharePoint может закончиться неудачей, потому что компания не готова к нему. Например, SharePoint предполагается задействовать для организации социальной сети. Чтобы успешно применять SharePoint для сбора, сохранения и применения знаний сотрудников (которые исчезают, когда люди покидают компанию), нужно использовать социальную сеть в системах оценки производственных показателей, компенсации и всех остальных. Социальная сеть должна быть частью широкой инициативы для достижения конкретных целей в бизнесе. Она должна стать элементом культуры, а не чужеродным инструментом. Не пытайтесь внедрять проект SharePoint, если компания не готова к нему.
Не учтены все варианты
В SharePoint, и особенно в MOSS, есть множество функций, не используемых многими компаниями. Например, мало применяются профили пользователей, хотя с их помощью можно значительно усовершенствовать поиск нужных людей.
Вот краткое описание принципа действия профилей пользователей. SharePoint извлекает для каждого пользователя информацию из AD или другой базы данных LDAP, такой как Active Directory Application Mode (ADAM) или Active Directory Lightweight Domain Services (AD LDS). Набор информации, извлекаемой из AD, можно расширить, поэтому в профили пользователей SharePoint удается передать стандартные и пользовательские атрибуты. Можно также извлечь информацию из базы данных и использовать процесс (например, Identity Lifecycle Manager или сценарий), чтобы синхронизировать эту информацию с данными AD, а затем импортировать комбинированные данные в профили пользователей. Кроме того, можно задействовать каталог бизнес-данных (BDC) для получения информации непосредственно из других типов баз данных, таких как база данных отдела кадров. BDC не может быть первичным источником информации о пользователях, но может дополнить сведения, импортируемые из базы данных AD или LDAP. Дополнительные сведения о профилях пользователей можно найти в ресурсах, перечисленных во врезке «Источники сведений о профилях пользователей SharePoint».
Поскольку профили пользователей получают информацию из многих типов данных, они успешно функционируют, когда нужно создать каталог, с помощью которого конечные пользователи могут искать и устанавливать связь с сотрудниками внутри компании. Например, в корпоративной сети крупной фирмы по оказанию финансовых услуг имеется каталог сотрудников. Информация в корпоративный каталог поступает из разных источников, в том числе AD. Было решено интегрировать или заменить каталог в корпоративной сети функциональностью профилей пользователей и поиска сотрудников SharePoint. В этом случае у компании есть несколько вариантов, в том числе:
- разместить ссылку на существующий каталог в корпоративной сети на соответствующих страницах SharePoint или узлах My Site;
- представить существующий каталог в корпоративной сети внутри SharePoint, например с помощью Web-частей просмотра страниц на соответствующих страницах SharePoint;
- спроектировать специальные веб-части для требуемого взаимодействия с внутренними источниками данных и/или существующим каталогом в корпоративной сети;
- заменить каталог в корпоративной сети профилями пользователей SharePoint, механизмом поиска сотрудников и узлами My Site, используя BDC для получения информации из источников, отличных от AD.
У каждого подхода есть свои преимущества и недостатки. В первых двух случаях требуется меньше всего усилий, но интеграция наименее тесная. Два последних варианта требуют разных усилий для настройки и подготовки программного кода, в зависимости от функциональности и двустороннего взаимодействия с внутренними данными. Но специализированные веб-части отличаются большой гибкостью (с их помощью можно сделать почти все), а профили пользователей позволяют получать информацию из AD. А благодаря BDC можно извлекать, индексировать и обрабатывать данные из других источников с использованием различных функций SharePoint.
Еще один допустимый, но нетрадиционный подход — использовать профили пользователей SharePoint и функциональность My Site, не развертывая персональных узлов My Site. Этот метод рассматривается в блоге Иана Морриша SharePoint User Profiles, My Links and My SharePoint Sites without a personal My Site (www.wssdemo.com/blog/archive/2009/03/05/SharePoint-User-Profiles-and-My-Sites.aspx). Он удобен, потому что применение My Site может значительно усложнить управление и плохо согласовываться с корпоративной культурой. Почему бы не воспользоваться всеми преимуществами профилей пользователей для поиска сотрудников, одновременно избежав неприятных последствий?
Как показано в этом примере, обычно существует много вариантов. Когда нужно принять решение, подобное описанному выше, полезно оценить весь спектр возможных вариантов (в том числе без использования SharePoint), прежде чем приступать к делу.
Обходите барьеры
Зная о типичных барьерах на пути реализации SharePoint, можно подготовиться к их преодолению, а встретив препятствие — предпринять необходимые шаги, чтобы оно не повредило внедрению.
Дэн Холм (danh@intelliem.com) — директор консалтинговой службы Intelliem, которая организовывает консультации для предприятий, внедряющих SharePoint, Office, Windows и Active Directory
Источники сведений о профилях пользователей SharePoint
Дополнительные сведения о профилях пользователей можно почерпнуть из следующих ресурсов.
- На веб-странице Manage user profiles на сайте TechNet дано введение в профили пользователей с акцентом на задания для ИТ-специалистов. На панели содержания даны ссылки на дополнительные статьи по теме.
- Статьи MSDN «What's New for Developers in Office SharePoint Server 2007» (msdn.microsoft.com/en-us/library/ms585163.aspx) и «Personalizing Your Portal» (msdn.microsoft.com/en-us/library/ms496822.aspx) — отличные ресурсы для разработчиков. Кроме того, ИТ-специалистам рекомендуется прочитать дополнительные статьи, указанные в разделе содержания. Документация MSDN часто бывает полезна, так как позволяет заглянуть во внутренние механизмы и в результате лучше понять функциональность. С ее помощью как ИТ-специалистам, так и администраторам, ответственным за принятие решений, проще разобраться, чего можно добиться, дополнив SharePoint специализированным программным кодом.
- Феноменальный блог Тодда Багински «HOW TO: Enhance SharePoint User Profiles With The Business Data Catalog» (www.toddbaginski.com/blog/archive/2009/03/08/45.aspx). Это лучший из обнаруженных мною ресурсов, так как в нем показана не только ценность профилей пользователей для бизнеса, но и подробно рассмотрен пример расширения профилей с использованием каталога бизнес-данных (BDC).
- Сайт Office Online располагает информацией о профилях пользователей в «Managing User Profiles from Active Directory» (office.microsoft.com/en-us/sharepointserver/CH011715111033.aspx). Материал опубликован в разделе Microsoft Office SharePoint Server (MOSS), но относится к тематике Microsoft SharePoint Portal Server 2003. Не уверен, что его содержимое полностью применимо к MOSS 2007, поэтому обращаюсь к нему лишь в крайних случаях.
Чтобы найти еще больше ресурсов по профилям пользователей, введите фразу SharePoint «user profiles» (вместе с кавычками) в привычном поисковом механизме.