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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В процессе реализации разработанной стратегии многие компании сталкиваются с определенными трудностями. Одной из типичных проблем является то, что стратегию компании могут внятно сформулировать лишь 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

ba_knowledge

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


tqm_concept

Основные положения концепции 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

Воркшоп (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 доска

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

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

Заключение

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


бизнес-процесс

Бизнес-процесс. Управление и моделирование в BPM (Business Process Management)

Введение в управление бизнес-процессами (Business Process Management, BPM)

Распространенные роли в управлении бизнес-процессами:

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

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

Видео по бизнес-процессам:

Рисунок «Три взгляда на BPM»

Три взгляда на BPM

Усовершенствование бизнес процессов (BPI) – это разовая инициатива или проект, направленный на более полное соответствие стратегии организации и ожиданий клиентов. BPI включает в себя выбор, анализ, проектирование и внедрение усовершенствованного процесса.

Управление процессами предприятия (EPM) – это применение принципов, методов и процессов BPM в конкретной организации. EPM: а) обеспечивает соответствие портфеля и архитектуры сквозных процессов стратегии и ресурсам организации и б) предоставляет модель регулирования для оценки и управления BPM инициативами.

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

Управление бизнес процессами

Что такое управление бизнес процессами (BPM)?

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

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

  1. Бизнес процессы, поддерживающие управление бизнес процессами. Например, у организации должны быть процессы, которые обеспечивают:
    • описание и проектирование бизнес процессов;
    • разработку и внедрение бизнес процессов;
    • мониторинг и контроль исполнения бизнес процессов;
    • непрерывное и постоянное улучшение бизнес процессов, несмотря на и в ответ на внутренние и внешние изменения.
  2. Определенные роли (люди), вовлеченные в управление бизнес процессами . Таковые включают (не ограничиваясь ими) следующие:
    • архитектор процессов, который отвечает за описание и проектирование бизнес процессов;
    • процессный аналитик, который отвечает за построение, внедрение, мониторинг и оптимизацию бизнес процессов;
    • владелец процесса, который отвечает за исполнение бизнес процесса от начала до конца, в соответствии с определенными целевыми показателями эффективности и в конечном итоге за создание ценности для потребителя.
  3. Внедрение специализированных информационных технологий управления бизнес процессами , обеспечивающих следующую функциональность:
    • описание бизнес процессов в контексте корпоративной архитектуры;
    • проектирование бизнес процессов с целью внедрения;
    • исполнение бизнес процессов в контексте операционной деятельности;
    • мониторинг целевых показателей эффективности бизнес процессов;
    • анализ бизнес процессов с целью выявления и оценки возможностей для улучшения;
    • управление изменениями бизнес процесса.

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

Рисунок «Бизнес-процесс»

бизнес-процессКонцепция потребителя во взаимодействии функций внутри организации

Концепция потребителя в бизнес-процессе BPMЦенность в виде проектных спецификаций

ценность в виде проектных спецификацийПример: IТ подразделение фармацевтической компании оказывает услуги бизнес подразделениям. Каждая такая услуга предоставляется посредством бизнес процесса внутри IТ подразделения. Связь поставщик – потребитель сервиса показана ниже. Бизнес-процесс создает ценность для потребителя в форме продукции или услуг. Суть BPM заключается в оптимизации того, как эта ценность создается.

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

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

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

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

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

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

schema_rascheta_kpi_bizness_processa

Категории бизнес-процессов

Бизнес-процессы можно разделить на три категории:

  • Основные процессы – сквозные и, как правило, кросс функциональные процессы, непосредственно создающие ценность для потребителя. Основные процессы также называют ключевыми, так как они представляют собой действия, необходимые с точки зрения выполнения организацией своей миссии. Эти процессы составляют цепочку создания ценности, в которой каждый шаг добавляет ценность к предыдущему, измеряемую вкладом в создание или поставку продукции или сервиса и в конечном счете в создание ценности для потребителя.
  • Вспомогательные процессы предназначены для поддержки основных, обычно через управление ресурсами и/или инфраструктурой, необходимых основным процессам. Разница между основными и вспомогательными процессами в том, что вспомогательные процессы непосредственно не создают ценность для потребителя. Примеры вспомогательных процессов обычно относятся к ИТ, финансам, управлению персоналом. Хотя вспомогательные процессы зачастую тесно связаны с функциональными областями (например, процесс выдачи и отзыва разрешения на сетевой доступ), они могут пересекать функциональные границы и зачастую действительно их пересекают.
  • Процессы управления предназначены для измерения, мониторинга и контроля бизнес деятельности. Они призваны гарантировать, что основные и вспомогательные процессы спроектированы и исполняются в соответствии с поставленными операционными, финансовыми целями, регуляторными и юридическими ограничениями. Как и вспомогательные, процессы управления непосредственно не добавляют ценности для потребителя, но они необходимы для обеспечения соответствия операций целевым уровням производительности и результативности.

Модель зрелости BPM

Модель зрелости бизнес-процессов BPM:

Модель зрелости бизнес-процессов BPM

Моделирование бизнес-процессов

Цели моделирования процессов

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

Процессные модели – это средства:

  • управления процессами организации;
  • анализа эффективности процесса;
  • описания изменений.

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

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

Причины моделирования бизнес-процессов

Процессные нотации

Распространенные процессные нотации:

Процессные нотации

BPMN:
BPMN диаграмма

Диаграмма с дорожками Брюса Силвера:
Диаграмма с дорожками

Блок-схема:
Блок схема

Процессная цепочка, управляемая событиями (EPC):
Процессная цепочка, управляемая событиями (EPC)

UML:
uml

IDEF:
IDEF

Карта потока создания ценности:
Карты потока создания ценностиСпециализированные подходы к моделированию процессов

Специализированные подходы к моделированию процессов:
Специализированные подходы к моделированию процессов

Процессная иерархия

Процессная иерархия:
Процессная иерархия

Основные принципы моделирования бизнес-процессов

Что означает моделирование бизнес-процессов на практике? Моделирование бизнес-процессов в компании может быть направлено на решение большого числа различных задач:

  • Точно определить результат бизнес-процесса и оценить его значение для бизнеса.
  • Определить набор действий, составляющих бизнес-процесс. Ясное определение набора задач и действий, которые необходимо выполнить, чрезвычайно важно для детального понимания процесса.
  • Определить порядок выполнения действий. Действия в рамках одного бизнес-процесса могут выполняться как последовательно, так и параллельно. Очевидно, что параллельное исполнение, если оно допустимо, позволяет сократить общее время выполнения процесса и, следовательно, повысить его эффективность.
  • Произвести разделение зон ответственности: определить, а затем отслеживать, какой сотрудник или подразделение компании несет ответственность за выполнение того или иного действия или процесса в целом.
  • Определить ресурсы, потребляемые бизнес-процессом. Точно зная, кто какие ресурсы использует и для каких операций, можно повысить эффективность использования ресурсов посредством планирования и оптимизации.
  • Понять суть взаимодействий между участвующими в процессе сотрудниками и подразделениями компании и оценить, а затем повысить эффективность коммуникации между ними.
  • Увидеть движение документов в ходе процесса. Бизнес-процессы производят и потребляют различные документы (в бумажной или электронной форме). Важно разобраться, откуда и куда идут документы или информационные потоки, и определить, оптимально ли их движение и действительно ли все они необходимы.
  • Определить потенциальные узкие места и возможности для улучшения процесса, которые будут использованы позже для его оптимизации.
  • Более эффективно внедрить стандарты качества, например ИСО 9000, и успешно пройти сертификацию.
  • Использовать модели бизнес-процессов в качестве руководства для новых сотрудников.
  • Эффективно произвести автоматизацию бизнес-процессов в целом или отдельных их шагов, включая автоматизацию взаимодействия с внешней средой — клиентами, поставщиками, партнерами.
  • Разобравшись в совокупности бизнес-процессов компании, понять и описать деятельность предприятия в целом.

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

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

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

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

Шаги построения модели бизнес-процесса

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

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

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

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

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

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

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

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

Пояснение принципа прослеживания требований

Сбор и анализ требований

Сбор и анализ требований

Первые 90% работы отнимают
10% времени, а последние 10%
— оставшиеся 90% времени.
Правило 90/90

Все требования к проектируемой системе предлагается размещать на нескольких иерархических уровнях. На самом нижнем уровне располагаются требования, которые одинаково подходят для автоматизации технологических процессов в целом без учета особенностей конкретной прикладной области. Здесь необходимо обратиться к ГОСТам и другим нормативным документам. Далее следует уровень требований к автоматизированной системе определенного (заданного) класса с учетом соответствующих нормативных документов, определяющих порядок и описание заданного технологического процесса. И наконец, третий уровень составляют требования к конкретной системе. Кроме того, в стандарте IEEE 830-1993 Спецификация требований к ПО (Software Requirements Specification – SRS) проведено деление всех требований на две группы. Первая группа документирует потребности заказчика и записывается на языке, понятном заказчику – это т.н. С-требования. Вторая группа документирует требования в специальной, структурированной форме. Этот документ называют требованиями разработчика, или D-требованиями.

