Верхнеуровневая схема бизнес процесса пример

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

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

170___________________________ ВВ. Репин. В.Г. Елиферов Процессный подход к управлению

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

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

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

• увязка результатов деятельности (выходов) и процессов, определение гра­
ниц процессов;

• определение проблемных областей при выполнении процессов;

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

папе работ следует заносить в таблицы (табл. 3.8—3.10). Отметим, что до начала работ с таблицами целесообразно составить простейшие эскизы процессов верх­него уровня. Эти эскизы позволят быстрее и точнее сформировать таблицы.

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

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

В начале главы 3 была описана методология «ускоренного» моделирования бизнес-процессов организации, согласно которой первый шаг построения мо­делей — определение внешних входов и выходов организации (см. на рис.3.7).

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

Определив перечень входов и выходов, рабочая группа составляет предвари­тельный перечень бизнес-процессов верхнего уровня, причем основных про­цессов. Заметим, что в ходе этих процессов создается добавленная ценность, их выходами яГотовая продукция Б?**

* Предварительное формулирование процесса.

** Можно отнести эти выходы как к процессу «Сбыт», так и к процессу «Производство».

Таблица 3.9 Перечень основных процессов

Таблица 3.10 Входы и выходы основного процесса

172_________________________________ В.В. Репин, В Г. Елиферов Процессный подход к управлению

Таблица ЗЛО (окончание)

При формировании табл. ЗЛО могут появиться входы, которые являются результатом выполнения вспомогательных процессов, и выходы, которые яв­ляются входами для вспомогательных процессов. Анализируя данные входы и выходы, рабочая группа составляет перечень вспомогательных бизнес-про­цессов организации.

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

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

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

Таблица 3.11 Состав функций пронеси

На каком основании присваивать названия функциям, входящим в процесс? Поскольку «новоиспеченный» бизнес-процесс как объект управления не регла­ментирован в документах организации, то источниками информации о нем мо­гут служить:

а) мнения руководителей и специалистов подразделений, участвующих в про­
цессе;

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

Глава 3 Описание и анализ бизнес-процессов 173

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

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

• ограниченное количество функций на схеме (не более шести-восьми);

• все функции должны быть одного уровня;

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

• на схеме должны быть отображены основные материальные и информа­
ционные потоки;

• должна быть отражена информация по управлению процессом;

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

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

Какой из представленных на рис. 3.29 процессов на ваш взгляд является более корректным? Первый вариант процесса не устраивает нас по нескольким причинам. Во-первых, функция «Обработка заявки клиента» весьма детальна и не исчерпывает всех работ, связанных с деятельностью по формированию портфеля заказов. Во-вторых, объект «Приход денег» вовсе не является функ-

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

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

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

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

Представление типового процесса «Закупки» на верхнем уровне приведено на рис. 3.31. Процесс сформирован при помощи нотации ARIS Value-added Chain Diagram (ARIS VAD).

Рнс. 3.30. Пример процесса верхнего уровня. Процесс «Закупки»: МТО — материально-техническое обеспечение; ТМЦ — гпмрте шптрмдшыг ценности.

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

1) функции планирования закупок ТМЦ;

2) функции формирования заказов на ТМЦ;

3) функции получения, хранения и отпуска ТМЦ в производство;

4) функции оплаты ТМЦ и контроля дебиторской задолженности;

5) функции бухгалтерского учета операций по закупкам ТМЦ.
Обратные связи показаны на схеме процесса (см. рис. 3.31) при помощи

входящих и исходящих объектов. Например, функция «Получать, хранить и отпускать ТМЦ» имеет выход под названием «Данные по состоянию склада и движению ТМЦ», который является входом функции «Планировать закупки ТМЦ». На приведенной схеме процесса можно найти и другие обратные связи. Информационные и материальные потоки показаны на схеме процесса «За­купки» в укрупненном виде. При последующей декомпозиции процесса на бо­лее детальные эти потоки также будут рассмотрены более подробно.

176__________________________ ВВ. Репин, В.Г. Елиферов. Процессный п одход к управлении)

Тот же самый процесс, но разработанный в нотации IDEF0, предстаааен на рис. 3.32. Этот процесс будет подробно рассмотрен в главе 4 при описании цикла PDCA. Таким образом, при формировании процесса верхнего уровня очень важно отобразить основные типы потоков и существующие обратные связи. Если схема процесса верхнего уровня сформирована корректно, то существенно облегчается задача последующей декомпозиции процессов.

