Поиск 

Методы проведения каскадирования. Современное управление персоналом: Каскадирование целей, или Как транслировать стратегию каждому сотруднику? Технология каскадирования целей

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

Сам по себе факт коммуницирования стратегии мотивирует сотрудников («Мне понятно, куда мы движемся и что будет с компанией через три года»). Дополнительная мотивация появляется тогда, когда сотрудник знает, что лично он должен делать для достижения общей цели. Инструментом, помогающим довести до каждого стратегию компании, может быть каскадирование целей в системе Balanced Scorecard.

Типичная проблема стратегического управления - незнание стратегии теми, кто призван ее реализовывать. Разумеется, сам факт осведомленности еще не означает, что каждый сотрудник станет оценивать свои действия с точки зрения пользы для общего дела. Можно повысить готовность персонала участвовать в реализации стратегии, если привлекать его к разработке мероприятий, направленных на достижение стратегических целей компании, а также если связать материальную и нематериальную мотивацию с достижением стратегических целей. Другими словами, сотрудник будет ориентирован на реализацию стратегии компании, если он:

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

Система Balanced Scorecard (BSC) разрабатывалась профессорами Капланом и Нортоном именно как инструмент реализации стратегии. После определения ключевых целей в проекциях «финансы», «клиенты», «бизнес-процессы» и «инфраструктура/персонал», разрабатывают набор индикаторов для мониторинга их достижения и устанавливают целевые значения этих индикаторов. Далее продумывают основные мероприятия, направленные на достижение поставленных целей. Базовый вариант системы BSС представлен в табл. 1. А расширенный включает индикаторы не только для целей, но и для мероприятий, предполагает указание подразделений, участвующих в их реализации, а также бюджеты и сроки их проведения (табл. 2).

Таблица 1. Базовый вариант системы Balanced Scorecard
(компания - интернет-провайдер)

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

Таблица 2. Расширенный вариант системы Balanced Scorecard
(компания - производитель строительных конструкций)

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

Существует, однако, и более развернутый вариант BSC, который предполагает построение системы целей, показателей и мероприятий для отдельных структурных подразделений (то есть каскадирование). В результате у каждого структурного подразделения компании (департамента, филиала, отдела и т. д.) появляется своя система BSC («карта»), отражающая ключевые цели этих подразделений, их индикаторы и мероприятия, необходимые для их достижения. «Карта» объясняет персоналу его участие в реализации стратегии компании, помогает руководству оценивать работу каждого сотрудника (подразделения) и служит основой системы мотивации.

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

ПРОЕКЦИИ НА УРОВНЕ СТРУКТУРНЫХ ПОДРАЗДЕЛЕНИЙ

Обычно в системе BSC верхнего уровня представлены четыре проекции: «финансы», «клиенты», «бизнес-процессы» и «инфраструктура/персонал». Общие цели компании, сформулированные в рамках этих проекций, как правило, образуют причинно-следственную цепочку. Логика рассуждений при этом такова, что квалифицированные и мотивированные сотрудники, используя развитую инфраструктуру (оборудование, программное обеспечение, транспортный парк и т. д.), способны обеспечить необходимые компании качество и скорость бизнес-процессов. Отлаженные бизнес-процессы дают преимущество перед конкурентами и способствуют удовлетворенности клиентов. Удовлетворенные клиенты и конкурентные преимущества, в свою очередь, составляют предпосылки достижения финансовых целей (рис. 1).


Рисунок 1. Причинно-следственные цепочки целей в системе BSC

Как это применить на практике? Цели в «карте» верхнего уровня прописывают начиная с проекции «финансы». В первую очередь компания должна ответить на вопрос: «Сколько мы хотим заработать и сколько собираемся при этом потратить?» Второй вопрос звучит следующим образом: «Что мы должны сделать для своих клиентов, чтобы достичь своих финансовых целей?» Третий касается проекции «бизнес-процессы»: «Как должна быть построена работа компании, чтобы достичь целей в рамках проекций «клиенты» и «финансы»?» И наконец, четвертый вопрос - о том, какие персонал и инфраструктура необходимы компании для достижения целей в рамках трех верхних проекций.

Что касается числа проекций на уровне компании в целом, то на практике оно может варьироваться. Как правило, речь идет о выделении особо значимого для компании аспекта в отдельную проекцию (например, «поставщики», «государство») и добавлении ее к четырем «классическим». Разумеется, при желании отношения компании с поставщиками можно рассмотреть в проекции «Бизнес-процессы», а с государством - в проекции «рынок/клиенты».

Система BSC на уровне структурных подразделений обычно повторяет ее модель на уровне компании в целом. У каждого подразделения обычно есть свои «финансы» (например, бюджет отдела и сумма, отведенная на премии), свои «клиенты» (коллеги), свои «бизнес-процессы» («глобальные» процессы компании в целом, в которых участвует структурное подразделение, и «локальные» процессы, протекающие внутри структурного подразделения), а также свои «инфраструктура/персонал». Таким образом, система BSC превращает структурное подразделение (производственный цех, отдел логистики, финансовый отдел, отдел IT и т. д.) в мини-компанию в составе компании. Каждое структурное подразделение понимает, что квалифицированный персонал и развитая инфраструктура необходимы ей для того, чтобы быстро и качественно выполнять свою работу (проекция «бизнес-процессы»). Отлаженные процессы необходимы структурному подразделению, чтобы успешно взаимодействовать с внутренними клиентами (коллегами из других подразделений или руководством компании). От того, насколько успешным будет это взаимодействие, зависят в том числе и финансовые результаты подразделения (соблюдение бюджета, получение запланированной суммы премии). Другими словами, каждое структурное подразделение компании продает свой продукт (услугу) внутренним (и внешним) клиентам, стремясь максимально удовлетворить их ожидания. Поэтому индекс удовлетворенности внутренних клиентов (балльная оценка коллег) в компаниях, опирающихся на такую логику ведения бизнеса, - стандартный показатель практически во всех подразделениях.

