Многие модели, практики и методы управления были созданы и развиты на основе инициатив в области информационных технологий. Появился Agile, развилась дисциплина управления проектами, а бизнес-операции и цифровые операции стали единым целым.

Технология, по сути, сотворена из логики, и нам ещё многому предстоит у неё научиться.

От монолитности к сервис-ориентированности

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

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

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

Монолитные компании

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

Затем случается рискованное явление — эффект домино…

...простые процессы становятся сложными…

… и lean-фреймворки становятся слишком тяжеловесными…

Пределы человеческих отношений

Число Данбара — это предполагаемый когнитивный предел количества людей, с которыми человек может поддерживать стабильные социальные отношения. (источник)

Робин Данбар считает, что человек в среднем может стабильно и комфортно поддерживать отношения со 150 людьми. Это объясняет, почему в крупных компаниях всегда присутствует бюрократия: когда у менеджеров значительно вырастает число контактов и они начинают чувствовать себя менее комфортно в связи с этим, они пытаются компенсировать это большим количеством контроля. Однако проблема — не контроль сам по себе, а ручные задачи и фиктивный контроль. Например, подсчёт рабочего времени или создание тасков в Jira даже для того, чтобы пойти выпить кофе.

Люди теряют связь с миссией 

Когда я работал в Farfetch, платформе для электронной коммерции предметов роскоши, их миссия звучала как «из любви к моде».

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

Позже в компании появился новый директор по данным (Chief Data Officer, CDO), который запустил стратегическую инициативу под названием: «Где данные соприкасаются с модой».

По-моему, для команды данных это звучало гораздо лучше. Но даже такой лозунг наверняка окажется слишком общим, когда команда данных достигнет 300 человек: сотрудники, сосредоточенные на конкретной части науки о данных, скорее всего, не будут чувствовать свое к этому отношение.

Стратегическая разведка — «мудрость толпы»

«Мудрость толпы» — это книга Джеймса Суровецкого об объединении информации в группы с целью принятий лучших решений, чем те, которые могут быть приняты любым отдельным членом группы.

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

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

Распределить полномочия по принятию решений — всё равно что создать огромный кластер мощных машин для обработки данных и проведения сложного анализа.

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

И тут возникает ключевой вопрос:

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

Сервисные единицы

Вместо того чтобы масштабировать структуру, разбейте её на простые, слабосвязанные и полунезависимые части.

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

Отсылки к подобным идеям можно найти в таких книгах, как «Strategic IQ: Creating Smarter Corporations», где Джон Р. Уэллс говорит о чём‑то вроде стратегических единиц. Однако я решил рассмотреть подход с сервисными единицами, поскольку его можно сравнить с логикой SOA и он в значительной степени поддерживается практиками управления услугами, такими как ITIL и VeriSM, чтобы помочь решить конкретные проблемы в этой системе.

В сервис‑ориентированной организации каждый отдел, область или сектор становится сервисным единицами со своими поставщиками и клиентами. Состоят они примерно из 150 человек.

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

• Сотрудники начинают фокусироваться на своих клиентах, а не на начальнике.

• Более мелкие единицы со значимой миссией — когда у каждого подразделения есть своя миссия, связанная с их основными клиентами.

• Становится проще управлять — меньше людей, проще процессы, всё просто течёт через прочные отношения.

• Более тесные человеческие отношения.

Девиз «радовать клиентов» — звучит красиво, но HR или внутренней ИТ-команде очень сложно объективно связать это со своей непосредственной деятельностью.

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

Сервисный центр

Сервисный центр можно сравнить с брокером сообщений в SOA-архитектуре. Добавление сервисного центра для посредничества в отношениях между сервисными единицами приносит другие важные результаты:

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

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

• Централизованное управление процессами и программным обеспечением: SC работает как центр управления, где можно внедрять бизнес-правила и измерять эффективность системы на основе общих метрик.

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

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

А что происходит на уровне высшего руководства?

Обмен на уровне C-Level управляет системой, которая теперь в основном самоуправляемая, регулируя её с помощью политик и бизнес-правил, применяемых в сервисном центре. Это приводит к следующему:

• Быстрое внедрение основных политик (например, уровней утверждения затрат).

• Снижение количества микроменежмента.

• Быстрое обеспечение стратегического перемещения высшим руководством.

• Все перестают бояться аудита внутренних процессов.

Общие метрики

Каждый отдел был создан для того, чтобы приносить пользу другому подразделению — будь то другой отдел или конечный клиент, например, операционный или коммерческий.

Таким образом, в дополнение к традиционным метрикам каждого отдела, таким как пропускная способность, финансовая, операционная эффективность и так далее, на уровне сервисных подразделений необходимо отслеживать два основных стратегических KPI:

Уровень обслуживания — уровень, на котором сервисная единица соответствует критериям качества, согласованным с клиентами.

Удовлетворённость клиентов — необходимо слышать голос клиента, в том числе и по нецелевым критериям.

Сервис-ориентированная организация — это самоуправляемая система, которая имитирует естественный процесс непрерывного совершенствования, при котором люди наделены полномочиями добиваться изменений и имеют чёткое намерение для этого.

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

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

22 мая в рамках онлайн-курса «ITSM-специалист» пройдёт открытый урок «Набор инструментов для ITSM». Мы рассмотрим несколько методов поиска точек роста в ИТ, изучим способы внедрения улучшений и разрешения спорных ситуаций. В итоге с этим набором инструментов вы сможете применить принципы ITSM на практике. Если интересно, записывайтесь по ссылке.