Фреймворк в бизнесе что это

Фреймворки масштабирования Agile на компанию

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

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

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

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

И перед тем, как перейти к обзору фреймворков я хочу порекомендовать доклад Асхата Уразбаева «Фреймворки масштабирования Agile» на SECR-2017 со сравнением разных фреймворков.

Начну я с наиболее простого Scrum of Scrums, который появился раньше других. Он применяется в случае, если у вам в компании есть независимые Scrum-команды, каждая из которых делает свой продукт. Тогда для работы надо общими вопросами достаточно собрать команду Product Owner для обсуждения стратегии развития продуктов и координации усилий, и команду Scrum Master для обсуждения и координации вопросов организации. Если в командах есть Tech Lead, отвечающий за технологии и обучение им сотрудников, то добавляется еще координирующая команда из них.

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

Другой относительно простой способ – это собрать Integration Team из представителей отдельный команд, которая будет решать вопросы координации и зависимостей. Это предлагает Nexus и достаточно в случае, когда зависимости являются достаточно слабыми.

Более сложный фреймворк – Large Scaled Scrum (LeSS) (русское описание) – несколько команд на одном продукте с общим Product Owner, BackLog, спринтами, планированием, демо и поставкой, это позволяет объединить до 8 команд. У фреймворка есть huge вариант, применяемый для больших компаний и рассчитанный на работу 1000+ человек.

Ответственность команды не ограничивается выполнением основных производственных задач, она имеет много планов и фокусов, и логично, когда это реализуется через отдельные организационные структуры. Это мы видели на примере Scrum of Scrum, который организует две структуры управления – продуктовую и организационную, иногда дополняемую третьей, технологической. Более сложной конструкцией является Spotify фреймворк, который заслуживает отдельного рассмотрения.

Основной производственной единицей в ней является клан (tribe) в 100-200 человек, который работает над отдельным продуктом. Он представляет собой матрицу: делится на кроссфункциональные производственные отряды (squad) и функциональные отделы (chapter). Отряды реализуют новый функционал и состоят из специалистов разных специализаций, которые дополняют друг друга. А отделы координируют работы специалистов из разных команд, использующих общие технологии, решая такие задачи, как разработка мобильных интерфейсов в едином стиле, однородная работа серверной части или развитие технологий тестирования. Отметим, что отделы работают над применением технологий в рамках продукта, а вот для развития технологий в целом по компании существуют еще гильдии (guild) по интересам. По мере роста компании над кланами появились структуры следующего уровня – альянсы (alliance) и бизнес-единицы (business unit).

Конструкция – очень сложная и многоплановая и во многом обусловленная контекстом компании. Spotify ей делится, но с предостережением: «используйте наши опыт, но не пытайтесь тупо скопировать, оно не взлетит, мы это точно знаем, потому что у нас самих конструкция развивается и растет». Но много попыток именно механического копирования, обычно неудачных. А вот идеи заложены плодотворные.

При этом в самой компании Spotify организационная структура развивается очень быстро. И я хочу интересующимся порекомендовать доклад Yuliya Kurapatenkava на Saint TeamLeadConf-2018, в котором она рассказывала про логику развития (мой конспект есть в отчете с конференции, сам доклад по-английски). И вы можете сравнить то, что звучит в докладе с тем описанием фреймворка, которое доступно по ссылке в начале раздела и фиксирует состояние несколько лет ранее.

Здесь стоит рассмотреть практическое применение подобных фреймворков. Один продукт, над которым работают несколько команд, далеко не всегда означает единственный продукт в смысле софта, более того, часто речь идет об одном бизнес-продукте, поддержка которого со стороны софта требует общей серверной части и нескольких приложений на разных платформах – web и мобильных. Естественным образом для того, чтобы какой-то новый функционала стал доступен конечным пользователям, он часто должен быть реализован в серверной части и для каждой из платформ. И тут может быть два подхода: сделать команды, каждая из которых сосредоточенна вокруг каждого софтверного продукта, при этом только она работает с кодовой базой продукта и отвечает за его архитектуру. В этом случае для организации могут применяться фреймворки, подобные LeSS.

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

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

Scaled Agile Framework (SAFe) является самым сложным Agile-фреймворком, но при этом – самым популярным. Это сложная конструкция уровня компании с управлением потоками создания ценности и архитектурой. На мой взгляд, популярность этого фреймворка сродни популярности PMBOK или RUP – в нем есть все и на все случаи жизни, и предлагается просто взять нужное. Те, кто читал мою статью «Развитие и провал регулярного менеджмента в IT» не удивятся моему мнению, что у это – неработоспособная конструкция, хотя и привлекательная в своем инженерном совершенстве. И он не будет работать по тем же самым причинам – его сложность превышает разумный предел, при этом обвинить сам фреймворк будет невозможно, всегда окажется, что это вы не смогли его правильно реализовать.

