Декомпозиция задач: что это и зачем нужно

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

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

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

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

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

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

Технология создания товаров и услуг

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

От того, насколько эффективными являются действия, зависит:

Прибыльность организации.
Ее конкурентоспособность.

Общепринятая методология описания бизнес-процессов подразумевает использование одного из трех способов:

текстовый;
табличный;
графический.

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

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

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

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

В этом отношении у компании имеется широкое пространство для маневра, так как методов описания бизнес-процессов существует множество: более двух десятков — точно. Вопреки распространенному мнению, большое количество способов не является проблемой, так как все они основаны на двух главных — WFD и DFD (Work Flow Diagram и Data Flow Diagram соответственно).

Существует семь золотых правил описания БП:

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

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

Агальцов, В.П. Базы данных. В 2-х т. Т. 2. Распределенные и удаленные базы данных: Учебник / В.П. Агальцов. — М.: ИД ФОРУМ, НИЦ ИНФРА-М, 2013. — 272 c.
Бритов Г., Осипова Т. Моделирование бизнес-процессов. — М.:LAP, 2014. – 124 с.
Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. — СПб.:Питер, 2015. – 368 с.
Голицына, О.Л. Базы данных: Учебное пособие / О.Л. Голицына, Н.В. Максимов, И.И. Попов. — М.: Форум, 2012. — 400 c.
Гурвиц Г. Microsoft Access 2010. Разработка приложений на реальном примере. — СПб.: БХВ-Петербург, 2010. — 497с.
Давыдова Е. М. Базы данных Учеб. пособие для вузов / Е. М. Давыдова, Н. А. Новгородова. — 3-е изд., перераб. и доп. — Томск : В-Спектр, 2012. — 128 с.
Исаев Г. Проектирование информационных систем. Учебное пособие. — М.: Омега-Л, 2015. — 432с.
Карпова, И.П. Базы данных: Учебное пособие / И.П. Карпова. — СПб.: Питер, 2013. — 240 c.
Кит Т. Томпсон Автоматизация продаж. Умный подход. — М.: Вершина, 2016 — 272 с.
Коваленко В. Проектирование информационных систем. — М.: Форум, 2012. — 320с.
Кузин, А.В. Базы данных: Учебное пособие для студ. высш. учеб. заведений / А.В. Кузин, С.В. Левонисова. — М.: ИЦ Академия, 2012. — 320 c.
Кузнецов С. Базы данных. — М.: Academia, 2012. — 496с.
Миков А. Информационные процессы и нормативные системы в IT. Математические модели. Проблемы проектирования. Новые подходы. — М.: Либроком, 2013. — 256с.
Пирогов, В.Ю. Информационные системы и базы данных: организация и проектирование: Учебное пособие / В.Ю. Пирогов. — СПб.: БХВ-Петербург, 2014. — 528 c.
Редько В.Н., Бассараб И.А. Базы данных и информационные системы. — М.: Знание, 2015. — 602 c.
Степанов В. Информационные технологии управления продажами и маркетингом. — М.: LAP Lambert Academic Publishing, 2013. — 284 с.
Советов, Б.Я. Базы данных: теория и практика: Учебник для бакалавров / Б.Я. Советов, В.В. Цехановский, В.Д. Чертовской. — М.: Юрайт, 2013. — 463 c.
Уорден К. Новые интеллектуальные материалы и конструкции. Свойства и применение; М.: Техносфера, 2012. — 456 c.
Уткин В., Балдин К. Информационные системы в экономике. — М.: Academia, 2012. — 288с.
Шаймарданов Р.Б. Моделирование и автоматизация проектирования структур баз данных — М.: Юнити, 2016. — 469 c.

Инновационный проект – организационная основа инновационной деятельности. Управление инновационным риском. Организация венчурного финансирования.
Право собственности на землю (Понятие и содержание права собственности на землю)
Сущность внутреннего контроля и процедуры внутреннего контроля (ООО «Багира»)
Косвенные налоги и их место в налоговой системе РФ. . .
Бизнес-планирование в экономической деятельности предприятия
Акционерные общества в современной России
Распределенная технология обработки информации в базе данных (БД)
ОПЫТ АНКЕТИРОВАНИЯ И ИНТЕРВЬЮИРОВАНИЯ В МАРКЕТИНГОВОМ ИССЛЕДОВАНИИ
PR в системе Интегрированных коммуникаций (Понятие PR)
Современный банковский маркетинг: методы и тенденции развития (Банковский маркетинг: цель, задачи и принципы)
Языки гипертекстовой разметки (История развития Интернета и появление HTML)
Основы программного обеспечения работы ЭВМ

Постановка целей по технологии SMART

Прежде, чем заняться разбивкой на шаги, ставим цель по технологии SMART. В «Армии» выдрессировали в этом плане — постоянно заворачивали выполненные задания, поставленные цели на каждый месяц, если они были не по СМАРТу. Мне теперь очень странно видеть абстрактную цель. Многие знакомы с этой технологией, но не применяют ее в жизни, либо применяют частично, или с неотсмартованными целями. В этом как раз огромная польза живых тренингов — в переводе знаний в навыки.

«Мечта — это не отсмартованная цель». (С)

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

Цель должна быть:

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

M - Measurable - Измеримая. У цели должны быть четко понимаемые, измеряемые показатели, критерии оценки, желательно в числах.

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