Возможны также модификации «классической» модели BSC для структурных подразделений. Так, например, в системе BSC одного из восточноевропейских заводов крупного автомобилестроительного концерна есть только три проекции: «финансы», «бизнес-процессы» и «инфраструктура/персонал». Проекция «клиенты» выпадает: сам по себе завод клиентов искать не должен, поскольку все заказы приходят к нему из концерна, а взаимодействие со сторонними клиентами в модели ведения бизнеса не предусмотрено. Строго говоря, клиентами этого завода являются другие предприятия концерна, на которые он поставляет свою продукцию (детали автомобилей). Но руководство завода сочло, что отследить аспекты отношений с другими предприятиями в составе концерна можно в рамках проекции «бизнес-процессы». Основные показатели, которые при этом анализировали, - процент брака, число заказов, выполненных вовремя, и число жалоб от внутренних клиентов.

Продолжение следует

Типичная проблема стратегического управления — незнание стратегии теми, кто призван ее реализовывать. Разумеется, сам факт осведомленности еще не означает, что каждый сотрудник станет оценивать свои действия с точки зрения пользы для общего дела. Можно повысить готовность персонала участвовать в реализации стратегии, если привлекать его к разработке мероприятий, направленных на достижение стратегических целей компании, а также если связать материальную и нематериальную мотивацию с достижением стратегических целей. Другими словами, сотрудник будет ориентирован на реализацию стратегии компании, если он:
  • знает и понимает стратегию компании в целом;
  • видит свой вклад в реализацию стратегии;
  • представляет вклад коллег в реализацию стратегии;
  • участвовал в разработке мероприятий, необходимых для достижения стратегических целей;
  • участвовал в составлении системы целей и показателей для своего структурного подразделения (должности);
  • мотивирован (материально и/или нематериально) на достижение целевых значений принятых показателей;
  • располагает ресурсами, знаниями, навыками и инфраструктурой, необходимыми для достижения поставленных перед ним целей.

Система Balanced Scorecard (BSC) разрабатывалась профессорами Капланом и Нортоном именно как инструмент реализации стратегии. После определения ключевых целей в проекциях «финансы», «клиенты», «бизнес-процессы» и «инфраструктура/персонал», разрабатывают набор индикаторов для мониторинга их достижения и устанавливают целевые значения этих индикаторов. Далее продумывают основные мероприятия, направленные на достижение поставленных целей. Базовый вариант системы BSС представлен в табл. 1. А расширенный включает индикаторы не только для целей, но и для мероприятий, предполагает указание подразделений, участвующих в их реализации, а также бюджеты и сроки их проведения (табл. 2).

Таблица 1. Базовый вариант системы Balanced Scorecard
(компания — интернет-провайдер)

Необходимо помнить, что та или иная цель (например, «обеспечить приток новых клиентов») достигается не только благодаря специальным мероприятиям. Нужно учитывать также влияние мероприятий, отнесенных к другим целям этой же проекции и к целям других проекций (например, «бизнес-процессы» и «инфраструктура/персонал»). В то же время неоднократное упоминание в общем перечне того или иного мероприятия в контексте разных целей нарушает принцип компактности — один из ключевых при построении системы BSC. Поэтому рекомендуется то или иное мероприятие относить к одной цели — к той, достижению которой оно способствует в наибольшей степени.

Таблица 2. Расширенный вариант системы Balanced Scorecard
(компания — производитель строительных конструкций)

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

Существует, однако, и более развернутый вариант BSC, который предполагает построение системы целей, показателей и мероприятий для отдельных структурных подразделений (то есть каскадирование). В результате у каждого структурного подразделения компании (департамента, филиала, отдела и т. д.) появляется своя система BSC («карта»), отражающая ключевые цели этих подразделений, их индикаторы и мероприятия, необходимые для их достижения. «Карта» объясняет персоналу его участие в реализации стратегии компании, помогает руководству оценивать работу каждого сотрудника (подразделения) и служит основой системы мотивации.

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

ПРОЕКЦИИ НА УРОВНЕ СТРУКТУРНЫХ ПОДРАЗДЕЛЕНИЙ

Обычно в системе BSC верхнего уровня представлены четыре проекции: «финансы», «клиенты», «бизнес-процессы» и «инфраструктура/персонал». Общие цели компании, сформулированные в рамках этих проекций, как правило, образуют причинно-следственную цепочку. Логика рассуждений при этом такова, что квалифицированные и мотивированные сотрудники, используя развитую инфраструктуру (оборудование, программное обеспечение, транспортный парк и т. д.), способны обеспечить необходимые компании качество и скорость бизнес-процессов. Отлаженные бизнес-процессы дают преимущество перед конкурентами и способствуют удовлетворенности клиентов. Удовлетворенные клиенты и конкурентные преимущества, в свою очередь, составляют предпосылки достижения финансовых целей (рис. 1).


Рисунок 1.

Как это применить на практике? Цели в «карте» верхнего уровня прописывают начиная с проекции «финансы». В первую очередь компания должна ответить на вопрос: «Сколько мы хотим заработать и сколько собираемся при этом потратить?» Второй вопрос звучит следующим образом: «Что мы должны сделать для своих клиентов, чтобы достичь своих финансовых целей?» Третий касается проекции «бизнес-процессы»: «Как должна быть построена работа компании, чтобы достичь целей в рамках проекций «клиенты» и «финансы»?» И наконец, четвертый вопрос — о том, какие персонал и инфраструктура необходимы компании для достижения целей в рамках трех верхних проекций.

Что касается числа проекций на уровне компании в целом, то на практике оно может варьироваться. Как правило, речь идет о выделении особо значимого для компании аспекта в отдельную проекцию (например, «поставщики», «государство») и добавлении ее к четырем «классическим». Разумеется, при желании отношения компании с поставщиками можно рассмотреть в проекции «Бизнес-процессы», а с государством — в проекции «рынок/клиенты».

