Механизм интеграции

Моделирование бизнеса — IDEF, UML, ARIS

Классификация моделей

Понятие модели

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

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

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

Модель внешнего вида часов
модель внешнего вида часов
Структурная схема часов
структурная схема часов

Виды подобия: прямое (макет, фотография), косвенное (подобие по аналогии), условное (на основе соглашений).

Процесс моделирования имеет свойство динамичности: модели развиваются, уточняются, переходят одна в другую.

Классификация моделей

Классификация моделей познавательные нормативные
Познавательные (объяснительные) модели отражают уже существующие объекты.

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

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

Классификация моделей материальные абстрактные
Материальные модели построены из реальных объектов.
Абстрактные модели — это идеальные конструкции, выполненные средствами мышления, сознания.

Классификация моделей декларативные процедурные
Декларативные модели отражают свойства, структуры, состояния объектов.
Процедурные модели отражают процедурное, операционное знание.

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

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

Языки описания моделей

Языки описания моделей: аналитические, численные, логические, теоретико-множественные, лингвистические, графические.

Графические модели (схемы, диаграммы, графики, чертежи) – наглядны.
Нотация — система условных обозначений (знаков) и правил их использования, принятая в конкретной методологии.

Требования к нотации:

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

Содержание модели бизнеса

В модели бизнеса отражают:

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

Методы моделирования бизнеса

Структурные методы

Структурные методы
Основаны на последовательной декомпозиции системы на все более мелкие подсистемы.

Принципы структурного подхода:

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

Две группы методов: моделирующие функциональную структуру и структуру данных

Наибольшее распространение получили методологии:

  • IDEF0 – функциональные модели, основанные на методе SADT;
  • IDEF1X – диаграммы данных «сущность-связь» (ERD);
  • IDEF3 — диаграммы потоков работ (Work Flow Diagrams);
  • DFD — диаграммы потоков данных (Data Flow Diagrams).

Методы объектно-ориентированного моделирования

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

Наиболее известные методы:

  • Booch’93 Г. Буча,
  • OMT Дж. Румбаха
  • OOSE А. Джекобсона
  • UML (Unified Modeling Language) – на основе Booch’93, OMT, OOSE

Главным структурообразующим элементом является объект.
В программировании объект — это структура, объединяющая данные и процедуры.
В модели бизнеса объекты – это участники бизнес-процесса (активные объекты) и пассивные объекты (материалы, документы), над которыми выполняют действия активные объекты.

Методы имитационного моделирования

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

Наиболее распространенные методы:

  • сети Петри и раскрашенные сети Петри (CPN, Colored Petri Nets);
  • GPSS (General Purpose Simulating System) – унифицированный язык имитационного моделирования;
  • SIMAN (SIMulation ANalysis) – язык визуального моделирования.

Интегрированные методы

Интегрированные методы
Интегрированные методы моделирования объединяют различные виды моделей – структурного анализа, объектно-ориентированные, имитационные и др.

  • ARIS (Architecture of Integrated Information System) позволяет отражать в единой интегрированной модели: оргструктуры, функции, данные, процессы. Использует множество типов моделей.
  • G2 — методология создания динамических интеллектуальных систем позволяет моделировать процессы с использованием знаний эксперта.
  • BRM (Business Rules Management) – методология управления бизнес-правилами.

Структурные методологии

Методология IDEF0

Методология IDEF0
Методология IDEF0 базируется на методе SADT (Structured Analysis and Design Technique) Росса, предназначенном для структурированного представления функций системы и анализа системных требований.
IDEF0-модель состоит из диаграмм и фрагментов текста. На диаграммах все функции системы и их взаимодействия представлены как блоки (функции) и дуги (отношения).

Основные элементы модели:

  • Функциональный блок (Activity) – преобразование (активность);
  • Выходы (Output) – результат преобразования;
  • Входы (Input) — объекты, которые преобразуются в Выходы;
  • Управление (Control) — информация, как происходит преобразование;
  • Механизм (Mechanism) – объекты, осуществляющие преобразование.

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

  • I (Input),
  • C (Control),
  • O (Output) и
  • M (Mechanism).

Типы связей между блоками:
Выход-вход
Выход-вход
Выход-управление
Выход-управление
Выход-механизм
Выход-механизм
Обратная связь по управлению
Обратная связь по управлению
Обратная связь по входу
Обратная связь по входу

Методология IDEF3

IDEF3-модели используются для документирования технологических (информационных) процессов, где важна последовательность выполнения процесса

Выделяют четыре элемента IDEF3-модели:
Единицы работ (Unit of work) IDEF3 Единица работы — отображают действия, процессы, события, этапы выполнения работ. Единица работы может иметь только один вход и один выход

Ссылки (Referents):
необходимые элементы для выполнения процесса (сырье, материалы);
результат процесса (изделие);
активаторы процесса (клиент, поставщик).
Ссылки (Referents) idef3

Связи (Links), которые бывают двух типов:
передают действия от одной единицы работ к другой
Связи (Links) idef3
соединяют ссылку с единицей работ (активируют единицу работ)
Связи (Links) idef3

Перекрестки (Junctions) – элементы модели, за счет которых описывается логика и последовательность выполнения этапов процесса.
Бывают двух видов:
перекрестки слияния – Fan-in
перекрестки слияния – Fan-in idef3
перекрестки ветвления – Fan-out
перекрестки ветвления – Fan-out

Типы перекрестков

Асинхронное И (Asynchronous AND)
выходной процесс запустится, если завершились все входные процессы
26_asynchronous_and_zavershilis_vse_vhodnie
после завершения входного процесса запустятся все выходные процессы
Асинхронное И (Asynchronous AND)

Синхронное И (Synchronous AND)
выходной процесс запустится, если завершились одновременно все входные процессы
Синхронное И (Synchronous AND)
после завершения входного процесса запустятся все выходные процессы, причем запустятся одновременно
Синхронное И (Synchronous AND)

Асинхронное ИЛИ (Asynchronous OR)
выходной процесс запустится, если завершится один или несколько входных процессов
Асинхронное ИЛИ (Asynchronous OR)
после завершения входного процесса запустятся один или несколько выходных процессов
Асинхронное ИЛИ (Asynchronous OR)

Синхронное ИЛИ (Synchronous OR)
выходной процесс запустится, если завершились один или несколько входных процессов, причем завершились одновременно
Синхронное ИЛИ (Synchronous OR)
после завершения входного процесса запустится один или несколько выходных процессов, причем запустятся одновременно
Синхронное ИЛИ (Synchronous OR)

Исключающее ИЛИ (XOR, Exclusive OR)
выходной процесс запустится, если завершился только один входной процесс
34_XOR_Exclusive_OR_input
после завершения входного процесса запустится только один выходной процесс
Исключающее ИЛИ (XOR, Exclusive OR)

Пример IDEF3

Пример IDEF3

Правила создания перекрестков

  1. Каждому перекрестку слияния должен предшествовать перекресток ветвления.
  2. Перекресток слияния «И» не может следовать за перекрестком ветвления типа синхронного, асинхронного или исключающего «ИЛИ».
  3. Перекресток слияния типа исключающего «ИЛИ» не может следовать за перекрестком ветвления типа «И».
  4. Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.
  5. Перекресток не может быть одновременно перекрестком слияния и ветвления. В ситуации, когда необходимо одновременно осуществить слияние и разветвление потоков работ, вводится каскад перекрестков.

Правило относительно единиц работ

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

Номер работы А13.1.2 означает:
родительская работа имеет код А13,
номер декомпозиции – 1
номер работы на текущей диаграмме – 2.

Методология DFD

Диаграммы потоков данных DFD позволяют эффективно и наглядно описать процессы документооборота и обработки информации.
Используются две нотации: Йордана и Гейна-Сарсона

Типы структурных элементов (в нотации Гейна-Сарсона):
1. Процессы (функции, операции, действия), которые обрабатывают и изменяют информацию. Процессы показывают, каким образом входные потоки данных преобразуются в выходные
Методология DFD Процессы
2. Потоки данных, которые обозначают взаимодействие процессов с внешним миром и между собой. Поток данных соединяет выход процесса (объекта) с входом другого процесса (объекта).
Поток данных соединяет выход процесса (объекта) с входом другого процесса (объекта)
3. Хранилища данных — представляют собой собственно данные, к которым осуществляется доступ. Эти данные могут быть созданы или изменены процессами.
Хранилища данных - представляют собой собственно данные, к которым осуществляется доступ.
4. Внешние сущности — определяют внешние элементы, которые участвуют в процессе обмена информацией с системой. Внешние сущности изображают входы в систему (источники информации) и/или выходы из системы (приемники информации). Примеры: заказчик, персонал, поставщик, клиент, склад, банк
Внешние сущности - определяют внешние элементы, которые участвуют в процессе обмена информацией с системой

Пример:
Методология DFD пример

Объектно-ориентированный язык UML

Язык UML был разработан для создания моделей информационных систем (ИС) с целью их последующей реализации в виде объектно-ориентированных программ.
Все представления о модели сложной системы фиксируются в виде диаграмм -специальных графических конструкций (схем, графов).
Имеется 8 основных типов диаграмм UML, отражающих различные аспекты: процессы, выполняемые системой (предоставляемые пользователю сервисы), последовательность выполняемых системой алгоритмических операций,
структуру программных объектов, их взаимодействие (обмен сообщениями) и т.д.

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

Прецедентная модель бизнеса

Отражает основные бизнес-процессы, их взаимодействие с окружением.
Начинается с построения внешней диаграммы (вариантов использования — Use Case Diagram), показывающей, как бизнес виден извне
Прецедентная модель бизнеса

Актор (действующее лицо, business actor) — субъект окружения бизнеса. Примеры акторов: Клиент, Покупатель, Поставщик, Партнер, Акционер, Заказчик.
Актор (действующее лицо, business actor)

Прецедент (вариант использования, business use case) — относительно законченная последовательность действий в рамках некоторого бизнес-процесса, приносящая ощутимый результат конкретному актору .
Примеры прецедентов: Производство продукта Продажа продукта, Сервисное обслуживание, Разработка продукта, Маркетинг и сбыт.
Прецедент (вариант использования, business use case)

Экземпляр (реализация) прецедента – конкретный вариант хода событий класс прецедентов — обобщенный прецедент.

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

Между прецедентами и акторами устанавливаются отношения коммуникации (отношения ассоциации со стереотипом communicate).
Они моделируют взаимосвязи прецедентов с окружением (информационные и материальные потоки)
Между прецедентами, как правило, устанавливаются только отношения зависимости а также отношения, структурирующие прецеденты – отношения обобщения, включения (зависимости со стереотипом include), расширения (зависимости со стереотипом extend).
отношения обобщения, включения (зависимости со стереотипом include), расширения (зависимости со стереотипом extend)

Для каждого из элементов модели составляется спецификация.
В спецификации актора: наименование, стереотип (business actor), описание, список атрибутов, список обязательств и др.

В спецификации прецедента: наименование, стереотип (business use case), краткое описание, перечень связанных с прецедентом поддиаграмм и документов

Поток событий прецедента

Поток событий — описание прецедентов последовательностью шагов

Поток событий прецедента «Продажа продукта»:

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

Диаграмма деятельности (Activity Diagram)

Диаграмма деятельности (Activity diagram)

Элементы диаграммы деятельности

Элементы диаграммы деятельности

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

Структурирование прецедентов

Чтобы упростить описание прецедента, необходимо его структурировать. Рассмотрим два способа структурирования.
1. Выделение фрагментов
Если из описания прецедента с альтернативными потоками событий можно выделить фрагмент, представляющий собой относительно законченную последовательность событий, то данный фрагмент рассматривается как отдельный прецедент. Между выделенным прецедентом и базовым устанавливается отношения включения (include).
Иногда используют отношение расширения (extend). Оно устанавливается между базовым прецедентом и прецедентом, содержащим некоторое дополнительное поведение, выполняемое при определенных условиях.

2. Обобщение
Если несколько прецедентов имеют похожее поведение, то следует выделить общее поведение в отдельный прецедент (родительский). Между каждым из частных прецедентов и родительским устанавливается отношение обобщения (generali-zation).

Объектная модель бизнес-процесса

Раскрывает внутреннее устройство бизнеса: какие виды ресурсов используются для реализации прецедентов и каким образом они взаимодействуют.
Классы объектов модели бизнеса:
активные — исполнители процессов (стереотип business worker), например, Продавец, Изготовитель, Разработчик;
53_uml_aktivnie_klassi
пассивные — сущности (стереотип business entity), например, Продукт, Заказ, Счет.
пассивные - сущности (стереотип business entity)

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

Классы и объекты

Класс – некоторый тип объектов (множество похожих объектов),
Экземпляр – конкретный объект (представитель класса).
Экземпляр – конкретный объект (представитель класса)

Объекты имеют:
имя (через двоеточие может быть указано имя класса)
свойства — описываются с помощью атрибутов
поведение — представляется с помощью операций

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

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

Динамическая диаграмма взаимодействия

Прецедент «Продажа заказного продукта»:
Продавец получает заявку клиента
Продавец формирует заказ и передает его Изготовителю продукта.
Изготовитель изготавливает продукт.
Изготовитель отправляет продукт на Склад и сообщает о готовности Продавцу.
Продавец сообщает Клиенту о готовности продукта и принимает от Клиента оплату.
Продавец сообщает Отправителю адрес клиента и заказывает транспорт.
Отправитель получает продукт со склада и доставляет его клиенту.
Динамическая диаграмма взаимодействия