В ГОСТ 24.103-84 «Автоматизированные системы управления. Основные положения» перечислены общесистемные принципы, которые необходимо соблюдать при создании АСОИУ:

  1. системность – заключается в том, что при создании, функционировании и развитии АСУ должны быть установлены и сохранены связи между структурными элементами, обеспечивающие ее целостность;
  2. развитие – заключается в том, что АСУ должна создаваться с учетом возможности пополнения и обновления функций и видов ее обеспечения путем доработки программных и (или) технических средств или настройкой имеющихся средств;
  3. совместимость – заключается в обеспечении способности взаимодействия АСУ различных видов и уровней в процессе их совместного функционирования;
  4. стандартизация и унификация – заключается в рациональном применении типовых, унифицированных и стандартизованных элементов при создании и развитии АСУ;
  5. эффективность – заключается в достижении рационального соотношения между затратами на создание АСУ и целевыми эффектами, получаемыми при ее функционировании.

Кроме того, в п.3.4. ГОСТ 24.103-84 при создании АСУ рекомендуется максимально использовать типовые проектные решения, пакеты прикладных программ, унифицированные пакеты а также применять для новых объектов управления ранее созданные проекты АСУ. Это положение полностью соответствует принципам инженерии ПО, в особенности, концепции повторного использования компонентов.
ГОСТ 24.104-85 «Автоматизированные системы управления. Общие требования» устанавливает требования к каждому виду обеспечения отдельно. Перечислим те из них, на которые нужно обратить внимание.

Требования к программному обеспечению:

  1. В АСУ должны быть преимущественно использованы системы управления базами данных (СУБД), зарегистрированные в установленном порядке.
  2. Программное обеспечения АСУ должно иметь средства диагностики технических средств АСУ и контроля на достоверность входной информации.
  3. В программном обеспечении АСУ должны быть реализованы меры по защите от ошибок при вводе и обработке информации, обеспечивающие заданное качество выполнения функций АСУ.

Требования к информационному обеспечения АСУ

  1. Форма представления выходной информации АСУ должна быть согласована с заказчиком (пользователем) системы.
  2. В АСУ должны быть предусмотрены необходимые меры по контролю и обновлению данных в информационных массивах АСУ, восстановлению массивов после отказа каких-либо технических средств АСУ, а также контролю идентичности одноименной информации в базах данных.

Требования безопасности

  1. Неправильные действия персонала АСУ не должны приводить к аварийной ситуации.

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

Кроме сбора требований особое значение имеет процесс управления требованиями. В технологии Rational Unified Process определяются пять уровней зрелости процесса управления требованиями:

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

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

Хорошую спецификацию отличают следующие элементы:

  1. Акцент на деталях и их четкое определение.
  2. Забота о недопущении неверного толкования.
  3. Непротиворечивость внутри данной спецификации и другими спеками.
  4. Логическая взаимосвязь компонентов.
  5. Полнота охвата предмета.
  6. Соответствие нормативным актам.
  7. Соответствие деловой практике.

С-Требования

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

Перед проведением интервью:

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

Во время интервью:

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

После интервью:

  • составить черновик С-требований SRS с использованием CASE-инструментов;
  • определить конфигурацию оборудования;
  • передать черновик С-требований заказчику для получения его замечаний.

Рисунок – Порядок составления С-требований
Порядок составления С-требований

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

  • Методология SADT;
  • Диаграммы вариантов использования (use case) UML.
  • Диаграммы последовательности (sequence diagram) UML.
  • Диаграммы состояний (statechart diagram) UML.
  • Прототипирование дизайна пользовательского интерфейса входит в фазу проектирования программного обеспечения, однако его также можно считать и частью фазы формирования требований.

Порядок анализа требований заказчика включает следующие шаги:
1. Если требование простое и не имеет связей с другими требованиями, его выражают четкими предложениями в соответствующем разделе SRS.
2. Если требование представляет собой взаимодействие пользователя и приложения, то его, как правило, выражают с помощью варианта использования. Для этого:
2.1. Задают имена вариантам использования;
2.2. Определяют действующие лица;
2.3. Записывают последовательность действий пользователя и приложения;
2.4. Минимизируют ветвление.
3. Если требование затрагивает элементы обработки, каждый из которых получает и выдает данные, используют диаграмму потоков данных (DFD). При этом:
3.1. Определяют элементы обработки (обычно высокого уровня);
3.2. Определяют хранилища данных;
3.3. Показывают пути передачи данных между обрабатывающими элементами. Указывают типы данных, передаваемых в каждом случае.
4. Если требование затрагивает состояния, в которых может находиться программа (или части программы), строят диаграмму состояний в следующей последовательности:
4.1. Определяют состояния (каждое состояние обычно определяют отглагольным существительным, например «Ожидание»);
4.2. Указывают исходное и конечное состояние.
4.3. Определяют события, происходящие вне рассматриваемой части системы, и приводящие к переходу между состояниями;
4.4. Определяют вложенные состояния.

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

D-Требования

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

Рисунок – Порядок получения D-требований
Порядок получения D-требований

Существуют несколько типов D-требований:
1. Функциональные требования – определяют работу, которую должно выполнять проектируемая система (например, «приложение будет вычислять стоимость портфеля акций пользователя»).
2. Нефункциональные требования.
2.1. Производительность. Требования к производительности определяют временные ограничения, которые должны быть выполнены в программе. Заказчики и разработчики обсуждают ограничения по времени вычислений, использованию оперативной памяти, объему запоминающих устройств и т. д.
2.2. Надежность и безопасность. Требования надежности определяют надежность в измеряемых величинах. Требования такого типа предполагают вероятность неидеальной работы программы и ограничивают область ее несовершенства. Особое внимание в ПЗ необходимо уделить вопросам обеспечения безопасности системы с учетом возможности искажения данных посредством несанкционированного доступа, сбоя системного или прикладного ПО.
2.3. Обработка ошибок. Эта категория требований объясняет, как программа должна реагировать на возникающие ошибки. Например, что должна делать программа, если она получает сообщение из другой программы в неразрешенном формате? Это не касается ошибок, генерируемых самой программой.
2.4. Интерфейсные требования. Интерфейсные требования описывают формат, в котором программа общается с окружением.
2.5. Ограничения. Ограничения на проектирование или реализацию описывают границы или условия того, как приложение должно быть задумано и разработано. Например, накладываются ограничения на инструменты и языки программирования ввиду сложившихся традиций организации, опыта программистов, совместимости и проч.
3. Обратные требования – это функционал, который система не обеспечивает.

 

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

1. Процесс начинается с перечисления классов, упомянутых в вариантах использования – это т.н. классы анализа.
2. Полученный набор классов обычно неполон и следует попытаться найти остальные классы предметной области.
3. Для каждого из полученных классов выписывается вся необходимая функциональность программы, за которую отвечает данный класс. Например, «у каждого клиента будет имя» (атрибут класса Клиент) и «программа должна иметь возможность вычислять капитал каждого клиента» (метод класса Клиент). События, которые должны обрабатывать объекты класса, также должны быть определены. В это же время должны быть разработаны и планы тестирования для каждого D-требования.
4. Связи между классами определяются в два этапа:
4.1. Начальный набор связей определяется на основе анализа диаграмм сотрудничества (collaboration) или диаграмм последовательности. Если два объекта взаимодействуют (обмениваются сообщениями), между ними на диаграмме должна существовать связь (путь взаимодействия), которая преобразуется в двунаправленную ассоциацию между соответствующими классами. Если сообщения между некоторой парой объектов передаются только в одном направлении, то для соответствующей ассоциации вводится направление навигации.
4.2. Анализируются и уточняются ассоциации между классами-сущностями. Задаются мощности ассоциаций, могут использоваться множественные ассоциации, агрегации, обобщения и ассоциации-классы.
5. D-требования проверяются и сравниваются с С-требованиями.
6. D-требования проверяются заказчиком и, затем, публикуются.

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

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

  1. Класс анализа является четкой абстракцией, моделирующей один конкретный элемент предметной области. Он должен имеет от 3-х до 5-ти операций. Все свойства класса служат реализации его назначения. Однако для реализации своего назначения класс должен иметь минимальное количество связей с другими классами.
  2. В классах анализа содержаться только ключевые атрибуты и операции, определенные на очень высоком уровне абстракции. Как правило, каждая операция уровня анализа затем разбивается на несколько операций уровня проекта.
  3. Необходимо избегать глубоких деревьев наследования (3 и более уровней), поскольку частой ошибкой при построении иерархии наследования является использование функциональной декомпозиции, где каждый уровень абстракции имеет только одну операцию. Наследование использует только там, где есть явная иерархи наследования, вытекающая непосредственно из предметной области.
  4. При выявлении классов посредством анализа текста С-требования, существительные указывают на классы или атрибуты, а глаголы служат признаком операций. Однако синонимы и омонимы могут стать причиной появления ложных классов.
  5. При выявлении классов совместно с пользователями часто используют т.н. CRC(Class-Responsibilities-Collaborators)-анализ с помощью стикеров и мозговой штурм.

