Архитектура причин вместо списка проблем
В любой сложной организации проблем всегда много.
Срываются сроки.
Растёт текучесть.
Руководители перегружены.
Клиенты жалуются.
Проекты конкурируют за ресурсы.
Решения принимаются слишком долго.
Сотрудники не проявляют инициативу.
Процессы требуют ручного контроля.
Функции конфликтуют.
Показатели начинают расходиться с планом.
Обычно каждую такую проблему начинают обсуждать отдельно.
Для сроков создают отдельный план.
Для текучести — отдельную программу.
Для перегрузки руководителей — инициативу по делегированию.
Для качества — дополнительный контроль.
Для взаимодействия функций — новые встречи.
Для проектов — новый формат отчётности.
Для мотивации — обновлённые KPI.
Организация постепенно формирует длинный список проблем и такой же длинный список действий.
На первый взгляд это выглядит как активное управление.
Но именно здесь часто возникает фундаментальная ошибка.
Список проблем ещё не является пониманием системы.
Пять разных симптомов могут иметь одну общую причину.
Одна проблема может создавать несколько последствий.
А одно управленческое решение способно одновременно улучшить один показатель и ухудшить три других.
Поэтому в сложной организации важно переходить от списка проблем к архитектуре причин.
Список проблем описывает поверхность
Допустим, у компании есть пять наблюдений.
Проекты задерживаются.
Сотрудники перерабатывают.
Руководители жалуются на нехватку людей.
Качество ухудшается.
Количество срочных задач растёт.
Можно начать решать каждую проблему отдельно.
Нанять людей.
Усилить контроль качества.
Попросить проектных менеджеров точнее планировать.
Ввести ограничения на переработки.
Создать правила для срочных задач.
Каждое действие само по себе выглядит разумно.
Но если посмотреть глубже, может оказаться, что все пять симптомов создаются одной структурой.
Компания запускает больше инициатив, чем способны обработать ограниченные ресурсы.
Тогда возникает цепочка.
Слишком много проектов создают перегрузку.
Перегрузка увеличивает переключения.
Переключения замедляют работу.
Сроки начинают сдвигаться.
Чтобы компенсировать задержки, люди работают дольше.
Усталость увеличивает ошибки.
Ошибки ухудшают качество.
Для исправления ситуации появляются срочные задачи.
Срочные задачи ещё сильнее разрушают плановую работу.
Теперь перед нами уже не пять отдельных проблем.
Перед нами один механизм.
Разница между причиной и симптомом особенно важна для управления
Если человек приходит к врачу с температурой, температура является реальной проблемой.
Но она не обязательно является причиной болезни.
С организацией происходит то же самое.
Высокая текучесть реальна.
Но что её создаёт?
Недостаточная компенсация?
Слабое управление?
Перегрузка?
Плохой подбор?
Отсутствие развития?
Конфликт ролей?
Неустойчивая бизнес-модель?
Проблема в том, что управлять симптомом обычно проще.
Он виден.
Его можно измерить.
Можно назначить владельца.
Сформировать проект.
Но если механизм остаётся прежним, симптом либо возвращается, либо возникает в другом месте.
Именно поэтому системное мышление предлагает искать не единичное событие, а структуру, которая устойчиво производит наблюдаемый результат. В материалах по системному мышлению эта логика строится вокруг анализа паттернов, ограничений и причинно-следственных связей, а не только внешнего проявления проблемы.
У одной причины может быть множество проявлений
Допустим, решения в компании чрезмерно централизованы.
На первый взгляд это одна управленческая особенность.
Но последствия могут проявляться в разных функциях.
Проекты ждут согласований.
Сотрудники перестают проявлять инициативу.
Средний менеджмент перегружен.
Клиенты дольше получают ответы.
Сильные сотрудники начинают раздражаться из-за отсутствия автономии.
Топ-менеджеры жалуются на операционную загрузку.
Организация нанимает дополнительных координаторов.
Каждое подразделение видит собственную проблему.
Проектный офис — задержки.
HR — вовлечённость и удержание.
Операции — медленные решения.
Руководство — собственную перегрузку.
Но все они могут быть различными проявлениями одной архитектуры решений.
Если организация не соединит эти наблюдения, она начнёт одновременно лечить несколько симптомов одного механизма.
И наоборот: одинаковый симптом может иметь разные причины
Допустим, продажи упали на 15%.
Это один показатель.
Но причины могут быть совершенно разными.
Изменился спрос.
Появился сильный конкурент.
Ухудшилось качество лидов.
Цена перестала соответствовать ценности продукта.
Команда продаж ослабла.
Операции не способны выполнить объём обещаний.
Изменились условия оплаты.
Продукт потерял релевантность.
Если организация сразу формулирует:
«У нас проблема с продажами»,
она уже рискует слишком сильно сузить пространство анализа.
Функция, в которой проявилась проблема, не обязательно является местом, где находится причина.
Это одно из ключевых различий между функциональным и системным анализом.
Архитектура причин начинается с вопроса «что с чем связано?»
Список выглядит так:
текучесть;
низкая производительность;
переработки;
ошибки;
недовольство клиентов.
Архитектура причин пытается соединить элементы.
Например:
нехватка ресурсов → рост нагрузки → переработки → усталость → ошибки → переделки → ещё большая нагрузка.
Теперь становится видно, что система содержит обратную связь.
Проблема усиливает саму себя.
Больше нагрузки создаёт больше ошибок.
Больше ошибок создаёт больше повторной работы.
Повторная работа увеличивает нагрузку.
Получается замкнутый цикл.
Если организация будет бороться только с ошибками через дополнительный контроль, она может ещё сильнее увеличить нагрузку.
То есть локально разумное решение усиливает первоначальный механизм.
Именно обратные связи делают сложные проблемы устойчивыми
В линейной модели всё выглядит просто.
Причина создаёт следствие.
Исправили причину — проблема исчезла.
В организационных системах часто возникают циклы.
Например:
руководитель не доверяет команде;
поэтому сильнее контролирует;
у команды меньше пространства для самостоятельных решений;
команда меньше развивает самостоятельность;
руководитель видит, что без него решения принимаются плохо;
доверие снижается ещё сильнее.
Что здесь является причиной?
Слабая команда?
Контролирующий руководитель?
Недостаток опыта?
Отсутствие делегирования?
Если искать одну «корневую причину», можно легко потерять структуру.
Более точный взгляд:
система воспроизводит поведение через взаимное усиление нескольких факторов.
Тогда задача управления — найти точку, изменение которой способно разорвать цикл.
Причина может находиться далеко от места, где проявляется проблема
Представим снижение клиентской удовлетворённости.
Первое внимание естественно направляется на клиентский сервис.
Но механизм может начинаться значительно раньше.
Продажи обещают индивидуальные условия.
Операции получают нестандартные задачи.
Количество исключений растёт.
Сроки увеличиваются.
Клиенты сталкиваются с задержками.
Сервис получает больше обращений.
В итоге показатель ухудшается именно у клиентского блока.
Но проблема сформировалась на этапе коммерческого решения.
Если анализ остановится на функции, где проявился симптом, компания будет обучать операторов лучше общаться с раздражёнными клиентами.
Хотя настоящая причина — в архитектуре предложения.
Причина может находиться и далеко во времени
Сегодня компания сокращает расходы на обучение.
Финансовый эффект виден сразу.
Через несколько месяцев новые сотрудники дольше выходят на производительность.
Опытные сотрудники тратят больше времени на помощь новичкам.
Их собственная производительность падает.
Нагрузка увеличивается.
Через год растёт текучесть.
Если смотреть на момент увольнений, решение о сокращении обучения уже никто не связывает с текущей проблемой.
Между причиной и следствием слишком большое временное расстояние.
Поэтому архитектура причин должна учитывать задержки.
Без них организация часто связывает между собой только события, которые произошли рядом.
А самые важные причинные связи остаются незаметными.
Не все причины одинаково сильны
Представим проект, который задержался из-за нескольких факторов.
Поставщик опоздал на неделю.
Команда недооценила объём.
Бизнес несколько раз менял требования.
Критический специалист был занят другим проектом.
Согласование решения заняло три недели.
Можно записать пять причин.
Но этого недостаточно.
Нужно понимать, какой фактор действительно определял результат.
Если без трёхнедельного согласования проект всё равно успевал, а без критического специалиста — нет, влияние причин различается.
Архитектура причин должна показывать не только наличие связи.
Но и её силу.
Иначе организация получает просто более интеллектуально оформленный список.
Нужно различать непосредственную причину и структурную
Допустим, клиент получил заказ поздно.
Непосредственная причина:
логистика не успела отправить.
Почему?
Поставка была готова позже.
Почему?
Производство задержало выполнение.
Почему?
Не было комплектующего.
Почему?
Закупка пришла поздно.
На этом можно остановиться.
Но структурный вопрос звучит иначе:
почему отсутствие одного комплектующего способно системно срывать весь заказ?
Возможно:
нет буфера;
поставщик единственный;
прогнозирование слабое;
правила запасов чрезмерно жёсткие;
информация о риске появляется слишком поздно.
Непосредственная причина объясняет конкретный случай.
Структурная — почему система уязвима к таким случаям регулярно.
Для предотвращения повторений второй уровень важнее.
Архитектура причин должна отделять факт от интерпретации
Это один из самых сложных элементов анализа.
Факт:
срок согласования вырос с двух до пяти дней.
Интерпретация:
руководители стали медленнее принимать решения.
Но причины могут быть другими.
Увеличилось количество вопросов.
Решения стали сложнее.
Появились новые требования к рискам.
У руководителей стало больше зон ответственности.
Изменилась структура полномочий.
Если интерпретацию быстро превратить в факт, вся причинная схема будет построена на слабом основании.
Поэтому сильный анализ должен постоянно различать:
что мы наблюдаем;
что предполагаем;
что уже подтвердили.
Необходимо искать паттерны, а не единичные примеры
Один проект задержался из-за ресурса.
Это случай.
Пять проектов регулярно борются за одного и того же специалиста.
Это уже паттерн.
Один сотрудник пожаловался на руководителя.
Это отдельная ситуация.
В нескольких командах возникает одинаковая проблема.
Теперь стоит искать общий механизм.
Один клиент попросил необычное условие.
Это может быть исключение.
Если разные клиенты начинают независимо требовать одно и то же, возможно, меняется рынок.
Архитектура причин строится на повторяемости.
Именно повторяемость помогает отделять системную структуру от шума.
Хорошая причинная карта часто соединяет разные функции
Представим организацию, где одновременно возникают четыре проблемы.
Продажи жалуются на нехватку продукта.
Операции — на постоянные изменения приоритетов.
Закупки — на срочные запросы.
Финансы — на рост запасов.
Если функции анализируют ситуацию отдельно, появляются четыре проекта улучшения.
Но причинная архитектура может выглядеть так:
нет устойчивого процесса планирования спроса → прогноз регулярно меняется → операции перестраивают производство → закупки работают срочно → компания увеличивает страховые запасы → оборотный капитал растёт.
Теперь проблема перестаёт принадлежать одной функции.
Это уже сквозная система.
Именно такие механизмы особенно сложно исправлять через функциональные KPI.
Причинная архитектура помогает увидеть управленческие противоречия
Очень часто проблема создаётся не плохим процессом, а конфликтом рациональных целей.
Например:
продажи стимулируются на объём;
операции — на стандартизацию;
финансы — на снижение запасов;
клиент ожидает скорость и индивидуальность.
Каждая функция принимает локально правильные решения.
Но вместе они создают постоянный конфликт.
Продажи обещают больше вариативности.
Операции сопротивляются.
Финансы ограничивают запас.
Сроки растут.
Причина не находится внутри одного подразделения.
Она встроена в систему целей.
В таком случае обучение взаимодействию будет иметь ограниченный эффект.
Нужно менять архитектуру KPI, полномочий и компромиссов.
Иногда главная причина — отсутствие решения
Это особенно распространённая ситуация.
Организация обсуждает проблему неделями.
Есть несколько вариантов.
Но никто не имеет полномочий окончательно выбрать один.
Проект продолжает работать во временном режиме.
Появляются обходные решения.
Команда компенсирует неопределённость ручной работой.
Через некоторое время список проблем становится длиннее.
Кажется, что система становится всё сложнее.
Хотя значительная часть сложности возникла вокруг одного непринятого решения.
Поэтому при анализе причин полезно спрашивать:
какое управленческое решение должно было быть принято раньше, но не было принято?
Иногда это намного сильнее любого процессного анализа.
Отсутствие приоритета тоже является причиной
Организация может рассматривать перегрузку как ресурсную проблему.
Не хватает людей.
Но почему не хватает?
Потому что одновременно выполняется слишком много задач.
Почему выполняется слишком много?
Потому что все инициативы объявлены важными.
Почему ничего не остановлено?
Нет механизма приоритизации или руководители не готовы отказаться от собственных проектов.
Тогда нехватка ресурсов становится следствием отсутствия выбора.
Это особенно важно на уровне портфеля.
Портфельное управление должно помогать видеть не только статус каждой инициативы, но и совокупную нагрузку, зависимости, ресурсы и конфликт приоритетов на уровне всей организации.
Если этих связей нет, каждый проект может выглядеть реалистичным отдельно, а весь портфель — быть физически невыполнимым.
Причины могут усиливать друг друга
Допустим, компания сталкивается с высокой текучестью.
Текучесть уменьшает количество опытных сотрудников.
Нагрузка на оставшихся растёт.
Они чаще перерабатывают.
Качество снижается.
Количество конфликтов увеличивается.
Часть сильных людей увольняется.
Текучесть растёт ещё сильнее.
Теперь недостаточно сказать:
«Причина — высокая нагрузка».
Высокая нагрузка одновременно является и причиной, и следствием.
Это цикл.
В таких системах организация может долго пытаться найти первую точку возникновения проблемы.
Но для управления важнее другое:
где можно разорвать цикл сейчас?
Архитектура причин не требует найти одну абсолютную первопричину
Термин «корневая причина» полезен.
Но иногда он создаёт ложное ожидание.
Будто где-то в глубине обязательно существует одна последняя причина.
Мы найдём её.
Исправим.
Всё станет хорошо.
В сложной организации это далеко не всегда так.
Например, низкая скорость решений может поддерживаться одновременно:
централизацией;
недоверием;
недостатком данных;
размытыми полномочиями;
высокой стоимостью ошибки;
культурой наказания;
сложной структурой согласований.
Какой элемент является «настоящим»?
Возможно, никакой по отдельности.
Именно их сочетание создаёт устойчивое состояние.
Системный анализ поэтому иногда ищет не корень, а структуру взаимного усиления.
Слабая причинная схема всегда заканчивается виновником
Если любой анализ в конечном счёте приводит к выводу:
«Люди недостаточно ответственные»,
стоит насторожиться.
Не потому, что ответственность людей никогда не бывает проблемой.
Бывает.
Но персональное объяснение часто является самым быстрым способом завершить сложный анализ.
Проект задержался — слабый PM.
Команда не проявляет инициативу — слабый руководитель.
Продажи падают — слабые продавцы.
Процесс не работает — сотрудники не соблюдают правила.
Это удобные объяснения.
Они дают понятный объект воздействия.
Но сильный анализ дополнительно спрашивает:
какие условия сделали такое поведение устойчивым или возможным?
Если ошибся конкретный человек — что не сработало в системе защиты?
Если человек не обладал компетенцией — почему это не было обнаружено раньше?
Если команда регулярно нарушает процесс — почему нарушение рациональнее соблюдения?
Так персональная ответственность сохраняется, но не заменяет системное объяснение.
Причинная архитектура должна включать управленческие решения
Иногда схемы процессов выглядят так, будто организация работает сама.
Поступил запрос.
Прошёл этап.
Возникла задержка.
Появился результат.
Но значительная часть системы создаётся решениями руководителей.
Кто получил ресурс?
Какой проект стал приоритетным?
Какой KPI установлен?
Кому дали полномочия?
Какой риск считается допустимым?
Что решили не делать?
Где допустили исключение?
Поэтому в причинной карте должны присутствовать не только процессы и люди.
Но и решения, которые сформировали текущую систему.
Иначе анализ превращается в описание операционной поверхности без архитектуры управления.
Нужно искать место, где система меняет своё поведение
Допустим, поток работы движется относительно стабильно.
Но после определённого этапа начинает образовываться очередь.
Именно здесь особенно полезно остановиться.
Почему?
Что изменяется в этой точке?
Возникает необходимость согласования?
Добавляется другой приоритет?
Используется дефицитный ресурс?
Меняется владелец?
Теряется информация?
Повышается стоимость ошибки?
Такие переходные точки часто содержат больше информации, чем анализ среднего времени процесса целиком.
Архитектура причин помогает отделить важное от просто заметного
Громкая проблема не обязательно является наиболее значимой.
Один крупный конфликт руководителей привлекает внимание всей компании.
Но реальное ограничение может находиться в незаметном процессе, который ежедневно задерживает сотни небольших решений.
Одна большая ошибка вызывает расследование.
Но тысячи маленьких повторных операций создают больший финансовый эффект.
Проблемные зоны, которые легко обсуждать, часто получают непропорционально много внимания.
Причинная архитектура заставляет смотреть не на эмоциональную яркость проблемы, а на её место в системе.
Нужно оценивать не только последствия, но и охват причины
Допустим, организация обнаружила неясные роли в одном проекте.
Это локальная проблема.
Но если похожая неопределённость существует во всех кросс-функциональных инициативах, причина имеет системный охват.
То же самое с:
приоритетами;
правами решений;
ресурсными конфликтами;
данными;
согласованиями;
KPI.
Чем больше разных симптомов способен объяснить один механизм, тем выше его потенциальная значимость.
Это хороший критерий при выборе точки воздействия.
Сильная причинная гипотеза должна что-то предсказывать
Представим предположение:
«Проекты задерживаются из-за портфельной перегрузки».
Если гипотеза верна, мы должны увидеть дополнительные признаки.
Критические специалисты участвуют одновременно в большом количестве инициатив.
Очереди концентрируются вокруг одних и тех же ресурсов.
Новые проекты ухудшают прогноз уже запущенных.
Приоритеты постоянно конфликтуют.
Люди часто переключаются.
Сроки отдельных задач нестабильны.
Если ничего подобного нет, гипотезу нужно пересмотреть.
Хорошая причинная модель не только объясняет прошлое.
Она позволяет предположить, что ещё мы должны увидеть в системе.
Причинные схемы нужны не ради красивой визуализации
Можно нарисовать огромную карту.
Десятки стрелок.
Сотни элементов.
Это создаёт ощущение глубины.
Но если после схемы непонятно, какое решение стало яснее, аналитическая работа не завершена.
Архитектура причин должна помочь ответить на несколько управленческих вопросов.
Что является главным механизмом?
Что поддерживает его устойчивость?
Какой элемент сильнее всего влияет на систему?
Где воздействие может дать максимальный эффект?
Какие побочные последствия возникнут?
Что нужно измерить после изменения?
То есть задача причинной карты — не показать сложность.
А сделать сложность управляемой.
Точка воздействия часто находится не там, где самая большая проблема
Допустим, компания имеет большой объём просроченных задач.
Можно вложить ресурсы в разбор очереди.
Но если новые задачи продолжают поступать быстрее, чем система их завершает, очередь восстановится.
Более сильная точка воздействия может находиться на входе.
Ограничить количество запускаемой работы.
Изменить приоритизацию.
Защитить критический ресурс.
Убрать лишний этап.
Перераспределить полномочия.
Системное решение часто кажется косвенным.
Но именно оно меняет механизм, который создаёт симптом.
Иногда нужно вмешиваться не в причину, а в обратную связь
Допустим, сотрудникам опасно сообщать плохие новости.
Поэтому проблемы скрываются.
Руководство получает информацию поздно.
Решения принимаются в кризисе.
После кризиса контроль усиливается.
Люди ещё сильнее боятся поднимать проблемы.
Можно долго обсуждать культуру.
Но более практическое изменение может быть связано с реакцией руководства на раннюю эскалацию.
Если ранний сигнал начинает приводить к помощи, а не наказанию, меняется обратная связь.
Сотрудники начинают говорить раньше.
У руководства появляется больше времени на решение.
Количество кризисов уменьшается.
Доверие постепенно растёт.
Небольшое изменение в цикле способно перестроить поведение всей системы.
Архитектура причин особенно нужна при повторяющихся проблемах
Если один и тот же тип проблемы возникает снова, это важный сигнал.
Проекты каждый квартал конфликтуют за ресурс.
Новые сотрудники регулярно плохо проходят адаптацию.
Решения постоянно зависают на одном уровне.
Команды повторяют одни и те же ошибки.
Клиенты системно сталкиваются с одним типом задержки.
В такой ситуации очередное оперативное исправление уже недостаточно.
Нужно спрашивать:
какая структура делает повторение проблемы предсказуемым?
Это и есть момент перехода от управления событиями к управлению системой.
Нужно учитывать и вторичные эффекты решений
Представим решение:
увеличить контроль, чтобы снизить количество ошибок.
Первичный эффект может быть положительным.
Ошибок действительно становится меньше.
Но дополнительный контроль увеличивает время решения.
Руководители перегружаются.
Сотрудники реже действуют самостоятельно.
Через некоторое время скорость падает.
Количество эскалаций растёт.
Теперь возникает новая проблема.
Если анализ учитывал только прямое влияние:
контроль → меньше ошибок,
решение выглядело идеально.
Если добавить вторичные эффекты, картина становится сложнее.
Архитектура причин должна включать не только то, что мы хотим изменить.
Но и то, как сама система ответит на наше вмешательство.
Самые дорогие проблемы часто находятся в архитектуре управления
Не в навыках сотрудников.
Не в конкретной инструкции.
Не в одном слабом руководителе.
А в том, как организация распределяет:
цели;
ресурсы;
приоритеты;
полномочия;
ответственность;
информацию;
риски.
Если эти элементы противоречат друг другу, операционный уровень будет постоянно производить проблемы.
Можно бесконечно исправлять их локально.
Но пока архитектура остаётся прежней, система продолжит воспроизводить похожие результаты.
Именно поэтому управление портфелем, приоритизация, прозрачность зависимостей, владельцы результата и управленческие контуры становятся не административным дополнением, а частью способности организации исполнять стратегию.
Переход от списка проблем меняет саму роль руководителя
Когда руководитель работает со списком, его задача выглядит так:
устранить как можно больше пунктов.
Когда он работает с архитектурой причин, задача меняется:
найти ограниченное количество механизмов, которые создают значительную часть наблюдаемых проблем.
Это другое качество управления.
Не быстрее тушить пожары.
А уменьшать способность системы их создавать.
Не запускать больше корректирующих инициатив.
А искать, почему они снова требуются.
Не бороться со всеми отклонениями одинаково.
А понимать, какие из них являются следствием одной структуры.
Иногда после системного анализа список проблем становится короче
И это хороший признак.
В начале обсуждения было:
восемь проблем.
После анализа выяснилось:
три являются симптомами перегрузки;
две — следствиями неясных полномочий;
ещё две возникают из-за противоречащих KPI;
одна действительно локальна.
Теперь вместо восьми независимых проектов появляется несколько системных направлений.
Организация перестаёт распылять внимание.
И начинает работать с механизмами.
Именно в этот момент анализ начинает экономить управленческую энергию.
Правильная архитектура причин не утверждает, что всё связано со всем
Это тоже крайность.
В сложной системе действительно много взаимосвязей.
Но если соединить стрелкой каждый элемент с каждым, схема потеряет практический смысл.
Нужна дисциплина.
Какая связь подтверждается?
Какая является гипотезой?
Насколько она значима?
Есть ли задержка?
Какова сила влияния?
Что изменится, если элемент убрать?
Системное мышление не означает усложнение ради сложности.
Наоборот.
Его задача — найти более простую модель, которая достаточно хорошо объясняет наблюдаемую реальность.
Управление начинается с отказа принимать список проблем за саму реальность
Список полезен.
Он помогает зафиксировать симптомы.
Показать масштаб.
Разделить наблюдения.
Но это только начало.
Если пять показателей ухудшаются одновременно, не обязательно запускать пять инициатив.
Если одна проблема повторяется годами, не обязательно ещё раз усиливать старое решение.
Если разные функции жалуются на разное, возможно, они просто смотрят на разные части одного механизма.
Сильный руководитель поэтому пытается увидеть за отдельными событиями структуру.
Что здесь является причиной?
Что следствием?
Что усиливает само себя?
Где существуют задержки?
Что поддерживает текущий режим?
Как связаны разные функции?
Какие решения сделали такое поведение рациональным?
Что является ограничением?
И где находится точка, изменение которой способно перестроить несколько результатов одновременно?
Список проблем отвечает на вопрос: «Что у нас не работает?»
Архитектура причин отвечает на значительно более важный:
«Почему наша система снова и снова производит именно такие проблемы?»
И именно с этого вопроса начинается переход от постоянного исправления последствий к настоящему управлению системой.
Данный материал носит исключительно ознакомительный и дискуссионный характер и отражает личное мнение автора.
