Метод каскадирования целей. Процесс разработки ссп для каждого уровня организации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как уже было отмечено каскадирование на нижестоящие организационные единицы служит для обеспечения реализации стратегии на всем предприятии.

Каскадирование ССП осуществляется по двум направлениям:

Горизонтально - вовлечение других подразделений предприятия одного уровня иерархии
Вертикально - вовлечение других уровней руководства

На этапе каскадирования достигаются следующие цели:

Разработка сбалансированных целей для нижестоящих подразделений
Отражение вклада отдельных подразделений в реализацию стратегии
Делегирование задачи и ответственности
Понимание и согласие сотрудников с целями компании и отделов
Поощрение самостоятельной деятельности сотрудников и ответственности в реализации стратегии
Фокусирование внутренних процессов на стратегически важных целях
Ориентация на действия за счет стратегического управления ресурсами

Для каскадирования необходимо:

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

Определение структуры

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

Определение методов

Для каскадирования в различных ситуациях используются различные методы.

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

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

Для первого метода - компания определяет для себя ССП, а нижестоящая бизнес единица (подразделение) формулирует для себя самостоятельную стратегию и ССП.

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

Метод 1.
Самостоятельное формулирование стратегии и целей (с учетом стратегических рамок деятельности и конкретных задач со стороны вышестоящего подразделения).

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

Возможные ситуации:

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

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

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

Метод 2.

Прямое определение целей на основе целей верхнего уровня.

Из ССП переносятся цели, которые могут быть поддержаны рассматриваемым подразделением. Метод прямого переноса целей предусматривает индивидуальную разработку только по темам, которые доводятся «сверху». Цели конкретизируются посредством опросов и преобразуются в перспективы.

Метод 3 .

Стандартная ССП с адаптацией целевых показателей и/или стратегических мероприятий.

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

Метод 4.

Комбинирование стандартных и индивидуальных целей.

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

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

Метод 5.

Прямое определение стратегических мероприятий

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

Метод 6.

Открытая коммуникация

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

Данный метод позволяет подразделению следовать духу ССП и ориентироваться на стратегию.

Каскадирование в подразделениях центрального офиса и служб общекорпоративного значения

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

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

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

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

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

«…Конечно, можно платить и от продаж. Но лучше платить людям за то, что они делают на самом деле».

Территориальный менеджер крупной табачной компании.

KPI и каскадирование целей.

Показатели, на которых основывается стимулирование труда его переменной оплатой, обычно называют KPI — Key Performance Indicator — ключевые индикаторы производительности [труда]. Методика KPI вызывает у применяющих ее руководителей одно серьезное затруднение: где взять эти самые KPI. Разумеется, существуют целые библиотеки KPI. Однако использование готовых решений редко приводит к искомому результату: желательно, чтобы этот инструмент был создан и приспособлен под конкретику предприятия, подразделения, должности и, в некоторых случаях, — даже под отдельного сотрудника.

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

Первый принцип каскадирования заключается в том, что все процессы на предприятии должны служить достижению заданной конечной цели или группе целей. Формирование таких целей — вопрос стратегии компании и выходит за тематические рамки этой книги. Можно отметить, что с точки зрения продаж и их прогнозирования цели компании нужно связать с маркетинговой стратегией, со стадией жизни, положением в матрице BCG и прочими ориентирующими рамками.

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

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

Бренд-менеджер: «…Наша задача — увеличить за год продажи марки «ААА» с 10 000 до 15 000 ед. От 1000 до 2000 ед. мы добавим за счет увеличения частоты покупок существующей аудитории, около 1000 покупателей мы намерены отобрать у субститута «БББ», остальных — у субститута «ВВВ». Подробности и финансовые границы — в годовом маркетинговом плане. Как отдел продаж будет обеспечивать удовлетворение этого дополнительного спроса?»

Нач. отдела продаж: «…Исходя из имеющегося прогноза спроса, детализованного по времени и территориям, мы должны обеспечить улучшение дистрибуции в городах Г-1 и Г-2 на период маркетинговых активностей: нумерической — до 90% POS с OOS не выше 30%; качественной — 100%-й фейсинг в группах POS р-1 и р-2; размещение POSM в точках... Это может привести к временному росту возвратов с …% до …%; бюджет трейд-маркетинга составит до … д.е.».

Итак, в рамках концепции каскадирования цели устанавливаются сверху вниз, на каждом уровне управления дробясь на подцели, соответствующие ресурсам объекта управления и его месту в бизнес-процессе. Цели конкретного сотрудника и являются его индикаторами деятельности (KPI).

Технология каскадирования целей

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

Рис. 1

Логику декомпозиции диктует, разумеется, конкретный бизнес-процесс. В нашем случае, когда речь идет о маркетинге и управлении продажами, самыми традиционными подходами для декомпозиции целей являются маркетинг-микс «4Р», концепция push-pull и комбинация количественной и качественной дистрибуции. На рис. 2 отображен этот подход как фрагмент графа декомпозиции целей.

