Система-локатор или WMS?

Все системы, которые используются сегодня на складах, условно можно разделить на три класса: учетные, системы-локаторы (IMS или ILS) и системы управления складом (WMS).

Учет и контроль

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

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

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

Отслеживать, что происходит с товаром на складе, можно по статусу сформированных в учетной системе документов на выполнение операций. Документ может иметь, например, такие статусы:

• запланирован – документ создан, работы с ним не начаты, и автор (например, менеджер по продажам) может вносить любые изменения;
• выполняется – на складе начата работа по выполнению задания, и теперь корректировки может вносить только оператор склада. Но подтвердить получение товара по документу с этим статусом грузополучатель еще не может;
• завершен – задание выполнено, оператор склада грузоотправителя теряет право вносить изменения в документ (собственно, редактирование документа заблокировано всем пользователям), а оператор склада грузополучателя получает возможность подтверждения приема товара.

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

Конечно, к учетным системам склады так или иначе приспосабливаются, однако ряд проблем все равно остается. Таких, к примеру, как перепроведение документов задним числом, которое обычно делают не материально ответственные люди. Или как вопросы синхронизации при работе в распределенной базе – когда, допустим, старая версия документа «затирает» новую на очередной синхронизации данных. Немало неприятностей возникает и в связи с задвоенными номенклатурами, некорректными наименованиями товаров, неправильным построением дерева товарных категорий и пр. Результат всегда один и тот же – потеря информации о товарных остатках и возникновение либо недостачи, или необъяснимого излишка товаров.

Интересно бывает увидеть на остатках, допустим, минус 10 штук, по­лу­ча­ется, что если сейчас на склад придет 10 единиц товара, мы их положим в ячейку, и они ан­ни­ги­ли­ру­ются? Тог­да в графе «остатки» будет ноль, и все станет нормально. И как бы мы ни пытались из­бе­жать по­добных проблем, «обвешивая» систему новыми приложениями, полностью устранить их прак­ти­чески невозможно – корень их скрыт в самом ядре программы, которая оперирует исключительно артикулами и их количеством. Образно говоря, сколько «Жигуль» не тюнингуй, он все равно будет «Жигулем». Даже если туда поставить закись азота, разные брызговики, дополнительные кнопки, сигнализацию и т.д., быстрее он не поедет и больше людей не перевезет.

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

Семинар на тему "Складская логистика торгового предприятия" будет проходить в Киеве 21-22 ноября с участием Виктора Леонидовича Барановского.

 Системы-локаторы

Несколько больше возможностей дают так называемые системы-локаторы (встречаются два названия: IMS – Information Management System (система управления информацией) и ILS – Information Location Sycten (система информирования о расположении)). В их основе – все та же бухгалтерская модель, но к ней уже добавлена ячеистая структура склада (код аналитического учета – адрес ячейки хранения) и доработан пользовательский интерфейс.

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

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

– IMS позволяет также наложить на ячейки ограничения по размерам и весу, и если когда-нибудь произойдет чудо и 100% товаров будут правильно взвешены и обмеряны, система сможет выдавать более качественные рекомендации, какой товар куда поставить. Но полная точная информация по всему ассортименту наскладескорее исключение, чем правило. 80% корректной информации по весогабариту – реальность,а дальше против нас работает закон Парето. По тем же причинам «сбоит» функция пополнения ячеек, если она использует весогабаритные характеристики.

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

Когда автоматизированная система работает с грузовыми единицами, она может объединить некоторый товарный запас, какое-то количество разных артикулов (сочетание артикул/количество) в одну складскую единицу хранения и дальше обрабатывать ее как одно целое, т.е. выдавать исполнителю команду на действия не с товаром, а с грузовым местом. В IMS этого как минимум пока нет – «дополнительная складская обработка», например стикеровка или комплектация наборов или учет товаров, состоящих из нескольких единиц, ей не по зубам. К примеру, лучше не пытаться разработать алгоритм на перемещение кровати, состоящей из трех предметов (ножки в одном ящике, рама в другом, матрас в третьем), поскольку это разные артикулы, размещенные в разных ячейках. Это затрудняет возможность полноценного контроля перемещения товара.

Впрочем,эта проблема частично решается за счет развитой многоуровневой и много­ва­ри­ант­ной структуры упаковки, которая характерна для систем-локаторов. Скажем, ту же кровать можно собрать в один «большой ящик» и присвоить ему новый артикул – простая «комплектация набора». Еще один инструмент - использование понятия «партия». Когда склад принял 100 еди­ниц товара, из которых было сфор­мировано 10 поддонов, каж­дый из них может рассматриваться как мик­ро­партия. И такой микропартией можно оперировать в системе-локаторе до тех пор, по­ка ее не надо снова разделить на базовые единицы, т.е. штуки.

 Курс на сближение