Без возможности четкого контроля каждого требования от проекта до программного кода, реализующего это требование, было бы сложно убедиться в том, что программа разработана в соответствии с установленными требованиями. Когда требования меняются (чего следует ожидать), это становится еще сложнее. Возможность отображать каждое требование на соответствующие части проекта и программы называется прослеживанием.
Один из способов, помогающих обеспечить прослеживание, заключается в отображении каждого функционального D-требования на конкретную функцию целевого языка. На рисунке демонстрируется обеспечение принципа прослеживания для некоторого требования №NNN «Поиск учебно-методических материалов (УММ)»:

  1. С-требования, сформулированные заказчиком при проведении анкетирования (или интервью), отображаются на диаграмме вариантов использования;
  2. на этапе проработки D-требований, каждое С-требование представляется комплектом из трех диаграмм: деятельности, классов и последовательностей;
  3. при проектировании архитектуры системы для удовлетворения требования №NNN в некотором классе слоя предметной области предусматривается соответствующий метод(ы) (например, «findByAuthor» и «findByTitle)»;
  4. на стадии детального проектирования прорабатывается алгоритм метода, отвечающего за выполнение требования №NNN, а также создается ER-диаграмма БД и конструируется SQL-запрос(ы), выполнение которого обеспечит удовлетворение данного требования;
  5. на стадии реализации для выполнения требования №NNN разрабатываются листинги соответствующих методов и, наконец, на стадии тестирования выполнение требования №NNN проверяется с использованием составленного плана тестирования.

Рисунок – Пояснение принципа прослеживания
Пояснение принципа прослеживания требований

На протяжении всего процесса проектирования необходимо прилагать усилия по планированию будущего тестирования. Существует несколько преимуществ в написании тестов одновременно с требованиями.
Во-первых, это позволяет прояснить требование.
Во-вторых, это переносит некоторую часть работы из фазы тестирования проекта в фазу разработки требований. Пусть, например, SRS включает в свой состав D-требование №NNN следующего содержания: «NNN. ФИО каждого студента информационной системы «Деканат» будет представлять собой строку символов от 1 до 256». C целью планирования процедуры тестирования необходимо составить проект плана тестирования, примерная форма которого может быть представлена в виде таблицы .

Таблица «Тестовые данные для проверки D-требования №nnn»

№ п/п Входные тестовые данные Ожидаемый результат
1 Иванов Иван Иванович Иванов Иван Иванович
2 length()<10 Сообщение с вопросом о корректности вводимых данных
3 length()>256 Сообщение с вопросом о корректности вводимых данных
4

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

Рисунок «Шаблон таблицы для проверки D-требований»
Шаблон таблицы для проверки D-требований

Во втором столбце таблицы приводится идентификатор D-требования. В столбце 3 приводится идентификатор С-требования, в состав которого входит данное D-требование. В столбце 4 приводятся идентификаторы D-требований, выполнение которых необходимо и достаточно для реализации данного D-требования. В столбце 5 делают отметку, если данное D-требование не противоречит никакому другому D-требованию из перечисленных в таблице. В столбце 6 делают отметку, если данное D-требование может быть реализовано с учетом ограничений, накладываемых другими С- или D-требованиями, средой разработки, аппаратной платформой и т.д.

В столбце 7 делают отметку, если данное D-требование не может быть истолковано двояко. В столбце 8 делают отметку, если данное D-требование сформулировано предельно просто. В случае отсутствия отметки необходимо привести дополнительные разъяснения по содержанию такого требования. В столбце 9 делают отметку, если в данном требовании указаны допустимые отклонения от необходимого результата. В столбце 10 делают отметку, если формулировка данного D-требования не претерпит существенных изменений при возникновении в будущем необходимости наращивания функциональных возможностей системы. В столбце 11 делают отметку, если для данного требования составлен план тестирования. В столбце 12 делают отметку по окончании реализации данного D-требования в виде программного кода.

Порядок разработки каждого D-требования показан выше на рисунке и включает следующие шаги:

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

Как только все D-требования собраны, необходимо обновить SPMP и передать D-требования под управление конфигурациями.
Для формализации и детальной фиксации требований рекомендуется использовать спецификацию требований к программному обеспечению (Software Requirements Specification — SRS) в соответствии со стандартом IEEE 830-1993.


Процесс создания ценности

Инструменты и процесс разработки ценностного предложения

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

YouTube Трейлер YouTube Трейлер

Интегрированный набор инструментов

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

Интеграция бизнес-модели и ценностного предложения

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

  • Схема бизнес-среды помогает понять контекст, в котором вы разрабатываете предложение.
  • Шаблон бизнес-модели помогает создавать ценность для вашего бизнеса.
  • The Value Proposition Canvas (Разработка ценностных предложений) помогает создавать ценность для потребителей.

Шаблон бизнес-модели

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

Шаблон бизнес-модели

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

Шаблон бизнес-модели в формате Excel

Шаблон бизнес-модели в формате Excel.xlsx

Разбор бизнес-модели на примере «ДоДо Пицца»

YouTube Трейлер

Для кого подходят инструменты по «Разработке ценностных предложений»

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

Шаблон

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

Определение
Ценностное предложение описывает преимущества, которые ваши товары и услуги дают потребителю.
создание ценности

Карта ценности

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

Профиль потребителя

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

Задачи потребителя

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

Функциональные задачи

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

Социальные задачи

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

Личностные/эмоциональные задачи

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

Дополнительные задачи

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

  • ПОКУПАТЕЛЬ ЦЕННОСТИ. Задачи, связанные с приобретением ценности, такие как сравнение предложений, принятие решения о покупке, ожидание в очереди, оплата покупки или получение товара или услуги.
  • ПАРТНЕР ПО СОЗДАНИЮ ЦЕННОСТИ. Задачи, связанные с участием в создании ценности вашей организацией, например публикация обзоров или отзывов на товары или даже участие в разработке товара или услуги.
  • ЛИЦО, ПЕРЕДАЮЩЕЕ ЦЕННОСТЬ. Задачи, связанные с конечным этапом жизненного цикла ценностного предложения, – отмена подписки, утилизация товара, передача его другим лицам, перепродажа и т. д.

Контекст задачи

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

Важность задачи

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

Проблемы потребителя

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

Нежелательные результаты и свойства

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

Препятствия

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

Риски (возможность нежелательного исхода)

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

Серьезность проблем

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

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

Эти наводящие вопросы помогут вам продумать потенциальные проблемы потребителя:

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

Выгоды потребителя

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

Необходимая выгода

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

Ожидаемая выгода

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

Желательная выгода

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

Неожиданная выгода

Это преимущества, не относящиеся к категории желаемых или ожидаемых. Потребитель может даже не догадываться о них. Пока Apple не предложила пользователям сенсорные экраны и не запустила App Store, никто не подозревал, что они могут быть частью телефона.

Значимость выгоды

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

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

Эти наводящие вопросы помогут вам продумать потенциальные выгоды потребителя:

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

Пример: Профиль «читателя книги о бизнесе»

Профиль «читателя книги о бизнесе»

Важность, серьезность, необходимость:
Важность, серьезность, необходимость

Алгоритм действий по составлению профиля потребителя

Выберите потребительский сегмент
Выберите потребительский сегмент, профиль которого вы хотите составить.

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

Определите проблемы потребителей
С какими проблемами сталкиваются потребители? Запишите все, которые придут вам в голову, в том числе препятствия и риски.

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

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

Карта ценности

Карта ценности
Компоненты карты ценности
Компоненты карты ценности

Товары и услуги

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

Материальные/осязаемые

Товары, например промышленные.

Нематериальные

Продукты, например авторские права или услуги, такие как послепродажное обслуживание.

Цифровые

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

Финансовые

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

Значимость

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

Факторы помощи