Элементы диаграммы последовательности

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

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

Сообщения упорядочены по времени: первое сообщение изображается вверху диаграммы, следующее – ниже, следующее – еще ниже и т.д.
Однако диаграмма не содержит метрики времени (расстояния между сообщениями – это не интервал времени)

Статическая диаграмма взаимодействия

Диаграмма кооперации (Collaboration Diagram)
Статическая диаграмма взаимодействия

Диаграмма классов

Диаграмма классов (Class diagram) используется для отображения устойчивых связей между классами объектов
Диаграмма классов для прецедента «Продажа продукта»
Диаграмма классов для прецедента «Продажа продукта»
Для структурирования классов используются отношения обобщения и включения
Для структурирования классов используются отношения обобщения и включения

Описание объектов

Спецификация объекта состоит из описания свойств (атрибутов) и поведения (обязательств, операций).
Спецификация объекта состоит из описания свойств (атрибутов) и поведения (обязательств, операций).

Интегрированная методология ARIS


Методология ARIS (Architecture of Integrated Information System) разработана в 1990-х годах профессором А.-В. Шеером
Интегрированная методология ARIS
Для каждого из этих представлений можно построить несколько типов моделей (в ARIS 5.0 общее количество типов диаграмм — 130)

Выделено четыре основных вида моделей (четыре представления):

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

Организационная схема

К организационным моделям относится Организационная схема (Organizational chat).
Основные типы объектов этой модели:
Организационная схема (Organizational chat)

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

Дерево функций

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

Событийная цепочка процесса

К моделям процессов/управления относится Диаграмма eEPC (extended Event driven Process Chain)
К моделям процессов/управления относится Диаграмма eEPC (extended Event driven Process Chain)
Основные типы объектов:
67_aris_diagram_eEPC_tipi_objectov

Элементы диаграммы eEPC

  • Функция – некоторое (шаг процесса). С функцией могут быть связаны: исполнители, входные и выходные документы, программное обеспечение и т.д.
  • Событие — какое-либо завершенное состояние объекта, которое влияет на дальнейший ход процесса. С одной стороны события являются стимулом к выполнению функций, с другой – их результатом.
  • Логические операторы (И, ИЛИ, XOR) показывают разветвления в потоке процесса.

Примеры:
Элементы диаграммы eEPC

Интеграция моделей

Взаимосвязь моделей ARIS обеспечивается с помощью двух механизмов: интеграции и детализации
1. Механизм интеграции
Благодаря хранению объектов в едином репозитории (специальной базе данных).
При создании нового объекта в репозитарии появляется отдельная запись, задающая описание объекта.
Объект можно скопировать из одной модели и вставить в другую с помощью команд Copy/Paste.
Механизм интеграции

Детализация моделей

2. Механизм детализации: для объектов текущей модели можно задавать ссылки на другие модели, являющиеся подробным описанием этого объекта.
Типы детализации, разрешенные к использованию, зависят от типа объекта
70_aris_detalizaciya_modeley

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

Инструментальные средства

Возможности инструментальных средств

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

Использованная литература

1. Национальный исследовательский Томский политехнический университет. Томск. Силич В.А. 2016. 75 с. Презентация к лекции.


Критерии управления на основе данных

Для компаний с управлением на основе данных характерны виды деятельности, перечисленные ниже.

  • Эти компании постоянно проводят различные тестирования, например A/B тестирование на сайте или тестирование заголовков в электронной рассылке маркетинговой кампании. Социальная сеть LinkedIn, например, проводит до 200 тестирований в день, сайт электронной коммерции Etsy одновременно может проводить до десяти тестирований. Тестирование иногда проводится непосредственно с участием конечных пользователей, чтобы компания могла получить прямую обратную связь относительно потенциальных новых характеристик или новых продуктов.
  • Тестирования направлены на постоянное совершенствование деятельности компании и ее сотрудников. Это может быть постоянная оптимизация основных процессов, например сокращение производственного процесса на несколько минут или снижение цены за конверсию, что становится возможным благодаря тщательному анализу, специально разработанным математическим или статистическим моделям и симуляции.
  • Компании могут заниматься прогнозным моделированием, прогнозированием объема продаж, курса акций или выручки, но, что самое важное, они используют собственные прогнозные ошибки для улучшения своих моделей.
  • Практически всегда они выбирают среди будущих вариантов или действий на основе набора взвешенных показателей.

Ресурсы всегда конечны, и всегда есть аргументы за и против разных рациональных способов действий. Для принятия окончательного решения необходимо собрать данные для каждого набора показателей, которые тревожат или интересуют компанию, и определить их значимость. Например, когда компания Warby Parker собиралась открывать первый офис за пределами Нью Йорка, то комплексно рассматривала и оценивала целый ряд переменных в отношении нового места: индекс благополучия Gallup (Well being index), кадровый потенциал, прожиточный уровень, стоимость билетов до Нью Йорка и так далее. Марисса Майер (CEO компании Yahoo!) делилась похожей историей: как она выбирала между разными предложениями о работе и приняла решение работать в компании Google .
Компания с управлением на основе данных будет делать хотя бы что то из перечисленного, что направлено на будущее и имеет акцент на данных.

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

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

Технологии и обучение могут обеспечить первую часть плана: помочь специалистам по работе с данными с проведением анализа и представить результаты этого анализа. Однако именно от корпоративной культуры компании зависит, обратят ли на данные и результаты анализа внимание, будут ли им доверять и предпринимать на их основе конкретные действия.
Наконец мы добрались до самого важного аспекта, определяющего управление на основе данных. Для компании с управлением на основе данных именно данные – основной фактор, обусловливающий стратегию и влияющий на нее. В такой компании формируется конструктивная корпоративная культура, при которой данным доверяют, а результаты анализа бывают высокозначимыми, информативными и используются для определения следующих шагов.
В этом то и заключается сложность. Если решения в компании принимаются на основе интуиции, как вывести ее на уровень управления на основе данных? Это процесс нелегкий и небыстрый, поэтому не стоит ожидать мгновенных изменений, однако все сотрудники компании могут внести свой вклад в этот процесс. Мы рассмотрим несколько способов, как стимулировать развитие в компании управления на основе данных.


Специалисты по аналитике

Специалисты по аналитике

По-настоящему хороший аналитик должен будоражить людей… Я знаю, что я первый получаю данные, а значит, я первый узнаю историю. Открывать что-то новое увлекательно.
Дэн Мюррей

Человеческий фактор – важный компонент компании с управлением на основе данных. Кто такие специалисты по аналитике и как должна быть организована их работа?
Эта статья посвящена специалистам по аналитике: разным их типам и навыкам, которыми они должны обладать. Мы рассмотрим самые разные позиции и познакомимся с людьми, которые их занимают. Кроме того, мы обсудим плюсы и минусы разных организационных структур для выполнения аналитической работы.
Continue reading


Качество данных

80 % времени я трачу на очистку данных. Качественные данные всегда выигрывают у качественных моделей.
Томсон Нгуен

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

Специалистам‑аналитикам нужны правильные данные, собранные правильным образом и в правильной форме, в правильном месте, в правильное время. (Они просят совсем не много.) Если какое‑то из этих требований не выполнено или выполнено недостаточно хорошо, у аналитиков сужается круг вопросов, на которые они способны дать ответ, а также снижается качество выводов, которые они могут сделать на основании данных.
Continue reading


навыки аналитика

Навыки и качества хорошего аналитика

Какие качества определяют хорошего аналитика?

Аналитический склад ума

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


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

Управление реализацией стратегии и оценка ее эффективности

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

Разработка и реализация стратегии как отдельные фазы цикла стратегического управления

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

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

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

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

Ответы на ряд из поставленных вопросов Вы сможете найти в настоящем курсе, а остальное – узнаете при изучении модуля «Управление изменениями».

Успехи и неудачи в процессе стратегического управления

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

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

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

Создание и реализация стратегии – разные компетенции?

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

Проблемы реализации стратегии

В процессе реализации разработанной стратегии многие компании сталкиваются с определенными трудностями. Одной из типичных проблем является то, что стратегию компании могут внятно сформулировать лишь 3-4 сотрудника (как правило, это руководители основных структурных подразделений). Подавляющее большинство сотрудников компании могут не иметь никакого представления о том, в каком направлении будет развиваться бизнес в ближайшие годы и что с ним будет через 3-5 лет. Вторая проблема может заключаться в том, что сотрудники все-таки могут сформулировать суть стратегии своей компании, но затрудняются описать свою роль в ее реализации. Так, в одной из компаний сотрудник отдела маркетинга, «поймав» в коридоре генерального директора, обратился к нему со следующими словами: «Мне очень нравится та стратегия, которую Вы вчера озвучили на общем собрании. Я чувствую, что она позволит нашей компании стать лидером рынка. Я двумя руками «за»! Но я не могу понять, что именно я должен делать на своем рабочем месте для ее успешной реализации? И еще вопрос – чего я делать НЕ должен?» Еще несколько распространенных проблем – умышленное искажение либо ошибочная интерпретация стратегии, а также несогласие сотрудников со стратегией, сформулированной руководством. Сопротивление сотрудников может быть связано, в том числе, и с тем, что они не были привлечены к процессу разработки стратегии, и с другими причинами, с которыми Вы ознакомитесь в материалах модуля «Управление изменениями». Следующая проблема – отсутствие контроля над реализацией разработанных мероприятий и достижением стратегических целей. Функция контроля – обязательная управленческая функция даже в тех компаниях, в которых руководство предпочитает «вдохновлять» свой персонал, а не проверять каждый его шаг и устраивать разносы. Когда мы разрабатываем стратегию, мы пытаемся заглянуть в будущее. Но предсказать все с точностью до 100% мы не в состоянии. Всем компаниям приходится вносить изменения в разработанные стратегические планы. Поэтому очень важно понять, когда именно мы будем делать контрольные «срезы», в ходе которых в пакет реализуемых мероприятий могут вноситься необходимые для достижения целей изменения. Кроме того, очень важно продумать вопрос мотивации и стимулирования персонала. В идеале, каждый сотрудник компании должен четко понимать, какой гонорар его ожидает, если компания сможет достичь своих стратегический целей. Гонорар, разумеется, может быть материальным (деньги, оплаченный дополнительный отпуск, продвижение по службе и т.п.) и нематериальным (чувство удовлетворения от достигнутых успехов, самореализация и т.д.).

Что такое успешная реализация стратегии?

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

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

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

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

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

  • Понимаете ли Вы стратегию Вашего предприятия?
  • Достаточно ли регулярно Вас информируют о стратегии предприятия и ее изменении, если таковое имеет место?
  • Знаете ли Вы стратегические цели Вашего подразделения?
  • Понимаете ли Вы, как стратегические цели Вашего подразделения способствуют исполнению стратегии организации?
  • Cоответствуют ли стратегические цели Вашего подразделения, на Ваш взгляд, целям организации?
  • Cоответствуют ли стратегические цели Вашего подразделения целям других подразделений?
  • Достаточно ли эффективно Ваше подразделение сотрудничает с другими подразделениями в целях удовлетворения потребностей клиентов?
  • Получает ли Ваше подразделение достаточную поддержку от обслуживающих подразделений?
  • Понимаете ли Вы, как именно Ваша ежедневная работа способствует исполнению стратегии организации?
  • Обсуждали ли Вы с Вашим непосредственным руководителем Ваши личные цели в этом году в привязке к стратегии развития компании и Вашего подразделения?

Логика управления по целям

Введение в управление по целям

Общая схема управления по целям (англ. Management by Objectives) представлена на рисунке. Рисунок «Управление по целям» Реализация стратегии в цикле стратегического управления компанией Первый этап управления по целям – это разработка системы целей компании в целом. В качестве основной цели собственного существования большинство компаний заявляет заработок прибыли. Такова специфика работы коммерческих организаций. Некоммерческие организации, в отличие от коммерческого сектора, фокусируются на исполнении миссии. В большинстве отраслей одни и те же деньги можно заработать несколькими способами, поэтому цель «Максимизация прибыли» требует конкретизации. На уровне компании в целом должна быть прописана схема «зарабатывания» целевого значения прибыли.

Стратегическая карта и показатели степени достижения цели

В качестве базового шаблона для разработки системы целей для компании в целом мы рассмотрим шаблон «стратегической карты» (англ. Strategy Map), предложенный американцем Робертом Капланом. Логика «стратегической карты», с которой Вы уже познакомились в куре «Разработка и реализация стратегии» предполагает, что система целей для коммерческой организации должна прописываться в четырех взаимосвязанных проекциях – «Финансы», «Клиенты \ Продукты», «Бизнес-процессы», «Персонал \ Инфраструктура». Причинно-следственная связь этих проекций очевидна – квалифицированные и мотивированные сотрудники, используя развитую инфраструктуру (оборудование, программное обеспечение, транспортный парк и т.д.), призваны обеспечить необходимое компании качество и скорость выполнения бизнес-процессов. Отлаженные бизнес-процессы необходимы для достижения конкурентного преимущества и обеспечения удовлетворенности клиентов. Удовлетворенные клиенты и конкурентные преимущества являются предпосылкой достижения желаемых финансовых целей. При этом разработка системы целей для коммерческой организации осуществляется в следующей последовательности:

  1. Цели в проекции «Финансы»;
  2. Цели в проекции «Клиенты \ Продукты»;
  3. Цели в проекции «Бизнес-процессы»;
  4. Цели в проекции «Персонал \ Инфраструктура».