Но дело не только в сложности фреймворка: SAFe пытается за счет сложных регламентов превратить запутанную область в сложную, а это – невозможно (подробнее о сложности областей – в моей статье «Место Agile-команд в компании»). Однако, SAFe может быть полезен как теоретический источник, подобно PMBOK. Кстати, автором фреймворка является Дин Леффингуэлл (Dean Leffingwell), один из авторов RUP.

Довольно интересен фреймворк Enterprise Scrum предлагает переход от создания IT-продукта к поставке ценности, управляемой набором связанных метрик. К сожалению, в отличие от всего остального он не завершен. Его создатель Mike Beedle, кстати, один из авторов Agile-манифеста был, к сожалению убит в Чикаго весной 2018 года, и работа не завершена. Однако, на сайте есть достаточно подробная конструкция системы метрик, совместимая с Agile-методами управления, и, возможно, она вам окажется полезной при конструировании собственной, хотя в готовом виде ее, естественно, брать не стоит. Поэтому я и даю ссылку.

На этом я завершаю эту статью. Полное оглавление серии «Менеджмент цифрового мира» можно увидеть у меня на сайте. В следующей статье мы поговорим про кейсы Agile-трансформации. Продолжение следует…

Источник

Фреймворки для управления проектами

A. Что такое фреймворк для управления проектами?

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

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

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

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

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

В чем разница между методологией и фреймворком?

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

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

Б. Что общего у Agile-фреймоворков?

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

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

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

В. Фреймворк Scrum

Методология Scrum была разработана в 1990-х гг., и ее основы были изложены в статье в Harvard Business Review под названием «Разработка нового продукта. Новые правила игры». Большинство менеджеров проектов считают Scrum самым популярным Agile-фреймворком.

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

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

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

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

Scrum требует определенных ролей и обязанностей для участников Agile-команды, в том числе следующих:

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

Г. Другие популярные Agile-методики управления проектами

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

1. Kanban

Kanban — это простой и наглядный способ управления проектами. Он изначально разрабатывался как метод планирования и помогает командам создавать продукцию точно в срок (JIT), позволяя всем участникам видеть, как продвигается проект и что будет дальше.

Kanban ориентирован на визуализацию рабочего процесса, когда задачи разбиваются на небольшие части. Фреймворк Kanban во многом похож на Scrum. Здесь также используется доска для отображения информации и отслеживания хода работ, причем задачи распределяются по трем основным столбцам: «К исполнению», «В работе» и «Выполнено». Но в отличие от Scrum, Kanban-доска отражает всю работу по созданию продукта без разделения на спринты.

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

2. Экстремальное программирование (XP)

Экстремальное программирование (XP) — Agile-фреймворк, изначально созданный для Agile-проектов по разработке программного обеспечения. Как и Scrum, этот фреймворк нацелен на постоянную разработку и доставку продукта заказчику и использует интервалы или спринты.

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

3. Функционально-ориентированная разработка (FDD)

Функционально-ориентированная разработка — еще один Agile-фреймворк, специфичный для сферы разработки программного обеспечения. Он нацелен на создание моделей через каждые две недели. Также он требует отдельного плана разработки и проектирования для каждой функции модели, то есть превосходит все остальные Agile-фреймворки по объему документации. Из-за жестких требований к документации FDD лучше подходит командам с расширенными возможностями проектирования и планирования.

Фреймворк FDD разбивает проекты на пять базовых повторяющихся видов деятельности:

4. Метод разработки динамических систем (DSDM)

Метод разработки динамических систем (DSDM) возник из-за потребности в общем отраслевом фреймворке для быстрого создания программного обеспечения. DSDM предусматривают доработку, и любые вносимые изменения в ходе разработки должны быть обратимыми. Как и Scrum, XP и FDD, фреймворк DSDM разбивает проекты на мелкие спринты.

Этот фреймворк основан на восьми основных принципах:

5. Crystal

Crystal — это семейство Agile-методологий, включающее в себя Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Red и т. п. У каждой из этих методологий есть свой уникальный фреймворк, и выбирать методологию следует в зависимости от нескольких факторов, в том числе от размера команды, приоритетов и важности проекта. Принимая решение о том, как внедрить Agile-методологию, очень важно понимать, что для различных проектов в зависимости от их уникальных характеристик требуются различные наборы политик, практик и процессов.

