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

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

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

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

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

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

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

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

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

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

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

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

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

Управление

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

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

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

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

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

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

Набор целей

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

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

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

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

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

Предназначение ролей и обязательств

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создатель на веб-сайте Это человек, которые добавляет новый либо обновляет имеющийся контент веб-сайта.

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

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

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.