Как правило, такая стратегическая карта состоит из 20-23 ключевых целей, взаимосвязанных между собой причинно-следственными связями. Фактически стратегическая карта представляет собой дерево целей, где финансовые цели, которые ставятся перед организацией акционерами, декомпозируются на нефинансовые. Итак, в компании разработана система взаимосвязанных целей. Как менеджеру обеспечить их достижение? Согласно подходу Д.Нортона и Р.Каплана, для каждой стратегической цели нужно подобрать ключевые показатели (индикаторы), которые позволят менеджеру оценить степень ее достижения. Так как все показатели будут иметь количественную оценку, необходимо присвоить им целевые значения. Для цели «Повысить удовлетворенность клиента» можно использовать показатель «Уровень удовлетворенности клиента», который измеряется по данным опроса и при количественной обработке будет равен, допустим, 4, а желаемое целевое значение может составить, к примеру, 4,5.

В чем сбалансированность ССП?

Р. Каплан использует для обозначения системы показателей термин Balanced Scorecard. В русскоязычной литературе встречается множество вариантов перевода этого термина, но наиболее распространенным является термин «сбалансированная система показателей». Считается, что термин «Scorecard» позаимствован из гольфа. У игрока в гольф есть небольшая карточка («Card»), на которой он отмечает собственные результаты – очки, пункты, баллы («Score»). Точно так же руководитель компании в целом или руководитель одного из структурных подразделений может на небольшом клочке бумаги записать набор ключевых показателей, по которым он будет мониторить свой бизнес (либо его подразделение). Но важно помнить, что эта «карточка» должна быть «сбалансированной». Сбалансированность означает наличие связей между показателями, а также то, что система должна включать в себя как финансовые, так и нефинансовые показатели. Кроме того, система ключевых показателей любой компании должна включать в себя не только те из них, которые «достаются» из каких-то внутренних систем (управленческий учет, журналы учета процессов, базы данных), но и показатели, получаемые в ходе опросов клиентов и персонала. Сбалансированная система показателей настоятельно рекомендует бизнесменам получать обратную связь от клиентов (как правило, индекс удовлетворенности клиентов, число рекламаций, число рекомендаций) и от персонала (как правило, индекс удовлетворенности персонала). Сбалансированность системы показателей обеспечивается еще и тем, что организации начинают использовать не только ретроспективные показатели, позволяющие оценить, что было с компанией в прошедшем периоде («запаздывающие показатели»: прибыль, удовлетворенность клиента, количество прогулов/опозданий и т.д.), но и так называемые «опережающие», дающие возможность скорректировать или направить действия сотрудников в нужном для компании направлении (к примеру, «Количество встреч с ключевыми клиентами за период», доля полуфабрикатов низкого качества, снятых работниками с конвейера до заключительного этапа производства).

Декомпозиция/каскадирование стратегии на подразделения

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

Стратегически значимые мероприятия

После разработки системы целей компании в целом и целей структурных подразделений на третьем этапе необходимо подумать о мероприятиях и проектах, реализация которых будет необходимой и достаточной для достижения целей. Для разработанных мероприятий и проектов определяются бюджеты, сроки, участники и ответственные за их исполнение. При этом, как правило, получается, что ряд проектов может быть необходимым для исполнения сразу нескольких целей, а ряд – оказаться слабо влияющим на реализацию стратегии. На этом этапе полезно сделать «инвентаризацию» и определить приоритетность намеченных стратегических мероприятий, учитывая ограничения, которые могут быть связаны с их финансированием. Проводить такой анализ можно, выявив, какие инициативы поддерживают те или иные цели. Для этого используют приведенный ниже шаблон, указывая, какие именно мероприятия способствуют исполнению разработанных стратегических целей (выделено черным на пересечении строки и столбца). Таблица «Шаблон для анализа значимости стратегических мероприятий» Реализация стратегии в цикле стратегического управления компанией Этот же шаблон позволит выявить «провисающие» цели, то есть сформулированные цели без предложенных стратегических мероприятий, которые способствовали бы их реализации. В то же время можно предположить, что для Цели 2 реализуется избыточное количество мероприятий (но именно предположить, так как только решение команды проекта может быть основанием для исключения того или иного мероприятия!). В процессе реализации стратегических мероприятий важное значение имеет функция контроля и корректировки намеченных планов. Достигнутые по факту результаты сравниваются с запланированными. Существенно не только достижение целевых результатов, но и соблюдение бюджетов и сроков. После этого можно говорить о вознаграждении основных участников процесса. Если поставленные цели оказались достигнутыми, причем в намеченные сроки и без превышения бюджета, то сотрудники компании вправе рассчитывать на получение обещанного вознаграждения (материального и нематериального).

Финансовые цели и показатели

Рассмотрим более детально, какие же показатели используются сегодня предприятиями для оценки степени достижения стратегических целей и, следовательно, в качестве инструмента оценки эффективности стратегии и контроля ее реализации. Стоит отметить, что выбрав уже апробированные другими компаниями показатели, Вы сможете сравнить, насколько успешно Ваша компания справляется с достижением поставленных целей по сравнению с другими компаниями Вашей отрасли и/или других отраслей. Здесь, однако, следует помнить, что система полностью заимствованных у других компаний показателей представляет собой опасность, связанную с утерей уникальности как самой стратегии, так и системы ее реализации. Рассмотрим примеры финансовых целей и индикаторов, которые позволят оценить, насколько организация близка к достижению заявленных целей. Большинство компаний основной своей финансово-экономической целью назовет прибыль. Казалось бы, все очевидно. Однако известное утверждение американского финансиста Альфреда Раппопорта о том, что «прибыль – это мнение, а деньги – это факт» (англ. «Profit is Opinion, Cash is Fact»), подвергает эту очевидность сомнению. Любой бухгалтер или финансист знает, что определение величины прибыли компании за тот или иной период зависит от многочисленных нюансов учетной политики. Методы и сроки начисления амортизации, методы списания сырья и материалов со склада в производство, размеры резервов, сформированных в связи с наличием определенных рисков, варианты учета расходов будущих периодов и курсовых разниц – вот только некоторые факторы, оказывающие существенное влияние на расчет прибыли. Еще один важный фактор – так называемые вмененные издержки (стоимость собственного капитала компании). Все эти причины влияют на то, что в одном учете (для государственных органов) компания может показывать одну прибыль, в другом (для рынка капитала) – другую, а в третьем (для себя) – третью. Денежный поток, рассчитываемый как разница между поступлениями и выплатами за тот или иной период, является гораздо более информативным управленческим показателем. Как известно, компания может получать денежные средства по трем видам деятельности:

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

Выплаты компании также структурируются по трем видам деятельности:

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

Безусловно, в большинстве бизнесов наибольший интерес представляет показатель денежного потока от операционной деятельности. Кроме того, в финансовом анализе и расчетах часто используется значение свободного денежного потока (суммарный денежный поток от операционной и инвестиционной деятельностей). Показатели прибыли и денежного потока относятся к ключевым финансовым показателям. Однако помимо абсолютного значения прибыли или денежного потока (например, в евро) небезынтересным также является их относительное значение (в процентах к вложенному в бизнес капиталу). Рентабельность капитала по прибыли (англ. «Return on Investment», ROI) рассчитывается делением прибыли на величину инвестированного в компанию капитала. Рентабельность инвестированного капитала по денежному потоку (англ. «Cash Flow Return on Investment», CFROI) рассчитывается, соответственно, делением значения денежного потока на величину капитала. Синонимичным показателю ROI является показатель рентабельности активов (англ. «Return on Assets», ROA).

Простое математическое преобразование соотношения

таким образом:

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

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

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

Другие формулировки финансовых целей – «Увеличить выручку», «Снизить затраты», «Увеличить величину маржинального дохода», «Оптимизировать налоговые отчисления», «Повысить инвестиционную привлекательность бизнеса», «Уменьшить дебиторскую задолженность», «Окупить инвестиции в бизнес в течение n лет» – можно считать вторичными, поскольку их достижение в конечном итоге способствует цели более высокого порядка – росту прибыли.

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

Кроме того, при формулировании стратегических финансовых целей компании нужно учитывать идею цепочки стратегических целей компании (от проекции «Персонал / Инфраструктура» к проекции «Бизнес-процессы», от проекции «Бизнес-процессы» к проекции «Клиенты / Продукты» и далее к проекции «Финансы»). Например, формулировка «Не производить брак» с обоснованием «Не производя брак, мы экономим на затратах, а экономия на затратах – это типично финансовая цель», не является стратегической целью проекции «Финансы». «Не производя брак» (проекция «Бизнес-процессы»), мы, как правило, повышаем степень удовлетворенности клиентов (проекция «Клиенты»), что, в свою очередь, способствует росту значения прибыли и рентабельности активов (проекция «Финансы»). Такую цель, как «Снизить затраты», также можно считать правильной, поскольку практически всегда для практически всех компаний она будет правильной. Но это не значит, что проекция «Финансы» у всех компаний будет выглядеть одинаково. Безусловно, затраты в любом бизнесе – один из решающих факторов. Чтобы выжить на рынке, компания должна прикладывать перманентные усилия к управлению затратами. Однако в отношении формулировки «Снизить затраты» проблематичным является то обстоятельство, что постановка такой цели может предполагать ряд негативных моментов (например, снижение уровня качества продукции). Еще одна проблема связана с размером необходимого снижения затрат. Если ставится задача снизить затраты по всему предприятию в целом на 10%, то как в этом отношении должны работать отдельные подразделения – снижать свои затраты на 10%? Есть такие подразделения (например, конструкторские разработки), в которые наоборот следует инвестировать, увеличивая в данный момент их затраты. Кроме того, следует подумать над тем, какая формулировка лучше вписывается в существующую стратегию. Для компании, выбравшей для себя стратегию дифференциации («уникальность», «отличие») формулировка «Снизить затраты» может привести к необдуманному снижению затрат как самоцели и потери части той ценности, которую компания создает для своего потребителя. Например, для достижения цели по снижению затрат производитель автомобилей «Mercedes» может заменить кожаный салон более дешевым вариантом, но в этом случае создаваемый продукт рискует потерять ту ценность, которая важна для его клиентов. Таким образом, в проекции «Финансы» подавляющего большинства компаний самых разных отраслей и размеров будут присутствовать формулировки, касающиеся прибыли, денежного потока, рентабельности активов (ROA) и стоимости бизнеса. Все остальные финансовые показатели (выручка, затраты, рентабельность продаж, ликвидность, структура активов и пассивов, оборачиваемость) можно считать показателями второго уровня. Следует отметить, что формулировки стратегических целей в проекции «Финансы» у разных компаний могут быть и, скорее всего, будут идентичными или похожими. Однако целевые значения индикаторов, как правило, будут разными. Образно говоря, одна компания стремится заработать миллион, другая – десять миллионов, а третья – рассчитывает только на десять тысяч. Это зависит, в том числе, от того, в какой отрасли (прибыльной или неприбыльной) работает компания, от ее сильных и слабых сторон, от амбиций ее руководства. Важно понимать, что формулировка финансовых целей будет примерно одинаковой у компаний самых разных отраслей, самых разных размеров и с самыми разными стратегиями. Большинство компаний оценивают свои стратегии по достаточно стандартному набору финансовых показателей – выручка, прибыль, денежный поток, рентабельность капитала, стоимость бизнеса. Разница будет только в целевых значениях этих параметров – одна компания стремится стать «миллионером», а другая – «миллиардером». Это зависит, в том числе, от того, в какой отрасли (прибыльной или неприбыльной) работает компания, от ее сильных и слабых сторон, от амбиций ее руководства. Заработать один и тот же миллион в рамках одной и той же отрасли можно несколькими способами. Поэтому в проекциях «Клиенты», «Бизнес-процессы» и «Персонал \ Инфраструктура» компания прописывает именно свой способ заработать свой миллион/миллиард.

Цели и показатели проекции «Клиенты / Продукты»

Если формулировки целей в проекции «Финансы» должны давать ответ на вопрос «Какие параметры финансового состояния компании будут приемлемы для менеджмента и учредителей?», то формулировки целей компании в проекции «Клиенты \ Продукты» должны обеспечивать понимание того, каких позиций на рынке компания стремится достичь и чем компания в глазах клиентов будет отличаться от конкурентов. Другими словами, в рамках проекции «Клиенты / Продукты» компания должна четко – прежде всего, для себя самой – определить, в чем именно состоит ее «уникальное ценностное предложение» (англ. «unique value proposition»). «Уникальность» предложения для клиента заключается в том, что такого набора характеристик продукта по такой цене клиенту не предлагает больше никто из конкурентов компании. Характеристики продукта в данном случае понимаются широко – это и качественные характеристики сами по себе, и такие аспекты, как скорость обслуживания, ассортимент, возможность выполнения индивидуальных заказов, сервисная и информационная поддержка, удобство расчетов и т.д. Именно на четком понимании уникального ценностного предложения для своих клиентов строятся успешные стратегии. Важнейший вопрос, на который в этой проекции нужно дать ответ, – кто является нашим клиентом. На этапе стратегического анализа компания анализирует потенциальные сегменты на рынке и выбирает для себя целевые. На этапе «целеполагания» компания формулирует цели относительно выбранных сегментов.

