Освоение блок-схем бизнес-процессов: Комплексное руководство по визуализации, анализу и оптимизации

Введение

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

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

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

Ключевые концепции создания блок-схем бизнес-процессов

1. Цель блок-схем в BPM

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

• Общее понимание: Создание общей точки отсчета для всех заинтересованных сторон

• Анализ процессов: Выявление узких мест, неэффективности и проблем распределения ресурсов

• Стандартизация: Обеспечение последовательного выполнения в разных командах или отделах

• Обработка исключений: Картирование вариаций и пограничных случаев, отклоняющихся от обычного потока

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

2. Основные символы блок-схем

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

3. Логика точки принятия решения

Символы решений уникальны тем, что они генерируют несколько выходных путей. Лучшие практики предписывают:

• Ограничивайте решения бинарным выбором, когда это возможно (Да/Нет)

• Чётко подписывайте все исходящие стрелки

• Соблюдайте единообразие в ориентации путей (например, «Да» всегда направлено вниз, «Нет» — вправо)

• Разбивайте сложные многовариантные решения на последовательные бинарные решения или используйте структуры ветвления

4. Стратегия уровня детализации

Гранулярность вашей блок-схемы должна соответствовать её аудитории:

• Уровень руководства: Высокоуровневый обзор с 5–10 основными шагами

• Операционный уровень: Подробное пошаговое разложение с конкретными действиями

• Технический уровень: Детали реализации, включая взаимодействие систем

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

Примеры диаграмм с использованием кода PlantUML

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

Пример 1: Базовый процесс утверждения расходов

@startuml
skinparam backgroundColor white
skinparam handwritten false

title Процесс утверждения отчёта о расходах

start
:Представить отчёт о расходах;
note right: Событие-триггер

if (Сумма <= $500?) then (Да)
  :Автоматически утвердить;
  :Уведомить сотрудника;
else (Нет)
  if (Сумма <= $5000?) then (Да)
    :Направить менеджеру;
    if (Менеджер утверждает?) then (Да)
      :Утвердить;
    else (Нет)
      :Отклонить;
      :Уведомить сотрудника;
    endif
  else (Нет)
    :Направить финансовому директору;
    if (Директор утверждает?) then (Да)
      :Утвердить;
    else (Нет)
      :Отклонить;
      :Уведомить сотрудника;
    endif
  endif
endif

stop

@enduml

Пример 2: Диаграмма «Бассейны» для процесса онбординга клиентов

@startuml
skinparam backgroundColor white

title Процесс онбординга клиентов

|Отдел продаж|
start
:Получить подписанный контракт;
:Создать запись о клиенте в CRM;

|IT-отдел|
:Создать учетные записи пользователей;
:Настроить права доступа;
:Настроить электронную почту и инструменты;

|Отдел успеха клиентов|
:Запланировать вводную встречу;
:Предоставить учебные материалы;
:Провести начальную обучающую сессию;

|Финансы|
:Сформировать первый счет;
:Настроить цикл биллинга;

end
@enduml

Пример 3: Разрешение инцидентов ИТ с несколькими конечными точками

@startuml
skinparam backgroundColor white

title Поток устранения неполадок инцидентов ИТ

start
:Пользователь сообщает о проблеме;
:Классифицировать инцидент;

if (Это связано с оборудованием?) then (Да)
  :Направить техника;
  if (Можно исправить на месте?) then (Да)
    :Исправить оборудование;
    :Протестировать функциональность;
    stop
  else (Нет)
    :Заменить оборудование;
    :Обновить инвентарь;
    stop
  endif
else (Нет)
  if (Это связано с программным обеспечением?) then (Да)
    :Проверить базу известных проблем;
    if (Решение существует?) then (Да)
      :Применить исправление;
      :Подтвердить решение;
      stop
    else (Нет)
      :Передать в команду разработки;
      :Создать тикет на ошибку;
      stop
    endif
  else (Нет)
    :Направить в соответствующий отдел;
    stop
  endif
endif

