Команда корпоративного портала SharePoint

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

  • Спонсор  - принятие решения об инвестировании, получение отчетов о достижении целей
  • Менеджеры — для крупных организаций отвечают за бизнес направления и организуют работу владельцев контента и процессов. Координируют их взаимодействие с консультантами и IT менеджерами.
  • Владельцы контента, бизнес процессов — постановка задачи, прием результатов, управление изменениями. Без контента — его постоянного обновления, осмысленного управления ни одно SharePoint решение не будет полезным. Без постановки задач по автоматизации процессов и поддержки их развития через инициацию изменений по ходу развития бизнеса — решения на SharePoint/K2 потеряют быстро свою актуальность. Бизнес меняется, значит работа у этих людей будет всегда. На старте сложных проектов — когда надо автоматизировать десятки бизнес процессов — эти люди вместе с консультантами играют ключевую роль.
  • Внедренцы — обучение, изучение практики, коучинг, сбор требований, создание технических заданий, управление изменениями. Для них SharePoint — это прикладной продукт с набором бизнесовых фич. Их задача обеспечить эффективное выполнение бизнес процессов с помощью решений на SharePoint/K2.
  • Бизнес администраторы - управление системой или ее частями с точки зрения  бизнеса — настройки справочников, настройки бизнес правил, определение доступа, параметризация бизнес процессов, анализ работы бизнес процессов. Бизнес администраторы SharePoint решений — это достаточно новое понятие. В одном бизнесе приживается — в другом категорически нет. Вопрос в инициативности и продвинутости пользователей и их желания децентрализовать простые функции администрирования бизнес решений. Одно дело когда у вас 2 системных администратора, другое — когда плюс 10 бизнес администраторов в подразделениях.
  • IT менеджер системы — планирование, организация оперативного управления, управление технологическими рисками, обеспечение устойчивого качественного функционирования системы. Для них система — это единый объект (ПО, железо, каналы связи, рабочие места пользователей, обученные пользователи, налаженные процессы поддержки системы). Контроль и при необходимости организация решения сложных проблем пользователя. Для них SharePoint — это технологический продукт с набором технологических фич (производительность, доступность, надежность, качество).
  • Системные администраторы — настройка систем, обеспечение процедур резервного копирования и восстановления, мониторинг производительности, обеспечение выполнения SLA. SharePoint — это огромный комплекс сервисов. При добавлении того же K2 — вырастает еще (добавляются сервера, сервисы, базы данных).
  • Поддержка — обслуживание запросов пользователей, фиксация проблем, организация операций по разрешению простых проблем. Отличные знания SharePoint, практика работы с процессами — могут отличаться в зависимости от уровня инженера поддержки.
  • Инженеры SharePoint - решение проблем пользователй с системой. Часто это внешний подрядчик — но для многих решений где есть, например, K2/Nintex/Infopath — решение многих вопросов под силу инженеру IT в самом бизнесе
  • Инженеры инфраструктуры — операционки, мониторинг, виртуализация, железо — тут можно разбить еще на несколько ролей.

И конечно пользователи. Ключевые пользователи — те, которые генерируют требования, предложения, запросы на изменения. Те, которые становится локальными коучами и помогают внедрять систему на местах. Те, кому решение помогает в работе и те для кого это инструмент зарабатывания денег для бизнеса. Последние в списке но самые важные — для них команда должна предоставить качественное решение на SharePoint.

Что у вас плохо с SharePoint с вероятностью 99%?

У вас хреново с Governance. Однозначно.

Ваше решение возможно хорошо поставлено но не так сделано. Вы любите ваш дизайн но 90% пользователей считают его убожеством. Ваши пользователи не полностью и не так как надо используют его возможности. Причем то как они его используют скорее всего противоестественно. Правил нет — и  Аннушка уже дорвалась до SharePoint Designer с правами админа фермы. Сделанные вам решения не полностью удволетворяют бизнес. Бизнес хотел одно, тестировал второе, получил третье и мечтает о четвертом. Причем все это со скоростью клика на их планшетах. Нет бы бросили и не трогали так они туда начинают заливать безбожно контент. Кто же думали что они туда налопатят 5000 документов и 10000 записей за пару месяцев! Мама-мия. При росте нагрузки вся эта хрень которую вы наваяли начинает безбожно тормозить. Когда хрень упадет вы будете искать архив среди фильмов скачанных с торрентов но вспомните что удалили его так как не хватало места под новый блокбастер в Blue-Ray формате. Но это не страшно — пользователи всю неделю пока вы будете восстанавливать ферму отдохнут. Они откровенно устали работать там.  Ведь в вашей навигации пользователи так заблудились что вспоминают рецепт хождения сквозь стены из старого советского фильма. И главное это все правильно так как иного не определялось. Ведь вся эта лабуда сделана без царя в голове и стратегии на бумаге. Если вас спросят про ROI вы посчитаете этого человека не от мира сего. А вот когда вас спросят о том на основании чего вы можете закрыть проект — вы густо покраснеете без понимания потребностей бизнеса, целей, критериев сдачи. Зная это любой бизнес менеджер будет вас вертеть на пальце меняя требования и капризно топча ногой ваши планы на спокойные выходные.

Стоит поговорить про SharePoint Governance пока это не стало строкой диагноза в вашем профессиональном некрологе.

SharePoint проект за один подход?

Если вы думаете что вы определив требования и спланировав проект по реализации бизнес процесса в SharePoint (CRM) получите в итоге то что нужно бизнесу с одного захода -вы скорее всего ошибаетесь. Природа проектов по автоматизации бизнес процессов с большим вовлечением пользователей такова что создает условия для следующих рисков проекта:

  • Недоопределенность требований — не все сценарии учтены, не все заданы корректно. Это риск аналитики. В текущих условиях дефицита грамотных аналитиков И грамотных экспертов проблемных областей этот риск уже в вашем кармане!
  • Быстрое развитие опыта пользователя - если вчера пользователю нужна была “большая розовая кнопка” — то сегодня это больше полей, иные требования к usability, другие сочетания контента, более разнообразные представления информации
  • Бизнес процессы меняются. Да, бизнес процессы чаще всего живые и изменчивые нежели высеченные в камне. Процесс усовершенствования процессов в хороших организациях не заржавеет. Если вы знаете про такт очередного изменения процесса у вас повышаются шансы проскочить и сделать проект. Но это будет только первая итерация. Через ХХ дней пройдет этап усовершенствования процесса и вас призовут вносить изменения. Так что за один подход вы уже не успели.
  • Организационная структура меняется. Не дай вам бог в первой трети проекта встретится с организационными изменениями — когда заказчики бизнес процесса начинают прыгать в новую реальность оргструктуры: когда появляются новые функции, старые функцию меняются, функции перераспределяются между владельцами.
  • Стратегия меняется. То что было важным вчера сегодня уже не интересно. То что было мелочью весь этот год завтра у всех на виду. Приход новых топов в команду может спровоцировать серьезный пересмотр вашей стратегии. А в наши тяжелые времена смена топа раз в год это уже не новость.
  • Выходит новая версия ПО — то ли самого SharePoint, то ли с тем с кем вы интегрировались, то ли заканчивается проект внедрения нового ПО / замены старого