Типичными для этой проекции формулировками целей будут:

  • «занять лидирующие позиции в сегменте»;
  • «сохранить имеющиеся позиции на целевых рынках»;
  • «сохранить лояльность клиентов»;
  • «повысить удовлетворенность клиентов в целевых сегментах».

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

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

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

  • взаимоотношения с государством \ обществом;
  • взаимоотношения с конкурентами;
  • взаимоотношения с поставщиками \ партнерами.

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

Цели и показатели проекции «Бизнес-процессы»

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

Цепочки бизнес-процессов на примерах из практики

Цепочка бизнес-процессов дистрибутора запчастей

Основные бизнес-процессы

  • БП1. Исследование рынка
  • БП2. Анализ продаж и запасов
  • БП3. Управление продуктом
  • БП4. Закупки / Отношения с поставщиками
  • БП5. Логистика
  • БП6. Ценообразование и продвижение
  • БП7. Сбыт
  • БП8. Отгрузка / Доставка клиенту
  • БП9. Постпродажное обслуживание

Обслуживающие бизнес-процессы

  • БП10. Управление персоналом
  • БП11. ИТ
  • БП12. Контроллинг и риски
  • БП13. Отношения с государством
  • БП14. Управление финансами
  • БП15. Управление инфраструктурой
  • БП16. Общий менеджмент

Цепочка бизнес-процессов строительной компании (здания из металлических конструкций)

Основные бизнес-процессы

  • БП1. Маркетинг / Поиск заказчика
  • БП2. Заключение договора с заказчиком
  • БП3. Разработка инвестиционной схемы / Содействие в привлечении кредитов
  • БП4. Проектирование здания / Генпроектирование
  • БП5. Организация производства здания
  • БП6. Поставка комплектующих для здания
  • БП7. Монтаж здания / Генподряд
  • БП8. Технический надзор
  • БП9. Гарантийное обслуживание здания
  • БП10. Сервисное обслуживание здания

Обслуживающие бизнес-процессы

  • БП11. Информационные технологии (автоматизация)
  • БП12. Юридическое обеспечение деятельности
  • БП13. Система менеджмента качества (ISO)
  • БП14. Бухгалтерский учет и управление финансами
  • БП15. Контроллинг
  • БП16. Управление персоналом
  • БП17. Общий менеджмент

Цепочка бизнес-процессов производителя кухонной мебели

Основные бизнес-процессы

  • БП1. Исследование рынка
  • БП2. Брэндинг \ Продвижение
  • БП3. Мерчендайзинг в салоне
  • БП4. Прием и первичная обработка заказа
  • БП5. Конструкторская разработка
  • БП6. Закупка ресурсов
  • БП7. Производство продукта
  • БП8. Доставка \ Монтаж (сборка)
  • БП9. Гарантийное и послегарантийное обслуживание

Обслуживающие бизнес-процессы

  • БП10. Система безопасности \ Юридическое обеспечение \ Отношения с государством
  • БП11. Система информационного обеспечения \ ИТ-система
  • БП12. Финансовая система
  • БП13. Управление персоналом
  • БП14. Общий менеджмент

Таким образом, перед формулированием целей в проекции «Бизнес-процессы» компания должна определиться со списком собственных ключевых или стратегически значимых процессов. Что в данном случае определяет, стратегически значимый это бизнес-процесс или нет? Важно понимать, что в высококонкурентных отраслях примерно 80% от общего количества работ (процессов), выполняемых в компании, одинаково успешно отстроены у всех ее конкурентов. Еще примерно 15% от общего списка работ – это те работы, которые также выполняются всеми игроками в отрасли, но пока не у всех они получаются одинаково хорошо. И, наконец, примерно 5% из общего списка – это уникальные работы, которые только одна компания предлагает на рынке. Вообще говоря, 15% и 5% – это и есть стратегия. А 80% – это обычная операционная эффективность, являющаяся необходимой, но недостаточной для достижения успеха в отрасли. Если наша компания хорошо выполняет эти 80%, то ее просто допускают на «футбольное поле». Если компания желает выиграть, она должная успешнее конкурентов выполнять 15% и к тому же предлагать уникальные ценности (5%), которые умеет делать только она одна.

Приведем несколько примеров формирования стратегических целей и выбора показателей в проекции «Бизнес-процессы»:

  • «Ускорить время обслуживания клиента» (индикаторы – среднее время обслуживания клиента и объем отгрузок в течение первых 48 часов после момента поступления заявки);
  • «Оптимизировать систему закупок по А-ресурсам» (индикаторы – оборачиваемость склада по А-позициям, доля входного брака по А-позициям);
  • «Ускорить процесс инсталляции А-продуктов» (индикатор – среднее время инсталляции А-продуктов);
  • «Улучшить систему послепродажного сервиса» (индикатор – индекс удовлетворенности клиента сервисным обслуживанием (опрос));
  • «Освоить новые виды продуктов и услуг, смежных с существующими видами» (индикаторы – число новых видов продукции и услуг, объем продаж по новым видам продукции и услуг);
  • «Увеличить покрытие рынка с помощью развития региональных подразделений и агентской сети» (индикатор – число региональных подразделений и партнеров-агентов).

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

Цели и показатели проекции «Персонал / Инфраструктура»

Достижение целей в проекциях «Финансы», «Клиенты» и «Бизнес-процессы» базируется на качестве персонала, работающего в компании и на качестве инфраструктуры, которой компания располагает. Иными словами, кадры решают все. Но для достижения целей в проекции верхнего уровня нужны не только высококвалифицированные и удовлетворенные своим положением сотрудники, но и развитая инфраструктура. Под инфраструктурой может подразумеваться оборудование, здания, транспортный парк, информационные системы, программное обеспечение, лицензии. Единого мнения среди экспертов в отношении того, как должна именоваться «низовая» (или находящаяся в фундаменте) проекция, нет. Авторы методологии Р. Каплан и Д. Нортон предлагают термин «Обучение и рост» (англ. «Learning & Growth»), глава консалтинговой компании Horvath&Partners П. Хорват (P. Horvath) использует термин «Потенциал» (нем. «Potenzial»). Встречаются также такие варианты, как «Сотрудники» или «Инновации (Развитие)». Использование названия «Персонал / Инфраструктура» базируется на предположении о том, что компания сможет достичь цели в проекциях «Финансы», «Клиенты» и «Бизнес-процессы» тогда, когда будет располагать и качественным персоналом, и качественной инфраструктурой.

При этом «качество» персонала связано с достаточно широким спектром факторов, к числу которых можно отнести:

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

«Качество» инфраструктуры в этой проекции обычно рассматривается в контексте технических характеристик, возможностей и ограничений. Например, производственную компанию будут интересовать производительность оборудования, возможность его быстрой переналадки, степень изношенности мощностей, степень автоматизации. Торговая компания в этой проекции может рассматривать аспекты, связанные с широтой региональных торговых сетей или емкостью своих складов. Универсальный аспект инфраструктуры – программное обеспечение (гибкость, оперативность предоставления управленческой информации) или веб-страница (дизайн, технологичность). Следует разделять технические возможности инфраструктуры и степень использования этих возможности самой компанией. Например, на одном и том же оборудовании можно пошить одежду разного качества. Это, в том числе, зависит от совести работника. Другими словами, то, насколько хорошо компании удается использовать возможности своей инфраструктуры (равно как и своих сотрудников), рассматривается уже в проекции «Бизнес-процессы». По сути, в проекции «Персонал \ Инфраструктура» речь идет о потенциале. То, как именно этот потенциал используется, можно понять по показателям проекций «Бизнес-процессы», «Клиенты» и «Финансы». Ряд показателей, характеризующих ситуацию с персоналом, можно рассчитать на основе объективных количественных данных. К числу таких показателей можно, например, отнести текучесть кадров, среднюю заработную плату (в том числе ключевых специалистов), размер социального пакета, число рационализаторских предложений, заболеваемость, % курящих сотрудников, производительность («выработка») сотрудников. Но такие показатели в системе Balanced Scorecard, как правило, дополняются «субъективными» показателями, значения которых рассчитываются на основе имеющихся данных качественного характера. Такие данные, как правило, появляются после проведения опросов или тестирования. К подобным «качественным» показателям можно отнести индекс удовлетворенности персонала, средний балл по результатам профессиональной аттестации или балльную оценку персонала по методу «360 градусов». Подобного рода балльные оценки, рассчитываемые на основе опросов и тестирования, являются очень популярным методом количественного измерения целей проекции «Персонал».

Далее рассматриваются несколько примеров определения стратегических целей и показателей в проекции «Персонал / Инфраструктура»:

  • «Повышать квалификацию и взаимозаменяемость персонала» (индикаторы – сумма затрат на повышение квалификации персонала, средний балл по результатам профессионального тестирования, число должностей, на которых могут работать минимум 2 равноценных сотрудника);
  • «Улучшать коммуникации внутри подразделений и между подразделениями» (индикатор – индекс удовлетворенности сотрудников внутрифирменной коммуникацией);
  • «Внедрить CRM-систему» (индикаторы – технические характеристики программного обеспечения, число сотрудников, работающих в CRM-системе);
  • «Обновить парк производственного оборудования (индикаторы – отклонение от план-графика и бюджета).

Причинно-следственные связи между целями и показателями

Завершающим этапом работы по построению системы целей и показателей верхнего уровня является формирование причинно-следственных цепочек целей – как внутри проекций, так и между проекциями. Отражение связей между отдельными целями призвано дать ответ на вопрос, для чего именно реализуется та или иная цель в компании. При этом соблюдается общая направленность – достижение целей в проекции «Персонал / Инфраструктура» служит залогом успеха в достижении целей во всех остальных проекциях, в особенности в проекции «Бизнес-процессы». Достижение целей в проекции «Бизнес-процессы», в свою очередь, необходимо для достижения целей в проекциях «Клиенты» и «Финансы». Кроме того, как правило, прописываются связи между проекциями «Клиенты» и «Финансы», поскольку свои деньги компания, в конечном итоге, получает от своих клиентов. Важно понимать, что в системе стратегических целей компании нецелесообразно отражать все возможные связи между отдельными целями, поскольку это превратит систему целей в «нечитабельное нагромождение». В системе целей должны быть отражены лишь ключевые связи между стратегическими целями. Кроме того, логичным будет соблюдение следующего принципа – каждая из целей проекций «Персонал / Инфраструктура», «Бизнес-процессы» и «Клиенты» должна иметь хотя бы одну исходящую стрелочку, что означает, что исполнение данной цели способствует достижению другой. Достижение целей в этих проекциях рассматривается в конечном итоге как средство достижения финансовых целей. Проекция «Финансы» находится в самом верху системы целей компании, а потому реализация всех целей компании должна в конечном итоге способствовать достижению поставленных финансовых целей. При построении причинно-следственной цепочки целей речь идет о том, чтобы разъяснить менеджерам, почему должны быть достигнуты те или иные цели. Поэтому вопрос звучит не как «На какие цели влияет рассматриваемая цель Х?», а как «Почему должна быть достигнута цель Х?». Например, по цели «Сократить время поставок клиентам» причинно-следственная цепочка системы целей должна давать ответ не на вопрос «На какие другие цели влияет сокращение времени поставок?», а на вопрос «Почему именно нам нужно сократить время поставок?». Это, на первый взгляд, незначительное отличие, оказывает значительное влияние на формат причинно-следственной цепочки целей. По сути, причинно-следственная цепочка целей является ничем иным, как графическим методом описания стратегии компании. Продемонстрируем несколько примеров стратегических карт, позволяющих визуализировать причинно-следственные цепочки целей.

Пример из практики. Стратегическая «карта» (Strategy Map) целей компании-производителя лазерной техники Реализация стратегии в цикле стратегического управления компанией Пример из практики. Стратегическая «карта» (Strategy Map) целей компании-производителя кухонной мебели Реализация стратегии в цикле стратегического управления компанией

Целевые значения показателей/индикаторов

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

  1. стратегические цели компании, сформулированные в проекциях «Финансы», «Клиенты / Продукты», «Бизнес-процессы» и «Персонал / Инфраструктура» (рекомендуемое количество целей – примерно двадцать);
  2. показатели, в измеримом количественном виде описывающие степень достижения стратегических целей (каждую цель могут описывать один или несколько показателей);
  3. причинно-следственные связи между отдельными целями (отображаемые, как правило, в виде стрелок);
  4. целевые значения показателей.

Что такое целевое значение показателя и как его выбрать? Целевые значения показателей должны быть, с одной стороны, труднодостижимыми, но в то же время не слишком сложными. Другими словами, начинающий штангист не должен сразу ставить себе целью поднять вес, доступный лишь ограниченному числу призеров олимпийских игр. Гадкий утенок только в сказках через пару секунд превращается в прекрасного лебедя. Определив достижимые финансовые цели (бизнес «на миллион» и бизнес «на миллиард»), компании задумываются о значениях показателей в проекциях «Клиенты», «Бизнес-процессы» и «Персонал / Инфраструктура», которые будут достаточны для достижения целевых значений финансовых показателей. Если мы хотим продавать на сумму … евро, то какой максимальный срок выполнения заказа и максимальную долю брака мы можем себе позволить? А если нам нужна доля брака ниже … %, то персонал с какими компетенциями нам понадобится? Особенно на первом этапе построения систем управления по целям и показателям очень важно построение системы сбора информации о текущих значениях показателей в целях возможной корректировки целевых значений, если они излишне завышены или занижены. В ряде случаев компании выбирают показатели, по которым никогда не собиралась фактическая информация. Тогда первым шагом в определении целевого значения становится попытка измерить сегодняшнее значение показателя и принятие решения, насколько в стратегической перспективе оно может быть улучшено. Для этого уже на этапе формулирования показателей и определения их новизны назначаются лица, ответственные за сбор информации о текущем значении этих показателей и ее представление рабочей группе проекта.