Какую нотацию следует использовать для описания процессов верхнего уров­ня? На наш взгляд, вполне достаточно простейших средств рисования блок-схем, таких как MS Word или MS Visio. Если использовать более серьезные инструменты, то, безусловно, стандарт IDEF0 (см. главу 2).

Рис. 3.31. Процесс «Закупки-

ТМЦ — шварно-маюриальные ценности;

Ппрод — показатель продукта;

ПЭ — показатель эффективности процесса;

БП отнес процесс;

ОПЗ — Отдел планирования икупок;

ТО УЗ — Технический отдел управления закупками.

Глава 3 Описание и анализ бизнес-процессов 177

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

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

Верхний уровень. VAD ARIS:

ОАП — Отдел анализа поставщиков;

03 — Отдел закупок;

ЛВК — Лаборатория входного контроля;

ДЗ — дебиторская задолженность;

КЗ — кредиторская задолженность;

ДУК — данные удовлетворенности клиентов;

ФО — Финансовый отдел.

178__________________________ ВВ. Репин, В. Г. Елиферов, Процессный подход к управлению

Глава 3 Описание и анализ бизнес-процессов_________________________________________ 1 79

вем проверкой адекватности. Существует методика проверки адекватности мо­делей бизнес-процессов, которая будет рассмотрена в следующем параграфе.

Источник: infopedia.su

Карта процессов верхнего уровня компании и матрица RACI c помощью drawio и google sheets

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

Введение

Карта процессов верхнего уровня (КПВУ) — это схематичное изображение деятельности (деятельность = процесс) компании, процессный “скелет” компании. Это один из ключевых элементов BPM (Business Process Management). Полистав альбом КПВУ можно в целом понять, что и как компания делает, какие подразделения в каких процессах участвуют.

Обычно отрисовку верхнеуровневых схем выполняют в нотации VAD (value added chain diagram).

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

• Accountable (сокращение A) – подотчетный, утверждающий. Это видимо владелец процесса, а он должен быть одним (иначе будет по Райкину: «рукава и пуговицы»). Хотя часто в RACI под Accountable понимается что-то иное, судя по указанию нескольких «А» для одного процесса (задачи). Подробнее о Владельцах процессов (process owner) можно почитать тут: Process Roles — Who are the Process Owners? https://www.brcommunity.com/articles.php?id=b668
• Responsible (сокращение R) – ответственный непосредственно за выполнение работы, исполнитель бизнес-процесса (executors)
• Consulted (C) – консультант и Informed (I) – роль, которой нужно направить уведомляемые о выполнении процесса — обе эти роли не рассматриваем.

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

Странно. Так как ключевая роль у владельца процесса (A), то непонятно почему такую матрицу не назвали ARCI?

Задача

Нарисовать КПВУ и далее автоматически по ней построить матрицу RACI (половинчатую). Иметь возможность для анализа приведенных данных (поиск, фильтры, группировка), т.е. поместить названия процессов и роли (и связи между ними) в аналитическую табличку (Excel, google table и т.п.) или базу данных. Когда в компании полсотни подразделений и сотня верхнеуровневых процессов, то подобный инструмент становится очень актуальным.

Пожелания к инструментам: free open source. Это позволит создать единый стандарт подход к подобным вещам. Связка Visio-Excel-VBA позволяет решить поставленную задачу, включая связку VAD с RACI, но она не перспективна.

Возьмем drawio, он же diagram.net. В примере показан первый уровень верхнеуровневых процессов. В нем, как правило, нет «цепочки добавленного качества (стоимости)», поэтому можно было бы заменить VAD-кораблики на прямоугольники. Посмотреть примеры процессов верхнего уровня можно вбив в поисковик фразу «процессы верхнего уровня», категория «картинки».

Карты верхнеуровневых процессов:

Ссылка на пример Карты верхнеуровневых процессов в drawio

При вводе данных по каждому процессу мы используем заполнители (placeholders), как показано на рисунке:

Формочка для заполнения заполнителей такая:

2 Обработка в Google Sheets

Google Sheets — это не Open Source, но для демонстрации хороший инструмент. Я храню схемы процессов в xml, поэтому и экспортировать ничего не нужно. Если что, в drawio есть кнопка экспорта в xml.

Пара возникших проблем.

