Антипаттерны в цепочке поставок

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

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

Плохое руководство

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

RFQ из ада

Есть много областей, где RFQ (запросы на котировки) имеют смысл. К сожалению, программное обеспечение не относится к ним. Написание спецификации программного обеспечения гораздо сложнее, чем написание самого программного обеспечения. Задача пугающая. Когда начинается процесс RFQ, компании ухудшают ситуацию, привлекая консультантов, чтобы еще больше усложнить то, что уже является излишне сложной спецификацией. RFQ подавляет большую часть мышления по решению проблем, потому что процесс RFQ предполагает, что клиент уже знает все детали желаемого решения, в то время как “проблема” по своей сути в значительной степени остается нерешенной на момент написания RFQ. Более того, на практике RFQ способствует антагонистическому процессу выбора поставщика: хорошие поставщики уходят, а плохие остаются. Наконец, программное обеспечение - это быстроразвивающаяся отрасль, и к тому времени, когда ваша компания закончит процесс RFQ, ваш конкурент уже выпустит свое решение.

Хрупкий POC

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

Отказ от неопределенности

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

Доверие стажеру

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

Смерть от планирования

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

Отделение прогнозирования от оптимизации

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

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

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

Инициативы, основанные на модных словах

Вокруг 2010 года в розничной торговле было модно выяснить, как использовать прогнозы погоды для уточнения прогнозов спроса. В 2012 году модно было учитывать данные социальных сетей при прогнозировании спроса. В 2014 году господствовало понятие “большие данные”, которое затем было заменено машинным обучением в 2016 году. Каждый год приносит свою новую волну модных слов. Хотя повторное рассмотрение старой проблемы с новой перспективой обычно не причиняет много вреда, на самом деле наоборот, потеря основных проблем является практически уверенностью в опасности любой уже предпринятой инициативы. Если что-то кажется слишком хорошим, чтобы быть правдой, скорее всего, это так и есть. Улучшение цепочки поставок требует много усилий. Убедитесь, что любая новинка, которую вы хотите внести, действительно фокусируется на основных проблемах, с которыми сталкивается ваша цепочка поставок.

Плохая реализация ИТ

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

Остерегайтесь защитных механизмов ИТ

Поскольку команды ИТ могли почувствовать себя козлом отпущения не раз в прошлом, когда некоторые проекты компании потерпели неудачу, они могли разработать определенные “защитные механизмы”. Один из самых распространенных защитных механизмов состоит в требовании подробных письменных спецификаций для каждой новой инициативы. Однако спецификация программного решения обычно оказывается более сложной, чем сама реализация программного решения. Следовательно, это означает замену сложной проблемы еще более сложной проблемой. Другие защитные механизмы состоят в установлении жестких требований, таких как: программное обеспечение должно находиться на месте, программное обеспечение должно быть совместимо с XYZ, программное обеспечение должно иметь определенные функции безопасности и так далее. Хорошее программное обеспечение пишется годами. Как только длинный список требований записан, обычно остаются только два типа поставщиков программного обеспечения: те, которые несовместимы с вашими требованиями, и те, которые лгут о совместимости с вашими требованиями.

Недооценка усилий по работе с данными

Хотя это может показаться парадоксальным, инициативы в сфере цепочки поставок также могут потерпеть неудачу из-за того, что ИТ слишком вовлечены в разработку решения и берут на себя подготовку данных. Действительно, поскольку ИТ чрезвычайно сложны и могут включать в себя достаточно талантливых людей, может также случиться, что некоторые команды ИТ начинают считать, что они лучше знают бизнес, чем остальная часть компании. Основным нежелательным последствием такой логики является постоянное недооценка трудностей, связанных с работой с данными компании. Обработка данных в значимом смысле не сводится к перемещению мегабайт данных туда и обратно. Это скорее о тонком понимании того, как эти данные отражают процессы и рабочие процессы компании. Это также понимание тонких изгибов, предубеждений и ограничений данных, так как они происходят в системах компании в любое время. Перехватывание командами ИТ подготовки данных - надежный способ столкнуться с неожиданными задержками, поскольку они постепенно осознают, насколько недостаточно глубоко было представлено их первоначальное видение. Учитывая все это, разумным вариантом является делегирование этой роли заранее кому-то вне отдела ИТ.

Искушение расширяемой платформы

Когда речь идет о корпоративном программном обеспечении, есть одна вещь, в которой поставщики совершенствуются: искусство быть “расширяемой” платформой, которая поставляется с множеством модулей, которые, как оказывается, представляют множество возможностей для дополнительных продаж. Однако платформы плохо взаимодействуют друг с другом, и функциональные перекрытия, то есть две платформы, которые внутренне конкурируют за одну и ту же функцию в вашей компании, появляются очень скоро. Два перекрывающихся платформы - это кошмар для любой компании, и обычно приводит к механизмам синхронизации, которые оказываются сложными для настройки и еще сложнее для поддержки. Таким образом, хотя соблазнительно выбрать всеобъемлющее решение, разумный вариант практически всегда заключается в выборе узкоспециализированных приложений, которые делают одну вещь и делают ее хорошо. Управление десятками узкоспециализированных приложений просто, в то время как управление двумя большими платформами - с одинаково большими функциональными перекрытиями - является адским.