Разработка стратегических мероприятий

На предыдущем этапе мы определились с набором стратегически значимых индикаторов и выявили, какое целевое значение должен принять каждый из них в стратегической перспективе. Конкретизация того, как именно компания собирается достигать целевой «планки», происходит на следующем этапе – этапе разработки мероприятий (проектов, программ, планов действий), способствующих их достижению. Для каждой цели, сформулированной в проекциях «Клиенты», «Бизнес-процессы» и «Персонал / Инфраструктура», определяются ключевые мероприятия, необходимые для достижения целей. Что касается финансовых целей, то на их достижение, как правило, работают мероприятия, сформулированные в других проекциях. Например, такие мероприятия, как «Поиск более дешевых поставщиков» или «Увеличение цен», хотя и имеют влияние на финансовые показатели, относятся к целям, сформулированным в проекциях «Процессы» и «Клиенты». Однако существуют и такие мероприятия, реализацию которых можно напрямую увязать с той или иной финансовой целью. Например, достижению стратегической финансовой цели «Улучшить структуру затрат на капитал» будет способствовать реализация мероприятий «Привлечение заемного капитала» или «Увеличение доли собственного капитала». По каждому из разработанных мероприятий важно определить перечень всех подразделений (должностей), участвующих в реализации мероприятия, а также фамилию ответственного. Такая работа являет собой завершение процесса каскадирования – создания конкретного плана действий для каждого подразделения и даже отдельного сотрудника. Таким образом, ССП призвана устранить разрыв между стратегией, сформулированной на верхнем уровне, и каждодневной оперативной деятельностью сотрудников низовых подразделений. Принцип «цели + показатели + целевые значения показателей + система поддерживающих стратегических мероприятий», сформулированные в четырех проекциях («Финансы», «Клиенты», «Бизнес-процессы», «Персонал \ Инфраструктура») применим как к компании в целом, так и для отдельных структурных подразделений. Приведем ряд целей и показателей, использующихся подразделениями реальных компаний. Таблица 2. Индикаторы достижения целей Реализация стратегии в цикле стратегического управления компанией

Подразделение как мини-предприятие

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

Декомпозиция стратегии

Прямое перенесение цели предприятия на уровень стратегии подразделения

Рассмотрим несколько примеров, демонстрирующих, как декомпозируются цели верхнего уровня на цели подразделений прямым перенесением ее на уровень подразделения. Уже на этапе представления стратегии в виде системы стратегических целей удобно представить их в виде таблицы и проследить, на какие подразделения ложится основной груз исполнения стратегии (см. ниже). Примечание: ХХ – ответственность Х – участие Примеры

Пример 1. Сбалансированная система показателей (Balanced Scorecard) компании-производителя кухонной мебели

Пример 2. ССП и ее декомпозиция в компании-производителе обуви

Пример 3. ССП и ее декомпозиция в компании-производителе лазерной техники

Пример 4. ССП и ее декомпозиция в компании-производителе кухонной мебели

Каскадирование стратегии на вспомогательные подразделения

В отдельных случаях прямое каскадирование или перенос цели компании в разряд целей подразделения невозможен. Тогда формулирование ключевых стратегических целей и показателей подразделения (как правило, это касается обслуживающих подразделений), напрямую зависит от того, каким образом они могут удовлетворить их основных внутренних клиентов и создать дополнительную ценность для организации в целом. В качестве примера приведем обобщенную модель стратегической карты HR-подразделения, приведенную в книге Р. Каплана и Д. Нортона «Стратегическое единство». Рис. 8. Шаблон стратегической карты HR-подразделения

Глубина декомпозиции/каскадирования стратегии

Один из основных вопросов – это глубина каскадирования. После формирования «карты» стратегических целей, индикаторов и ключевых мероприятий верхнего уровня подобные «карты» строятся для основных «замов» генерального директора – по производству, маркетингу, снабжению, финансам или курируемых ими направлений бизнеса либо подразделений. Разумеется, вторые лица компании обязаны знать и понимать стратегию компании в целом и свой вклад в ее реализацию. Но целесообразность дальнейшего каскадирования (на третий, четвертый и т.д. уровень иерархии) для многих руководителей находится под сомнением. Один из моих знакомых (директор строительной компании) сказал мне, что слово «стратегия» главный инженер его компании отождествляет с игрой, которая продается в магазине «Детский мир». И не больше. Но, создавая «карту» целей, показателей и мероприятий для своего главного инженера (второй уровень в иерархии), директор надеется убедить его в том, что стратегия – это не только настольная игра, но и фактор выживаемости бизнеса в условиях обостряющейся конкуренции. В перспективе директор надеется дойти также до прорабов (третий уровень в иерархии). Каскадирование на четвертый уровень (рабочие, каменщики, маляры) представляется ему бесполезным занятием. Обоснование – низкий уровень образования и общей культуры этих сотрудников («они вообще таких слов, как стратегия, не знают») и отсутствие лояльности к компании («сегодня они у меня работают, а завтра – в другую компанию перебежали»). Среди других причин отказа от «глубокого» каскадирования называются также стремление сохранить определенную степень конфиденциальности стратегии компании («знакомить всех сотрудников компании со стратегией – это лить воду на мельницу конкурентов») и значительные затраты времени и ресурсов на составление подобных «карт» для структурных подразделений. Первый довод критики не выдерживает – если стратегию не знают те, кто ее должен реализовывать, она реализована не будет. Что касается второго довода, то мнений здесь может быть много. Есть мнение, что все менеджеры делятся на два типа: первый всегда спрашивает «А сколько это будет нам стоить?», а второй – «А что это нам принесет?». Проблема заключается в том, что сумму «знаменателя» (затраты на проект) более-менее точно оценить можно, а сумму «числителя» (эффект от внедрения проекта в стоимостной форме) – нет. Речь можно вести о повышении управляемости компании, об уменьшении числа конфликтов, о том, что руководитель вместо 20 минут на обеденный перерыв после внедрения системы Balanced Scorecard стал позволять себе целых 40… Очевидно, что идея о необходимости доведения стратегии до сотрудников вполне успешно была реализована в большой организации с названием «Советский Союз» (стратегическая цель строительства социализма (коммунизма) была известна каждому сотруднику организации, и рядовой шахтер четко понимал, что тонны добываемого им в единицу времени угля необходимы для достижения этой высокой цели). Знаменитая притча о трех строителях тоже иллюстрирует важность знания стратегии сотрудниками. Некий мудрец наблюдал за тем, как люди выполняют одну и ту же работу: возят тележки с камнем. Он спросил у одного из них: — Что ты делаешь? — Я вожу эти проклятые камни, потому что это воля моего хозяина, – ответил тот. Мудрец задал вопрос второму: — Что ты делаешь? — Я зарабатываю деньги, мне нужно кормить семью. И мудрец спросил третьего: — А ты что делаешь? — Я строю Храм! – ответил он. Другим словами, уже сам по себе факт коммуницирования стратегии сотрудникам уже служит для них мотивирующим фактором («мне понятно, куда мы движемся и что будет с компанией через 3 года»).

Стратегически значимые семейства должностей

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

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

Во-первых, сразу для всех работников организации разрабатывать систему задач, поддерживающих реализацию стратегии, – дело затратное и труднореализуемое. Поэтому рекомендуется начинать разработку персональных целей и планов развития с наиболее значимых для реализации стратегии работников, то есть занимающих так называемые стратегически значимые должности, которые могут быть легко определены в результате анализа основных стратегических инициатив. Практика показывает, что количество работников, занимающих стратегически значимые должности, не превышает 5-10% от общей численности персонала. Если стратегически значимые должности выделены, то можно оценить, насколько сегодняшние работники готовы к выполнению стратегически значимых задач, выявив их текущие компетенции и сравнив их с компетенциями, которые будут им необходимы для реализации стратегии организации. Итак, если выделена целевая группа стратегически значимых работников, то можно переходить к постановке личных целей и задач, которые в обязательном порядке должны включать и цели саморазвития. На этом этапе трансляции стратегии в массы может встать вопрос и о найме людей с новыми для организации компетенциями, и о построении/модификации системы обучения в компании.

Как подойти к формированию и согласованию личных и организационных целей?

В качестве примера приведем рекомендации по процедуре разработки персональных ССП в сети отелей Hilton.

Шаг 1. Попросите Вашего подчиненного проанализировать, какие стратегические цели перспектив «Клиенты» и «Внутренние процессы» ССП Вашего подразделения непосредственно связаны с его деятельностью, и детализировать их. К примеру, одной из стратегических целей Hilton Hotels является «Оптимизировать ключевые бизнес-процессы». Для руководителя хозяйственной службы она может быть детализирована как «Ускорить процедуру регистрации вновь прибывших постояльцев» или «Улучшить коммуникации между ресепшн и работниками хозяйственной службы».

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

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

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

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

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

Мотивация персонала и реализация стратегии

Дополнительная мотивация у сотрудника появляется тогда, когда он понимает, что лично он должен делать для реализации стратегии. Но мотивация становится еще более сильной, если достижение стратегических целей подкрепляется финансовой (зарплата, премия) или нефинансовой (дополнительный отпуск, доска почета, обучение) компенсацией. Как уже было отмечено, сам по себе факт наличия «карты» целей, показателей и мероприятий, объясняющих сотруднику его вклад в реализацию стратегии компании в целом, уже является значимым мотивирующим фактором. Вопрос о прямой связи значений показателей и суммы заработной платы – вопрос сложный. Важно понимать, что 2%-ое отклонение от целевого значения показателя X с точки зрения компании в целом может быть более проблемным, чем 10%-ое отклонение по показателю Y. Поэтому при проработке вопроса о связи системы целей и показателей с системой мотивации часто используют систему весов, присваиваемых отдельным показателям. Представим себе, что топ-менеджеры пришли к соглашению относительно индикаторов, которые будут демонстрировать, что компания движется к исполнению стоящих перед ней целей. Во многих случаях экспертная оценка позволит определить, что не все показатели в равной степени будут влиять на достижение той или иной цели. В данном случае логично присвоить каждому из них определенный вес, что делается, как правило, с использованием метода экспертных оценок. Сумма всех весов показателей достижения каждой конкретной цели должна составить 100%. Текущая оценка положения дел позволит управленцу оценить, насколько близка организация к достижению целевого значения показателя с учетом весов каждого из показателей. К примеру, для цели «Сократить удельную себестоимость продукции» можно построить следующую таблицу:

Таблица 3. Степень реализации цели «Сократить удельную себестоимость продукции» с учетом весов

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

Таблица 4. Степень реализации стратегииТаблица 5. Степень реализации стратегии с учетом весовых коэффициентов.

(Стрелочки «вверх» демонстрируют, что для достижения цели показатель должен увеличиваться, соответственно, «вниз» – уменьшаться). Мы видим, что при учете весов показатели степени достижения цели меняются. Важно также не допустить в компании ситуации, которая имело место быть на одном из кораблей, капитан которого премировал матросов за каждую пойманную крысу. Построенная им система мотивации привела к тому, что матросы стали активно разводить крыс с целью максимизации выручки от их реализации … При построении системы мотивации, связанной с системой Balanced Scorecard, часто приходится решать следующую дилемму. С одной стороны, система мотивации должна, по возможности, учитывать достижение всего спектра целей (в противном случае сотрудники могут концентрироваться на достижении целей, к которым система мотивации привязана, и оставлять без внимания прочие цели), а с другой – система мотивации должна быть простой и понятной (а значит, связанной с ограниченным числом показателей). В качестве компромиссного вариант можно предложить «завязывание» ежемесячной суммы заработной платы сотрудника на 3-5 ключевых показателей, а периодические (квартал, полгода, год, окончание проекта) могут быть привязаны к более широкому числу показателей. Кроме того, приходится учитывать специфику уровня в организационной иерархии и характера выполняемой работы. К примеру, должность главного маркетолога традиционно характеризуется как творческая. Он, условно говоря, может неделями не появляться в офисе, а раз в квартал выдавать «на гора» очередную гениальную идею, резко увеличивающую конкурентоспособность компании. И для таких сотрудников многие компании используют очень простую систему мотивации – большой оклад (+ премии за идеи) или увольнение. А система мотивации сотрудников, к примеру, распиловочного участка может быть более сложной – включать в себя определенную сумму фиксированного оклада, премии за достижение целевых значений определенных показателей (например, число рацпредложений, выработка на число сотрудников, стоимость заказов, выполненных вовремя, % экономии бюджета) и штрафы за определенные значения других показателей (например, доля брака, объем отходов, стоимость внепланового ремонта оборудования по вине отдела, число внутренних рекламаций). Надо отметить, что существуют системы мотивации, основанные на принципе «кнута и пряника» (и штрафы, и премии), существуют также системы, отказывающиеся от «кнута» (только «пряник» – премии) или отказывающиеся от «пряника» (только «кнут» – штрафы). И все они могут быть «самыми подходящими» в определенных ситуациях и могут строиться на основе системы целей и показателей Balanced Scorecard. Интересен также вариант трехуровневой системы мотивации, учитывающий достижения конкретного сотрудника (1-ый уровень), достижения его отдела (2-ой уровень) и достижения компании в целом (3-ий уровень). Д. Нортон и Р. Каплан провели исследования, показавшие, что оптимально вводить в систему компенсации вознаграждение, напрямую связанное с показателями результативности деятельности конкретного работника, можно не ранее чем через 2 года после запуска системы управления по целям и показателям, так как часто именно в первые два года сама система претерпевает серьезные изменения: исключаются невалидные показатели, корректируются цели и т.д. Как правило, сегодняшние компании вводят так называемый «фантомный» или виртуальный период начисления вознаграждения «по целям», чтобы минимизировать тревожность работников. Количественное выражение бонусов «по результатам» в практике современных компаний может существенно различаться – это может быть фиксированная сумма доплаты либо процент от оклада.