Факторы помощи – это описание того, как именно ваши товары и услуги помогают потребителям справляться с конкретными проблемами. Они должны ясно показывать, как вы намерены смягчать или устранять проблемы, которые возникают у потребителя до, во время или после выполнения его задач или которые не позволяют приступить к выполнению задач.
Хорошие ценностные предложения ориентированы на значимые для потребителя проблемы и в первую очередь на самые серьезные из них. Нет необходимости изобретать факторы помощи для всех без исключения проблем, идентифицированных в профиле потребителя, – это нереально ни для какого ценностного предложения. Удачные ценностные предложения обычно сфокусированы лишь на нескольких проблемах, с которыми они справляются исключительно хорошо.
Приведенные ниже наводящие вопросы позволяют рассмотреть разные подходы к оказанию потребителям помощи в преодолении проблем.

Задайтесь вопросом, способны ли ваши товары и услуги:

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

Значимость

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

Факторы выгоды

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

Задайтесь вопросом, способны ли ваши товары и услуги:

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

Значимость

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

Карта ценности для книги «Разработка ценностных предложений»

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

Алгоритм создания карты ценности

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

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

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

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

Соответствие

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

Краткая схема соответствия и подробная схема соответствия:

Сопоставление
соответствие

Пример соответствия:
Пример соответствия

Ваши отличительные черты в Ценностном предложении

Ценностное предложение — это то, что решает какую-то проблему (боль) клиента и обладает уникальными параметрами, которые задаете Вы сами.

Ценностное предложение

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

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

  1. Что вы делаете?
  2. Для кого вы это делаете?
  3. Что вы делаете иначе?

Каждый потенциальный клиент решает для себя 2 вопроса:

  1. Что ему это даст? Какую проблему Ваш продукт решает?
  2. Почему именно Ваш продукт или услуга? Это Ваше уникальное ценностное предложение. Чем Вы лучше конкурентов (Например: уникальность, комплекс, простота, стоимость)?

Что важно для покупателей?

1. Новизна

Для тех, кому важно обладать передовыми технологиями (новаторы)

Можете использовать, если:

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

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

Используйте ценность, если аналог вашего решение уже существует, но Вы:

  • Лучше в чем-то.
  • Быстрее.
  • Больше.

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

Используйте, если:

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

4. Плоды продуктивности
Сюда относятся все решения, связанные с личной или совместной производительностью (EX: Todolist, GTD, Basecamp).
Контроль выполненной работы и отслеживание процессов.

Используйте, если:

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

5. Дизайн и юзабилити
Примеров удачных решений тьма, начиная от коромысла и заканчивая Apple и Path.
Многие доказали, что степень конкуренции на рынке не так уж и важна. Понятность, красота и удобство найдут своих потребителей. Вечная ценность в сегменте B2C, но полезна и в остальных.

Берите на вооружение, если:

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

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

Используйте, если:

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

7. Экономия
Экономия собственных средств — всегда актуальна. Если Вы помогаете людям экономить, не важно на каком уровне (гипермаркет, финансовый консультант), они придут к Вам.

Экономия может быть Вашей ценностью, если:

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

8. Снижение риска
Стабильность и уверенность –основа общественного спокойствия. Все хотят гарантий!

Используйте, если:

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

9. Доступность и удобство
Некоторые предпочтут заказать товар из интернета более дешевому гипермаркету. Потому что так удобнее. Купят в магазине около дома не то, что изначально хотели, потому что нужного не оказалось. Это доступность.

Внедряйте эту ценность, если:

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

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

Используйте, если:

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

Резюме:
Вы можете иметь столько ценностных предложений, сколько захотите. Но это размажет ваше позиционирование, лучше сосредоточиться на 3. Можете использовать разные ценности для разных целевых аудиторий. Это снизит эффективность маркетинговых коммуникаций, но иногда допустимо.
Успешные стартапы на старте фокусируются на одном клиенте или одной рыночной нише.


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


Модель системы менеджмента качества

Качество программного обеспечения (Software Quality)

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

  • Фил Кросби: Качество — это соответствие пользовательским требованиям.
  • Уотс Хемпфри: Качество — это достижение отличного уровня пригодности к использованию.
  • Компания IBM: ввела в оборот фразу «качество, управляемое рыночными потребностями (market-driven quality)».
  • Критерий Бэлдриджа: «качество, задаваемое потребителем (customer-driven quality)».
  • Система менеджмента качества ISO 9001: Качество — это степень соответствия присущих характеристик требованиям.

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

Качество в проектной деятельности:

  • Управление требованиями («атрибуты качества» как категория нефункциональных требований);
  • Тестирование (т.н. наработка на отказ, такие метрики как MTTF — Mean Time To Failure, то есть среднее время между обнаруженными сбоями системы, и т.п. ).

«Приемлемое качество» можно сравнивать с уровнем обслуживания в рамках заданного SLA – Service Level Agreement. То есть, приемлемое качество может рассматриваться как <количественно выраженный> компромисс между заказчиком и исполнителем в отношении характеристик продукта, создаваемого исполнителем в интересах <решения задач> заказчика с учетом других ограничений проекта (в частности, стоимостью, что часто именуется как «cost of quality» – «стоимость качества»).

Рисунок «Область знаний — Качество программного обеспечения»

Область знаний - Качество программного обеспеченияРисунок «Модель системы менеджмента качества»

Модель системы менеджмента качества

Основы качества программного обеспечения (Software Quality Fundamentals)

Согласие, достигнутое по требованиями к качеству (в оригинале — quality requirements), наравне с четким доведением до инженеров того, что составляет качество <получаемого продукта>, требуют обсуждения и формального определения многих аспектов качества.

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

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

Культура и этика программной инженерии (Software Engineering Culture and Ethics)

Ожидается, что инженеры по программному обеспечению воспринимают вопросы качества программного обеспечения как часть своей <профессиональной> культуры.
Этические аспекты могут играть значительную роль в обеспечении качества программного обеспечения, культуре и отношении инженеров <к своей работе>. IEEE Computer Society и ACM разработали кодекс этики (“моральный кодекс” – code of ethics) и профессиональной практики, основанный на восьми принципах, помогающих инженерам укрепить их отношение к качеству и независимость <в решении вопросов обеспечения достойного качества создаваемых программных продуктов> в их повседневной работе.

Значение и стоимость качества (Value and Costs of Quality)

Понятие “качество”, на самом деле, не столь очевидно и просто, как это может показаться на первый взгляд. Для любого инженерного продукта существует множество <интерпретаций> качества, в зависимости от конкретной “системы координат”. Множество этих точек зрения необходимо обсудить и определить на этапе выработки требований к программному продукту. Характеристики качества могут требоваться в той или иной степени, могут отсутствовать или могут задавать определенные требования, все это может быть результатом определенного компромисса.

Стоимость качества (cost of quality) может быть дифференцирована на:

  • стоимость предупреждения <дефектов> (prevention cost),
  • стоимость оценки (appraisal cost),
  • стоимость внутренних сбоев (internal failure cost),
  • стоимость внешних сбоев (external failure cost).

Движущей силой программных проектов является желание создать программное обеспечение, обладающее определенной ценностью. Ценность программного обеспечения в может выражаться в форме стоимости, а может и нет. Заказчик, обычно, имеет свое представление о максимальных стоимостных вложениях, возврат которых ожидается в случае достижения основных целей создания программного обеспечения. Заказчик может, также, иметь определенные ожидания в отношении качества ПО. Иногда, заказчики не задумываются о вопросах качества и связанной с ними стоимостью. Является ли характеристики качества чисто декоративными или, все же, это неотъемлемая часть программного обеспечения? Ответ, вероятно, находится где-то посередине, как почти всегда бывает в таких случаях, и является предметом обсуждения степени вовлечения заказчика в процесс принятия решений и полного понимания заказчиком стоимости и выгоды, связанной с достижением того или иного уровня качества. В идеальном случае, большинство такого рода решений должно приниматься процессе работы с требованиями, однако эти вопросы могут подниматься на протяжении всего жизненного цикла программного обеспечения. Не существует каких-то <“стандартных”> правил того, как именно необходимо принимать такие решения. Однако, инженеры должны быть способны представить различные альтернативы и их стоимость.

Модели и характеристики качества (Models and Quality Characteristics)

ISO/IEC определяет три связанных модели качества программного обеспечения (ISO 9126-01 Software Engineering — Product Quality, Part 1: Quality Model):

  • внутреннее качество,
  • внешнее качество и
  • качество в процессе эксплуатации, а также набор соответствующих работ по оценке качества программного обеспечения (ISO14598-98 Software Product Evaluation).

Качество процессов программного обеспечения (Software engineering process quality)

Управление качеством (software quality management) и качество процессов программной инженерии (software engineering process quality) имеют непосредственное отношение к качеству создаваемого программного продукта.