Граница между локаторами и WMS, по мнению эксперта, постепенно стирается. WMS по тре­бо­ва­нию рынка становятся проще и дешевле за счет отказа от мало востребованных функций и формирования сравнительно недорогих «отраслевых решений» , а локаторы, наоборот, расширяют функционал и (к сожалению) за счет этого растут в цене. Однако принципиальная разница между ними заключается в том, что в локаторах нет такого важного шага, как автоматическая активизация заданий – их ставит исключительно оператор. Именно он должен дать команду на отбор и проверить, что она выполнена, затем дать команду на контроль и проверить выполнение и т.д.

– Фактически получается, что в систему-локатор встроен дополнительный элемент в виде оператора, который заполняет дыры в бизнес-процессах путем нажатия разных кнопок. Это необходимо именно потому, что локаторы работают не с грузовыми единицами, (поддонами или коробками), а с товарными запасами: артикул – количество.. И если ориентироваться по этому признаку, приходится признать, что некоторые так называемые WMS на самом деле таковыми не являются. В т.ч. программные продукты для склада, разработанные на базе 1С, скорее можно отнести к локаторам. Их функционал значительно расширен, но «выросли» они из учетной системы и опираются на ее логику.

Тем не менее, в локаторах уже сегодня очень удобно задавать топо­ло­гию склада – практически все системы, которые переросли класс «учет­ная», позволяют разделить склад по ячейкам хранения, сгруп­пи­ро­вать эти ячейки по определенным признакам и создать некую кон­фи­гу­ра­цию каждой зоны склада с определенным функционалом. А затем можно ограничить доступ человека к определенной зоне (массиву ячеек) – и это уже будет некая система контроля доступа, которую локатор своим путем, но все же реализует. Он создает привязку - разрешение: данную категорию товара хранить только в данной группе ячеек, и если сотрудник получает запрет на работу с данной категорией товара, ему автоматически блокируется доступ на соответствующую территорию склада и к соответствующим документам.

Можно в таких системах и логическую структуру склада построить. Это можно сделать с помощью всего двух параметров: категоризации товаров и классификатора АВС внутри товарной категории. Большинству компаний этого вполне достаточно, если при разделении на категории учитывать формат, условия хранения и совместимость товаров, а внутри каждой категории выделить «горячую» и «холодную» зоны. Прописав разрешение или запрет размещать товар в определенной зоне, можно двигаться дальше и ставить автоматизированную (путем нажатия кнопки) выдачу исполнителям заданий на получение товара, его размещение, движение между ячейками, проведение циклических инвентаризаций, отбор и отгрузку со склада.

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

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

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

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

Есть очень удобный блок учета по разным единицам измерения с возможностью переупаковки одной единицы в другую,В WMS, к примеру, довольно сложно получить 10 т сахара, расфасовать его в мешки с переменным весом, а затем отгрузить часть товара в мешках, а часть – в килограммах. Учетная система с такими вещами справляется гораздо легче, потому что в исходном бухгалтерском ядре этот блок был когда-то доведен до совершенства. Хотя – есть WMS-системы со встроенным «справочником тары», при его корректном заполнении и правильном использовании – появляется возможность оперировать с разными стандартами укладки штук в ящик

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

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

Разумная достаточность

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

Приемка товара:

• планирование приемки;
• контроль качества (как минимум, кондиция/некондиция, но параметры можно дополнить);
• переупаковка (изменение размерности единицы хранения);
• маркировка – под вопросом, но теоретически возможно, если «поиграть» со статусами документов;
• формирование всей приемной документации.

Размещение – по определенным критериям и правилам, ориентируясь на ту систему разрешений и запретов, которой в системе связаны товар и ячеистая структура склада:

• планирование;
• автоматический поиск ячеек для размещения.

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

Комплектация и отгрузка:

• планирование отгрузки товара, партионная отгрузка – легко решается в системе, но довольно сложно фактически;
• оптимизация места хранения – сценарий максимального заполнения ячейки в зоне резервного хранения («сращивание» паллет);
• оптимизация операций – как минимум, можно отсортировать ячейки по каким-то признакам и сформировать более-менее корректные маршруты движения для отборщиков;
• планирование комплектации – опять-таки, только по одному сценарию, чтобы обрабатывать разные товары по разным технологиям, нужны серьезные доработки;
• пополнение зоны комплектации – алгоритмы максимизации заполнения ячейки, FIFO, LIFO, минимакс (но множественность алгоритмов тоже под вопросом).

Сценарий разделения заказа между несколькими отборщиками также доступен в локаторе, но подходить к этому вопросу нужно очень внимательно,привязка логики к артикулу или партии может сыграть здесь очень злую шутку.Был случай, когда программист, которому недостаточно четко сформулировали задачу, сделал разделение строк в документе следующим образом: первая строка – первому отборщику, вторая – второму, третья – третьему. Т.е. заказы делились не по адресам ячеек, а по артикулам и партиям, и в результате три отборщика проходили один и тот же маршрут. И обнаружилось это практически случайно, когда два отборщика столкнулись у одной ячейки (им нужен был один артикул, но разные партии) и догадались сообщить о проблеме. Причем на вопрос: «То есть вы отбирали один товар из ячейкивдвоем?» они ответили, что третий только что отошел.

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

