В продолжение моих предыдущих топиков:

Совет №4. Выстройте правильную организационную структуру


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

По моему мнению, максимально важно, чтобы каждый сотрудник знал несколько базовых вещей:
  1. Наименование его должности
  2. Его основные должностные обязанности
  3. Его прямой начальник, к кому обращаться с проблемами
  4. Условия работы в компании, правила, библиотека процессов
  5. ЗП, плюшки и перспективы

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

Я выделил под управление орг. структурой два основных раздела в нашей системе хранения и управления информацией (Вики). Это Роли в компании, пример:
Должность Обозначение Роль(ключевая обязанность) Группа Текущий сотрудник
Тимлид ТЛ Руководитель группы разработчиков, отвечает за всю работу разработчиков. Общее руководство всеми командами разработчиков. Менеджера Имярек


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

Методика RACI является удобным и наглядным средством проектирования и планирования изменений, а именно участия различных ролей в процедурах и задачах процесса. Часто метод RACI(Раки) называют диаграммой или таблицей, но по сути это именно матрица ответственности. Термин RACI (или ARCI) является аббревиатурой: R – Responsible (исполняет); A – Accountable (несет ответственность, отвечает за задачу); C – Consult before doing (консультирует до исполнения); I – Inform after doing (оповещается после исполнения).

В нашем контексте, Тикет ставим тому кто исполняет R, если возникают вопросы решаем с R и A (тем кто несет ответственность), если нужен совет как решить проблему обращаемся к тому с кем нужно проконсультироваться C, и после выполнения сообщаем тому, кого нужно проинформировать I.

Если отсутствует Исполнитель ® задачи, он должен передать явно задачу тому, кто замещает, если задача не была передана, то ответственный тот кто Несет ответственность (A).

Важнейшим критерием работоспособности этой таблицы является обязательное и постоянное ее развитие, как только вы обнаружили любую неучтенную зону ответственности вы ее обязательно должны загнать в Раки :). Появилась проблему, что сотрудники не знают, кто должен это делать? Собрали, обсудили, зафиксировали решения в раки, ткнули туда всех носом, разошлись. Пример(выдержки):
Направление Деятельность R A C I
1. Поддержка офиса Заказ расходных материалов. КЗ МЖ МЖ -
1.1 Заказ билетов, логистика поездки. КЗ МЖ МЖ -
3.1 Технические консультации клиентам, установка нашего ПО АИ АБ МЖ АБ


Три простых инструмента:
  1. Должностные инструкции
  2. Таблица ролей
  3. Матрица ответственности

помогут вам в решении большинства спорных вопросов звучащих «а я не знал, я думал он».

Вывод для руководителя

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

Комментарии (5)


  1. Teacher
    28.07.2015 15:09

    Подскажите пожалуйста, сколько сейчас у вас в компании: сотрудников, ролей, строк в матрице ответственности?
    Матрица ответственности это просто файлик на портале (страничка в вики)?
    Спасибо


    1. undry Автор
      28.07.2015 15:24
      +1

      Около 30 ролей, около 40 сотрудников.
      Матрица ответственности где-то 30 строк, потому что у нас четко расписана библиотека процессов, и большинство людей по привычке смотрят в первую очередь туда (про библиотеку процессов я еще поговорю).
      Все свои инфо-материалы (матрица ответственности, роли, библиотека процессов, документация) я держу в Confluence Wiki от Attlassian.


      1. Teacher
        28.07.2015 15:32

        Не очень понял, у вас текущая деятельность идет по процессам, а если там нет (редкие ситуации), то это все собирается в матрице ответственности? Если да, то не получается ли дублирования (например, у вас в матрице если установка вашего ПО, а это, на мой взгляд, регламентированная повседневная деятельность)?


        1. undry Автор
          28.07.2015 15:39
          +1

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

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

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

          Вся наша деятельность регулируется Библиотекой процессов, когда лень описывать процесс, или он слишком мелок, или все еще возникают споры по отдельным моментам, я это вывожу в Матрицу ответственности. У нас управление эволюционировало в таком порядке:

          1) Упорядоченный хаос
          2) Жира
          3) Жира+Вики
          4) Хендбук с базовыми правилами
          5) Сборище полезных инструкций и тд
          6) Библиотека процессов
          7) Библиотека процессов + матрица ответственности


          1. Teacher
            28.07.2015 15:45

            А, спасибо. Теперь понятно. Ок, тогда с остальными вопросами подожду до следующей статьи с описанием процессов.