Существует два важнейших стандарта в области качества программного обеспечения.

  • TickIT — касается рассмотрения общей системы менеджмента качества ISO 9001-00 в приложении к программным проектам.
  • Другой важный стандарт – CMMI, обсуждаемый в области знаний “Процесс программной инженерии”, предоставляет рекомендации по совершенствованию процесса. Непосредственно с управлением качеством связаны процессные области (области компетенции) CMMI:
    • обеспечение качества процесса и продукта (process and product quality assurance, категория процессов CMMI “Support”),
    • проверка (verification, категория “Engineering”) и
    • аттестация (validation, категория “Engineering”).

При этом, CMMI классифицирует обзор (review) и аудит (audit) в качестве методов верификации, но не как самостоятельные процессы.

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

Качество программного продукта (Software product quality)

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

Стандарт ISO 9126-01 (Software Engineering — Product Quality, Part 1: Quality Model) определяет для двух из трех описанных в нем моделей, связанные характеристики и «суб-характеристики» качества, а также метрики, полезные для оценки качества программных продуктов.

Понимание термина “продукт” расширено включением всех артефактов, создаваемых на выходе всех процессов, используемых для создания конечного программного продукта. Примерами продукта являются (но не ограничиваются этим):

  • полная спецификация системных требований (system requirements specification),
  • спецификация программных требований для программных компонент системы (software requirements specification, SRS),
  • модели,
  • код,
  • тестовая документация,
  • отчеты, создаваемые в результате работ по анализу качества.

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

Повышение качества (Quality Improvement)

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

  1. процессами жизненного цикла,
  2. процессом обнаружения, устранения и предотвращения сбоев/дефектов и
  3. процессов улучшения качества.

К программной инженерии применимы теории и концепции, лежащие в основе совершенствования качества. Например, предотвращение и ранняя диагностика ошибок, постоянное совершенствование (continuous improvement) и внимание к требованиям заказчика (customer focus), составляющие принцип “building in quality”. Эти концепции основываются на работах экспертов по качеству, пришедших к мнению, что качество продукта напрямую связано с качеством используемых для его создания процессов.

Такие подходы, как TQM (Total Quality Management – всеобщее управление качеством) и PDCA (Plan, Do, Check, Act – Планирование, Действие, Проверка, Реакция/Корректировка), являются инструментами достижения задач, связанных с качеством. Поддержка менеджмента помогает в выполнении процессов, оценке продуктов и получению всех необходимых данных. Кроме этого, разрабатываемая программа совершенствования (improvement program, обычно является целевой и охватывает работу подразделения или организации, в целом) детально идентифицирует все действия и проекты по улучшению <отдельных аспектов деятельности> в рамках определенного периода времени, за который такие проекты можно осуществить с успешным решением соответствующих задач. При этом, поддержка менеджмента означает, что все проекты по улучшению обладают достаточными ресурсами для достижением поставленных целей. Поддержка менеджмента тесно связана с реализацией активного взаимодействия в коллективе, и должна предупреждать возникновение потенциальных проблем (и пассивного или даже активного противодействия реализации программы совершенствования или отдельных ее проектов). Формирование рабочих групп, поддержка менеджеров среднего звена и выделенные ресурсы на уровне проекта – эти вопросы обсуждаются в области знаний “Процесс программной инженерии”.

Процессы управления качеством программного обеспечения (Software Quality Processes)

Управление качеством программного обеспечения (SQM, Software Quality Management) применяется ко всем аспектам процессов, продуктов и ресурсов. SQM определяет процессы, владельцев процессов, а также требования к процессам, измерения процессов и их результатов, плюс – каналы обратной связи.

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

Планирование качества программного обеспечения включает:

  1. Определение требуемого продукта в терминах характеристик качества.
  2. Планирование процессов для получения требуемого продукта.

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

SQM может использоваться для оценки и конечных и промежуточных продуктов. Некоторые из специализированных процессов SQM определены в стандарте 12207:

  • Процесс обеспечения качества (quality assurance process);
  • Процесс верификации (verification process);
  • Процесс аттестации (validation process);
  • Процесс совместного анализа (joint review process);
  • Процесс аудита (audit process).

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

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

Управление рисками также может играть значительную роль для выпуска качественного программного обеспечения. Включение “регулярного” (как постоянно действующего, а не периодического; в оригинале – disciplined) анализа рисков и <соответствующих> техник управления <рисками> в процессы жизненного цикла программного обеспечения может увеличить потенциал для производства качественного продукта. Более подробную информацию по управлению рисками можно найти в области знаний “Управление программной инженерией”.

Подтверждение качества программного обеспечения (Software Quality Assurance, SQA)

Процессы SQA обеспечивают подтверждение того, что программные продукты и процессы жизненного цикла проекта соответствуют заданным требованиям. Такое подтверждение проводится на основе планирования (planning), постановки <работ> (enacting) и исполнения (performing) набора действий, направленных на то, чтобы качество стало неотъемлемой частью программного обеспечения.
Такой взгляд подразумевает ясное и точное формулирование проблемы, а также то, что определены и четко выражены, полны и однозначно интерпретируемы требования к соответствующему <программному> решению. SQA добивается обеспечения качества в процессе разработки и сопровождения за счет выполнения различных действий на всех этапах <жизненного цикла>, что позволяет идентифицировать проблемы еще на ранних стадиях, которые практически неизбежны в любой сложной деятельности.

Управление рисками (Risk Management) является серьезным дополнительным инструментом для обеспечения качества программного обеспечения.

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

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

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

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

Кроме того, SQA-план касается и вопросов работ по обеспечению качества, относящихся к другим типам деятельности, описанным в <различных> планах по созданию программного обеспечения, к которым также относятся поставка, установка, обслуживание заказных и/или тиражируемых/готовых программных решений (commercial off-the-shelf, COTS), необходимых для данного проекта программного обеспечения. SQA-план может содержать необходимые для обеспечения качества критерии приемки программного обеспечения и действия по формированию отчетности и управлению <и контролю над> работами.

Проверка (верификация) и аттестация (Verification and Validation, V&V)

Проверка и аттестация программного обеспечения – упорядоченный подход в оценке программных продуктов, применяемый на протяжении всего жизненного цикла. Усилия, прилагаемые в рамках работ по проверке и аттестации, направлены на обеспечение качества как неотъемлемой характеристики программного обеспечения и удовлетворение пользовательских требований.
V&V напрямую адресуется вопросам качества программного обеспечения и использует соответствующие техники тестирования для обнаружения тех или иных дефектов. V&V может применяться для промежуточных продуктов, однако, в том объеме, который соответствует промежуточным “шагам” <соответствующих> процессов жизненного цикла.

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

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

Оба процесса – верификация и аттестация – начинаются на ранних стадиях разработки и сопровождения. Они обеспечивают исследованию (экспертизу) ключевых возможностей продукта как в контексте непосредственно предшествующих результатов (промежуточных продуктов), так и с точки зрения удовлетворения соответствующих спецификаций. Целью планирования V&V является обеспечение процессов верификации и аттестации необходимыми ресурсами, четкое назначение ролей и обязанностей. Получаемый план V&V документирует и <детально> описывает различные ресурсы, роли и действия, а также используемые техники и инструменты.
План также касается аспектов управления, коммуникаций (взаимодействия), политик и процедур в отношении действий по верификации и аттестации и их взаимодействия. Кроме того, в нем могут быть отражены вопросы формирования отчетности по дефектам и документирования требований.

Оценка (обзор) и аудит (Review and Audits)

Пять типов оценок и аудитов:

  • Управленческие оценки (management reviews)
  • Технические оценки (technical reviews)
  • Инспекции (inspections)
  • “Прогонки” (walk-throughs)
  • Аудиты (audtis)

Управленческие оценки (Management Reviews)

Назначение управленческих оценок состоит в отслеживании развития <проекта/продукта>, определения статуса планов и расписаний, утверждения требования и распределения ресурсов, или оценки эффективности управленческих подходов, используемых для достижения поставленных целей.

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

Управленческие оценки определяют адекватность планов, расписаний и требований, в то же время, контролируя их прогресс или несоответствие. Эти оценки могут выполняться в отношении продукта, будучи фиксируемы в форме отчетов аудита, отчетов о состоянии (развитии), V&V-отчетов, а также различных типов планов — управления рисками проекта/проектного управления, конфигурационного управления, безопасности <использования> программного обеспечения (safety), оценки рисков и т.п.

Технические оценки (Technical Reviews)