Рис. 2

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

собственно нумерическая дистрибуция (доля точек, куда осуществляются поставки, в общем количестве точек);
out-of-stock (OOS — доля точек, в которых товар закончился на определенный момент, в общем количестве точек, в которые он поставлялся).

Качественную дистрибуцию или все, что называют «мерчандайзинг» так:

место товара на витрине, полке;
качество экспозиции;
размещение POS-материалов и т.п.

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

S — Specific: конкретная (ясная, определенная);
M — Measurable: измеряемая;
A — Attainable: достижимая;
R — Relevant: релевантная (соответствующая целям верхнего уровня);
T — Timed: спланированная во времени.

Конечно, доход от продаж — не единственная цель компании. Каскадирование всей совокупности целей позволит обнаружить на каждом уровне иерархии, для каждого структурного подразделения и сотрудника то, как эти цели взаимодействуют, где они взаимодополняют друг друга, а где вступают в конфликт за ресурсы. Гармонизировать такую систему целеполагания позволяет подход под названием BSC (Balanced Scorecard) – сбалансированная система показателей, или ССП.

BSC. Комплексные цели.

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

финансовые показатели;
показатели отношений с клиентами;
внутренние бизнес-процессы;
развитие персонала.

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

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

производство (создание стоимости);
администрирование (организация порядка);
предпринимательство (поиск выгод);
интеграция (лидерство).

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

Таким образом, у менеджера по работе с клиентами кроме задачи распределения поставок могут появиться, к примеру, такие задачи на 1 квартал планового года:

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

А система целей каждого подразделения и сотрудника обретет «трехмерность» со следующими связями каждой цели:

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

Рис. 3

На рис. 3 показана «трехмерная» матрица целей с т.з. отдельного сотрудника. Такая всеобъемлющая система целеполагания не только может смутить своей сложностью, но и действительно способна распылить ресурсы компании, в том числе один из ценнейших — сосредоточенное внимание менеджмента. Поэтому необходимой составляющей такой системы управления является технология определения приоритетов.

TOC. Определение приоритетов.

Ресурсов никогда не бывает в избытке. Менеджеру постоянно приходится принимать решения о том, на что эффективнее использовать время, деньги, материалы, интеллект. «Принцип Парето утверждает, что 20% факторов обеспечивают 80% результата. Теория ограничений говорит, что соотношение на самом деле 1% к 99%» — утверждает Одед Коуэн, Международный Директор Goldratt Schools.

Предлагаемый TOC (Theory of Constraints — Теория Ограничений Э.Голдратта) подход позволяет обнаружить в бизнес-процессе и структуре участки, наибольшим образом препятствующие достижению поставленных целей, и сфокусировать ресурсы и управленческое внимание именно на них. Вот как описывает алгоритм устранения ограничений системы Одед Коуэн:

Шаг 1. Найти ограничения системы.
Шаг 2. Решить, как максимально использовать ограничения системы («выжать» из него все возможное).
Шаг 3. Подчинить все остальные элементы системы принятому решению.
Первые три шага известны как «наведение порядка в доме». Они позволяют менеджеру обеспечить контроль над системой и повысить ее надежность и предсказуемость. Когда система приведена в стабильное состояние, она готова для сфокусированных инвестиций в те области, которые принесут максимальную отдачу, то есть, для следующего шага:
Шаг 4. Расширить (расшить) ограничение системы. Это означает снять напряжение, вызываемое ограничением, путем добавления мощности (в случае ограничения мощности), получением дополнительных клиентских заказов (в случае ограничения рынка) и сокращением времени выполнения заказов и проектов (в случае ограничения времени выполнения).
Шаг 5. Если на предыдущем шаге ограничение устранено, вернуться к шагу 1.

Еще одна цитата:

Узкими местами в деятельности предприятия могут быть не только звенья производства, но и управленческие принципы, методики и процедуры (например, сдельная оплата труда на всех участках). Примером узкого места в управлении могут быть не соответствующие текущим нуждам предприятия процедуры прогнозирования и планирования.
Маргарита Черненко. ТОС: в поисках слабого звена.

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

Если увеличить поставки необходимого сырья и материалов, сможет ли компания произвести и продать (при прочих равных) соответственно больший объем продукции? Ответ «да» означает, что проблема в снабжении.
Может быть, проблема в объеме производства? Вырастет ли выручка, если увеличить объем производства? Не будет ли проблем с сырьем и продажами при таком росте?
Или самая большая проблема — не снабжение и производство, а продажи? Если продажи начнут расти, справится ли компания со снабжением и производством?

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

спрос у конечного потребителя?
ширина дистрибуции?
распределение поставок?
мерчандайзинг?