Система BSC на уровне структурных подразделений обычно повторяет ее модель на уровне компании в целом. У каждого подразделения обычно есть свои «финансы» (например, бюджет отдела и сумма, отведенная на премии), свои «клиенты» (коллеги), свои «бизнес-процессы» («глобальные» процессы компании в целом, в которых участвует структурное подразделение, и «локальные» процессы, протекающие внутри структурного подразделения), а также свои «инфраструктура/персонал». Таким образом, система BSC превращает структурное подразделение (производственный цех, отдел логистики, финансовый отдел, отдел IT и т. д.) в мини-компанию в составе компании. Каждое структурное подразделение понимает, что квалифицированный персонал и развитая инфраструктура необходимы ей для того, чтобы быстро и качественно выполнять свою работу (проекция «бизнес-процессы»). Отлаженные процессы необходимы структурному подразделению, чтобы успешно взаимодействовать с внутренними клиентами (коллегами из других подразделений или руководством компании). От того, насколько успешным будет это взаимодействие, зависят в том числе и финансовые результаты подразделения (соблюдение бюджета, получение запланированной суммы премии). Другими словами, каждое структурное подразделение компании продает свой продукт (услугу) внутренним (и внешним) клиентам, стремясь максимально удовлетворить их ожидания. Поэтому индекс удовлетворенности внутренних клиентов (балльная оценка коллег) в компаниях, опирающихся на такую логику ведения бизнеса, — стандартный показатель практически во всех подразделениях.

Возможны также модификации «классической» модели BSC для структурных подразделений. Так, например, в системе BSC одного из восточноевропейских заводов крупного автомобилестроительного концерна есть только три проекции: «финансы», «бизнес-процессы» и «инфраструктура/персонал». Проекция «клиенты» выпадает: сам по себе завод клиентов искать не должен, поскольку все заказы приходят к нему из концерна, а взаимодействие со сторонними клиентами в модели ведения бизнеса не предусмотрено. Строго говоря, клиентами этого завода являются другие предприятия концерна, на которые он поставляет свою продукцию (детали автомобилей). Но руководство завода сочло, что отследить аспекты отношений с другими предприятиями в составе концерна можно в рамках проекции «бизнес-процессы». Основные показатели, которые при этом анализировали, — процент брака, число заказов, выполненных вовремя, и число жалоб от внутренних клиентов.

Иногда используются варианты и с большим числом проекций. В «карте» верхнего уровня одной инженерно-строительной компании — регионального дилера крупного мирового производителя строительных конструкций — было выделено шесть проекций: «финансы», «клиенты», «поставщик» (в силу особой значимости для стратегии компании), «бизнес-процессы», «инфраструктура» и «персонал». Каскадирование системы BSC на второй уровень предполагало разработку ключевых целей, показателей и мероприятий, с одной стороны, для реализации проектов компании, а с другой — для структурных подразделений, участвующих в этих проектах (отдела продаж, логистики, конструкторского, строительного и финансового). В «карте» уровня проектов и уровня структурных подразделений проекций тоже было шесть. Другими словами, цель верхнего уровня (например, поддерживание и улучшение отношений с основным поставщиком) была целью компании в целом и каждого сотрудника в отдельности. То же самое касалось обеспечения удовлетворенности внутренних клиентов, соблюдения корпоративных стандартов и достижения целевых значений финансовых результатов.

Как создаются «карты» целей и показателей структурных подразделений?

Построение «карты» целей, индикаторов и мероприятий для структурных подразделений (каскадирование) — наименее проработанная (и в теории, и на практике) часть системы BSC. Это отчасти связано с «детским» возрастом самой концепции и, соответственно, нехваткой опыта. Но существует общий алгоритм каскадирования:

  1. После создания системы стратегических целей и индикаторов верхнего уровня (компания в целом) разрабатывают пакет мероприятий, необходимых для достижения стратегических целей.
  2. Для каждого мероприятия определяют индикаторы, по которым будет оцениваться успешность его реализации, работа участников (в т. ч. ответственных), при необходимости — бюджет и сроки выполнения.
  3. Формируют матрицу, на одной оси которой располагают все мероприятия, а на другой — все структурные подразделения. На основе этой матрицы можно определить:
      a) какие структурные подразделения участвуют в реализации того или иного мероприятия;
      б) в каких мероприятиях участвует то или иное структурное подразделение.

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

  4. Определяют перечень проекций, в рамках которых будут разрабатываться цели, индикаторы и мероприятия структурных подразделений (обычно это «классические» проекции: «финансы», «клиенты», «бизнес-процессы» и «инфраструктура/персонал»).
  5. Каждое структурное подразделение на основе разработанной матрицы мероприятий и своих соображений должно определить, как оно будет содействовать достижению стратегических целей, сформулированных в «карте» компании. Помимо системы целей компании и матрицы мероприятий система BSC основывается на предварительном анализе сильных и слабых сторон этого структурного подразделения. Кроме того, рекомендуют провести внутрифирменный опрос подразделений, чтобы уточнить, какие продукты (услуги) им нужны от других подразделений и какие продукты (услуги) они сами передают другим структурным подразделениям.
  6. Каждое структурное подразделение формулирует свои ключевые цели в проекциях системы BSC, определяет необходимые для их измерения и оценки индикаторы и разрабатывает мероприятия, необходимые для достижения целей (формирование «карты» по принципу «снизу вверх»).
  7. Параллельно на основе той же базовой информации (п. 5) создают варианты «карт» для структурных подразделений по принципу «сверху вниз». Это могут делать вышестоящие руководители, специально созданная централизованная рабочая группа или внешние консультанты (возможны и целесообразны комбинированные варианты).
  8. Вариант «карты» структурного подразделения Х, созданный им самостоятельно («снизу вверх»), сравнивают с вариантом «карты», разработанным для этого подразделения централизованной инстанцией или внешними консультантами («сверху вниз»). Выявленные отличия обсуждают, в результате чего разрабатывают компромиссный вариант (систему целей, индикаторов, целевых значений и мероприятий).
  9. Дополнительно отслеживают связь системы BSC с системой бюджетирования, внутрифирменной отчетности и мотивации персонала.