Назначением технических оценок является исследование программного продукта для определения его пригодности для использования в надлежащих целях. Цель состоит в идентификации расхождений с утвержденными спецификациями и стандартами. Для обеспечения технических оценок необходимо распределение следующих ролей: лицо, принимающее решения (decision-maker); лидер оценки (review leader); регистратор (recorder); а также технический персонал, поддерживающий (непосредственно исполняющий) действия по оценке.

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

  • Формулировки целей
  • Конкретного программного продукта (подвергаемого оценке)
  • Заданного плана проекта (плана управления проектом)
  • Списка проблем (вопросов), ассоциированных с продуктом
  • Процедуры технической оценки

Команда <технической оценки> следует заданной процедуре оценки. Квалифицированные (с технической точки зрения) лица представляют обзор продукта (представляя команду разработки). Исследование <продукта> проводится в течение одной и более встреч (между теми, кто представляет продукт и теми, кто провидит оценку). Техническая оценка завершается после того, как выполнены все предписанные действия по исследованию продукта.

Инспекции (Inspections)

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

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

Инспектирование программного обеспечения всегда вовлекает авторов промежуточного или конечного продукта, в отличие от оценок, которые не требуют этого в обязательном порядке. Инспекции (как временные организационные единицы – группы, команды) включают лидера, регистратора, рецензента и нескольких (от 2 до 5) инспекторов. Члены команды инспектирования могут специализироваться в различных областями экспертизы (обладать различными областями компетенции), например, предметной области, методах проектирования, языке и т.п. В заданный момент (промежуток) времени инспекции проводятся в отношении отдельного небольшого фрагмента продукта (в большинстве случаев, фокусируясь на отдельных функциональных или других характеристиках; часто, отталкиваясь от отдельных бизнес-правил, функциональных требований или атрибутов качества, прим. автора). Каждый член команды должен исследовать программный продукт и другие входные данные до проведения инспекционной встречи, применяя, возможно, те или иные аналитические техники в небольшим фрагментам продукта или к продукту, в целом, рассматривая в последнем случае только один его аспект, например, интерфейсы. Любая найденная аномалия должна документироваться, а информация передаваться лидеру инспекции. В процессе инспекции лидер руководит сессией <инспекции> и проверяет, что все <члены команды> подготовились к инспектированию.

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

  1. Принятие <продукта> с отсутствием либо малой необходимостью переработки
  2. Принятие <продукта> с проверкой переработанных фрагментов
  3. Необходимость повторной инспекции

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

Прогонки (Walk-throughs)

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

Главные цели прогонки состоят в:

  • Поиске аномалий
  • Улучшении продукта
  • Обсуждении альтернативных путей реализации
  • Оценке соответствия стандартам и спецификациям

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

Аудиты (Audits)

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

Аудит является формально организованной деятельностью, участники которой выполняют определенные роли, такие как главный аудитор (lead auditor), второй аудитор (another auditor), регистратор (recorder) и инициатор (initiator). В аудите принимает участие представитель оцениваемой организации/организационной единицы. В результате аудита идентифицируются случаи несоответствия и формируется отчет, необходимый команде <разработки> для принятия корректирующих действий.

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

Практические соображения (Practical Considerations)

Требования к качеству программного обеспечения (Software Quality Requirements)

Факторы влияния (Influence factors)

На планирование, управление и выбор SQM-действий и техник оказывают влияние различные факторы, среди которых:

  • Область применения системы, в которой будет работать программное обеспечение (критичное для безопасности <людей>), критичное для бизнеса и т.п.)
  • Системные и программные требования
  • Какие компоненты используются в системе – коммерческие (внешние) или стандартные (внутренние)
  • Какие стандарты программной инженерии применимы в заданном контексте
  • Каковы методы и программные инструменты, применяемые для разработки и сопровождения, а также для обеспечения качества и совершенствования (продукта и процессов)
  • Бюджет, персонал, организация проектной деятельности, планы и расписания для всех процессов
  • Кто целевые пользователи и каково назначение системы
  • Уровень целостности системы

Информация об этих факторах влияет на то, как именно будут организованы и документированы процессы SQM, какие SQM-работы будут отобраны (стандартизированы в рамках проекта, команды, организационной единицы, организации), какие необходимы ресурсы и каковы ограничения, накладываемые в отношении усилий, направляемых на обеспечение качества.

Гарантоспособность (Dependability)

Гарантоспособость – гарантия <высокой> надежности, защищенности от сбоев.
В случаях, когда сбой системы может привести к крайне тяжелым последствиям (такие системы иногда называют в англоязычных источниках “high confidence” или “high integrity system”, в русском языке к ним иногда применяют название “системы повышенной надежности”, “высокой доступности” и т.п.), общая (совокупная) гарантоспособность системы (как сочетания аппаратной части, программного обеспечения и человека) является главным и приоритетным требованием качества, по отношению к основной функциональности <системы>.

Гарантоспособность (dependability) программного обеспечения включает такие характеристики, как защищенность от сбоев (fault-tolerance), безопасность использования (safety – безопасность в контексте приемлемого риска для здоровья людей, бизнеса, имущества и т.п. ), информационная безопасность или защищенность (security – защита информации от несанкционированных операций, включая доступ на чтение, а также гарантия доступности информации авторизованным пользователям, в объеме заданных для них прав), а также удобство и простота использования (usability). Надежность (reliability) также является критерием, который может быть определен в терминах гарантоспособности.

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

Уровни целостности программного обеспечения (Integrity levels of software)

Уровень целостности программного обеспечения определяется на основании возможных последствий сбоя программного обеспечения и вероятности возникновения такого сбоя. Когда важны различные аспекты безопасности (применения и информационной безопасности), при разработке планов работ в области идентификации возможных очагов аварий могут использоваться техники анализа опасностей (в контексте безопасности использования, safety) и анализа угроз (в информационной безопасности, security). История сбоев аналогичных систем может также помочь в идентификации наиболее полезных техник, направленных на обнаружение сбоев и <всесторонней> оценки качества программного обеспечения.

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

Характеристика дефектов (Defect Characterization)

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

На фоне эволюции (и появления новых) методов проектирования и языков, наравне с новыми программными технологиями, появляются и новые классы дефектов. Это требует огромных усилий по интерпретации (и корректировке) ранее определенных классов дефектов (сбоев). При отслеживании дефектов инженер интересуется не только их количеством, но и типом. Распределение дефектов по типам особенно важно для определения наиболее слабых элементов системы, с точки зрения используемых технологий и архитектурных решений, что приводит к необходимости их углубленного изучения, создания специализированных пилотных проектов, дополнительной проверки концепции (proof of concept, POC – часто применяемый подход при использовании новых технологий), привлечения сторонних экспертов и т.п. Сама по себе информация, без классификации, часто бывает просто бесполезна для обнаружения причин сбоев, так как для определения путей решения проблем необходима их группировка по соответствующим типам. Вопрос состоит в определении такой таксономии дефектов, которая будет значима для инженеров и организации, в целом.

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

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

  • Ошибка (error): “Отличие … между корректным результатом и вычисленным результатом <полученным с использованием программного обеспечения>”
  • Недостаток (fault): “Некорректный шаг, процесс или определение данных в компьютерной программе”
  • Сбой (failure): “<Некорректный> результат, полученный в результате недостатка”
  • Человеческая/пользовательская ошибка (mistake): “Действие человека, приведшее к некорректному результату”

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

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

Данные о несоответствиях и дефектах, найденных в процессе реализации соответствующих техник SQM, должны фиксироваться для предотвращения их потери. Для некоторых техник (например, технической оценки, аудита, инспекций), присутствие регистратора (recorder) – обязательно, именно для фиксирования такой информации, наравне с вопросами (в том числе, требующими дополнительного рассмотрения) и принятыми решениями. В тех случаях, когда используются соответствующие средства автоматизации, они могут обеспечить и получение необходимой выходной информации о дефектах (например, сводную статистику по статусам дефектов, ответственным исполнителям и т.п.). Данные о дефектах могут собираться и записываться в форме запросов на изменения (SCR, software change request) и могут, впоследствии, заноситься в определенные типы баз данных (например, в целях отслеживания кросс-проектной/исторической статистики для дальнейшего анализа и совершенствования процессов), как вручную, так и в автоматическом режиме из соответствующих средств анализа (ряд современных средств проектирования и специализированных инструментов позволяют анализировать код и модели с применением соответствующих метрик, значимых для обеспечения качества продуктов и процессов). Отчеты о дефектах направляются управленческому звену организации/организационной единицы или структуры (для принятия соответствующих решений в отношении проекта, продукта, процесса, персонала, бюджета и т.п.).

Техники управления качеством программного обеспечения (Software Quality Management Techniques)

Техники SQM могут быть распределены по нескольким категориям:

  • статические
  • техники, требующие интенсивного использования человеческих ресурсов
  • аналитические
  • динамические

Статические техники (Static techniques)

