Планирование: виды, методы, примеры

Характеристики бизнес процесса.

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

Результативность – достигает процесс необходимых результатов или нет. Если в результате процесса «Приготовление пирога» получился яблочный пирог, то процесс результативен.
Эффективность – сколько ресурсов затрачивает процесс на получение результата. Если вы знаете, что на приготовление пирога должно уйти 0,5 кг яблок, а было потрачено 2 кг, то процесс неэффективен.
Определенность – если процесс описан в каком-то документе, и то, как он выполняет в действительности, соответствует тому, что написано, значит, процесс определен. Если пирог был приготовлен полностью по рецепту, все ок.
Повторяемость – важнейшая характеристика! Она показывает, может ли процесс получать одинаковые результаты из раза в раз. Если повар постоянно выдает разные яблочные пироги, что-то не так с процессом. Или с поваром.:)
Адаптируемость – характеристика гибкости бизнес процесса, т. е. способности меняться в зависимости от условий. Можно ли быстро заменить яблоки на груши? Можно. Значит, процесс адаптируем.
Длительность – время, которое необходимо для выполнения процесса. Иными словами, промежуток времени между началом процесса и его завершением.
Стоимость – это совокупность всех затрат выполнения процесса 1 раз. Для этого необходимо подсчитать, сколько продуктов мы затратили на приготовление пирога, сколько стоит время повара, который его готовил, а также сколько стоит использование инструментов и посуды.

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

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

Декомпозиция целей

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

Принципы

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

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

Методика в подробностях

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

Очень важно понять, что первоочередная задача составления WBS » разделить проект на подпроекты до той степени детализации, когда появится возможность распределить элементарные работы

Если проект большой, WBS может иметь довольно общий характер. Можно остановиться на самом нижнем уровне, который отслеживает руководитель проекта. Этот уровень, напомним, принято называть пакетом работ. Следует учитывать, что начиная с этого уровня другие менеджеры, занятые на проекте, должны осуществить более подробное разделение проекта на части (подпроекты) до уровня элементарных работ.

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

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

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

Виды декомпозиции

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

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

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

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

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

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

Визуализация декомпозиции

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

Одним из самых удобных методов для наглядной декомпозиции целей являются древовидные интеллект-карты, ментальные карты, Mind Maps. Их можно рисовать на бумаге, либо составлять в специальных редакторах:

Miro (бывший RealTimeBoard);
XMind;
MindMeister;
MindJet Mindmanager;
Draw.io;
LucidChart.

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

Предложения от наших партнеров

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

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

Четкое следование иерархической системе, то есть подчинение низшего уровня более высокому. При этом каждый из них может быть связан только между собой и не иметь логического отношения к другим выше- или нижестоящим;
Деление одной задачи на некоторое число подзадач по однотипному принципу;
Разделение целей на этапы, каждому из которых присваивается процентное значение. Сумма всех значений должна равняться 100%;
Глубина или видимость многоуровневой системы должна позволять на первом этапе визуально охватывать всю систему целиком.

Системный подход к СДР

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

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

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

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

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

Пример: проект «Аполлон»

В 60-е годы в США был реализован проект полета человека на Луну с последующим возвращением на Землю. В этом очень крупном проекте участвовали многие тысячи сотрудников. Руководитель проекта, о котором идет речь, жил в Вашингтоне и тратил большую часть своего времени на взаимодействие с Конгрессом США и другими правительственными структурами.

Когда программа »Аполлон« достигла своего апогея, в ее реализации единовременно оказались задействованы 40 тыс. человек. В эту программу входил проект создания двигателя первой ступени ракеты-носителя »Сатурн 5«. У проекта был свой руководитель и множество сотрудников. В проекте разработки двигателя ракеты-носителя было задействовано несколько организаций, расположенных в различных частях страны. В рамках проекта, над которым трудились несколько тысяч человек, были другие проекты: проект тестирования механизмов, проект топливных систем, проект систем охлаждения и т. д. и у каждого проекта был свой руководитель.

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

Приложения функциональной декомпозиции

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

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

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

Основные потоки

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

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

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

Пример контекстной диаграммы (нажмите для увеличения)

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

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

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

Второй – это недокументированная информация, к которой чаше всего относятся требования собственников.

И, наконец, механизмы – здесь только 2 вида потоков: оборудование (материальный) и исполнители (подразделения и люди). Здесь не может быть документов, как и не может быть людей на стрелках управления!

Для навигации в модели предусмотрена сквозная нумерация. Контекстная диаграмма нумеруется «А-0». В дальнейшем каждый функциональный блок получает свой номер, какой бы глубокой ни была декомпозиция.

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

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

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

Определение необходимости в дальнейшей детализации

В учебно-справочной литературе по управлению проектами для проектов средней сложности рекомендуется использовать до 6 уровней СДР: 3 верхних уровня для предоставления информации уровня заказчика, 3 нижних уровня для детализации информации уровня исполнителя. Глубина детализации СДР зависит от размера и сложности проекта, поскольку должна обеспечивать четкую формализацию целей и результатов работы, которые необходимо выполнить. Каждый пакет работ включает весь объем работ, выполняемый основной организацией, ответственной за данный пакет работ, так же, как и организациями, с которыми заключены подрядные договора.

Дальнейшая детализация необходима, если:

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

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

Организация потока работ

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

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

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

Попробуем ответить на эти вопросы.

Декомпозиция

Если говорить об устоявшихся практиках в компании, то можем отталкиваться от двух штатных вариантов:

Декомпозирует PL в рамках PBR, то есть выполняется вертикальная декомпозиция (по бизнес-ценности).
Декомпозирует аналитик с привлечением команды разработки и тестирования. Это уже более детальная декомпозиция с применением технических условий.

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

Мероприятия

PBR (Product Backlog Refinement) — крупная декомпозиция с участием бизнес-заказчика. Помогает декомпозировать на ценностные задачи. В рамках данного мероприятия чаще происходит именно вертикальная декомпозиция, так как глубокого погружения в задачи не происходит.

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

Карточки

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

подзадачи внутри задачи,

задачи внутри эпика.

Подзадачи внутри задачи

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

Плюсы:

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

Минусы:

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

Задачи внутри эпика

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

Плюсы:

корректно считается количество задач в работе,
по каждой задаче понятен исполнитель.

Минусы:

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

Зачем декомпозировать

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

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

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

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

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

Список используемой литературы и интернет-источников:

https://pandia.ru/text/80/308/1379.php#:
http://www.rbs-kuzbass.ru/pm-ytim-50del/pm-ytim-2015/
https://www.cfin.ru/itm/project/wbs.shtml

Финансовые риски, их оценка и методы страхования
Финансовые риски, их оценка и методы страхования (Финансовые риски.)
Управление персоналом команды проекта (Основные принципы управления персоналом)
Формирование и развитие команды проекта (Принципы формирования команды проекта)
Методы мотивации персонала
Формирование и развитие команды проекта (Принципы формирования команды проекта:)
Электронный бизнес в предпринимательстве
Банкротство в законодательстве различных стран
Лояльность персонала, как важнейший критерий качества человеческого капитала организации
Факторы, влияющие на успех реализации проекта (Какие главные причины неудач в проекте?)
Операционная система Windows (Администрирование операционной системы Windows)
Методы руководства и управления персоналом

Заключение

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

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

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

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

Также читайте: Что такое стратегическое планирование