Рисунок «Структура системы компенсации компании-автопроизводителя»

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

Оптимальное количество и качество показателей ССП

При формулировке стратегических целей компании в целом обычно следуют принципу, предложенному Р. Капланом – «Twenty is Plenty» («двадцать – достаточно»). Иными словами, число ключевых целей в «карте» компании в целом не должно превышать двадцати (обозримое число ключевых аспектов деятельности). При составлении «карт» для структурных подразделений рекомендуется соблюдать этот же принцип. Другими словами, у главного логистика, директора по маркетингу или финансового директора и курируемых ими подразделений тоже есть примерно 20 целей, к достижению которых он стремится. Поскольку одна цель может измеряться и описываться не одним, а несколькими индикаторами, то число индикаторов в «карте», особенно на первом этапе, может насчитывать и 40, и 60 показателей. Их полный перечень необходим менеджеру того или иного структурного подразделения для всесторонней оценки своей «вотчины», но оценивать его работу по всем этим показателям вряд ли целесообразно. Во-первых, некоторые показатели просто информируют о том, в каком состоянии пребывает та или иная организационная единица, но не связаны напрямую с эффективностью деятельности сотрудников этой единицы. Например, степень изношенности недавно приобретенных в распиловочный участок пилорам (уже бывших в употреблении в другой компании) может интересовать генерального директора (проекция «Инфраструктура»), но вряд ли может быть использована для оценки результатов деятельности этого структурного подразделения (в отличие, скажем, от доли брака, числа внутренних рекламаций или объема заказов, выполненных вовремя). Во-вторых, слишком большое число показателей – «не есть хорошо» с точки зрения «читабельности» информации. Здесь уместно вспомнить известный принцип Парето и предположить, что рассмотрение 20% от всего перечня показателей позволяет оценить 80% успеха той или иной организационной единицы. Другими словами, из всего перечня показателей того или иного подразделения рекомендуется отобрать ключевые, а остальные – считать дополнительными. Ключевые показатели того или иного структурного подразделения с определенной периодичностью просматривает вышестоящее руководство, а полный их перечень (вместе с дополнительными) необходим сотрудникам этого подразделения для своевременного и качественного выполнения своих задач (в пределах установленных бюджетов).

Вопросы о «шаблонных» целях и показателях

Распространенные вопросы, связанные с каскадированием: «Существуют ли «типичные» системы целей, показателей и мероприятий для отдела логистики, финансового отдела, отдела IT, отдела маркетинга и т.д.? Является ли ССП водителя, работающего в бизнес-школе, идентичной ССП водителя, работающего в телекоммуникационной компании?» Чтобы ответить на эти вопросы, надо вспомнить, для каких целей компании используют сбалансированную систему показателей. Основная цель этой системы – коммуницирование разработанной стратегии сотрудникам компании. А стратегия всегда связана с уникальностью. Если компания конкурирует с другими компаниями за ограниченный ресурс – клиентов, – то ей нужно располагать определенными специфическими преимуществами по сравнению с конкурентами. Эти преимущества должны побуждать клиентов покупать продукт (услугу) именно у этой компании. И если у компании нет какого-либо особенного преимущества (уникальности) по сравнению с ее конкурентами, то у нее нет и шансов на выживание. Именно непохожесть компании на своих конкурентов является залогом ее успеха. В создании такой непохожести многие эксперты видят ядро стратегии. Чтобы компания могла быть успешной, должна существовать уникальная ценность для клиента, которую только эта компания предлагает на том или ином рынке. Таким образом, каждая стратегия – уникальна. А раз уникальной является стратегия, то уникальной будет и система стратегических целей, показателей и мероприятий верхнего уровня. Соответственно, уникальными будут и системы целей, показателей и мероприятий структурных подразделений. Разумеется, нельзя говорить о том, что система Balanced Scorecard водителя, работающего в бизнес-школе, будет кардинально отличаться от системы Balanced Scorecard, работающего в телекоммуникационной компании. Их «карты» будут в какой-то части похожими (идентичными), но в какой-то – отличными. Например, водителю, работающему в бизнес-школе, необходимы минимальные знания английского языка, поскольку ему часто приходится ездить в аэропорт и встречать там многочисленных иностранных партнеров. А водитель телекоммуникационной компании, к примеру, обязан каждодневно содержать в идеальной чистоте автомобиль, раскрашенный в фирменные красно-желтые цвета, поскольку это является частью маркетинговой стратегии компании. Однако стоит отметить, что ряд одинаковых показателей вполне обоснованно может использоваться самыми различными компаниями, только целевые значения этих показателей будут сильно варьироваться в зависимости от специфики деятельности использующих их организаций. Так, финансовые и временные затраты на обучение одного сотрудника в течение периода будут достаточно высокими в консалтинговой компании, и более скромными – в розничной торговле. Ряд подобных показателей компании можно использовать в целях бенчмаркинга, сравнивая себя с конкурентами. В изданных на русском языке книгах Д. Нортона и Р. Каплана вниманию читателя предлагаются шаблонные стратегические карты как отдельной компании, так и ключевых ее вспомогательных подразделений (управление персоналом, IT, управление финансами). Практика показывает, что эти обобщающие опыт различных предприятий шаблоны лучше использовать для аудита разработанных внутри компании стратегических карт и систем показателей, так как в противном случае понижается степень инновационности решений, предлагаемых членами рабочих групп по созданию и каскадированию стратегии. Заключение Процесс каскадирования/декомпозиции стратегии, ее коммуникации и трансляции до каждого рядового сотрудника призван обеспечить практическую реализацию знаменитого принципа, изложенного идеологом сбалансированной системы показателей, – «Make Strategy everyone’s everyday job» («сделать стратегию ежедневным делом каждого сотрудника»). Стратегия компании будет жизнеспособной только в том случае, когда каждый сотрудник компании (включая уборщицу и водителя) будет четко понимать, какой именно вклад он вносит в достижение стратегических целей бизнеса в целом и как от этого зависит его заработная плата и личный успех, а также будет иметь возможность развить необходимые для исполнения организационной стратегии компетенции. Ключевые управленческие компоненты реализации стратегии можно представить следующим образом: … Таким образом, создание сильной команды, способной преобразовать стратегический план в конкретные действия – вот залог успешной реализации стратегии.

Примечания по MBO

Выделим преимущества MBO:

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

Определим пять базовых принципов MBO:

  1. 1. Цели разрабатываются не только для организации, но и для каждого ее сотрудника. Причем цели сотрудников должны напрямую вытекать из целей организации.
  2. Цели разрабатываются «сверху вниз» для обеспечения связи со стратегией и «снизу вверх» для достижения релевантности к сотруднику
  3. Участие в принятие решений. Процедура разработки целей для сотрудника — это процесс его совместного творчества с непосредственным руководителем. В системе МВО цели не просто «спускаются сверху», они действительно разрабатываются начальником и подчи-ненным совместно. В ходе обсуждений и руководитель, и подчиненный начинают лучше понимать, что именно необходимо делать и каким образом.
  4. Оценка проделанной работы и постоянная обратная связь
  5. Все цели должны соответствовать правилу «SMART», тогда их можно использовать для построения эффективной системы мотивации персонала.

Основными элементами и этапами Управления по целям являются:

  1. Планирование деятельности и постановка индивидуальных целей (инструмент — Дерево целей).
  2. Текущий контроль за результатами деятельности и обмен информацией (обратная связь).
  3. Промежуточная и итоговая оценка результатов деятельности персонала (инструменты — BSC и KPI).

Внедрение MBO осуществляется в 4 этапа:

  • планирование изменений;
  • начало работ;
  • внедрение изменений;
  • завершение изменений.

Использованная литература

  1. Управление реализацией стратегии и оценка эффективности.pdf
  2. Семинар — Разработка и реализация стратегии и сбалансированной системы показателей в банке.ppt

Что нужно знать и уметь бизнес-аналитику?

Для начала хочу описать как я понимаю профессию бизнес-аналитика. Лично я вижу специализацию бизнес-аналитика в двух плоскостях — в бизнесе и в сфере ИТ. На мой взгляд — это два принципиально разных по навыкам специалиста.

1. Бизнес-аналитик в сфере ИТ

Бизнес-аналитик — это разносторонний специалист, который должен уметь:

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

Советы по оформлению любой документации

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

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

2. Как документировать скрипты системы:

  • В документе должно находиться общее концептуальное описание последовательности запусков тех или иных скриптов
  • Можно представить карту вызова скриптов из компонентов системы, можно сделать некую «карту» по скриптам (mindmap)
  • Сами скрипты в документе описывать не надо. Скрипты должны быть самодокументируемыми, т.е. в коде должны быть комментарии, которые заполняются разработчиками (в том числе для разъяснения бизнес-смысла скрипта)

3. Всегда стремитесь к балансу между картинками и текстом. Отсутствие или избыток картинок — не самые лучшие варианты оформления документации

Отношения с подчиненными

  • Неважно какую должность Вы занимаете и сколько опыта у Вас — уважайте своих подчиненных, обсуждайте трудности, нехватку знаний или проблемы в работе. Не обвиняйте их, иначе при любой возможности они свалят от Вас (именно свалят и не будут даже думать о возникших резко у Вас трудностях при потере специалиста).
  • Ставьте задачи правильно и корректно
  • Обсуждайте с подчиненным всегда заранее о необходимости задержаться на работе — помните, что у подчиненных есть личная жизнь и свободное время, которое они не обязаны тратить на работодателя (либо Вы будете всегда работать с не очень выдающимися специалистами, т.к. хорошие сотрудники при случае свалят 😉 )
  • Многое другое можно найти в опубликованных материалах стратоплан.ру (участвовал в их конференциях и семинарах — и Вам советую)

Как устроиться работать бизнес-аналитиком

1. Открываем HeadHunter;
2. Находим 20 вакансий по бизнес-анализу;
3. Выписываем из них главные пункты, которых ожидают от бизнес-аналитиков;
4. Составляем список 7 наиболее важных (общих для всех вакансий), которыми Вы не владеете;
5. Изучаем быстро за неделю;
6. Идем на собеседование (получаем обратную связь);
7. Учим дальше;
8. Повторяем цикл пунктов 6-7-6-7-… до тех пор, пока не устроитесь;
9. Сначала идите на совеседование в те компании, устроиться в которые Вы не хотите (чтобы не потерять шанс устроиться в хорошие компании при плохом исходе собеседования).


Основные положения концепции TQM

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

Традиционная модель управления Элементы Новая модель управления
Вертикальная Организационная структура Горизонтальная
Автократический Стиль руководства Кооперативный
Прибыль Центр внимания деятельности фирмы Клиенты
Самообслуживание Мотивация Разумный эгоизм (реалистический альтруизм)
Внутреннее Рынки Глобальные
Капитал Ресурсы Информация
Однородная Рабочая сила Разнородная
Безопасность Ожидания сотрудников Профессиональный рост
Персональная Организация работы Командная

tqm concept

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

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

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

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

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

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

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

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

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

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

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

  • управление в рамках каждого бизнес-процесса;
  • управление группой бизнес-процессов на уровне всей организации.

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

  • затраты на осуществление;
  • продолжительность осуществления;
  • показатели качества.

На основе этих показателей организация должна определить процессы проектирования, производства и поставки продукции или услуги. В результате традиционное управление результатами процесса переходит в управление самим процессом. Следует так-же помнить, что ИСО 9001 предписывает использовать и некоторые другие процессы (анализ со стороны руководства, корректирующие и предупреждающие действия, внутренние проверки си-стемы качества и т. д.). Следующим этапом на пути к TQM является оптимизация использования ресурсов в каждом процессе. Это означает строгий контроль за использованием каждого вида ресурсов и поиск возможностей для снижения затрат на производство продукции или оказание услуг.