Очевидно, что в случае привлечения сотрудников к составлению «карт» степень их сопротивления изменениям (нововведениям) будет гораздо ниже. К тому же они, как правило, предлагают множество полезных идей по поводу возможных мероприятий, проектов, инициатив, содействующих достижению стратегических целей компании.

СВЯЗЬ С СИСТЕМАМИ БЮДЖЕТИРОВАНИЯ И УПРАВЛЕНЧЕСКОГО УЧЕТА

Если у структурного подразделения есть своя проекция «финансы», оно рассматривается как центр финансовой ответственности. Конечно, это предполагает наличие в компании систем бюджетирования и управленческого учета, а в идеале — систему трансферного ценообразования. В отчете о прибылях и убытках каждого структурного подразделения (центра финансовой ответственности) будет либо «прибыль» (если внутренняя «выручка» превысила сумму расходов), либо «убыток» (если сумма расходов превысила сумму внутренней «выручки»), либо «0» (если сумма расходов соответствует сумме внутренней «выручки»). Финансовые цели структурных подразделений связаны, как правило, с достижением плановых значений ключевых финансовых показателей. Кроме того, в проекцию «финансы» эти подразделения включают целевое значение премии, которую рассчитывают получить, если уложатся в бюджет и достигнут целевых значений индикаторов по другим проекциям. Например, если будет соответствовать запланированному индекс удовлетворенности внутренних клиентов (проекция «клиенты»), достигнут средний балл по результатам профессионального тестирования, внесено определенное количество рацпредложений («персонал»), соблюдены процент брака, допустимое число нарушений внутренних стандартов («бизнес-процессы»).

ГЛУБИНА КАСКАДИРОВАНИЯ: НУЖНА ЛИ «КАРТА» УБОРЩИЦЕ?

После формирования «карты» стратегических целей, индикаторов и ключевых мероприятий верхнего уровня подобные «карты» создают для основных замов генерального директора — по производству, по маркетингу, по снабжению, по финансам. Разумеется, вторые лица компании обязаны знать и понимать стратегию компании в целом и свой вклад в ее реализацию. Что касается дальнейшего каскадирования (на третий, четвертый и т. д. уровень иерархии), то многие руководители сомневаются в его целесообразности. Один из моих знакомых (директор строительной организации) сказал мне, что слово «стратегия» главный инженер его компании отождествляет с игрой, которая продается в магазине «Детский мир». И не больше. Но, создавая «карту» целей, показателей и мероприятий для своего главного инженера (второй уровень иерархии), директор надеется убедить его в том, что стратегия — это не настольная игра, а фактор выживания бизнеса в условиях обостряющейся конкуренции. В перспективе директор надеется дойти и до прорабов (третий уровень иерархии). Каскадирование на четвертый уровень (каменщики, маляры, подсобники) представляется ему бесполезным занятием. Свою позицию он обосновывает низким уровнем образования и общей культуры этих сотрудников («они вообще таких слов, как стратегия, не знают») и отсутствием лояльности к компании («сегодня они у меня работают, а завтра в другую компанию перебегут»).

Среди других причин отказа от «глубокого» каскадирования называют стремление сохранить конфиденциальность («знакомить всех сотрудников компании со стратегией — это лить воду на мельницу конкурентов») и сэкономить время и ресурсы, затрачиваемые на составление подобных «карт» для структурных подразделений. Первый довод критики не выдерживает: если стратегию не знают те, кто должен ее реализовывать, она не будет реализована. Что касается второго, то мнений на этот счет много. Повлиять может, например, то, к какому типу менеджеров относятся управленцы компании — к тем, которые всегда спрашивают: «А сколько это будет нам стоить?», или к тем, кто интересуется: «А что это нам принесет?» Проблема в том, что сумму «знаменателя» (затраты на проект) более-менее точно оценить можно, а сумму «числителя» (эффект от внедрения проекта в стоимостной форме) — нет. Можно говорить только о повышении управляемости компании, об уменьшении числа конфликтов, о том, что руководитель после внедрения системы Balanced Scorecard вместо 20 минут на обеденный перерыв стал позволять себе целых 40…

Можно по-разному относиться к тому, что в компании Hewlett Packard все 140 тысяч сотрудников имеют свои «карты» ключевых целей, показателей и мероприятий. Кто-то скажет, что денег куры не клюют, вот и играются в управленческие игрушки, а кто-то — что очень доволен своим «эйчпишным» ноутбуком, и, скорее всего, в этом есть заслуга и системы BSC. Согласно исследованиям, проведенным в 2004 году компанией Horvath & Partners в немецкоязычной бизнес-среде (Германии, Австрии, Швейцарии), 75% опрошенных компаний располагают «картой» верхнего уровня, 44% — создали такие «карты» для функциональных подразделений второго уровня, а 10% «откаскадировали» идею вплоть до каждого сотрудника.

Разумеется, система BSC для всей компании не создается за одну ночь. Разработанные «карты» второго уровня какое-то время «шлифуют» и дорабатывают, поскольку на первом этапе практически невозможно учесть все нюансы, связанные с участием в реализации стратегии того или иного структурного подразделения. Только после этого начинается каскадирование на третий и последующие уровни организационной иерархии. Однако перерыв между каскадированием на второй и последующие уровни не должен быть слишком большим, чтобы у сотрудников, участвующих в построении системы BSC, не пропал энтузиазм. В общем, с одной стороны, спешить нужно медленно, а с другой — железо нужно ковать, пока оно горячо.