@enduml

Пример 4: Сложный процесс с подпроцессами

@startuml
skinparam backgroundColor white

title Обработка страхового заявления — основной поток

start
:Получить заявление о страховом случае;
:Проверить полноту документации;

if (Документация полная?) then (Да)
  partition "Процесс расследования заявления" {
    :Назначить следователя;
    :Проанализировать детали заявления;
    :Опросить свидетелей при необходимости;
    :Собрать доказательства;
    :Подготовить отчет о расследовании;
  }
  partition "Процесс разрешения заявления" {
    :Оценить обоснованность заявления;
    if (Заявление одобрено?) then (Да)
      :Рассчитать сумму выплаты;
      :Обработать платеж;
    else (Нет)
      :Подготовить письмо об отказе;
      :Предоставить инструкции по обжалованию;
    endif
  }
else (Нет)
  :Запросить дополнительные документы;
  if (Документы получены в течение 30 дней?) then (Да)
    :Повторно проверить;
  else (Нет)
    :Закрыть заявление как неполное;
    stop
  endif
  partition "Процесс расследования заявления" {
    :Назначить следователя;
    :Проанализировать детали заявления;
    :Опросить свидетелей при необходимости;
    :Собрать доказательства;
    :Подготовить отчет о расследовании;
  }
  partition "Процесс разрешения заявления" {
    :Оценить обоснованность заявления;
    if (Заявление одобрено?) then (Да)
      :Рассчитать сумму выплаты;
      :Обработать платеж;
    else (Нет)
      :Подготовить письмо об отказе;
      :Предоставить инструкции по обжалованию;
    endif
  }
endif

:Уведомить заявителя о результате;
stop

@enduml

Лучшие практики создания блок-схем

Чтобы максимально повысить эффективность ваших блок-схем, следуйте этим двенадцати проверенным практикам:

1. Начинайте с четкого триггера

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

2. Определите явные конечные точки

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

3. Разрешите все пути принятия решений

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

4. Поддерживайте согласованную ориентацию точек принятия решений

Установите и придерживайтесь соглашения: например, «Да/Истина» всегда направляется вниз от ромбов решений, а «Нет/Ложь» всегда направляется вправо. Это обеспечивает визуальную предсказуемость.

5. Используйте ветвление для решений с несколькими вариантами

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

6. Избегайте пересечения стрелок

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

7. Следуйте естественному направлению чтения

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

8. Последовательно используйте стандартные символы

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

9. Делайте схему простой и модульной

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

10. Соответствуйте уровень детализации аудитории

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

11. Используйте лаконичный язык

Используйте фразы «глагол + существительное» («Оплатить», «Подтвердить личность»), а не длинные описания. Детальные пояснения оставляйте для сопроводительной документации или выносок.

12. Обеспечьте визуальную согласованность

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

Современные инструменты: Visual Paradigm Flowchart + VPasCode + ИИ

Почему Visual Paradigm?

Visual Paradigm стал ведущей корпоративной платформой для создания диаграмм, которая сочетает интуитивное визуальное редактирование с мощными возможностями генерации на основе кода. Её сильные стороны включают:

• Интеграция с VPasCode: Генерация блок-схем программно с помощью кода, что обеспечивает контроль версий, автоматизацию и интеграцию с CI/CD

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

• Корпоративное сотрудничество: Совместное редактирование в реальном времени, ветки комментариев и рабочие процессы согласования

• Соответствие стандартам: Поддержка BPMN, UML, ArchiMate и других отраслевых стандартов

• Гибкость экспорта: Экспорт в форматы PNG, SVG, PDF и веб-форматы для встраивания

Использование VPasCode для программной генерации блок-схем

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

1. Воспроизводимость: Диаграммы генерируются из исходного кода, что обеспечивает согласованность

2. Сотрудничество: Команды могут проверять и изменять блок-схемы через код-ревью

3. Автоматизация: Интегрировать генерацию блок-схем в конвейеры документации

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

Пример фрагмента VPasCode:

flowchart ExpenseApproval {
  start -> SubmitReport
  SubmitReport -> CheckAmount {
    amount <= 500 -> AutoApprove
    amount <= 5000 -> ManagerReview
    else -> DirectorReview
  }
  ManagerReview -> ManagerDecision {
    approved -> Approve
    rejected -> Reject
  }
  AutoApprove -> NotifyEmployee
  Approve -> NotifyEmployee
  Reject -> NotifyEmployee
  NotifyEmployee -> end
}

Создание блок-схем с усилением искусственного интеллекта

Современные инструменты на базе ИИ могут ускорить разработку блок-схем за счёт:

• Преобразование текста в диаграмму: Описать процесс на естественном языке, и ИИ сгенерирует начальную структуру блок-схемы

• Предложения по оптимизации: ИИ анализирует существующие блок-схемы, рекомендует упрощения, выявляет потенциальные узкие места или предлагает возможности для стандартизации

• Обнаружение аномалий: Автоматически помечать неразрешённые пути принятия решений, изолированные шаги или несоответствующее использование символов

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

Интеграция с рабочими процессами разработки

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

• Хранить файлы VPasCode (например, PlantUML) в репозиториях Git наряду с кодом приложения

• Автоматически генерировать обновлённую документацию при изменении процессов

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

• Связывать элементы блок-схемы с модулями кода для обеспечения прослеживаемости

Практические сценарии применения

Сценарий 1: Стандартизация процессов между отделами

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

Решение:

1. Документировать текущий процесс каждого региона с помощью блочных диаграмм с дорожками (swim lane)

2. Выявить лучшие практики из каждого варианта

3. Создать единый стандартный блок-схему процесса

4. Распространить стандартизированную блок-схему по всем регионам

5. Использовать блок-схему в качестве инструмента для обучения и справочного материала по соблюдению требований

@startuml
title Процесс обработки жалоб клиентов - Стандартизирован по всем регионам

skinparam swimlaneBorderThickness 1
skinparam ActivityBackgroundColor #E3F2FD
skinparam ActivityBorderColor #1565C0
skinparam ActivityDiamondBackgroundColor #FFF3E0
skinparam ActivityDiamondBorderColor #EF6C00

|#FCE4EC|Клиент|
start
:Подать жалобуn(по телефону / электронной почте / через веб-сайт / лично);
:Получить подтверждениеnи номер дела;

|#E8F5E9|Ресепшн / Прием заявок|
:Зарегистрировать жалобу вnсистеме CRM;
:Классифицировать типnи степень серьезности жалобы;
:Назначить приоритетn(Низкий / Средний / Высокий / Критический);

|#FFF3E0|Ответственный за жалобуn(Региональное отделение)|
:Назначитьnспециалисту по делам;
:Подтвердить получение вnрамках SLA (24 часа стандарт / 4 часа критический);

|#E8EAF6|Специалист по делам|
:Расследовать проблемуnи собрать детали;

if (Установленаnпервопричина?) then (да)
  :Определить решениеnи корректирующие действия;
else (нет)
  :Передатьnэксперту по теме;
  :Провести дополнительное расследование;
endif

:Подготовить предложениеnпо решению;
:Связаться с клиентомnс предложенным решением;

|#FCE4EC|Клиент|
if (Решениеnпринято?) then (да)
  :Подтвердить удовлетворенность;
else (нет)
  :Вести переговоры /nскорректировать предложение;
  :Передать руководителю, если вопрос не решен;
endif

|#E8EAF6|Специалист по делам|
:Реализовать решениеn(возврат средств / исправление / замена);

|#E8F5E9|Ресепшн / Прием заявок|
:Обновить CRM сnрезультатом и примечаниями;

|#FFF3E0|Региональный менеджер|
:Проверить закрытие дела;
:Провести проверкуnкачества поnстандартному процессу;

|#FCE4EC|Клиент|
:Получить уведомлениеnо закрытии и опрос после закрытия;