R - Relevant - Уместная. Насколько эта цель желанна именно вами, а не продиктована другими людьми, вызвана вашей завистью, зависимостью, следованием за модой или каким-то мимолетным желанием? Насколько соответствует вашим ценностям и приоритетам, целесообразна в вашем текущем положении, насколько приближает вас к вашей цели на ближайший год, 5 лет? Насколько экологична, не вызывает ли внутреннего сопротивления? Если стоят несколько целей, они не должны мешать друг другу и создавать сопротивление.

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

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

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

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

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

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

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

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

Не спеша, эффективно и правильно – путь разработки. Часть 3. Практика

Черновой вариант книги Никиты Зайцева, a.k.a.WildHare. Разработкой на платформе 1С автор занимается с 1996-го года, специализация — большие и по-хорошему страшные системы. Квалификация “Эксперт”, несколько успешных проектов класса “сверхтяжелая”. Успешные проекты ЦКТП. Четыре года работал в самой “1С”, из них два с половиной архитектором и ведущим разработчиком облачной Технологии 1cFresh. Ну — и так далее. Не хвастовства ради, а понимания для. Текст написан не фантазером-теоретиком, а экспертом, у которого за плечами почти двадцать три года инженерной практики на больших проектах.

Функциональный блок

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

Обязательные элементы функционального блока в IDEF0

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

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

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

Для построения функциональной модели методология IDEF0 требует соблюдать следующие правила.

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

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

Основные элементы BPMN

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

Ниже на иллюстрации приведён пример процесса — поиска и приёма на работу нового сотрудника.

Фрагмент описания бизнес-процесса в нотации BPMNСкриншот: личный архив Анны Солодовниковой

Разберём основные элементы нотации. Их будет достаточно для большинства схем.

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

Изображение: Skillbox Media

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

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

Изображение: Skillbox Media

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

В нашем примере стартовые события — «Потребность в расширении штата» и «Текущий сотрудник написал заявление на увольнение».

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

Параллельный шлюз — означает, что два процесса исполняются одновременно. Читается как «И».В нашем примере параллельный шлюз — «Проведение собеседования» и «Проведение собеседования, заполнение листа оценки кандидата».

Изображение: Skillbox Media

Эксклюзивный шлюз — используют, чтобы обозначить ветвление потока управления на несколько альтернативных потоков, когда процесс зависит от выполнения условия. Читается как «ИЛИ».В этом случае процесс идёт чётко по одному из потоков.

Изображение: Skillbox Media

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

Изображение: Skillbox Media

Объект данных. Показывает, какие объекты сопровождают выполнение процесса. Например, бумажный документ, электронный документ, информацию и так далее.

В нашем примере объекты данных — «Заявка на подбор», «Лист оценки кандидата», «Предложение о работе».

Изображение: Skillbox Media

Потоки. Это стрелки, которые показывают движение по процессам и порядок их выполнения. Есть несколько видов потоков:

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

Изображение: Skillbox Media

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

Изображение: Skillbox Media

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

Изображение: Skillbox Media

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

Например, в нашей иллюстрации дорожки соответствуют кандидату, HR-менеджеру, руководителю отдела.

Изображение: Skillbox Media

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

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

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

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

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

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

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

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

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

Декомпозировать можно по-разному, это зависит от масштаба и сути задачи.

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

Вертикальная декомпозиция:

Бэкенд: считать количество покупок и отдавать данные на фронт.

Фронтенд: запрашивать данные при загрузке страницы и выводить.

Горизонтальная декомпозиция:

Бэкенд:

добавить столбец с количеством покупок в БД;
считать в этом столбце, сколько раз товар купили;
добавить метод, который будет возвращать количество покупок по id товара.

Фронтенд:

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

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

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

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

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

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

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

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

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

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

Мероприятия

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

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

Карточки

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

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

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

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

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

Плюсы:

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

Минусы:

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

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

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

Плюсы:

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

Минусы:

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

Необходимые условия для создания WBS

Чтобы создать WBS, вы должны уметь составлять расписание работы и оценивать стоимость работ.

Условия для создания расписания работы

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

Настройте календарь по умолчанию и календарь проекта:
1. Перейдите Управление проектом и учет > Настройка > Параметры управления проектом и учета > Планирование. В поле Рабочий календарь по умолчанию укажите календарь по умолчанию. Это будет рабочий календарь по умолчанию для любого нового создаваемого проекта.
2. Вы можете изменить календарь по умолчанию для конкретного проекта. Щелкните страницу сведений о проекте, а затем на экспресс-вкладке Проектная группа и планирование обновите поле Планирование календаря, выбрав другой календарь.
Установите стандартные рабочие дни и часы работы. Календарь, который вы установили в качестве рабочего календаря для своего проекта, будет использоваться в WBS для определения следующей информации:

Рабочие дни и праздники
Количество рабочих часов в день

Чтобы настроить рабочие дни и часы работы для календаря или создать новый календарь, щелкните Администрация организации > Общие > Календари.

Условия для оценки стоимости работ

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

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

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

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

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

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

Итак:

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

Несколько слов о преимуществах графики

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

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

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

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

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

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

Декомпозиция по типу работ

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

Условимся, что для реализации необходимы работы:

backend:

разработка API для фронта (BFF);

frontend:

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

тестирование.

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

Минусами такого подхода могут быть:

все еще большой размер задачи,
последовательное выполнение работ,
часто в таких задачах frontend выступает как тестировщик для backend, что приводит к потерям производительности первого (то есть front получает в работу сырой вариант реализации от back, так как обычно тестирование проводится в конце цикла реализации задачи).

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

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

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

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

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

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

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

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

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

Типичные ошибки

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

Рассмотрим типичные ошибки:

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

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

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

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

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

Заключение

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

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