Вначале пробовал парсить через функцию IMPORTXML(). Не вышло. Другие файлы парсит, но на этот выдает «Н/Д Не удалось обработать данные в формате XML». Даже для простых XPath-запросов типа «/», «//». Почему? Второй проблемой оказалось получить прямую ссылку с google drive. Для IMPORTXML нужна прямя ссылка, но разные: https://drive.google.com/uc?export=downloadid=[your_XML_file_id] не помогло.

Поэтому использовал DropBox c заменой окончания исходной ссылки «? dl = 0» на «? dl = 1».

В итоге бросил упражнения с IMPORTXML.

Для разбора xml использовал незатейливый скрипт.

В xml данные placeholders хранятся так:

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

Так как используются placeholders, то мы можем использовать в схеме любые графические примитивы: VAD-кораблики, прямоугольники, кружки.

Далее из вспомогательной таблички строим саму матрицу (полу-RACI):

Алгоритм такой: вручную расставляем в первой строке названия подразделений. Иначе ни как, хотя бы потому, что слева обычно указываются все front-подразделения, потом middle, далее back office и все обеспечивающие. Компу сложно рассказать про это.

Далее пробегаемся по вспомогательной табличке и сравниваем поля «Владелец» и «Исполнитель» с шапкой итоговой матрицы RACI (половинчатой). Если имеется равенство по Владельцу, то пишем «А» (Accountable), если по Исполнителю, то «R» (Responsible).

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

Заключение

Показанный пример упрощен для более легкого восприятия, в крупной компании такие карты верхнего уровня — это «пухлые» альбомы схем процессов, поэтому при изменении схем проводится достаточно большая работа по корректировке RACI. Любое изменение орг-штатной структуры компании или перераспределение (добавление, изъятие) функционала требует корректировки, как схем, так и матрицы. Данные подход позволяет строить матрицу автоматически по данным верхнеуровневых схем. Если есть готовые подобные инструменты — просьба сообщить.

Перспектива

Drawio diagram.net — достаточно удобная система, кроме того, это free + Open Source + облако + On-Premise, поэтому вследствие прочих равных функциональных характеристик имеет преимущества между схожими системами, включая, LucidChart.

Если с Drawio интегрировать базу данных или хотя бы Excel (наподобие связки с Excel в Visio), то получится уже «половина» ARIS. Интеграция позволит двухстороннюю связь между схемой и объектом в БД. Например, достаточно синхронизировать вышерассмотренные заполнители (placeholders) с одноименными объектами в БД. Есть такие решения?

ARIS-подобное на Open Source — когда то должно же появиться. Пока нет ни одной Open Source Free системы класса BPM-BPA. Хочется верить, что светлое (свободное) будущее BPM когда-нибудь, да наступит .

Источник: temofeev.ru

Верхнеуровневый план проекта

План проекта позволяет связать сроки, ресурсы и результаты в единую сущность. Чем детальнее план проекта, тем меньше будет отклонений. Уровень, на котором осуществляется планирование выбирает руководитель проекта. По моему опыту, любая задача должны лежать в интервале от 2 до 8 часов. В результате для проекта на 2 месяца получается план на несколько сотен строк с кучей зависимостей по задачам.

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

Кода у вас 3 человека в проекте со 100% участием, кажется простым загрузить в людей эти несколько сотен строк плана и они будут понимать всё, что происходит. Это не так. Люди понимают детали своих задач и совсем не воспринимают детали того, в чем они не разбираются. И такая избыточность даёт обратный эффект — люди тонут в деталях и не видят вектор движения в принципе.

Когда у вас в проекте более 10 человек, 8 из которых являются бизнес-пользователями с частичным привлечением в проект, задача «донести план до всех и убедиться что все его поняли» становиться нереальной.

Важно что бы все понимали когда и куда и кто идёт в проекте и какое будет их участие. Каждому участнику проекта необходимо быстро и просто «загрузить» так называемое «helicopter view» (обзор с вертолёта). Для этих целей и используется верхнеуровневый план проекта.

Верхнеуровневый план проекта

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

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

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

Детальный план проекта строиться из позиции 100% загруженности ресурсов в вашем проекте. Иными словами вы стоите в позиции «это самое важное дело в компании на текущий момент» и все ваше внимание на проекте. И вы исходите что все участники так же видят проект, как и вы.

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

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

А это уже создаёт кучу других проблем и точек сопротивления.

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

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

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

Пример детального плана проекта

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

Давайте сравним с верхнеуровневым планом.

Пример верхнеуровневого плана проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#happinesfromproject #управление проектами #методология управления #основные документы проекта #верхнеуровневый план проекта

Источник: dzen.ru