Статические техники предполагают <детальное> исследование (examination) проектной документации, программного обеспечения и другой информации о программном продукте без его исполнения. Эти техники могут включать другие, рассматриваемые ниже, действия по “коллективной” оценке или “индивидуальному” анализу, вне зависимости от степени использования средств автоматизации.

Техники коллективной оценки (People-intensive techniques)

Форма такого рода техник, включая оценку и аудит, может варьироваться от формальных собраний до неформальных встреч или обсуждения продукта даже без обращения к его коду. Обычно, такого рода техники предполагают очного взаимодействия минимум двух, а в большинстве случаев, и более специалистов. При этом, такие встречи могут требовать предварительной подготовки (практически всегда касающейся определения содержания встреч, то есть перечня выносимых на обсуждение вопросов). К ресурсам, используемым в таких техниках, наравне с исследуемыми артефактами (продуктом, документацией, моделями и т.п.) могут относится различного рода листы проверки (checklists) и результаты аналитических техник (рассматриваются ниже) и работ по тестированию. Данные техники рассматриваются, например, в стандарте 12207 при обсуждении оценки ( review) и аудита (audit).

Аналитические техники (Analytical techniques)

Инженеры, занимающиеся программным обеспечением, как правило, применяют аналитические техники. С точки зрения Agile-методик и подходов, individuals and interactions предполагает <непосредственное> общение и постоянное взаимодействие членов команды.

Иногда, несколько инженеров используют одну и ту же технику, но в отношении разных частей продукта. Некоторые техники базируются на специфике применяемых инструментальных средств, другие – предполагают “ручную” работу. Многие могут помогать находить дефекты напрямую, но чаще всего они используются для поддержки других техник. Ряд техник также включает различного рода экспертизу (assessment) как составной элемент общего анализа качества. Примеры таких техник — анализ сложности (complexity analysis), анализ управляющей логики (или анализ контроля потоков управления — control flow analysis) и алгоритмический анализ (algorithmic analysis).

Каждый тип анализа обладает конкретным назначением и не все типы применимы к любому проекту. Примером техники поддержки является анализ сложности, который полезен для определения фрагментов дизайна системы, обладающих слишком высокой сложностью для корректной реализации, тестирования или сопровождения. Результат анализа сложности может также применяться для разработки тестовых сценариев (test cases). Такие техники поиска дефектов, как анализ управляющей логики, может также использоваться и в других случаях. Для программного обеспечения с обширной алгоритмической логикой крайне важно применять алгоритмические техники, особенно в тех случаях, когда некорректный алгоритм (не его реализация, а именно логика, прим. автора) может привести к катастрофическим результатам (например, программное обеспечение авионики, для которой вопросы безопасности использования – safety играют решающую роль).

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

Динамические техники (Dynamic techniques)

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

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

В зависимости от организации <ведения> проекта, определенные работы по тестированию могут выполняться при разработке программных систем в SQA и V&V процессах. В силу того, что план SQM адресуется вопросам тестирования, данная тема включает некоторые комментарии по тестированию.

Тестирование (Testing)

Процессы подтверждения <качества>, описанные в SQA и V&V <планах>, исследуют и оценивают любой выходной продукт (включая промежуточный и конечный), связанный со спецификацией требований к программному обеспечению, на предмет:

  • трассируемости (traceability),
  • согласованности (consistency),
  • полноты/завершенности (completeness),
  • корректности (correctness)
  • и непосредственно выполнения <требований> (performance).

Такое подтверждение также охватывает любые выходные артефакты процессов разработки и сопровождения, сбора, анализа и количественной оценки результатов. SQA-деятельность обеспечивает гарантию того, что соответствующие (необходимые в заданном контексте проекта) типы тестов спланированы, разработаны и реализованы, а V&V – разработку планов тестов, стратегий, сценариев и процедур <тестирования>.
Вопросы тестирования детально обсуждаются в области знаний “Тестирование”. Два типа тестирования следуют задачам, задаваемым SQA и V&V, потому как на них ложится ответственность за качество данных, используемых в проекте:

  • Оценка и тестирование инструментов, используемых в проекте
  • Тестирование на соответствие (или оценка тестов на соответствие) компонент и COTS-продуктов (COTS — commercial of-the-shelf, готовый к использованию продукт) для использования в создаваемом продукте.

Иногда, независимые V&V-организации могут требовать возможности мониторинга процесса тестирования и, в определенных случаях, заверять (или, чаще, документировать/фиксировать) реальное выполнение <тестов> на предмет их проведения в соответствии с заданными процедурами. С другой стороны, может быть сделано обращение к V&V может быть направлено на оценку и самого тестирования: достаточности планов и процедур, соответствия и точности результатов.

Другой тип тестирования, которое проводится под началом V&V-организации – тестирование третьей стороной (third-party testing). Такая третья сторона сама не является разработчиком продукта и ни в какой форме не связана с разработчиком продукта. Более того, третья сторона является независимым источником оценки, обычно аккредитованным на предмет обладания соответствующими полномочиями (например, организацией-разработчиком того или иного стандарта, соответствие которому оценивается независимым экспертом и чьи действия подтверждены создателем стандарта). Назначение такого рода тестирования состоит в проверке продукта на соответствие определенному набору требований (например, по информационной безопасности).

Количественная оценка качества программного обеспечения (Software Quality Measurement)

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

Если характеристики качества выбраны правильно, такие измерения могут поддержать качество (уровень качества) многими способами. Метрики могут помочь в управлении процессом принятия решений. Метрики могут способствовать поиску проблемных аспектов и узких мест в процессах. Метрики являются инструментом оценки качества своей работы самими инженерами – как в целях, определенных SQA, так и с точки зрения более долгосрочного процесса совершенствования <достигаемого> качества.
С увеличением внутренней сложности, изощренности программного обеспечения, вопросы качества выходят далеко за рамки констатации факта – работает или на работает программное обеспечение. Вопрос ставится – насколько хорошо достигаются количественно оцениваемые цели качества.

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

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

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

Хотя, как количественные оценки (в данном случае речь идет о результатах оценок, а не о процессе измерений) характеристик качества могут полезны сами по себе (например, число неудовлетворенных требований и пропорция таких требований), могут <эффективно> применяться математические и графические техники, облегчающие интерпретацию значений метрик. Такие техники вполне естественно классифицируются, например, следующим образом:

  • Основанные на статистических методах (например, анализ Pareto, нормальное распределение и т.п.)
  • Статистические тесты
  • Анализ тенденций
  • Предсказание (например, модели надежности)

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

Характеристики качества программного обеспечения

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

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

Примечания:

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

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

Примечания:

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

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

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

Примечания:

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

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

Качество программного продукта

Качество программного продукта (software quality) — весь объем признаков и характеристик программной продукции, который относится к ее способности удовлетворять установленным или предполагаемым потребностям.

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

Важность каждой характеристики качества также меняется в зависимости от принятых точек зрения.

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

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

Пользователя могут интересовать следующие вопросы:

  • Имеются ли требуемые функции в программном обеспечении?
  • Насколько надежно программное обеспечение?
  • Насколько эффективно программное обеспечение?
  • Является ли программное обеспечение удобным для использования?
  • Насколько просто переносится программное обеспечение и другую среду?

Представление разработчика

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

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

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

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

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

Оценка качества программного продукта

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

Рисунок «Модель процесса оценивания»

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

Модель качества процесса

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

Рисунок «Концептуальная модель качества процесса разработки»

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

Руководство по применению характеристик качества

1 Применяемость

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

2.1 Представление пользователя
2.2 Представление разработчика
2.3 Представление руководителя

3 Модель процесса оценивания

3.1 Установление требований к качеству

3.2 Подготовка к оцениванию

3.2.1 Выбор метрик (показателей) качества
3.2.2 Определение уровней ранжирования
3.2.3 Определение критерия оценки

3.3 Процедура оценивания

3.3.1 Измерение
3.3.2 Ранжирование
3.3.3 Оценка

Комплексные показатели (подхарактеристики) качества

Комплексные показатели (подхарактеристики) качества

1 Введение

2 Определение комплексных показателей качества

2.1 Функциональные возможности (Functionality)

2.1.1 Пригодность (Suitability)
2.1.2 Правильность (Accuracy)
2.1.3 Способность к взаимодействию (Interoperability)
2.1.4 Согласованность (Compliance)
2.1.5 Защищенность (Security)

2.2 Надежность (Reliability)

2.2.1 Стабильность (Maturity)
2.2.2 Устойчивость к ошибке (Fault tolerance)
2.2.3 Восстанавливаемость (Recoverability)

2.3 Практичность (Usability)

2.3.1 Понятность (Understandability)
2.3.2 Обучаемость (Learnability)
2.3.3 Простота использования (Operability)