Является ли бережливое управление проектами (Lean) Agile-фреймворком?

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

Д. Определение эпика Agile

В Agile-методологии управления проектами эпики — это «крупные истории пользователей».

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

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

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

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

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

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

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

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

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

Предлагаем посмотреть видеоролик Knowledge Hut, более подробно демонстрирующий определение и ценность эпиков Agile.

Е. Лучшие рекомендации для менеджеров проектов по выбору оптимального фреймворка

Если вы можете выбирать из более чем шести популярных Agile-фреймворков, как узнать, который из них подходит для вашего проекта?

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

Вот семь лучших рекомендаций по управлению проектами, основанных на стандарте по оценке зрелости управления проектами в организациях (Organizational Project Management Maturity Model, OPM3) и руководстве по внедрению управления проектами в организациях от Института управления проектами (PMI).

Ж. Бесплатные инструменты для управления Agile-проектами

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

Источник

Сравнение моделей и фреймворков стратегического планирования

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

Сравнительная таблица фреймворков стратегического планирования

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

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

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

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

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

В уроке 3 бесплатного курса стратегического планирования мы разбираем различные бизнес фреймворки для определения стратегии. Вот полное видео урока:
» alt=»»>

Фреймворки реализации стратегии

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

Фреймворк Системы Сбалансированны Показателей (ССП)

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

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

Фреймворк OKR

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

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

Хосин Канри (Hoshin Kanri)

Фреймворк Хосин Канри поож на OKR и BSC:

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

В рамка методики Хосин Канри стратегическое планирование и каскадирование обозначаются термином «стратегическое развёртывание.» Этапы процесса развёртывания стратегии поожи на классические шаги стратегического планирования.

Фреймворк MBO — один из первы фреймворков реализации стратегии, который предложил эффективный способ доносить цели с уровня руководства до уровня отдельны сотрудников. Он имеет много общи идей с фреймворками ССП и OKR. MBO установил определенные требования к целям:

На этапе описания стратегии фреймворк проигрывает в выразительны способностя ССП или Хосин Канри, но на уровне реализации стратегии его простота приобретает особую ценность.

Фреймворки формулирования стратегии

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

Три Горизонта (Three Horizons) McKinsey

Фреймворк Three Horizons McKinsey решает задачу инновационного планирования. В нем предлагается определить приоритетность инновационной деятельности в соответствии с тремя временными рамками (горизонтами)

Фреймворк эффективен при формулировании стратегии, особенно если речь идет об инновационной стратегии.

SWOT+S

Классический Фреймворк SWOT помогает анализировать позицию компании с четыре точек зрения: Сильные стороны, Слабые стороны, Возможности и Угрозы. План действий по SWOT-анализу:

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

Такой подод также облегчает использование результатов SWOT-анализа для дальнейшего описания стратегии на стратегической карте K&N.

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

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

Фреймворк 7-S

7-S фреймворк — это еще один фреймворк формулирования стратегии. В этом случае стратегия бизнеса анализируется с точки зрения 7 факторов (каждый фактор в английском языке начинается с буквы S). Эти 7 факторов делятся на:

PESTEL

PEST или анализ PESTEL относится к анализу внешни факторов. Что это за факторы?

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

Пять сил по Портеру

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

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

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

Анализ Парето

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

Ключевая идея анализа Парето в контексте стратегического планирования — сравнить:

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

Анализ ограничений

Анализ ограничений (или теория TOC) был впервые описан в книге «Цель» доктора Голдратта, с использованием ряда примеров из сферы производства. Этот анализ помогает определить ограничения (узкие места) системы и оптимизировать производительность, следуя этим пяти этапам:

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

Анализ разрывов

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

Вот как анализ разрывов помогает на различны этапа процесса стратегического планирования:

Модели приоритизации

Формулирование стратегии – это процесс выбора, а выбор – это анализ альтернатив и расстановка приоритетов.

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

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

В отдельной статье мы рассмотрели некоторые популярные модели приоритизации. Мы также дали несколько конкретны примеров для пользователей BSC Designer.

В контексте стратегического планирования эти модели могут войти в набор инструментов для формулирования стратегии. В сравнительной таблице мы можем поместить и в столбец Этапа 2.

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

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

Общие принципы

В каки случая программное обеспечение для стратегического планирования может помочь

Программное обеспечение BSC Designer

В каки случая BSC Designer может быть полезным в контексте автоматизации:

Выводы

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

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

Источник