9. Качество поставщиков. Требования к качеству продукции поставщиков предъявляются практически такие же, что и к своей собственной. Для мониторинга поставщиков следует оперативно отслеживать качество их продукции и своевременно отказываться от услуг ненадежных (если это возможно). Целесообразно также налаживать с ними взаимовыгодные отношения, в том числе направленные на определенную регламентацию их действий. На этом этапе устанавливаются документированные процедуры, обязательные для соблюдения поставщиком на всех этапах сотрудничества.

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

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

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

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

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

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

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

  1. проводится обследование производства и подготавливается специальный доклад;
  2. на основе обследования и анализа фактического состояния производства выбирается система менеджмента качества и разрабатывается Программа качества. В Программе находит отражение стратегия обеспечения качества продукции пред-приятия/компании, определяемая на начальной стадии его выполнения задолго до размещения заказов на закупку и постав-ку оборудования. Программа должна предусматривать: организационную структуру, в рамках которой она будет реализовываться; четкое распределение ответственности и уровень полномочий отдельных лиц, групп и организаций, участвующих в решении этой проблемы;
  3. разрабатывается Руководство по реализации Программы качества, в котором описываются сущность и механизм функционирования Системы менеджмента качества;
  4. на специальном совещании с участием консалтинговой фирмы обсуждаются детали, сроки и организация выполнения Про-граммы качества и Руководства, вносятся необходимые исправления и принимаются решения (в том числе по вопросам обучения и аттестации персонала);
  5. мероприятия из Программы и Руководства включаются в общий план предприятия/компании/проекта;
  6. программа качества и Руководство запускаются в производство; специализированная фирма проводит периодические проверки, документально оформляя их результаты и внося необходимые уточнения в указанные документы;
  7. в ходе реализации Программы и Руководства специализированная фирма осуществляет поддержку системы и защиту интересов предприятия. Недопустимо решать вопросы менеджмента качества «в отрыве» от системы управления предприятием/компанией/проектом в целом. Такой подход означал бы, что подразделение, обеспечивающее качество продукции проекта, выполняет свои задачи вне жестких рамок графика и стоимости работ. На практике это приводит к появлению психологии, разделяющей участников проекта на ответственных и без-ответственных. В результате чего персонал, выполнявший основные работы по проекту, практически не несет ответственности за качество. В итоге становится невозможно добиться хорошего качества продукции в целом.

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

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

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

  • специалистам, временно входящим в его команду: в строительстве – инспекторам по качеству;
  • привлекаемой специализированной фирме.

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

Рисунок – Структура менеджмента качества крупной строительной компании

Рисунок 5 – Структура менеджмента качества крупной строительной компании

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

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

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

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

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


Воркшоп (Workshop). План и пример воркшопа

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

План воркшопа «Приложение с аналитикой по магазинам — GCI»

Цели и границы

Цели воркшопа:

  1. Ознакомиться более подробно с приложением GCI.
  2. Понять, какие возможности использования имеются у приложения.
  3. Выявить дополнительные требования, которые не удовлетворены этим приложением. Другими словами понять объем и направление необходимых доработок.

Границы:

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

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

Продолжительность:3 часа

Целевая аудитория: Аналитики отдела снабжения и закупок

Состав воркшопа

Этап 1 «Общая вводная по приложениям GRI и GCI»

Общий этап для двух воркшопов по приложениям GRI и GCI.

Описание результатов и дополнительных требований (см. План воркшопа по GRI).

Этап 2 «Обзор приложения GСI и выявление дополнительных требований»

Предполагаемая продолжительность 3 часа
Цели 1. Получить подробное представление о возможностях приложения GCI;
2. Выявить дополнительные требования к приложению;
3. Оценить достаточность детализации данных;
4. Оценить группировку данных;
5. Оценить достаточность данных для аналитики по магазинам.
Подпункты этапа ——————————————————————————————-
· Шаг 1 Обзор видов анализа в приложении GСI
· Шаг 2 Обзор дашборда приложения GCI (панель с группами KPI)
· Шаг 3 Обзор видов анализа для каждой группы KPI
· Шаг 4 Обсуждение табличного и графического представления данных
· Шаг 5 Обзор показателей в графическом и табличном представлении данных
· Шаг 6 Выявление дополнительных требований:
· Количество пользователей
· Дополнительные KPI
· Интеграция с другими источниками данных (помимо GOLD)
· Требования к скорости доработки приложений
· Требования по ограничению видимости данных разным пользователям
· Требования к объему данных

Описание результатов и дополнительных требований:

Оценка приложения

Приложение GCI оценивается каждым участником в отдельности и затем считается общий балл.

Складская аналитика в приложении GCI 1 = Плохо

5 = Отлично

Участник воркшопа:
1 Глубина детализирования данных для складской аналитики
2 Достаточность показателей KPI
3 Достаточность исторических данных
4 Возможность использования приложения GCI без дополнительных доработок
5 Удобство интерфейса для анализа
6 Общее впечатление от приложения GCI
7 Удовлетворенность параметрами перезагрузки данных (1 раз в сутки, ночью)
ИТОГОВАЯ ОЦЕНКА (сумма/количество):
Дополнительные комментарии:

Скачать План воркшопа по GCI.docx


Scrum Framework

Руководство по скраму (Scrum) — К.Швабер и Дж.Сазерленд

Руководство по скраму (Scrum) — К.Швабер и Дж.Сазерленд

Цель Руководства по Скраму

Скрам (Scrum) – это подход для разработки и поддержки функционально сложных продуктов. Данное руководство содержит определение Скрама. Определение включает в себя описание ролей, мероприятий и артефактов Скрама, а также правил, обеспечивающих связь между ними. Кен Швабер и Джефф Сазерленд разработали Скрам; руководство по Скраму написано и представлено ими. Они являются основателями данного руководства по Скраму.

Общее Описание Скрама

Скрам (Scrum – потасовка, драка за мяч в регби) – это подход, в рамках которого возможно решить сложные адаптивные проблемы, и в то же время продуктивно и с применением творческого подхода разработать продукт наивысшего качества. Скрам является:

  • Легким
  • Простым в понимании
  • Чрезвычайно сложным в овладении

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

Скрам Подход (Scrum Framework)

Скрам состоит из Скрам Команд (Scrum Teams), внутри которых распределены соответствующие роли (roles), а также мероприятий (events), артефактов (artifacts) и правил (rules). Каждый компонент Скрама имеет свое предназначение и является ключевым для успеха и использования Скрама.
Различные стратегии использования Скрама изменяются, и их описание выходит за пределы данного руководства.
Правила Скрама связывают мероприятия, роли и артефакты, регулируя отношения и взаимодействие между ними. Правила Скрама прописаны в данном документе.

Scrum FrameworkТеория Скрама

Скрам основывается на теории управления эмпирическими процессами, или эмпиризме. Эмпиризм утверждает, что знание приходит с опытом и принятием решений на основании того, что является известным. Скрам использует итеративный, инкрементальный подход для оптимизации прогнозируемости и управления рисками.
В основе управления эмпирическими процессами лежат три главных принципа: прозрачность (transparency), проверка (inspection) и адаптация (adaptation).

Прозрачность

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

  • Все участники процесса должны пользоваться общей терминологией, относящейся к процессу;
  • Исполняющие работу и оценивающие ее результат в виде продукта должны иметь единое определение “Готовности”1.

Проверка

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

Адаптация

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

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

  • Планирование Спринта (Sprint Planning Meeting)
  • Ежедневный Скрам (Daily Scrum)
  • Обзор Спринта (Sprint Review Meeting)
  • Ретроспектива Спринта (Sprint Retrospective)

Скрам

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

Скрам Команда

Скрам Команда состоит из

  • Владельца Продукта (Product Owner),
  • Команды Разработчиков (Development Team) и
  • Скрам Мастера (Scrum Master).

Команда Scrum

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

Владелец Продукта

Владелец Продукта ответственен за достижение максимальной ценности продукта и работы, исполняемой Командой Разработчиков. Способы, которыми он этого достигает, могут отличаться и зависят от организаций, Скрам Команд и индивидуумов.
Владелец Продукта является единственным человеком в Команде, отвечающим за Журнал Требований к Продукту (Product Backlog). Управление Журналом Продукта включает в себя:

  • Четкое определение элементов Журнала Продукта;
  • Упорядочение элементов Журнала Продукта для оптимизации достижения целей и поставленных задач;
  • Ответственность за ценность работы, исполняемой Командой Разработчиков;
  • Обеспечение доступности, прозрачности и понятности Журнала Продукта, а также отображения тех требований, над которыми Скрам Команде предстоит работать в ближайшее время.
  • Ответственность за понимание Командой Разработчиков требований Журнала Продукта на надлежащем уровне.

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

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

Команда Разработчиков

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

Командам Разработчиков присущи следующие характеристики:

  • Они самоуправляемы. Никто (и даже Скрам Мастер) не может указывать Команде, как правильно превращать Журнал Продукта в Инкременты работающей функциональности;
  • Команды Разработчиков кроссфункциональны, и обладают всеми навыками, необходимыми для разработки Инкремента продукта;
  • Скрам не признает никаких других должностей в Команде Разработчиков, кроме Разработчика, невзирая на вид работы, выполняемой человеком; у этого правила нет исключений;
  • Отдельные члены Команды Разработчиков могут владеть специализированными знаниями в различных областях, однако ответственность лежит на всей Команде Разработчиков, подразумевающейся одним целым.
  • У Команды Разработчиков нет структурных подразделений, которые бы выполняли отдельные функции, как, к примеру, подразделение тестирования или бизнес-анализа.

Размер Команды Разработчиков

Оптимальный размер Команды Разработчиков должен быть довольно небольшим, чтобы Команда оставалась простой в управлении и в то же время довольно большим, чтобы выполнить значимый объем работы. Если в Команде Разработчиков менее трех человек, взаимодействие уменьшается, что приводит к снижению продуктивности. Кроме того, на определенном этапе Спринта у небольшой Команды может почувствоваться недостаток необходимых знаний, вследствие чего она будет не в состоянии завершить работу над потенциально готовым к выпуску Инкрементом продукта. Если же в Команде более девяти человек, нужно прилагать больше усилий для координации их работы. Большие Команды Разработчиков создают слишком много сложностей для управления эмпирическим процессом. Роли Владельца Продукта и Скрам Мастера не учитываются при подсчете размера Команды Разработчиков за исключением случаев, когда они выполняют работу из Журнала Спринта.

Скрам Мастер

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

Обязанности Скрам Мастера по отношению к Владельцу Продукта

Скрам Мастер во многом помогает Владельцу Продукта, в частности:

  • Обнаруживает методы эффективного управления Журналом Продукта;
  • Сообщает видение, цели и элементы Журнала Продукта Команде Разработчиков;
  • Учит Команду Разработчиков создавать лаконичные и понятные элементы Журнала Продукта;
  • Осуществляет долгосрочное планирование по продукту в эмпирической среде;
  • Понимает и практикует гибкие методы разработки и управления;
  • По требованию или необходимости может выступить ведущим мероприятий Скрама.

Обязанности Скрам Мастера по отношению к Команде Разработчиков

Скрам Мастер во многом помогает Команде Разработчиков, в частности:

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

Обязанности Скрам Мастера по отношению к Организации

Скрам Мастер во многом помогает организации, в частности:

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

Мероприятия Скрама

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

Мероприятия scrum (скрама)

Спринт

Сердцем Скрама является Спринт, с временными рамками (time-boxes) в один месяц или менее, в результате которого создается ценный и потенциально “готовый” к выпуску Инкремент продукта. Длина Спринта является постоянной на протяжении всего периода разработки. Следующий Спринт начинается сразу же по окончании предыдущего.
Спринт состоит из Планирования Спринта, Ежедневных Скрамов, работы по разработке, встрече по Обзору Спринта, а также Ретроспективы Спринта.

Во время Спринта:

  • Не допускается внесение никаких изменений, которые бы повлияли на Цель Спринта (Sprint Goal);
  • Состав Команды Разработчиков и цели по качеству продукта остаются неизменными;
  • Границы, в пределах которых ведется разработка в Спринте, могут быть уточнены и повторно обговорены между Владельцем Продукта и Командой Разработчиков по мере большего понимания.

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

Отмена Спринта

Спринт можно остановить перед окончанием его временных рамок. Только у Владельца Продукта есть право на то, чтобы остановить Спринт, хотя он может сделать это и под влиянием заинтересованных лиц, Команды Разработчиков или же Скрам Мастера.
Спринт отменяют в том случае, если его цели перестают быть актуальными. Это может произойти вследствие изменения направления работы компании, изменения технологий или рыночных условий. В общем, Спринт нужно отменить, если в силу некоторых обстоятельств в нем уже нет необходимости. Однако, принимая во внимание его короткую продолжительность, отмена редко имеет смысл.
При отмене Спринта все выполненные и “готовые” элементы из Журнала Продукта пересматриваются. Их принимают при условии, что они представляют потенциально готовый к выпуску Инкремент функциональности. Все остальные требования переоцениваются и возвращаются в Журнал Продукта. Работа, проделанная над ними, обесценивается быстро, и поэтому требует пересмотра.
Отмена Спринта требует дополнительных ресурсов, так как все члены Команды должны перегруппироваться при Планировании Спринта и приступить к новому Спринту. Отмена Спринта является для Команды неприятным процессом, однако на деле это происходит довольно редко.

Планирование Спринта

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

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

  • Что будет разработано в Инкременте, являющимся результатом работы следующего Спринта?
  • Как максимально эффективно выполнить работу по созданию Инкремента?

Часть первая: Что будет сделано в этом Спринте?