«КАРТЫ» ДЛЯ СТРУКТУРНЫХ ПОДРАЗДЕЛЕНИЙ

При формулировке стратегических целей компании обычно следуют принципу, предложенному Р. Капланом: Twenty is Plenty («Двадцать — достаточно»). Иными словами, ключевых целей в «карте» компании должно быть не больше двадцати (таково обозримое число ключевых аспектов деятельности). При составлении «карт» для структурных подразделений рекомендуют придерживаться этого же принципа: например, у главного логистика, директора по маркетингу, финансового директора тоже должно быть приблизительно по 20 целей.

Поскольку одна цель может измеряться и описываться не одним, а несколькими индикаторами, то индикаторов в «карте» может быть 40, 60 и даже больше. Их полный перечень необходим менеджеру структурного подразделения для всесторонней оценки своей «вотчины», но оценивать его работу по всем этим показателям вряд ли целесообразно. Во-первых, некоторые показатели просто информируют о состоянии той или иной организационной единицы, но не связаны напрямую с эффективностью деятельности сотрудников этой единицы. Например, степень изношенности недавно приобретенных в распилочный участок пилорам (бывших в употреблении другой компании) может интересовать генерального директора (проекция «инфраструктура»), но вряд ли ее можно использовать для оценки результатов деятельности этого структурного подразделения (в отличие, скажем, от процента брака, числа внутренних рекламаций или объема заказов, выполненных вовремя).

Во-вторых, слишком большое число показателей затрудняет восприятие информации. Здесь уместно вспомнить известный принцип Парето и предположить, что рассмотрение 20% показателей позволяет на 80% оценить успешность той или иной организационной единицы. Другими словами, из перечня показателей того или иного подразделения рекомендуется отобрать ключевые, а остальные считать дополнительными. Ключевые показатели структурного подразделения с определенной периодичностью просматривает вышестоящее руководство, а полный их перечень (вместе с дополнительными) необходим сотрудникам этого подразделения, чтобы своевременно и качественно выполнять свои задачи (в пределах установленных бюджетов).

Так, например, в систему BSC вышеупомянутой инженерно-строительной компании включены 17 стратегических целей и 41 показатель. Из этого списка руководство компании отобрало 9 ключевых, используемых для оперативного мониторинга работы отдела:

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

В расширенный перечень показателей (предполагающий менее частый мониторинг значений со стороны руководства или содержащий показатели, предназначенные для использования внутри отдела) внесены следующие величины:

  • сумма закупок;
  • объем просроченной кредиторской задолженности;
  • фиксированная часть заработной платы сотрудников отдела;
  • переменная часть заработной платы;
  • балльная оценка работы сотрудников отдела коллегами;
  • процент соответствия квалификации сотрудников целевому набору компетенций;
  • общий индекс удовлетворенности персонала и др.

СВЯЗЬ «КАРТЫ» С СИСТЕМОЙ МОТИВАЦИИ

Прямая зависимость величины заработной платы от достижения целевых показателей — вопрос сложный. Важно понимать, что 2-процентное отклонение от целевого значения показателя X с точки зрения компании в целом может быть более проблемным, чем 10-процентное отклонение по показателю Y. Поэтому, отвечая на вопрос о связи «карты» целей и показателей с системой мотивации, часто используют систему весов, присваивая определенный уровень значимости каждому показателю. Важно также не допустить в компании ситуации, сложившейся на одном из кораблей: капитан премировал матросов за каждую пойманную крысу. Созданная им система мотивации привела к тому, что матросы стали активно разводить крыс с целью максимизации выручки от их реализации…

При построении системы мотивации в рамках BSC часто приходится решать следующую дилемму. С одной стороны, система мотивации должна, по возможности, учитывать достижение всего спектра целей (в противном случае сотрудники могут концентрироваться исключительно на целях, к которым эта система привязана, и оставлять без внимания прочие цели), а с другой — она должна быть простой и понятной (а значит, предполагать учет ограниченного числа показателей). В качестве компромиссного варианта можно предложить «завязывание» ежемесячной суммы заработной платы сотрудника на 3-5 ключевых показателях, а периодические выплаты (квартальные, полугодовые, годовые, в связи с завершением проекта) могут зависеть и от большего числа показателей.

Кроме того, приходится учитывать специфику уровня организационной иерархии и характер выполняемой работы. К примеру, работа главного маркетолога считается творческой. Он, условно говоря, может неделями не появляться в офисе и раз в квартал выдавать на-гора очередную гениальную идею, которая повышает конкурентоспособность компании. Для таких сотрудников многие компании используют очень простую систему мотивации — большой оклад (плюс премии за идеи) или увольнение. А система мотивации сотрудников, к примеру, распилочного участка может быть более сложной: включать фиксированную сумму оклада, премии за достижение целевых значений определенных показателей (например, количество рацпредложений, выработку на число сотрудников, стоимость заказов, выполненных вовремя, процент экономии бюджета) и штрафы за отклонения по другим показателям (например, по проценту брака, объему отходов, стоимости внепланового ремонта оборудования по вине отдела, числу внутренних рекламаций).

Есть системы мотивации, основанные на принципе кнута и пряника (и штрафы, и премии), а также отказывающиеся от «кнута» (только «пряник») или от «пряника» (только «кнут»). Каждая из них может оказаться самой подходящей в определенных ситуациях и основываться на системе целей и показателей BSC. Интересен также вариант трехуровневой системы мотивации, учитывающий достижения конкретного сотрудника (1-й уровень), его отдела (2-й уровень) и компании в целом (3-й уровень).

НАСКОЛЬКО ПОХОЖИ СИСТЕМЫ BSC АНАЛОГИЧНЫХ СТРУКТУРНЫХ ПОДРАЗДЕЛЕНИЙ РАЗНЫХ КОМПАНИЙ?