Еще одна вещь, которая локатору не по силам – биллинг. Причина, опять-таки, в исходной учетной модели. Локатор работает с артикулами и количествами, и четкое фиксирование времени начала и конца складских операций и характеристик партий, которые при этом обрабатывались, для него – невозможная задача. Кроме того, в нем нет ограничений, сколько заданий можно одновременно «повесить» на одного исполнителя – хоть все сразу.

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

Самое неприятное – что эти данные легко можно подтасовать, поскольку с ядром системы они никак не коррелируют. Если в WMS можно задать условие, что из машины не может быть выгружено больше 32 паллет (ну хорошо, максимум 64), то в локаторе, где эта опция служит только для сбора информации, можно записать и 320 поддонов. Или указать, что весь товар пришел россыпью, а не на паллетах, потому что так выгоднее для зарплаты.

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

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

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

Коробочные решения

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

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

Еще в начале 2000-х, когда логистика в Украине была в зачаточном состоянии, коробочные решения были просто находкой: не умея практически ничего, получить готовый бизнес-процесс, который гарантированно работает – это просто супер. Однако сейчас ситуация в корне изменилась. За последние лет 6 этап унификации и стандартизации бизнес-процессов многие компании уже пережили. Сегодня же, чтобы выжить на рынке, каждая из них ищет свои конкурентные преимущества, и стандартные решения в такой ситуации становятся дополнительным ограничением. А если начать дорабатывать «коробку», она вполне может рассыпаться.

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

К преимуществам коробочных решений однозначно относятся невысокая стоимость и короткие сроки внедрения, а также хорошая hot-line поддержка с большим количеством операторов coll-центра, которые, по крайней мере, ответят на звонок 24 часа в сутки 7 дней в неделю. Разумно достаточный функционал и бюджетные «ноу-хау», которые могут пригодиться складу, в такие продукты уже заложены, а в рамках сервисного обслуживания клиент будет получать также регулярные обновления – дополнительные опции, разработанные в ходе новых внедрений. Поставщики идут на это, потому что им выгоднее отдать эти опции почти бесплатно (плата за сопровождение покрывает обычно и обновления программы), поддерживая тем самым лояльность клиентов, чем держать несколько вариантов «коробки».

А вот простота «коробки», по мнению специалистов, не всегда является преимуществом – она может спровоцировать доработки, которые система «не потянет».

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

– Дело в том, что иногда людям неудобно признаваться, что их обманули, что они потратили деньги и не получили результата. И некоторые предпочитают делать хорошую мину при плохой игре: «Да-да, все хорошо, все работает! Приехать посмотреть? Да нет, у нас сейчас реконструкция, мы никого не принимаем!» Но нужно действительно ехать и смотреть – только так вы можете убедиться, что в других компаниях продукт успешно работает. Устные комментарии, что «все нормально», или просто весомый список из 200 «компаний - наших клиентов» – еще не повод для принятия решения.

Кстати, поставщики коробочных решений активно пользуются тем, что люди не любят признавать свои ошибки. Они требуют обычно минимум 70–80% предоплаты, и это становится для них своего рода гарантией, что клиент не остановит проект даже в случае явной неудачи. Не каждый имеет мужество признать, что деньги потрачены впустую, многие предпочитают довести проект до конца, доплатить оставшиеся 20–30% и потом некоторое время притворяться, что все нормально.

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

• покрытие требуемого функционала должно быть не менее 70%, причем доработки могут касаться только каких-то второстепенных, сервисных функций и ни в коем случае не должны затрагивать ядро;
• на рынке продукт должен быть представлен не менее 2 лет, количество успешных внедрений – не менее 10. Если купить новую, пусть даже более продвинутую версию, велики шансы стать тем самым «подопытным кроликом», на котором поставщик будет «обкатывать» систему;
• наличие авторизированных представительств в регионе – лучше всего, чтобы сервисный инженер был в пределах 1-дневной доступности. Удаленный доступ положение не спасает, поскольку пользователи системы обычно не имеют достаточной квалификации, чтобы самостоятельно диагностировать возникающие проблемы;
• продукт должен быть масштабируемый – так, чтобы в течение какого-то времени он поспевал за ростом бизнеса, открытием новых филиалов и пр.;
• большим плюсом является возможность опционной настройки логики продукта – например, чтобы в сезон и в несезон, когда меняются ассортимент и объемы складской обработки, можно было задействовать разные алгоритмы;
• и необходимое требование – наличие готовых интерфейсов взаимодействия с другими программными продуктами, чтобы не возникало проблем с обменом данными.

 Резюме

– Локаторы за последнее время получили ряд усовершенствований. По функционалу они все больше приближаются в WMS, а иногда «осваивают» даже те функции, которые не во всех WMS реализованы. Так что вполне можно надеяться, что уже в ближайшем будущем два класса систем фактически сольются в один, и потребители будут оценивать их не по исходной модели, которая «зашита» в ядре, а по полноте функционала и степени автоматизации, которую тот или иной продукт в состоянии обеспечить.

Детальную программу семинара "Складская логистика торгового предприятия" можно посмотреть на сайте. По вопросам регистрации звоните: [відкрити контакти](044)221-38-10, [відкрити контакти](067)680-15-70