Всем привет.
По роду своей деятельности мне довольно приходилось довольно много моделировать бизнес-процессы различных организаций. Как уже работающих компаний (с целью систематизации и оптимизации существующей деятельности), так и новых, т.е. старт-апов (проектирование деятельности «с нуля»). В этой заметке я попробую кратко обобщить цели такого моделирования (раздел I), основные виды моделей (раздел II), рассказать о своих инструментальных наработках (раздел III), а также порассуждать о том, чего тут еще не хватает, в т.ч. и с точки зрения курса на импортозамещение (раздел IV).
Действительно, первый и естественный вопрос – а что это такое и зачем вообще это нужно на предприятии? Пойдем и мы каноническим путем и начнем прямо с начала (Ваш К.О.). Итак:
(1) Бизнес-процессы предприятия – это просто совокупность всех его внутренних процессов, т.е., аллегорически, это – «физиология предприятия» (в то время как организационная структура – это его «анатомия»). Чтобы чем-то управлять – нужно, как минимум, знать, как оно работает.
Важно понимать, что любой бизнес-процесс (т.е. деловой процесс) – это просто некоторая технология работы, которая или уже фактически существует в организации, или же предполагается к осуществлению (проектируется), но никак не какой-то документ или «листик с квадратиками и стрелочками». Нет, любой процесс – это технология, порядок выполнения каких-либо действий, необходимых для бизнеса (для организации). Более того, не будем забывать, что в идеале такой порядок работы должен определяться внутренними документами на официальном языке – стандартами организации (СТО). А сами графические схемы являются удобным средством проектирования нового порядка работы / визуализации уже существующего (и их можно оформлять в качестве информационно-справочного приложения к СТО).
(2) Наличие актуальной и подробной процессной модели работы (в виде комплекта актуальных СТО и/ или иерархического набора графических диаграмм) уже работающего предприятия значительно упрощает:
(3) В случае проектирования нового предприятия проработка и визуализация в виде диаграмм («картинок») основных его бизнес-процессов позволяет:
(4) Регламентация бизнес-процессов позволяет проводить их аудит («а так ли оно все работает, как это предписано?»),
(5) Использование графических диаграмм процессов облегчает обучение новых сотрудников и их адаптацию, а также позволяет уйти от излишней зависимости от «ноу-хау» отдельных сотрудников («Если он уйдет – как же во всем этом разобраться»?),
(6) Наличие формализованных описаний внутренних процессов является важной вехой на пути внедрения информационных систем и средств автоматизации деятельности.
Примечание. Здесь важно не путать первичное и вторичное. Да, компьютерная программа может работать только по четкому алгоритму. Но не нужно забывать, что «Автоматизация для бизнеса, а не бизнес для автоматизации», и что множество бизнес-процессов предприятия всегда больше (уж точно не меньше) области автоматизации. Итак, сначала ноты (технология) – потом инструмент (автоматизация), но не наоборот.
(7) Региональная экспансия: «записав» в модель/ систему внутренних стандартов технологию работы успешного предприятия, можно затем ее тиражировать на другие, вновь открываемые, или создать франшизу.
(II.1) С точки зрения актуальности содержания модели делятся на:
(1) Модель «Как есть» (англ. «AS IS»): отражает РЕАЛЬНОЕ положение дел на момент описания, фактически имеющуюся, сложившуюся технологию работы.
(2) Модель «Как должно быть» (англ. «TO BE»): отражает целевое состояние, которое в дальнейшем предполагается претворить в жизнь. Например, модель работы вновь открываемого предприятия, или же новый (совсем новый или улучшенный старый) порядок выполнения каких-либо работ.
(2) Модель «Как должно бы быть» (англ. «SHOULD BE»): отражает «идеализированное» положение дел (согласно регламентирующим документам), тогда как фактическая схема работ в реальности может быть несколько иной. На практике необходимость в построении таких моделей встречается нечасто.
Отметим, что приведенные модели одного и того же процесса могут различаться весьма значительно. Пример: модель регулируемого пешеходного перехода, светофор переключается автоматически через определенный промежуток времени.
«Как есть»: Некоторые пешеходы ждут зеленого и переходят только на зеленый. А некоторые – не ждут зеленого сигнала, они смотрят по сторонам и перебегают дорогу, если, по их мнению, опасность попасть в ДТП им не грозит. Так делать не стоит, но в реальности, к сожалению, случается.
«Как должно бы быть» (ибо так написано в ПДД): Все пешеходы ждут зеленого и переходят только на зеленый.
В данном случае, модель «Как должно бы быть» могла бы совпасть с «Как должно быть». Однако они могут не совпасть, если в качестве модели «Как должно быть», т.е. той, которая будет признана целевой, будет одна из следующих:
«Как должно быть»: «Светофор с кнопкой». Пешеходы подходят к переходу и нажимают на кнопку – через определенный промежуток времени загорается зеленый.
«Как должно быть»: Пешеходный переход запрещен.
«Как должно быть»: Пешеходный переход станет надземным или подземным.
«Как должно быть»: Улица станет пешеходной.
(II.1) С точки зрения метода моделирования и, соответственно, области применения результата рассмотрим следующие виды моделей:
(1) Функциональные модели.
(2) Модели потоков работ (worklow-модели).
Функциональные модели представляют собой «принципиальную схему работы». Т.е. что рожь сначала сеять, потом жать, потом молотить. Или что сначала изготовить детали, потом собрать изделие, потом – выходной контроль качества. И т.д.
Сегодня, пожалуй, одной из самых популярных методологий функционального моделирования является IDEF0. По сути, эта методология является де-факто «мировым стандартом», признанным как за рубежом, так и в РФ (см., напр. Р 50.1.028-2001. методология функционального моделирования). Описание методологии IDEF0 легко найти, в т.ч. и в Сети.
Моделирование предприятия часто рекомендуют начинать с формирования функциональной модели. Однако нужно помнить, что такие модели являются «статичными», они не предназначены для, например, описания пошаговой реализацию какой-либо рабочей процедуры. А предназначены они для отображения общей картины, принципиальной схемы работы. Что до детальных пошаговых моделей осуществления какой-либо деятельности, то для этого предназначены модели потоков работ (worklow-модели). И о них – ниже.
Модели потоков работ (worklow-модели) позволяют описать процесс как упорядоченную последовательность выполнения различных действий, возникающих событий, а также объектов, участвующих в реализации данного процесса. Именно такие модели нужно строить, когда Вы хотите описать/ спроектировать конкретный процесс на своем предприятии, например, «Порядок приема товара на склад», «Правила подачи заявки на перевозку», и др.
Модели потоков работ могут формироваться как на очередном шаге построения функциональной модели – при ее дальнейшей детализации, – так и самостоятельно, когда есть необходимость описать (спроектировать) какую-либо отдельную процедуру. На практике второй путь тоже используется нередко, когда работа начинается с «болевых точек» предприятия, или же вообще идет методом «от реестра процессов предприятия».
Что до выбора конкретной нотации worklow-моделирования (т.е. собственно графического языка), то тут, в отличие от функционального моделирования, выбор довольно большой. Это и IDEF3, и «плавательные дорожки», и средства ARIS, и методология BPMN, и другие. И каждой из этих методологий есть свои плюсы.
Что до меня, то я пользуюсь нотацией «собственного изготовления» – CH-1 нотацией. Скажу честно, когда я только начинал заниматься выстраиванием бизнес-процессов, у меня и в мыслях не было сочинять какой-то там язык. Но: начав с одного из стандартных средств, в реальной работе оказалось (повторюсь, именно в моем случае), что средств используемого языка недостаточно для краткой и полной записи «со слов», причем без потери данных, другой оказался для сотрудников слишком сложен…. И вот так, вводя дополнительные символы и некоторые изменения, не думая – не гадая, в середине «двухтысячных» и появилась CH-1. Пара слов о ней ниже.
Итак, нотаций workflow-моделирования существует множество. И это нужно рассматривать как плюс: принцип «пусть расцветают сто цветов» тут как нельзя более кстати. Выбор нотации моделирования зависит от задачи (а задачи бывают очень разные). Например, для моделирования производственных линий используются совсем другие, не упомянутые здесь методы моделирования. Так что такой «методический плюрализм» в моделировании потоков работ не случаен.
Если мы говорим о CH-1 нотации, то она изначально предназначена для описания процессов в виде последовательности действий с указанием их исполнителей, связанных событий, значимых параметров выполняемых действий и/ или процесса в целом (например, нормативная длительность) и возникающих потоков: материальных и информационных. Русскоязычная версия ее спецификации (с примерами) выложена здесь: https://drive.google.com/file/d/0B_wUAIgOErG8MTQzYzJhNGUtZGY1NC00OTE1LWFlMzgtMDEyZmFjYTFjMDk3/view?usp=sharing&resourcekey=0-4GSk6JELtRDeHZ6CC70PYg, подробнее см. также здесь https://ch1-notation.blogspot.com (персональная страница про CH-1).
Если же говорить о софте, то используемые в данной (как, впрочем, и в любой другой) нотации символы можно найти почти в любом ПО, имеющем встроенные библиотеки графических примитивов. Причем как в коммерческом ПО, так и в ПО, распространяемом бесплатно. Кроме того, на сегодняшний день в ряде программных продуктов существуют специальные библиотеки символов CH-1.
При этом, если используемый программный продукт поддерживает механизм гиперссылок (что встречается довольно часто), то с их помощью полезно:
Что до использования более специализированных программных продуктов для моделирования процессов (не «рисовалок» и редакторов), то и здесь мнения могут быть различными. Лично мне они не очень удобны ввиду большого количества налагаемых дополнительных ограничений. Хотя кому-то они наоборот будут более удобны. Тут опять же – «на вкус и цвет (и задачу)» – товарища нет.
Диаграмма (схема) бизнес-процесса – это, по сути, его (прото)регламент в графическом виде. Ну, или (прото)стандарт организации, если выражаться более официально. Вся информация о том, «кто, куда, чего и как» должна там наличествовать. А, соответственно, встает вопрос: «Нельзя ли сформировать текст по диаграмме нажатием одной кнопки»? Причем задачу можно усложнить: регламент (стандарт) должен быть на «человеческом» языке, а не в стиле «отчет» из серии набора заголовков: «Кто?» «Что?» «Когда?» и т.п. и автоматически копируемого в соответствующие разделы несклоняемого текста.
Если говорить о CH-1 диаграммах, то для них был разработан алгоритм их машинного перевода на «человеческий язык» в форму готового проекта стандарта. Алгоритм – на сей день не оттестированный (ввиду нереализованности в коде) – размещен здесь: https://drive.google.com/file/d/0B_wUAIgOErG8bTluc2xYSVI4NXc/view?usp=sharing&resourcekey=0-myqzNChQpk7MslmcbtVyPw, см. также здесь: https://ch1-notation.blogspot.com (персональная страница про CH-1). С реализацией этого в коде одному мне не справиться не удалось. При этом оптимальным видится двуступенчатый вариант, когда мы имеем экспорт из графического редактора в, например, xml, а затем генерацию текста в текстовом редакторе уже из xml. Подобная организация является открытой в том смысле, что последовательно к ней можно «подрубать» все новые и новые графические и текстовые редакторы. Также она должна обеспечивать конфиденциальность данных, и, с этой точки зрения, вариант ПО с открытым исходным кодом является выигрышным.
И в заключении – о чем? – об импортозамещении. Совершенно очевидно, что, как минимум, для стратегических предприятий, госорганов и других организаций, для которых важна информационная безопасность, доверять даже «отрисовку» своих процессов импортному ПО с закрытым исходным кодом может быть неприемлемым. Действительно, процессная модель предприятия, охватывающая его внутренние процессы, – что в графическом (иерархический набор диаграмм), что в текстовом (в виде стандартов организации) виде, – содержит почти всю информацию о его внутреннем устройстве – «бери и строй», как говорится. Поэтому создание подобного полностью отечественного программного продукта (как синтез «рисовалки» (редактор диаграмм, графический векторный редактор) и «текстогенератора») приобретает особую актуальность.
По роду своей деятельности мне довольно приходилось довольно много моделировать бизнес-процессы различных организаций. Как уже работающих компаний (с целью систематизации и оптимизации существующей деятельности), так и новых, т.е. старт-апов (проектирование деятельности «с нуля»). В этой заметке я попробую кратко обобщить цели такого моделирования (раздел I), основные виды моделей (раздел II), рассказать о своих инструментальных наработках (раздел III), а также порассуждать о том, чего тут еще не хватает, в т.ч. и с точки зрения курса на импортозамещение (раздел IV).
(I) Что это и Зачем все это нужно
Действительно, первый и естественный вопрос – а что это такое и зачем вообще это нужно на предприятии? Пойдем и мы каноническим путем и начнем прямо с начала (Ваш К.О.). Итак:
(1) Бизнес-процессы предприятия – это просто совокупность всех его внутренних процессов, т.е., аллегорически, это – «физиология предприятия» (в то время как организационная структура – это его «анатомия»). Чтобы чем-то управлять – нужно, как минимум, знать, как оно работает.
Важно понимать, что любой бизнес-процесс (т.е. деловой процесс) – это просто некоторая технология работы, которая или уже фактически существует в организации, или же предполагается к осуществлению (проектируется), но никак не какой-то документ или «листик с квадратиками и стрелочками». Нет, любой процесс – это технология, порядок выполнения каких-либо действий, необходимых для бизнеса (для организации). Более того, не будем забывать, что в идеале такой порядок работы должен определяться внутренними документами на официальном языке – стандартами организации (СТО). А сами графические схемы являются удобным средством проектирования нового порядка работы / визуализации уже существующего (и их можно оформлять в качестве информационно-справочного приложения к СТО).
(2) Наличие актуальной и подробной процессной модели работы (в виде комплекта актуальных СТО и/ или иерархического набора графических диаграмм) уже работающего предприятия значительно упрощает:
- внесение изменений в существующую схему работы,
- перераспределение работ и ответственности между различными сотрудниками и отделами,
- установку необходимых контрольных точек (например, «Секретарь снимает трубку на 2-3 гудок», «Заказы на следующий день принимаются в обработку до 16-00 предыдущего дня», и т.д.).
(3) В случае проектирования нового предприятия проработка и визуализация в виде диаграмм («картинок») основных его бизнес-процессов позволяет:
- представить себе будущую технологию работы более полно наглядно,
- выявить какие-то потенциально сложные места, нестыковки, поставить перед собой и затем найти ответ на различные вопросы («А как будет…?», «А кто будет делать…?», «А до которого часа нужно закончить эту работу?» и пр.).
- а еще в графическом виде схемы бизнес-процессов удобнее согласовывать со всеми заинтересованными людьми и экспертами предметной области (наглядность).
(4) Регламентация бизнес-процессов позволяет проводить их аудит («а так ли оно все работает, как это предписано?»),
(5) Использование графических диаграмм процессов облегчает обучение новых сотрудников и их адаптацию, а также позволяет уйти от излишней зависимости от «ноу-хау» отдельных сотрудников («Если он уйдет – как же во всем этом разобраться»?),
(6) Наличие формализованных описаний внутренних процессов является важной вехой на пути внедрения информационных систем и средств автоматизации деятельности.
Примечание. Здесь важно не путать первичное и вторичное. Да, компьютерная программа может работать только по четкому алгоритму. Но не нужно забывать, что «Автоматизация для бизнеса, а не бизнес для автоматизации», и что множество бизнес-процессов предприятия всегда больше (уж точно не меньше) области автоматизации. Итак, сначала ноты (технология) – потом инструмент (автоматизация), но не наоборот.
(7) Региональная экспансия: «записав» в модель/ систему внутренних стандартов технологию работы успешного предприятия, можно затем ее тиражировать на другие, вновь открываемые, или создать франшизу.
(II) Модели процессов: виды
(II.1) С точки зрения актуальности содержания модели делятся на:
(1) Модель «Как есть» (англ. «AS IS»): отражает РЕАЛЬНОЕ положение дел на момент описания, фактически имеющуюся, сложившуюся технологию работы.
(2) Модель «Как должно быть» (англ. «TO BE»): отражает целевое состояние, которое в дальнейшем предполагается претворить в жизнь. Например, модель работы вновь открываемого предприятия, или же новый (совсем новый или улучшенный старый) порядок выполнения каких-либо работ.
(2) Модель «Как должно бы быть» (англ. «SHOULD BE»): отражает «идеализированное» положение дел (согласно регламентирующим документам), тогда как фактическая схема работ в реальности может быть несколько иной. На практике необходимость в построении таких моделей встречается нечасто.
Отметим, что приведенные модели одного и того же процесса могут различаться весьма значительно. Пример: модель регулируемого пешеходного перехода, светофор переключается автоматически через определенный промежуток времени.
«Как есть»: Некоторые пешеходы ждут зеленого и переходят только на зеленый. А некоторые – не ждут зеленого сигнала, они смотрят по сторонам и перебегают дорогу, если, по их мнению, опасность попасть в ДТП им не грозит. Так делать не стоит, но в реальности, к сожалению, случается.
«Как должно бы быть» (ибо так написано в ПДД): Все пешеходы ждут зеленого и переходят только на зеленый.
В данном случае, модель «Как должно бы быть» могла бы совпасть с «Как должно быть». Однако они могут не совпасть, если в качестве модели «Как должно быть», т.е. той, которая будет признана целевой, будет одна из следующих:
«Как должно быть»: «Светофор с кнопкой». Пешеходы подходят к переходу и нажимают на кнопку – через определенный промежуток времени загорается зеленый.
«Как должно быть»: Пешеходный переход запрещен.
«Как должно быть»: Пешеходный переход станет надземным или подземным.
«Как должно быть»: Улица станет пешеходной.
(II.1) С точки зрения метода моделирования и, соответственно, области применения результата рассмотрим следующие виды моделей:
(1) Функциональные модели.
(2) Модели потоков работ (worklow-модели).
Функциональные модели представляют собой «принципиальную схему работы». Т.е. что рожь сначала сеять, потом жать, потом молотить. Или что сначала изготовить детали, потом собрать изделие, потом – выходной контроль качества. И т.д.
Сегодня, пожалуй, одной из самых популярных методологий функционального моделирования является IDEF0. По сути, эта методология является де-факто «мировым стандартом», признанным как за рубежом, так и в РФ (см., напр. Р 50.1.028-2001. методология функционального моделирования). Описание методологии IDEF0 легко найти, в т.ч. и в Сети.
Моделирование предприятия часто рекомендуют начинать с формирования функциональной модели. Однако нужно помнить, что такие модели являются «статичными», они не предназначены для, например, описания пошаговой реализацию какой-либо рабочей процедуры. А предназначены они для отображения общей картины, принципиальной схемы работы. Что до детальных пошаговых моделей осуществления какой-либо деятельности, то для этого предназначены модели потоков работ (worklow-модели). И о них – ниже.
Модели потоков работ (worklow-модели) позволяют описать процесс как упорядоченную последовательность выполнения различных действий, возникающих событий, а также объектов, участвующих в реализации данного процесса. Именно такие модели нужно строить, когда Вы хотите описать/ спроектировать конкретный процесс на своем предприятии, например, «Порядок приема товара на склад», «Правила подачи заявки на перевозку», и др.
Модели потоков работ могут формироваться как на очередном шаге построения функциональной модели – при ее дальнейшей детализации, – так и самостоятельно, когда есть необходимость описать (спроектировать) какую-либо отдельную процедуру. На практике второй путь тоже используется нередко, когда работа начинается с «болевых точек» предприятия, или же вообще идет методом «от реестра процессов предприятия».
Что до выбора конкретной нотации worklow-моделирования (т.е. собственно графического языка), то тут, в отличие от функционального моделирования, выбор довольно большой. Это и IDEF3, и «плавательные дорожки», и средства ARIS, и методология BPMN, и другие. И каждой из этих методологий есть свои плюсы.
Что до меня, то я пользуюсь нотацией «собственного изготовления» – CH-1 нотацией. Скажу честно, когда я только начинал заниматься выстраиванием бизнес-процессов, у меня и в мыслях не было сочинять какой-то там язык. Но: начав с одного из стандартных средств, в реальной работе оказалось (повторюсь, именно в моем случае), что средств используемого языка недостаточно для краткой и полной записи «со слов», причем без потери данных, другой оказался для сотрудников слишком сложен…. И вот так, вводя дополнительные символы и некоторые изменения, не думая – не гадая, в середине «двухтысячных» и появилась CH-1. Пара слов о ней ниже.
(III) Пара слов о CH-1 нотации
Итак, нотаций workflow-моделирования существует множество. И это нужно рассматривать как плюс: принцип «пусть расцветают сто цветов» тут как нельзя более кстати. Выбор нотации моделирования зависит от задачи (а задачи бывают очень разные). Например, для моделирования производственных линий используются совсем другие, не упомянутые здесь методы моделирования. Так что такой «методический плюрализм» в моделировании потоков работ не случаен.
Если мы говорим о CH-1 нотации, то она изначально предназначена для описания процессов в виде последовательности действий с указанием их исполнителей, связанных событий, значимых параметров выполняемых действий и/ или процесса в целом (например, нормативная длительность) и возникающих потоков: материальных и информационных. Русскоязычная версия ее спецификации (с примерами) выложена здесь: https://drive.google.com/file/d/0B_wUAIgOErG8MTQzYzJhNGUtZGY1NC00OTE1LWFlMzgtMDEyZmFjYTFjMDk3/view?usp=sharing&resourcekey=0-4GSk6JELtRDeHZ6CC70PYg, подробнее см. также здесь https://ch1-notation.blogspot.com (персональная страница про CH-1).
Если же говорить о софте, то используемые в данной (как, впрочем, и в любой другой) нотации символы можно найти почти в любом ПО, имеющем встроенные библиотеки графических примитивов. Причем как в коммерческом ПО, так и в ПО, распространяемом бесплатно. Кроме того, на сегодняшний день в ряде программных продуктов существуют специальные библиотеки символов CH-1.
При этом, если используемый программный продукт поддерживает механизм гиперссылок (что встречается довольно часто), то с их помощью полезно:
- «привязывать» диаграммы декомпозиции к декомпозируемым работам;
- «прицеплять» к диаграммам шаблоны используемых при реализации бизнес-процесса документов, примеры их заполнения, ссылки на руководящие документы и т.д.
Что до использования более специализированных программных продуктов для моделирования процессов (не «рисовалок» и редакторов), то и здесь мнения могут быть различными. Лично мне они не очень удобны ввиду большого количества налагаемых дополнительных ограничений. Хотя кому-то они наоборот будут более удобны. Тут опять же – «на вкус и цвет (и задачу)» – товарища нет.
(IV) В мечтах о будущем: автоматическая генерация регламентов (машинный перевод «диаграмма-текст»)
Диаграмма (схема) бизнес-процесса – это, по сути, его (прото)регламент в графическом виде. Ну, или (прото)стандарт организации, если выражаться более официально. Вся информация о том, «кто, куда, чего и как» должна там наличествовать. А, соответственно, встает вопрос: «Нельзя ли сформировать текст по диаграмме нажатием одной кнопки»? Причем задачу можно усложнить: регламент (стандарт) должен быть на «человеческом» языке, а не в стиле «отчет» из серии набора заголовков: «Кто?» «Что?» «Когда?» и т.п. и автоматически копируемого в соответствующие разделы несклоняемого текста.
Если говорить о CH-1 диаграммах, то для них был разработан алгоритм их машинного перевода на «человеческий язык» в форму готового проекта стандарта. Алгоритм – на сей день не оттестированный (ввиду нереализованности в коде) – размещен здесь: https://drive.google.com/file/d/0B_wUAIgOErG8bTluc2xYSVI4NXc/view?usp=sharing&resourcekey=0-myqzNChQpk7MslmcbtVyPw, см. также здесь: https://ch1-notation.blogspot.com (персональная страница про CH-1). С реализацией этого в коде одному мне не справиться не удалось. При этом оптимальным видится двуступенчатый вариант, когда мы имеем экспорт из графического редактора в, например, xml, а затем генерацию текста в текстовом редакторе уже из xml. Подобная организация является открытой в том смысле, что последовательно к ней можно «подрубать» все новые и новые графические и текстовые редакторы. Также она должна обеспечивать конфиденциальность данных, и, с этой точки зрения, вариант ПО с открытым исходным кодом является выигрышным.
И в заключении – о чем? – об импортозамещении. Совершенно очевидно, что, как минимум, для стратегических предприятий, госорганов и других организаций, для которых важна информационная безопасность, доверять даже «отрисовку» своих процессов импортному ПО с закрытым исходным кодом может быть неприемлемым. Действительно, процессная модель предприятия, охватывающая его внутренние процессы, – что в графическом (иерархический набор диаграмм), что в текстовом (в виде стандартов организации) виде, – содержит почти всю информацию о его внутреннем устройстве – «бери и строй», как говорится. Поэтому создание подобного полностью отечественного программного продукта (как синтез «рисовалки» (редактор диаграмм, графический векторный редактор) и «текстогенератора») приобретает особую актуальность.