Существуют ли стандартные системы целей, показателей и мероприятий для отдела логистики, финансового, отдела IT, маркетинга и т. д.? Идентична ли система BSC водителя, работающего в бизнес-школе, и водителя, занятого в телекоммуникационной компании?

Чтобы ответить на эти вопросы, надо вспомнить, для чего компании используют систему BSC. Ее основная цель — доведение стратегии до ведома сотрудников компании. А стратегия всегда связана с уникальностью. Именно на четком понимании уникальности своего предложения, адресованного клиентам, строятся успешные стратегии.

А раз стратегия уникальна, то уникальной будет и система стратегических целей, показателей и мероприятий верхнего уровня. Соответственно, будут уникальными и системы целей, показателей и мероприятий структурных подразделений. Разумеется, нельзя говорить о том, что системы BSC водителей, работающих в бизнес-школе и в телекоммуникационной компании, будут кардинально отличаться. Их «карты» частично похожи, а частично — нет. Например, водителю, работающему в бизнес-школе, необходимо базовое знание английского языка, поскольку ему часто приходится ездить в аэропорт, чтобы встретить иностранных партнеров. А водитель телекоммуникационной компании обязан содержать в идеальной чистоте автомобиль, раскрашенный в фирменные цвета, поскольку это — часть маркетинговой стратегии компании.

Каскадирование призвано обеспечить практическую реализацию знаменитого принципа, изложенного идеологом системы BSC: «Make Strategy everyone"s everyday job» («Сделать стратегию каждодневным делом каждого сотрудника»). Стратегия компании будет жизнеспособной только в том случае, если каждый ее сотрудник (включая уборщицу и водителя) будет четко представлять, какой именно вклад он вносит в ее реализацию и как зависит от этого его заработная плата. Именно этой цели служит простой и гениальный управленческий инструмент — система Balanced Scorecard.

    Владислав Толкач , директор академии контроллинга бизнес-школы "Галактика", руководитель департамента контроллинга Института приватизации и менеджмента.

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

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

Одним из таких инструментов реализации стратегии служит широко известная Сбалансированная система показателей (Balanced Scorecard), разработанная профессорами Р. Капланом и Д. Нортоном. Данная система позволяет руководителям переводить стратегические цели компании в четкий план оперативной деятельности подразделений и ключевых сотрудников, а также оценивать результаты их деятельности с точки зрения реализации стратегии с помощью ключевых показателей эффективности. Другой не менее известный инструмент, - система Управления по целям (Management by objective), которая была предложена Питером Друкером в 50-е годы. Суть такого управления сводится к декомпозиции бизнес-целей каждому сотруднику операционного уровня. Декомпозиция - это процесс каскадирования (разложения) стратегии, целей компании для каждого уровня организации от самого высокого до самого низкого. Процесс каскадирования, предполагает последовательную передачу каждому подразделению компании, сформированного дерева стратегических целей и мероприятий (в горизонтальном и вертикальном направлении). Результатом являются созданные «карты целей» как для отдельных структурных подразделений компании, так и для должностей (вертикальная интеграция). А также процесс согласования данных «карт целей» и мероприятий между подразделениями одного уровня иерархии (горизонтальная интеграция). За основу каскадирования берется организационная структура компании.

Проект построения и внедрения системы целевого управления включает в себя несколько этапов:

1. Формирование дерева стратегических целей.

Стратегические цели в том или ином варианте имеет каждая компания. Необходимым условием является их четкая формализация и отсутствие противоречий. Лучшим способом определения корпоративных целей является формулировка их по направлениям деятельности, которые необходимы для реализации стратегии. В этом случае хорошо использовать предложенную Д. Нортоном и Р. Капланом схему по 4-м составляющим: «Финансы», «Клиенты и маркетинг», «Бизнес-процессы», «Персонал и системы». Ответ на вопросы по каждой перспективе позволяет сформулировать цели и соответствующие им мероприятия и показатели.

Так, например, при формировании стратегической карты в компании Тойота Центр («Алмаз Мотор», «Алмаз Систем») , командой топ – менеджеров и линейных руководителей было выделено порядка 20 целей по перспективам:

  • Финансы: Увеличить прибыль предриятия на N%
  • Клиенты и маркетинг : Обеспечить удевлетворенность клиентов на уровне N% и выше среднего по диллерской сети
  • Бизнес-процессы : Обеспечить производительность труда на уровне коэффициента N
  • Персонал и системы : Сформировать кадровый резерв на руководящие позиции

2. Каскадирование стратегических целей.

После формирования дерева стратегических целей – «ЧТО», необходимо дальнейшее уточнение задач и мероприятий, которые направлены на достижение заданных целей – «КАК», а также определяются подразделения, участвующие в их реализации – «КТО»

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

Цели подразделений, формируются из целей более высокого порядка путем:

а) включения в свою карту целей вышестоящего подразделения, если подразделение следующего уровня влияет на выполнение данной цели (например, «Выполнить план по продаже Х штук автомобилей в автосалоне» является составной частью цели «Выполнить план по продаже Y штук автомобилей в регионе»);

б) дублирования целей вышестоящего подразделения, но со своими целевыми значениями (например, «Увеличить активную базу клиентов на 20 % по отношению к прошлому году», «… на 10 %»);

в) определения новой цели, которая связанна со стратегической, и влияет непосредственно или косвенно на ее реализацию (например, «Обеспечить уровень удовлетворенности клиентов на уровне +5% от среднего по сети», транслируется в цель «Соблюдать стандарты, установленные на предприятии»);

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

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

Например, один из основополагающих принципов Lexus «стремление к совершенству» проявляется, как в производстве качественного автомобиля, так и в обслуживании клиентов. Для того чтобы реализовать стратегическую цель - «повышение удовлетворенности клиентов», отдел продаж должен обеспечить высокое качество обслуживания, подчеркнуть все преимущества, которые клиент получит от владения автомобилем, а отдел сервиса должен обеспечить высокое качество послепродажного обслуживания, предложить оперативное и выгодное решение вопросов. Однако все эти цели возможны только в том случае, если руководитель сможет создать команду профессионалов. И этот процесс включает все стадии, от подбора правильных людей до организации непрерывного обучения и развития. Особое значение имеет управление эффективностью: постановка целей, оценка и обратная связь

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