В этой части Команда Разработчиков пытается спланировать функциональность, которая будет разработана во время Спринта. Владелец Продукта представляет Команде Разработчиков упорядоченный Журнал Продукта и вся Скрам Команда старается достичь единого понимания работы, которую предстоит проделать на протяжении Спринта.
Входными для этой встречи являются Журнал Продукта, последний разработанный Инкремент продукта, возможности Команды Разработчиков, а также последний показатель ее продуктивности. Количество элементов из Журнала Продукта, которые Команда способна выполнить до окончания Спринта определяется самой Командой. Только Команда Разработчиков может реально оценить объем работы, который она в состоянии завершить до окончания Спринта.
После того, как Команда Разработчиков спрогнозирует элементы Журнала Продукта, которые она выполнит в данном Спринте, Скрам Команда приступает к формированию Цели Спринта. Цель Спринта – это цель, которая будет достигнута в результате Спринта благодаря реализации Журнала Продукта и которая указывает Команде Разработчиков, почему она работает именно над этим Инкрементом функциональности.

Часть вторая: Как выбранная работа будет проделана?

После того, как объем работы Спринта определен, Команда Разработчиков решает каким образом на протяжении Спринта воплотить отдельную функциональность в “готовый” Инкремент продукта. Требования Журнала Продукта, выбранные для выполнения во время ближайшего Спринта вместе с планом их разработки, называют Журналом Задач Спринта (Sprint Backlog).

Как правило, Команда Разработчиков начинает планировать систему и работу, благодаря которой Журнал Продукта можно превратить в работающий Инкремент продукта. Работа может быть разной степени трудоемкости и сложности. Однако обычно во время Планирования Спринта Команда Разработчиков планирует такой объем работы, который она в состоянии выполнить за Спринт. До окончания этой встречи работа, запланированная Командой Разработчиков на первые дни Спринта, разбивается на требования, которые можно выполнить за день или менее. Команда Разработчиков сама организовывает свою работу, планируя поэтапность выполнения требований из Журнала

Спринта как во время встречи по Планированию Спринта, так и, при необходимости, на протяжении всего Спринта.
Владелец Продукта может присутствовать на второй части Планирования Спринта, чтобы иметь возможность объяснить задания из Журнала Продукта и, при необходимости, помочь найти альтернативы. Если же Команда Разработчиков решает, что у нее слишком много, либо слишком мало работы, она может повторно обсудить требования Журнала Спринта с Владельцем Продукта. Команда может пригласить людей со стороны, чтобы они посоветовали что-то с технической или же экспертной точки зрения.
До окончания встречи по Планированию Спринта Команда Разработчиков должна быть в состоянии объяснить Владельцу Продукта и Скрам Мастеру, каким образом она собирается работать в качестве самоуправляемой команды, чтобы достичь Цели Спринта и создать ожидаемый Инкремент продукта.

Цель Спринта

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

Ежедневные Скрамы

Ежедневные Скрамы – это 15-минутные совещания для Команды Разработчиков с целью синхронизации действий и создания плана работы на ближайшие 24 часа. Это делается для того, чтобы проверить, что нового было сделано со времени проведения прошлого Ежедневного Скрама и спланировать работу, которую можно успеть сделать за следующие 24 часа.
Эти совещания происходят в обусловленном месте в одно и то же время во избежание путаницы. Во время таких совещаний каждый участник Команды Разработчиков рассказывает коллегам о следующем:

  • Что было сделано со времени прошлой встречи?
  • Что планируется сделать до следующей встречи?
  • Что ему мешает в выполнении запланированных заданий?

Члены Команды Разработчиков используют Ежедневные Скрамы для оценки прогресса продвижения к Цели Спринта, а для оценки отклонения от планируемого завершения работ из Журнала Спринта. Ежедневные Скрамы усиливают вероятность того, что Команда Разработчиков достигнет Цели Спринта. Часто Команда Разработчиков встречается сразу же после Ежедневного Скрама для перепланирования оставшейся работы по Спринту. Ежедневно Команда Разработчиков должна быть в состоянии объяснить Владельцу Продукта и Скрам Мастеру как она намеревается работать в качестве самоуправляемой Команды для достижения цели и создания ожидаемого инкремента продукта за время, оставшееся до окончания Спринта.

Скрам Мастер ответственен за то, чтобы Команда Разработчиков не пропускала такие совещания, однако ответственность за проведение Ежедневного Скрама лежит на Команде Разработчиков. Скрам Мастер обучает Команду Разработчиков удерживать время проведения Ежедневного Скрама в границах не более 15 минут.
Скрам Мастер обеспечивает соблюдение того, чтобы участвовали в Ежедневных Скрамах только члены Команды Разработчиков. Ежедневный Скрам не является статус-совещанием, а скорее совещанием для членов Команды, работающей над превращением требований из Журнала Продукта в Инкремент готового продукта.

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

Обзор Спринта

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

Обзор Спринта включает в себя следующие элементы:

  • Владелец Продукта определяет, что является “готовым”, а что нет;
  • Команда Разработчиков вспоминает, что прошло гладко во время Спринта и с чем возникли трудности, а также то, как она с ними справилась;
  • Команда Разработчиков проводит демонстрацию того, что было сделано, и отвечает на вопросы по Инкременту;
  • Владелец Продукта обсуждает состояние Журнала Продукта. Он делает предположения касательно возможной даты окончания проекта, принимая во внимание скорость продвижения работы над ним;
  • Вся Команда принимается за обсуждение того, что делать в дальнейшем, для того чтобы данный Обзор Спринта предоставлял важную входную информацию для последующей встречи по планирования Спринта.

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

Ретроспектива Спринта

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

Целью Ретроспективы Спринта является:

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

Скрам Мастер поощряет Скрам Команду пересмотреть свои процессы разработки в рамках процессов и практик Скрама, чтобы сделать её более эффективной в следующем Спринте. Во время каждой Ретроспективы Спринта Скрам Команда ищет пути улучшения качества разрабатываемого продукта, при необходимости уточняя определение “Готовности”.
До окончания Ретроспективы Скрам Команда должна определить практичные и действенные факторы улучшения процесса работы, которые она реализует в следующем Спринте. Внедрение этих изменений в следующем Спринте как раз и является адаптацией к проверке самой Скрам Команды. Хотя изменения могут быть внесены в любое время, Ретроспектива Спринта является специализированным совещанием, посвященным исключительно проверке и адаптации.

Артефакты Скрама

Артефакты Скрама предоставляются в качестве работы или ценности того, насколько они полезны в обеспечении прозрачности и возможностей для инспекции и адаптации. Определенные Скрамом Артефакты специально спроектированы таким образом, чтобы обеспечить максимальную ясность ключевой информации, необходимой для того, чтобы Скрам Команда достигла успеха в поставке “готового” Инкремента.

Журнал Продукта

Журнал Продукта – это упорядоченный список всего, что может быть нужным в продукте, он является единственным источником требований для любых изменений, которые может потребоваться внести в продукт. Ответственность за Журнал Продукта несет Владелец Продукта, включая его содержание, доступность и упорядочение.
Журнал Продукта никогда не является полным. Начальная версия этого документа содержит только первоначально известные и наиболее понятные требования. Журнал Продукта постоянно обновляется по мере обновления самого продукта и среды, в которой он разрабатывается. То есть Журнал Продукта является динамическим, постоянно изменяющимся для соответствия требованиям продукта, его конкурентоспособности и пригодности. Журнал Продукта существует ровно столько, сколько существует и сам продукт.
Журнал Продукта содержит все свойства, функции, требования, усовершенствования и информацию по исправлению дефектов, то есть те данные, которые и определяют изменения и которые нужно сделать в следующих выпуска продукта. Элементам Журнала Продукта должно присваиваться короткое описание, порядковый номер и оценка объемов работы.
В Журнале Продукта требования часто упорядочены по ценности, риску, приоритетности и необходимости. Наиболее важные требования обрабатываются в первую очередь. Чем выше приоритет требования и чем сильнее потребность в его разработке, тем больше согласованности должно быть по поводу этого требования и его значимости.

Элементы Журнала Продукта с высоким уровнем приоритетности должны быть более понятными и содержать больше деталей, чем менее приоритетные. Более точно можно рассчитать время работы над теми требованиями, которые являются более понятными и содержат больше дополнительной информации. Чем ниже приоритетность, тем меньше деталей. Те требования Журнала Продукта, над которыми Команда Разработчиков будет работать во время текущего Спринта, являются детализированными и разбитыми на части таким образом, что любое из этих требований может быть выполнено и “готово” в рамках одного Спринта. Требования Журнала Продукта, которые можно выполнить и “завершить” в течение одного Спринта считаются “готовыми” и “выполняемыми” для того, чтобы их внесли в план во время следующего Планирования Спринта.
Как только продукт начинает использоваться, его значение возрастает и вызывает ответную реакцию рынка, его Журнал становится более полным и всеобъемлющим. Требования к продукту постоянно изменяются, и поэтому Журнал Продукта – это живой артефакт. Изменения в сфере требований, рыночных условий, технологий и ресурсов приводят также и к изменению Журнала Продукта.

Довольно часто случается так, что над одним продуктом работают несколько Команд. Но всё равно используется только один Журнал Продукта, чтобы определить работу на ближайший период. При этом к элементам Журнала Продукта вводится дополнительный атрибут, позволяющий сгруппировать запросы по Скрам Командам.
Поддержание Журнала Продукта – это деятельность по добавлению деталей, оценок предполагаемых затрат времени, и упорядочивания элементов. Это непрерывный процесс, во время которого Владелец Продукта и Команда Разработчиков детализируют требования Журнала Продукта. Во время обработки требования проверяются и пересматриваются. Однако Владелец Продукта в любое время может изменить статус этих требований.

Поддержание Журнала Продукта – это часть деятельности во время Спринта, исполняемой Владельцем Продукта и Командой Разработчиков. Часто Команды Разработчиков владеют знаниями в нужной области и сами могут осуществить обработку требований. Как и когда сделать обработку требований решает только Скрам Команда. Обработка требований обычно занимает не более 10% времени Скрам Команды.
Команда Разработчиков несет всю ответственность за оценку объемов работы. Владелец Продукта может помочь Команде осмыслить требования и выбрать альтернативы, но конечная оценка зависит только от Команды.

Отслеживание прогресса на пути к Цели

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

Различные графики типа “сколько осталось ”(burndown) и “сколько сделано ”(burnup), отображающие реальное продвижение, отклонение, и ожидаемое движение, а также другие наглядные практики используются для предсказания прогресса. Эффективность этих практик проверена. Однако их использование не заменяет важности использования принципов эмпиризма. В сложной среде очень трудно предсказать, как будут развиваться события. Единственное на что можно положиться при принятии решений о будущей работе, это опыт прошлого.

Журнал Спринта

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

Журнал Спринта определяет объем работы, которую Команда Разработчиков должна выполнить, чтобы превратить Журнал Продукта в “готовый” Инкремент. Журнал Спринта визуализирует ту работу, которую Команда Разработчиков считает необходимой для достижения Цели Спринта.
Журнал Спринта это достаточно детализированный план, чтобы прогресс в его воплощении можно было увидеть на каждом Ежедневном Скраме. Команда Разработчиков вносит изменения в Журнал Спринта на протяжении всего Спринта, и, соответственно, Журнал Спринта постоянно изменяется. Такие изменения происходят потому, что в процессе работы Команда Разработчиков узнает все новые и новые детали о работе, которую нужно выполнить для достижения Цели Спринта.

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

Отслеживание прогресса Спринта

В любое время во время Спринта можно подытожить количество работы, оставшейся в Журнале Спринта. Команда Разработчиков отслеживает оставшееся количество работы, как минимум, во время каждого Ежедневного Скрама. Команда Разработчиков ежедневно отслеживает количество оставшейся работы и вероятность достижения Цели Спринта. Благодаря отслеживанию количества оставшейся работы во время Спринта Команда Разработчиков может управлять прогрессом.
Скрам не принимает во внимание время, потраченное на работу над элементами Журнала Спринта. Единственными ценными показателями являются оставшееся количество работы и конечный срок завершения работы.

Инкремент

Инкремент – это сумма всех выполненных требований Журнала Продукта реализованных во время текущего Спринта и всех предыдущих Спринтов. По окончанию Спринта новый Инкремент должен быть «Готовым», то есть он должен быть пригодным к эксплуатации и отвечать определению Скрам Команды понятия “Готовности”. Несмотря на решение Владельца Продукта выпускать ли эту версию Инкремента, он должен быть готовым к использованию.

Scrum доска/Agile Board

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

скрам доска (scrum board)

Пример доски из жизни:

agile доска

Определение «Готовности»

Когда элемент Журнала Продукта или же Инкремент назван “готовым”, все должны понимать, что означает “Готово”. Хотя это определение разные Скрам Команды интерпретируют по-разному, чтобы гарантировать прозрачность, члены Команды должны иметь общее совместное понимание, что означает, когда работа сделана. Именно такое единое определение понятия “Готовности” используется Скрам Командой для оценки окончания работ над Инкрементом Продукта.
Одно и то же определение помогает Команде Разработчиков в понимании того, сколько требований выбрать из Журнала Продукта во время Планирования Спринта. Целью каждого Спринта является разработка Инкремента потенциально готовой к выпуску функциональности, отвечающей текущему определению “Готовности” Скрам Команды.
По окончанию каждого Спринта Команда Разработчиков представляет Инкремент функциональности продукта. Такой Инкремент является пригодным к эксплуатации, и поэтому Владелец продукта может решить сразу же его выпустить. Каждый последующий Инкремент должен дополнять все предыдущие Инкременты, а также быть тщательно протестирован для обеспечения стабильной работы всех Инкрементов продукта.
По мере увеличения профессионализма Скрам Команды, определение понятия “Готовности” может расширяться более строгими критериями для достижения лучшего качества продукта.

Заключение

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