|#E8F5E9|Ресепшн / Прием заявок|
:Закрыть делоnв системе;

|#FFF3E0|Команда качестваn(Центральная)|
:Собрать метрикиn(время ответа, время решения, CSAT);
:Провести анализ дляnулучшения процесса;

stop

@enduml

Сценарий 2: Выявление узких мест

Задача: Выполнение заказа в среднем занимает 5 дней, но руководство считает, что это должно занимать 2 дня.

Решение:

Сгенерировать блок-схему с помощью встроенного генератора с поддержкой ИИ в VPasCode:

1. Детально отобразить полный процесс от заказа до доставки

2. Добавить оценки времени для каждого этапа процесса

3. Выявить этапы, где накапливаются задержки

4. Проанализировать точки принятия решений, вызывающие циклы переделок

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

6. Внедрить изменения и измерить улучшение

@startuml
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
<style>
  element { MaximumWidth 100 }
  start   { Backgroundcolor #00695C }
  stop    { Backgroundcolor #C2185B }
  activity{ Backgroundcolor #81D4FA; MaximumWidth 150 }
  diamond { Backgroundcolor #FFB74D; MaximumWidth 80 }
  arrow   { LineColor #424242; Fontcolor #000000 }
  swimlane{ Fontcolor #000000; FontSize 14 }
</style>

title Диаграмма деятельности по анализу узких мест в процессе от заказа до доставки

|#F0F8FF|Выполнение заказа|
start
:Получить заказ клиентаn(0,5 дня);
:Проверить детали заказа и кредитную проверкуn(0,5 дня);
if (Заказ действителен?) then (да)
  :Направить заказ на складn(0,25 дня);
else (нет)
  :Вернуть заказ на доработкуn(1,0 дня переделка);
  :Получить исправленный заказn(0,5 дня);
endif

|#FFF8DC|Складские операции|
:Подобрать товары со складаn(1,0 дня);
if (Все товары в наличии?) then (да)
  :Упаковать и маркировать отгрузкуn(0,5 дня);
else (нет)
  :Оформить заявку на закупкуn(задержка 1,5 дня);
  :Ожидать поставку от поставщикаn(задержка 1,5 дня);
  :Получить и разместить товар на складеn(0,5 дня);
endif
:Подготовить транспортные документыn(0,25 дня);

|#E8F5E9|Логистика и доставка|
:Отправить перевозчикуn(0,5 дня);
if (Доставка подтверждена?) then (нет)
  :Обработать исключение при доставкеn(1,0 дня переделка);
  :Вернуть в сеть перевозчикаn(0,5 дня);
else (да)
  :Обновить статус заказа в системеn(0,25 дня);
endif

|#F0F8FF|Улучшение процесса|
:Измерить общее время циклаn(фактическое против целевых 2 дней);
if (Время цикла <= 2 дней?) then (нет)
  :Проанализировать накопление задержек по этапам;
  :Проанализировать циклы переделок на основе решений;
  :Исключить этапы, не добавляющие ценностиnи переработать поток;
  :Внедрить изменения;
  :Измерить улучшение;
else (да)
  :Стандартизировать и документировать процесс;
endif
:Отчет о результатах руководству;

stop
@enduml

Сценарий 3: Введение в должность новых сотрудников

Задача: Новые сотрудники сообщают о путанице в том, кто что делает в первую неделю работы.

Решение:

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

2. Расположить действия в хронологическом порядке с четкими передачами

3. Включите точки принятия решений для вариаций, специфичных для ролей

4. Опубликуйте блок-схему в руководстве для сотрудников

5. Используйте её в качестве контрольного списка, чтобы убедиться, что ни один шаг не пропущен

@startuml
title Новое трудоустройство сотрудника - Блок-схема с дорожками

skinparam defaultTextAlignment center
skinparam shadowing false
skinparam roundcorner 10
skinparam swimlaneBorderColor #2E86C1
skinparam swimlaneTitleBackgroundColor #D6EAF8
skinparam ActivityBackgroundColor #EAF2F8
skinparam ActivityBorderColor #2E86C1
skinparam ActivityDiamondBackgroundColor #FDEBD0
skinparam ActivityDiamondBorderColor #E67E22

|#D6EAF8|Отдел кадров|
|#E8F8F5|ИТ|
|#FEF9E7|Руководитель|
|#F5EEF8|Наставник|

|Отдел кадров|
start
:Отправить предложение о работе и контракт;
:Собрать подписанные документы;
:Создать запись о сотруднике в HRIS;

fork
  :Отправить приветственное письмо с деталями первого дня;
fork again
  :Уведомить ИТ о подготовке оборудования;
fork again
  :Назначить наставника новому сотруднику;
end fork

:Запланировать ориентацию в первый день;

|ИТ|
:Получить заявку на трудоустройство от отдела кадров;
:Подготовить ноутбук и учетные записи;
:Настроить электронную почту, VPN и доступ к системе;
:Настроить программное обеспечение, специфичное для роли;

if (Требуется ли специальный доступ для роли?) then (Да)
  :Запросить повышенные права;
  :Настроить специализированные инструменты;
else (Нет)
endif

:Доставить оборудование на рабочее место / отправить по почте;

|Руководитель|
:Получить уведомление о новом сотруднике;
:Подготовить рабочее место и представление команде;
:Спланировать расписание на первую неделю;
:Назначить начальный проект / задачи;

|Отдел кадров|
:Провести ориентацию в первый день;
:Ознакомить с корпоративными политиками;
:Завершить оформление льгот;

|Наставник|
:Встретить нового сотрудника в первый день;
:Экскурсия по офису и знакомства;
:Обед с новым сотрудником;

|Руководитель|
:Провести приветственную встречу 1:1;
:Обсудить ожидания по роли и цели;
:Познакомить с членами команды;

|ИТ|
:Сессия настройки ИТ в первый день с новым сотрудником;
:Проверить работу всех учетных записей;

if (Обнаружены проблемы?) then (Да)
  :Устранить неполадки и решить;
  :Повторно проверить доступ;
else (Нет)
endif

|Отдел кадров|
:Обучение по соблюдению нормативных требований в дни 2-3;
:Ознакомление с руководством для сотрудников;

|Наставник|
:Сессии наставничества в дни 2-3;
:Объяснить рабочие процессы и инструменты команды;
:Ответить на вопросы и предоставить guidance;

|Руководитель|
:Встреча для проверки в третий день;

if (Является ли роль руководителем людей?) then (Да)
  :Записаться на программу лидерского онбординга;
  :Назначить наставника по лидерству;
else (Нет)
endif

:Назначить результат первой недели;

|Отдел кадров|
:Опрос обратной связи в пятый день;
:Собрать контрольный список онбординга;

|Наставник|
:Подведение итогов в конце недели с новым сотрудником;

|Руководитель|
:Проверка производительности в первую неделю;
:Подтвердить работу всех доступов и инструментов;

|Отдел кадров|
if (Все пункты контрольного списка выполнены?) then (Нет)
  :Отследить недостающие пункты;
else (Да)
endif

:Отметить завершение онбординга в HRIS;

stop

@enduml

Типичные ошибки, которых следует избегать

1. Чрезмерная сложность: Попытка отразить каждое исключение в одной диаграмме. Решение: Используйте подпроцессы и модульный дизайн.

2. Неоднозначный язык: Нечеткие описания шагов, такие как «Решите проблему». Решение: Используйте конкретные фразы «глагол-существительное».

3. Отсутствие заинтересованных сторон: Неучастие участников процесса в создании блок-схемы. Решение: Проведите совместные семинары.

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

5. Неправильное использование символов: Использование неверных символов для действий по сравнению с решениями. Решение: Проведите обучение и предоставьте справочные руководства.

6. Игнорирование исключений: Картирование только «счастливого пути». Решение: Явно документируйте обработку ошибок и потоки исключений.

Заключение

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

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

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

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