Ненадежные извлечения данных

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

Плохие числовые рецепты

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

Анализ ABC

Подход ABC к инвентаризации был разработан в то время, когда компьютеры не были вариантом для управления цепочкой поставок. Основное преимущество анализа ABC заключается в том, что он настолько прост, что может быть выполнен вручную. Однако, учитывая ошеломляющую вычислительную мощность современных компьютеров, использование анализа ABC уже не имеет смысла. Нет никаких преимуществ в разделении тысяч SKU на 3 или 4 произвольных класса. Между самым продаваемым товаром и очень длинным хвостом существует полный континуум. Логика, оптимизирующая цепочку поставок, должна охватывать этот континуум, а не отрицать его существование. На практике мы также наблюдаем, что негативные эффекты анализа ABC усугубляются изменениями на рынке, которые приводят к нестабильности классов, с товарами, которые постоянно меняют свой класс со временем.

Резервный запас

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

Ручные корректировки прогноза

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

Оповещения и мониторинг плохих прогнозов

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

“Залатывание” исторических данных

Когда в исторических данных обнаруживаются смещения, такие как нехватка товара или акции, искушение исправить эти смещения путем изменения исторических данных, чтобы данные лучше отражали то, как бы выглядела история без смещения. Мы называем этот процесс “залатывание” исторических данных. Основная идея залатывания заключается в том, что все прогнозные модели разработаны как варианты скользящей средней. Если у вас есть только скользящие средние, то, действительно, исторические данные должны быть скорректированы, чтобы учесть эти скользящие средние. Однако залатывание не является решением. На самом деле, решение заключается в расширении горизонта и поиске лучших прогнозных моделей, которые не являются такими неисправными, как скользящая средняя. Лучшие статистические модели должны использоваться для успешной работы с “обогащенными” историческими данными, где сами смещения рассматриваются как входные данные. Хотя такие статистические модели могли быть недоступны десятилетия назад, это определенно уже не так.

Время выполнения второго класса

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

Псевдонаука

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

Фантастические бизнес-кейсы

Решения в области цепочек поставок, конечно, не являются единственной областью корпоративного программного обеспечения, где поставщики делают смелые заявления, но, как гласит старая поговорка: если что-то кажется слишком хорошим, чтобы быть правдой, вероятно, это так и есть. Мы сами наблюдали, что практически каждый январь на торговой выставке NRF в Нью-Йорке, одной из крупнейших розничных выставок в мире, которая работает уже более столетия. Мы часто замечаем очень крупного поставщика, который смело заявляет, что уровень запасов теперь можно уменьшить вдвое с помощью их нового решения. Если бы только 1/10 этих заявлений было правдой, отрасль уже десять лет назад достигла бы почти идеального уровня запасов. Существует так много способов манипулировать числами бизнес-кейса, что большинство поставщиков даже не лгут на самом деле. Самый распространенный случай - это то, что компания, рекламируемая как “пример успеха” для решения, изначально имела чрезвычайно дисфункциональную цепочку поставок, и поэтому было возможно получить также и чрезвычайно большие показатели улучшения, когда через год все вернулось к нормальному состоянию.

Доверьте прогнозирование команде по продажам

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

Проверенные решения

Поиск проверенного решения, которое смогло доставить ощутимые преимущества для компании, очень похожей на вашу, может показаться очень рациональной перспективой. С анекдотической точки зрения, именно это сделала Nokia и бесчисленное количество других компаний, пока они не исчезли. Большинство крупных компаний не действуют так быстро, когда дело доходит до выбора сложного решения. Процесс выбора поставщика может занять до 1 года. Затем достижение рабочей скорости с выбранным решением может занять еще один год. Мониторинг и получение доверия к результатам могут занять еще 1 или 2 года, особенно для тех цепочек поставок, где не все решения являются устойчивыми, и где цепочка поставок может быстро вернуться к предыдущему уровню производительности, как только поставщик больше не будет постоянно присутствовать на месте, чтобы настраивать решение. После этого может потребоваться еще 1 год, чтобы поставщик решения в конечном итоге достиг вашей компании с этим трудно достигнутым доказательством. Фатальный недостаток в этой линии мысли заключается в том, что ваша компания может позволить себе прийти на вечеринку с опозданием в 5 лет. Когда речь идет о программном обеспечении, 5 лет - это очень долгое время. Большинство программного обеспечения фактически считается устаревшим к 5-му году; почему ваше решение для цепочки поставок должно быть иным?

Плохие метрики, плохие показатели

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