Микросервисная архитектура использует сервис в качестве единицы модульности. Каждый сервис - это отдельный бизнес-процесс или бизнес-объект, который что-то делает для получения конкретного результата. Например, интернет-магазин, используя эту архитектуру, мог бы состоять из таких микросервисов, как Сервис Заказов (Order Service), Сервис Клиентов (Customer Service), Каталог товаров (Catalog Service) и т.д.

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

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

Проблема № 1: Разделение модели предметной области

Паттерн «модель предметной области» (Domain model) является хорошим способом реализации сложной бизнес-логики. Модель предметной области для интернет-магазина будет включать в себя такие классы, как Заказ , Позиция заказа , Клиент , Товар . В микросервисной архитектуре классы Заказ и Позиция заказа являются частью сервиса Заказ , класс Клиент является частью сервиса Клиент , а класс Товар принадлежит сервису Каталог .

Проблемой в разделении модели предметной области на сервисы является то, что классы часто ссылаются друг на друга. Например, Заказ ссылается на Клиента , который его сделал, а Позиции заказа ссылаются на Товары . Что же делать со ссылками, нарушающими границы сервисов? Позже мы увидим, как понятие агрегата (Aggregate) из DDD (Domain Driven Design) решает эту проблему.

Микросервисы и базы данных

Отличительной особенностью микросервисной архитектуры является то, что данные, принадлежащие сервису, доступны только через API этого сервиса. Например, в интернет-магазине Сервис Заказов имеет базу данных, которая включает в себя таблицу ORDERS, а Сервис Клиентов имеет свою базу данных, которая включает в себя таблицу CUSTOMERS. Из-за такой инкапсуляции сервисы слабо связаны, и разработчик может изменить схему своего сервиса без необходимости координировать свои действия с разработчиками, работающими над другими сервисами. Во время выполнения приложения сервисы изолированы друг от друга. Например, сервис никогда не будет ожидать окончания блокировки базы данных, принадлежащей другому сервису. С другой стороны, функциональное разделение базы данных затрудняет поддержание целостности данных, а также реализацию многих типов запросов.

Проблема № 2: Транзакции

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

BEGIN TRANSACTION … SELECT ORDER_TOTAL FROM ORDERS WHERE CUSTOMER_ID = ? … SELECT CREDIT_LIMIT FROM CUSTOMERS WHERE CUSTOMER_ID = ? … INSERT INTO ORDERS … … COMMIT TRANSACTION
К сожалению, мы не можем использовать такой простой подход для поддержания согласованности данных при микросервис-ориентированном подходе. Таблицы ORDERS и CUSTOMERS принадлежат различным сервисам и могут быть доступны только через API. Они даже могут находиться в различных базах данных.

В данном случае традиционным решением будут распределенные транзакции , но для современных приложений это неподходящая технология. Теорема CAP требует от разработчика сделать выбор между доступностью (Availability) и согласованностью данных (Consistency), и доступность, как правило, является предпочтительным выбором. Кроме того, многие современные технологии, такие как большинство NoSQL-баз данных, не поддерживают даже обычные транзакции, не говоря уже о распределенных. Важное значение имеет и поддержание целостности, так что нам нужно другое решение. Ниже мы увидим, что решением является использование cобытийно-ориентированной (Event-driven, message-driven) архитектуры, основанной на Event Sourcing.

Проблема № 3: Запросы к базе данных

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

SELECT * FROM CUSTOMER c, ORDER o WHERE c.id = o.ID AND o.ORDER_TOTAL > 100000 AND o.STATE = "SHIPPED" AND c.CREATION_DATE > ?
Мы не можем использовать этот вид запроса в микросервис-ориентированном интернет-магазине. Как уже упоминалось ранее, таблицы ORDERS и CUSTOMERS принадлежат различным сервисам и могут быть доступны только через API. Некоторые сервисы могут даже не использовать SQL-базу. Но можно использовать подход, известный как Event Sourcing, что делает поиск информации еще более сложной задачей.

Дальше мы увидим, что решением является сохранение материализованных представлений с помощью подхода, известного как Command Query Responsibility Segregation (CQRS). Но сначала, давайте рассмотрим вопрос Domain-Driven Design (DDD) при разработке микросервисов.

DDD-агрегаты как строительные блоки микросервисов

Как видите, есть несколько проблем, которые необходимо решить ради успешной разработки приложений с использованием микросервисов. Решение некоторых из этих проблем может быть найдено в обязательной для прочтения книге Эрика Эванса “Domain-Driven Design ”. В ней описывается подход к проектированию сложного программного обеспечения, что очень полезно при разработке микросервисов. В частности, Domain-Driven Design позволяет создавать модульную модель предметной области, которая может быть распределена по сервисам.

Что такое агрегаты?

В Domain-Driven Design Эванс определяет несколько строительных блоков для моделей предметной области. Многие из них стали частью повседневного языка разработчиков, включая Entity, Value object, Service, Repository и т.д. Однако, один строительный блок - агрегат - был, в основном, проигнорирован разработчиками, за исключением DDD-пуристов. Но оказывается, что агрегаты являются ключом к разработке микросервисов.

Агрегат представляет собой кластер объектов предметной области, которые можно рассматривать как единое целое. Он состоит из корневого объекта-сущности (Entity) и, возможно, одного и более других связанных с ними объектов-сущностей и объектов-значений (Value Object). Например, модель предметной области для интернет-магазина содержит такие агрегаты, как Заказ и Клиент . Агрегат Заказ состоит из корневой сущности Заказ , одного или нескольких объектов-значений Позиция заказа наряду с другими объектами-значениями, такими как Стоимость , Адрес доставки и Платежные реквизиты . Агрегат Клиент состоит из сущности Клиент и нескольких объектов-значений, таких как Информация о доставке и Информация о платеже .

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