2.4 Эффективность (Efficiences)

2.4.1 Характер изменения во времени (Time behavior)
2.4.2 Характер изменения ресурсов (Resource behavior)

2.5 Сопровождаемость (Maintainability)

2.5.1 Анализируемость (Analysability)
2.5.2 Изменяемость (Changeability)
2.5.3 Устойчивость (Stability)
2.5.4 Тестируемость (Testability)

2.6 Мобильность (Portability)

2.6.1 Адаптируемость (Adaptability)
2.6.2 Простота внедрения (Installability)
2.6.3 Соответствие (Conformance)
2.6.4 Взаимозаменяемость (Replaceabilily)

Примечания:

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

Качество проекта

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

Управление качеством проекта

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

Принципы качества (ISO 9000)

  1. Ориентация на потребителя
  2. Ответственность руководства
  3. Вовлечение людей
  4. Процессный подход
  5. Системный подход к менеджменту
  6. Постоянное улучшение
  7. Принятие решений, основанное на фактах
  8. Взаимовыгодные отношения с поставщиками

Рисунок «Различия в понимании управления качеством в ISO 9000 и PMBoK»

Различия в понимании управления качеством в ISO 9000 и PMBoK

Управление качеством проекта (PMI): подпроцессы

  • Планирование качества
  • Обеспечение качества
  • Контроль качества

Планирование качества

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

Процесс планирования качества: входы

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

Процесс планирования качества: инструменты и технологии

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

Процесс планирования качества: выходы, результаты

  • План управления качеством. Описывает, как команда управления проектом будет проводить политику качества. Должен затрагивать следующие области:
  • Контроль проектирования.
  • Контроль документирования.
  • Контроль закупки материалов.
  • Инспекции.
  • Контроль испытаний (тестирования).
  • Контроль над контрольно-измерительным оборудованием.
  • Корректирующие действия.
  • Записи по качеству.
  • Аудиты (план и процедура)
  • Документированные процедуры и рабочие инструкции. Описывают детально процессы и то, как измерить качество процесса, подпроцесса и отдельных совершаемых действий.
  • Контрольные листы. Списки вопросов для проверки, что ничего не упущено.

Обеспечение качества

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

Процесс обеспечения качества: входы

  • План управления качеством. Выход процесса планирования качества.
  • Рабочие инструкции. Еще один выход процесса планирования качества.
  • Результаты контрольных измерений качества. Выход процесса контроля качества.

Процесс обеспечения качества: инструменты и техники

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

Аудиты качества

Структурированные «осмотры», которые подтверждают «выученные уроки». Типы аудита качества бывают:

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

Процесс обеспечения качества: выходы

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

Контроль качества

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

Процесс контроля качества: входы

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

Контроль качества: инструменты и техники

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

«Цель использования инструментов – зафиксировать результаты или изменения, отобразить их графически, и далее выявить и скорректировать проблемы подходящим способом».

Процесс контроля качества: выходы

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

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

  • http://sorlik.blogspot.com, Сергей Орлик, 2004-2005
  • Генельт А.Е. Учебно-методическое пособие по дисциплине «Управление качеством разработки ПО» 2007, Санкт-Петербург

ТРИЗ (Теория решения изобретательских задач)

ТРИЗ — Теория решения изобретательских задач

Что такое ТРИЗ?

Теория решения изобретательских задач, или ТРИЗ — область знаний о механизмах развития технических систем и методах решения изобретательских задач. ТРИЗ не является строгой научной теорией, а представляет собой обобщённый опыт изобретательства и изучения законов развития науки и техники. В результате своего развития ТРИЗ вышла за рамки решения изобретательских задач в технической области, и сегодня используется также в нетехнических областях (бизнес, искусство, литература, педагогика, политика и др.).
YouTube Трейлер

  1. Перевыставить задачу (найти суть задачи)
  2. Выставление эталона
    • Подбор примеров (как это уже сделано?)
    • Как бы задача была решена если бы была волшебная палочка?
    • Как решить задачу ничего не делая?
  3. Преодоление технического противоречия

Структура и функции ТРИЗ

Цель ТРИЗ — выявление и использование законов, закономерностей и тенденций развития технических систем.

Основные функции ТРИЗ

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

Вспомогательные функции ТРИЗ

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

Структура ТРИЗ

  • Законы развития технических систем (ТС)
  • Информационный фонд ТРИЗ
  • Вепольный анализ (структурный вещественно-полевой анализ) технических систем
  • Алгоритм решения изобретательских задач — АРИЗ
  • Методы развития творческого воображения

Список приемов устранения технических противоречий

1. Принцип дробления:
а) разделить объект на независимые части;
б) выполнить объект разборным;
в) увеличить степень дробления объекта.

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

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

4. Принцип асимметрии:
а) перейти от симметричной формы объекта к асимметричной;
б) если объект асимметричен, увеличить степень асимметрии.

5. Принцип объединения:
а) соединить однородные или предназначенные для смежных операций объекты;
б) объединить во времени однородные или смежные операции.

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

7. Принцип “матрешки”:
а) один объект размещен внутри другого, который, в свою очередь, находится внутри третьего и т. д.;
б) один объект проходит сквозь полости в другом объекте.

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

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

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

11. Принцип “заранее подложенной подушки”:
компенсировать относительно невысокую надежность объекта заранее подготовленными аварийными средствами.

12. Принцип эквипотенциальности:
изменить условия работы так, чтобы не приходилось поднимать или опускать объект.

13. Принцип “наоборот”:
а) вместо действия, диктуемого условиями задачи, осуществить обратное действие;
б) сделать движущуюся часть объекта или внешней среды неподвижной, а неподвижную — движущейся;
в) перевернуть объект “вверх ногами”, вывернуть его.

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

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

16. Принцип частичного или избыточного действия:
если трудно получить 100% требуемого эффекта, надо получить “чуть меньше” или “чуть больше” — задача при этом существенно упростится.

17. Принцип перехода в другое измерение:
а) трудности, связанные с движением (или размещением) объекта по линии, устраняются, если объект приобретает возможность перемещаться в двух измерениях (т. е. на плоскости). Соответственно задачи, связанные с движением (или размещением) объектов в одной плоскости, устраняются при переходе к пространству в трех измерениях;
б) использовать многоэтажную компоновку объектов вместо одноэтажной;
в) наклонить объект или положить его “на бок”;
г) использовать обратную сторону данной площади;
д) использовать оптические потоки, падающие на соседнюю площадь или обратную сторону имеющейся площади.

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

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

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

21. Принцип проскока:
вести процесс или отдельные его этапы (например, вредные или опасные) на большой скорости.

22. Принцип “обратить вред в пользу”:
а) использовать вредные факторы (в частности, вредное воздействие среды) для получения положительного эффекта;
б) устранить вредный фактор за счет сложения с другими вредными факторами;
в) усилить вредный фактор до такой степени, чтобы он перестал быть вредным.

23. Принцип обратной связи:
а) ввести обратную связь;
б) если обратная связь есть, изменить ее.

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

25. Принцип самообслуживания:
а) объект должен сам себя обслуживать, выполняя вспомогательные и ремонтные операции;
б) использовать отходы (энергии, вещества).

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

27. Принцип дешевой недолговечности взамен долговечности:
заменить дорогой объект набором дешевых объектов, поступившись при этом некоторыми качествами (например, долговечностью).

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

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

30. Принцип использования гибких оболочек и тонких пленок:
а) вместо обычных конструкций использовать гибкие оболочки и тонкие пленки;
б) изолировать объект от внешней среды с помощью гибких оболочек и тонких пленок.

31. Принцип применения пористых материалов:
а) выполнить объект пористым или использовать дополнительные пористые элементы (вставки, покрытия и т. д.);
б) если объект уже выполнен пористым, предварительно заполнить поры каким-то веществом.

32. Принцип изменения окраски:
а) изменить окраску объекта или внешней среды;
б) изменить степень прозрачности объекта или внешний среды.

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

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

35. Принцип изменения физико-химических параметров объекта:
а) изменить агрегатное состояние объекта;
б) изменить концентрацию или консистенцию;
в) изменить степень гибкости;
г) изменить температуру.

36. Принцип применения фазовых переходов:
использовать явления, возникающие при фазовых переходах, например, изменение объема, выделение или поглощение тепла и т. д.

37. Принцип применения теплового расширения:
а) использовать тепловое расширение (или сжатие) материалов;
б) использовать несколько материалов с разными коэффициентами теплового расширения.

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

39. Принцип применения инертной среды:
а) заменить обычную среду инертной;
б) вести процесс в вакууме.

40. Принцип применения композиционных материалов:
перейти от однородных материалов к композиционным.

Использование ТРИЗ в IT-технологиях

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