багатоликий sharepoint

Я часто консультую людей з приводу SharePoint, і кожен раз я чую приблизно одне й те саме: "ми плануємо \ розробляємо \ впроваджуємо \ використовуємо \ хотім_викінуть портал на SharePoint". Таке відчуття, що єдине для чого призначений SharePoint - робити портали. Як бітрікс або, не дай бог, друпал. Ситуацію ще підігрівають HRи, які хочуть "інтранет" (маючи на увазі рівно те саме, що і портали).

Якщо ж трапляється грамотний замовник, який розуміє проблеми за межами фрази "корпоративний портал", то підрядник найчастіше намагається впарити своє "портальний рішення". Це "рішення" повинно задовольняти всі потреби замовника одним махом.

Звичайно портали щоразу різні, але в них дуже багато спільного.

Типовий корпоративний портал на SharePoint

Зазвичай на портал покладаються такі завдання:

Портал обов'язково повинен мати унікальний дизайн.
Портал має сприяти поліпшенню комунікації.
Портал повинен мати функцію документообігу.
Портал повинен бути сховищем активів для підрозділів.
Портал повинен забезпечувати спільну роботу.
..а ще автоматизувати заявки, робити пошук, обов'язково потрібна міні-crm, голосування, показувати дні народження і трудові ювілеї, новини, фотографії, посилання ... нічого не забув?

Найдивніше, що багато цілі суперечать один одному, але це нікого не бентежить. Наприклад документообіг вкрай погано поєднується з унікальним дизайном. Нікому в голову не прийде робити унікальний дизайн в Documentum або DocsVision, а в SharePoint це нормально. Сховище активів вимагає розмежування доступу відповідно до організаційною структурою, а спільна робота і поліпшення комунікацій, навпаки, вимагає подолання рамок організаційної структури. Весь feature soup, який пропонується в якості корисного функціоналу, взагалі ніяк не корелює з заявленими цілями і присутній, в основному, "для галочки". І це ще не найстрашніше ...

Найстрашніше починається коли цей портал намагаються реально використовувати. Адже бізнес динамічний, постійно потрібно щось поміняти, підкрутити, дати доступ, створити сайт, змінити сторінку. Але універсальне "портальний рішення" більше нагадує не гнучку систему, а мистецький з граніту, яке навіть пересунути не можна, не те що якось поміняти.

Пристосувати "портал" під конкретні завдання користувачів виявляється складно, а без цього adoption стає низький і вкладення не окупаються. Гігантський набір фич на порталі використовується від сили на 20% і, найчастіше, страждає від проблем масштабування.

Чому так відбувається

Сам термін корпоративний портал є ментальним шорткати, який позбавляє продавця і покупця від необхідності з'ясування потреб. Крім того, для продавця продати "корпоративний портал" - це хороший спосіб продати проект допилювання порталу під конкретні потреби.

Я думаю для багатьох не секрет, що деякі вендори "корпоративних порталів" по факту не мають порталу як продукту (що поширюється без програмістів).

Як зробити правильне рішення

Для створення гарного рішення на SharePoint необхідно:

Зосередитися на цілях
Поставити вимірні KPI
Планувати інформаційну архітектуру
Створювати найпростіші рішення

Це, звичайно, простіше сказати, ніж зробити. Потрібна хороша підготовка і багатий досвід, а також адміністративний вагу, щоб вас слухали. Але це все теми для окремих посад.

Важливо розуміти, що у різних цілей різні засоби вирішення, архітектура і KPI, можливо суперечать один одному.

Приклади рішень на SharePoint

Корпоративний пошук

Робочі області команд і проектів

Мета - збільшити ефективність спільної роботи.
KPI - кількість пересилаються по електронній пошті документів. Взяти baseline до запуску системи, зменшити на 30% -50% -80% за смаком.
Архітектура - необхідно зробити максимально простий процедуру створення сайтів з бібліотекою і списками для спільної роботи. Без заявок в ІТ і погоджень.
Рішення - стандартні сайти команд SharePoint, плоскі дозволу, контрольований життєвий цикл. Навчання користувачів можливостям платформи.

Корпоративний сайт

документообіг

Мета - зменшити час узгодження.
KPI - Час узгодження документів (за типами). Можна взяти baseline з поточної ситуації, зменшити на 30% -50% -80% за смаком.
Архітектура - фіксовані маршрути, ролі, типи документів. Це дуже важливий момент. Якщо згідно може брати участь будь-яку кількість людей, то вважати KPI стає неможливим. Якщо документи не можна розділити за типами, то теж викликає проблеми розрахунку KPI.
Рішення - Окремий сайт або колекція, типи контенту, шаблони, workflow. Передбачити обчислення кількості днів \ годин \ хвилин на узгодження. Ну і без навчання, швидше за все, нікуди.

Спеціалізовані варіанти рішень:

Enterprise Content Management \ Електронний Архів
Автоматизація заявок
бази знань
Системи оцінки персоналу
Системи внутрішніх вакансій

Спробуйте на дозвіллі продумати конкретні цілі і KPI таких систем.

Найважливіше - все це різні системи. Немає сенсу все валити в одну купу і називати "корпоративним порталом", так досягти KPI не вийде.