Страницы подразделений: мини-главная для каждой команды

Один из самых частых вопросов в компании звучит так: «чья это работа?». Оргструктура показывает, кто кому подчиняется, но не чем занимается каждая команда. Именно этот пробел и объясняет существование страниц подразделений.

Оргструктуры недостаточно

Оргструктура — карта иерархии, а не ответственности. Увидев имена под квадратом «Операции», вы не поймёте, идёт ли договор с поставщиком через них или через закупки.

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

Что должно быть на странице?

Сложная структура не нужна; четыре раздела закрывают большинство компаний:

1. Чем мы занимаемся — зона ответственности команды в нескольких фразах.
2. Кто здесь — список команды и доступность.
3. С чем к нам приходить — типичные запросы и вопросы и кто занимается каждым случаем.
4. Материалы — документы, формы и процессы, принадлежащие этой команде.

Третий раздел самый ценный и чаще всего пропускаемый. Фраза вроде «споры по счетам — в Финансы, графики платежей — в Бухгалтерию» предотвращает сотни неверных адресаций в год.

Роль в адаптации

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

Поэтому работает пункт в списке адаптации: «прочитай страницу своего подразделения и трёх команд, с которыми будешь работать больше всего». Процесс мы разбираем в статье об адаптации.

Естественная опора для адресации

Структура подразделений — не только страница, но и основа адресации контента. Объявление может уйти только в Финансы, документ — только полевой команде, обучение — только новым руководителям.

Когда эта связь выстроена, точность всей системы растёт: меньше материалов уходит всем подряд, а доля прочтений поднимается. Логику мы разбираем в статье об объявлениях.

Кто пишет и кто поддерживает?

Поручать написание страниц подразделений HR — распространённая ошибка; результат — обобщённый текст. Страницу должна писать сама команда: никто не знает лучше, чем она занимается.

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

Список команды должен быть автоматическим

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

Это ещё один пример ценности синхронизации с каталогом, о которой мы пишем в статье о справочнике сотрудников.

А что с матричными структурами?

Когда человек принадлежит двум командам или перемещается по проектам, единственного назначения не хватает. Два практичных подхода: фиксировать основное подразделение человека, а дополнительные связи строить через сообщества или проекты.

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

Объявления подразделения

Живой страницу держат собственные объявления команды, которые на ней накапливаются. Напоминание Финансов о закрытии месяца не обязано уходить всей компании, но на странице Финансов оно уместно.

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

Измерение

• Полнота страниц — у скольких подразделений есть по-настоящему написанная страница?
• Просмотры — какие страницы ищут и открывают?
• Актуальность — число страниц, не тронутых год.

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