Microsoft SharePoint 2010: Планирование управления

Для создания эффективной структуры управления нужно исследование, планирование, точное исполнение и постоянная оценка и сопровождение.

Стив Райт и Кори Эркес

Адаптированная выдержка из книги «SharePoint Governance» (Apress, 2012).

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

• Кто является исполнительным спонсором проекта, иначе говоря, кто будет его оплачивать?
• Что предполагается совершить?
• Как будет осуществляться поддержка развернутой системы?
• Как обеспечить, чтобы система предоставляла сервисы, которые нужны компании? Как узнать, когда решение не приносит ценность?

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

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

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

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

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

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

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

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

Начало общения

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

• Пригласить в команду управления добровольцев.
• Собрать предложения по содержимому и функциональных требованиях.
• Собрать идеи, которые могут повысить ценность портала.

Руководство

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

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

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

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

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

Их вклад должен признаваться и вознаграждаться. Участие в подобных мероприятиях может требовать много времени, если это делается, как следует. Важно, чтобы это время учитывалось в общей нагрузке и плане развития карьеры. Если просить сотрудников делать это помимо и в дополнение к обычной 40-часовой рабочей неделе, это автоматически переведет эту работу в категорию низкоприоритетных.

Набор целей

Как в любом другом проекте, управление порталом SharePoint нуждается в четком определении целей. Как и с концепцией, существует много рекомендаций по определению целей. Один из самых распространенных подходов называется S.M.A.R.T.:

• Конкретность (Specific) Цели должны точно определять, что должно быть сделано.
• Измеримость (Measurable) Цели должны поддаваться количественной оценке и быть конкретными, чтобы можно было объективно оценивать степень выполнения, а также успех или неудачу.
• Достижимость (Attainable) Цели никогда не нужно определять так, что их нельзя было полностью достичь. Определение цели, которую трудно достичь, — это хорошо. Бессмысленно определять цель, которую достичь невозможно.
• Существенность (Relevant) Цели должны всегда быть ориентированы на реализацию миссии или концепции проекта.
• Ограниченность во времени (Time-bound) У целей всегда должен быть срок. Цель с неопределенным сроком малополезна, потому что ее вроде бы и незачем достигать.

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

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

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

Назначение ролей и обязанностей

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

Исполнительный спонсор Этот «чемпион» проекта обычно связан с той частью компании, которая предоставляет ресурсы для проекта.

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

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

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

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

ИТ-менеджер Он руководит администраторами и разработчиками, работающими над системой.

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

Системный администратор Устанавливает, наблюдает и обновляет серверы, относящиеся к порталу.

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

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

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

Ответственный за сайт На каждом сайте SharePoint есть один или несколько ответственных, которые управляют доступом к сайту.

Дизайнер сайта Сайт дизайнер отвечает за списки, библиотеки и другое содержимое сайта. Зачастую ответственным за сайт и дизайнером сайт является один человек.

Автор на сайте Это человек, которые добавляет новый или обновляет существующий контент сайта.

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

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

Стив Райт (Steve Wright) является старшим менеджером в отделе бизнес-аналитики компании Sogeti USA из Омахи, штат Небраска. За последние 20 лет с небольшим Стив работал над системами управления воздушным движением, а также над финасовыми, страховыми и  многими другими системами. Он выступал в роли автора и рeцензента многих изданий, посвященных таким продуктам Microsoft, как Windows, SharePoint, SQL Server и BizTalk.

Кори Эркес (Corey Erkes) работает управляющим консультантом в компании Sogeti USA из Омахи, штат Небраска. Erkes работал со многими компаниями на разных этапах внедрения их решений SharePoint. Он также является одним из создателей пользовательской группы SharePoint в Омахе.