[Перевод] Сервис-ориентированные организации
Многие модели, практики и методы управления были созданы и развиты на основе инициатив в области информационных технологий. Появился 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 на практике. Если интересно, записывайтесь по ссылке.
Habrahabr.ru прочитано 6775 раз