Межагрегатные связи должны использовать первичные ключи

Первое правило заключается в том, что агрегаты всегда ссылаются друг на друга через уникальный идентификатор (например, первичный ключ) вместо прямых ссылок на объекты. Например, Заказ ссылается на своего Клиента , используя CustomerId, а не ссылку на объект клиента. Аналогичным образом, Позиция заказа ссылается на Товар , используя ProductID.

Такой подход сильно отличается от традиционного, при котором внешние ключи в модели предметной области считаются плохой практикой. Использование идентификатора, а не ссылки на объект, означает, что агрегаты слабо связаны. Вы можете легко разместить различные агрегаты в различных сервисах. На самом деле, бизнес-логика сервиса состоит из модели предметной области, которая представляет собой набор агрегатов. Например, OrderService содержит агрегат Заказ , а CustomerService содержит агрегат Клиент .

Одна транзакция создает или обновляет один агрегат

Второе правило заключается в том, что транзакция может создать или обновить только один агрегат. Когда я впервые прочитал об этом правиле много лет назад, это не имело никакого смысла! В то время я разрабатывал традиционные монолитные приложения на основе РСУБД, и поэтому транзакции могли обновлять произвольные данные. Сегодня же это ограничение идеально подходит для микросервисной архитектуры. Это гарантирует, что транзакция содержится внутри сервиса. Это ограничение также соответствует ограничениям транзакций большинства NoSQL-баз данных.

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

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

Например, выше сказано, что в модели предметной области интернет-магазина Заказ и Клиент - это отдельные агрегаты. Альтернативой является сделать Заказ частью агрегата Клиент . Преимуществом большого агрегата Клиент является то, что приложение сможет атомарно обеспечивать проверку кредитного лимита. Недостаток подхода в том, что он сочетает в себе функциональность Заказа и Клиента в одном и том же сервисе. Это снижает масштабируемость, так как транзакции, обновляющие разные заказы одного и того же клиента, не смогут выполняться параллельно. Кроме того, два пользователя могут вступить в конфликт, если они попытаются редактировать различные заказы одного клиента. С увеличением количества заказов загрузка агрегата Клиент будет становиться всё более дорогой. Из-за этих проблем лучше делать агрегаты настолько маленькими, насколько это возможно.

Даже соблюдая требование по созданию или обновлению транзакцией только одного агрегата, приложения по-прежнему должны поддерживать согласованность между агрегатами. Например, сервис Заказ должен проверить, что новый агрегат Заказ не превысит совокупный кредитный лимит клиента. Есть несколько различных способов поддержания согласованности. Одним из вариантов является обман приложения и создание/обновление нескольких агрегатов в одной транзакции. Это возможно только тогда, когда все агрегаты принадлежат одному и тому же сервису и сохраняются в одной и той же РСУБД. Другой, более правильный вариант заключается в поддержании согласованности между агрегатами с использованием событийно-ориентированного подхода.

Использование событий для поддержания согласованности данных

В современном приложении есть различные ограничения по транзакциям, которые делают его сложным для поддержания согласованности данных в сервисах. Каждый сервис имеет свои собственные данные, но использование распределенных транзакций не является жизнеспособным вариантом. Кроме того, многие приложения используют NoSQL-базы, которые не поддерживают даже обычные локальные транзакции, не говоря уже о распределенных. Следовательно, современное приложение должно использовать управляемую событиями модель транзакции, известную как «согласованность в конечном счете» (Eventually Consistent).

Что такое событие (Event)?

Как гласит словарь Merriam-Webster (и Капитан Очевидность), «событие» - это то, что происходит (случается):

В этой статье мы определяем событие предметной области (Domain Event) как то, что произошло с агрегатом. Событие обычно представляет собой изменение состояния. Рассмотрим, например, агрегат Заказ . События, изменяющие его состояние, включают в себя Заказ создан , Заказ отменен , Заказ отправлен . События могут представлять собой попытки нарушить бизнес-правила, например, кредитный лимит Клиента .

Использование событийно-ориентированной (Event-Driven) архитектуры

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

Интернет-магазин проверяет кредитный лимит клиента при создании заказа, используя следующую последовательность шагов:

  1. Агрегат Заказ , который создается со статусом NEW, публикует событие OrderCreated.
  2. Агрегат Клиент получает уведомление о событии OrderCreated, резервирует кредит для заказа и публикует событие CreditReserved.
  3. Агрегат Заказ получает уведомление о событии CreditReserved и меняет свой статус на УТВЕРЖДЕН.
Если кредитная проверка терпит неудачу из-за нехватки средств, агрегат Клиент публикует событие CreditLimitExceeded. Это событие не отражает изменения состояния, а представляет собой неудачную попытку нарушить бизнес-правила. Агрегат Заказ получает уведомление об этом событии и меняет свое состояние на ОТМЕНЕН.

Микросервисная архитектура как сеть событийно-управляемых агрегатов

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

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

Резюме

Микросервисная архитектура функционально разделяет приложение на сервисы, каждый из которых соответствует определенному бизнес-объекту или бизнес-процессу. Одной из основных проблем при разработке микросервисных бизнес-приложений является то, что транзакции, модели предметной области и запросы противостоят разделению на сервисы. Вы можете разделить модель предметной области, применяя концепцию «агрегата» из Domain Driven Design. Бизнес-логика каждого сервиса представляет собой модель предметной области, состоящую из одного или нескольких агрегатов DDD.

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

Во второй части статьи мы рассмотрим, как реализовать надежную архитектуру, управляемую событиями с помощью Event Sourcing, а также как реализовать запросы в микросервисной архитектуре с помощью CQRS.