Важно рассматривать «узкие места» через призму соотношения дополнительных доходов и дополнительных издержек. В этом случае мы сконцентрируемся на участках, «расширение» которых будет приносить наибольшую дополнительную прибыль (если таковы интересы компании, конечно).

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

Кайдзен

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

Муда — «потери» — все то, что затрачивает ресурсы, но не добавляет при этом ценности. Кайдзен выделяет семь видов муда:

1. Дефекты и брак (продукция, требующая проверки, сортировки, утилизации, понижения сортности, замены или ремонта).

2. Ожидание (перерывы в работе, связанные с ожиданием людей, материалов, оборудования или информации).

3. Избыточная обработка (усилие, не добавляющее с точки зрения потребителя к изделию/услуге ценности).

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

5. Перепроизводство (производство изделий, которые никому не нужны; производство продукции в большем объеме раньше или быстрее, чем это требуется на следующем этапе процесса).

6. Запасы (любое избыточное поступление продукции в производственный процесс, будь то сырье, полуфабрикат или готовый продукт).

7. Транспортировка (транспортировка частей или материалов внутри предприятия).

Мура — «неравномерность» — нестабильность в методах работы или в нагрузке процесса.

Мури — «перегрузка» — напряжение (сверхурочная, сверхнапряженная работа) человека или оборудования.

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

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

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

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

С этой точки зрения KPI могут быть разделены на три типа:

1. «Авральные», связанные с ликвидацией узких мест путем экстренных изменений.

2. Оптимизирующие, связанные со снижением непродуктивных издержек.

3. Стабилизирующие, обеспечивающие поддержание нормального режима работы.

Первый и второй типы применяют в узких местах процесса, второй и третий — в остальных.

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

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

Резюме

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

Итак, вот короткое резюме алгоритма, описанного в этой главе, «внедренное» в цикл менеджмента:

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

2. Планирование. Определение способов устранения ограничений. Расстановка приоритетов.

3. Руководство . Каскадирование целей. Фиксация KPI, их связи с взысканиями и вознаграждениями.

4. Подведение итога . Контроль, оценка, взыскания и вознаграждения.

Давайте посмотрим, как может выглядеть карта целей для территориального менеджера:

Препятствие росту, приоритет №1: ширина дистрибуции марки «С» вдвое ниже целевой. Оцениваемые потери компании — 1,2-1,5 млн. д.е. в год.

Источник потерь, приоритет №2: до 1/3 расходных накладных возвращается в бухгалтерию после дедлайнов. Оцениваемые налоговые риски и внутренние потери компании — до 300 тыс. д.е. в год.

Источник потерь, приоритет №3: удельные издержки на мерчандайзинг на территории на 40% выше, чем в среднем по стране; совокупное превышение — до 150 тыс. д.е. в год.

Все цели и показатели на период:

группа		описание
Финансовые	Авральный	довести ширину дистрибуции марки «С» до 70% совокупно на территории, в т.ч. в городе Х — до 90%, в городе Y — до 80%
Процессные	Оптимизирующие	довести возврат оформленных расходных накладных в бухгалтерию в установленные сроки до 90%
Финансовые	Оптимизирующие	снизить удельные расходы на мерчандайзинг на 25%
Финансовые	Стабилизирующий	Удерживать среднюю длительность дебиторской задолженности не выше 90 дней и количество оплат с длительностью от 90 до 120 дней не выше 10%
Финансовый	Стабилизирующий	Удерживать OOS не выше 20% по всем маркам на любой момент измерений
Финансовый	Стабилизирующий	Удерживать качество мерчандайзинга в рамках стандарта
Клиентский	Стабилизирующий
Развивающий	Оптимизирующий	Провести квартальную аттестацию персонала.

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

Микросервисная архитектура использует сервис в качестве единицы модульности. Каждый сервис - это отдельный бизнес-процесс или бизнес-объект, который что-то делает для получения конкретного результата. Например, интернет-магазин, используя эту архитектуру, мог бы состоять из таких микросервисов, как Сервис Заказов (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) архитектуры

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

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

Агрегат Заказ , который создается со статусом NEW, публикует событие OrderCreated.
Агрегат Клиент получает уведомление о событии OrderCreated, резервирует кредит для заказа и публикует событие CreditReserved.
Агрегат Заказ получает уведомление о событии CreditReserved и меняет свой статус на УТВЕРЖДЕН.

Если кредитная проверка терпит неудачу из-за нехватки средств, агрегат Клиент публикует событие CreditLimitExceeded. Это событие не отражает изменения состояния, а представляет собой неудачную попытку нарушить бизнес-правила. Агрегат Заказ получает уведомление об этом событии и меняет свое состояние на ОТМЕНЕН.

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

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

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

Резюме

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

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

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

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

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

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

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

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

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

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