Голосовой ввод обычно никому не нужен. В реалиях производства дешевле поставить человека, который будет ходить туда-сюда или говорить коллеге по рации и вбивать что-то в терминал, чем настраивать распознавание речи. Собственно, так мы и решали вопрос голосового ввода довольно долго.
Человек с рацией неизменно побеждал по экономическому эффекту.
Но у нас есть станок, выдающий муфту за муфтой для трубопроводов. Муфты сверхответственные, под давление 150 атмосфер, поэтому около станка стоит оператор и наблюдает, что же оттуда выходит.
Он внимательно смотрит на 19 муфт, а двадцатую берёт и начинает измерять разными точными инструментами. Делает он от 20 до 27 замеров, а результаты записывает на бумажке.
Затем останавливает станок, идёт к терминалу и вводит в систему данные замеров.
Возвращается и снова смотрит на муфты.
Можно было поставить второго человека — у терминала, но теперь мир поменялся: дефицит рабочих специальностей, вот это всё. Квалифицированные рабочие нужны в других местах.
Понадобилось добраться с автоматизацией до этого самого станка.
Первым сюрпризом стало то, что нужно распознаватьнеформальную лексику специализированную терминологию. Некоторые слова выражают одобрение догадки робота, а некоторые (обычно более короткие) означают команду «Немедленная отмена текущей операции».
Устройство-ассистент должно понимать специалиста цеха буквально с полуслова.
Сейчас я расскажу отличную историю, как мы всё это внедряли.
Вот схема участка. Как видите, терминалы находятся между станками. На типовую муфту нужно плюс-минус 26 параметров: номер МНС/номер партии, тип резьбы, наружный диаметр, отклонение высоты профиля, отклонение шага, конусность, диаметр расточки, диаметр резьбы, резьбовой калибр, заключение годности и т. п. Ввод их в терминал занимает примерно полторы минуты.
Поскольку изделие очень ответственное, тут и замеры, и несколько систем контроля.
Одна из основных задач оператора — осматривать муфты и визуально искать брак. Ну и тут же, как я уже говорил, он делает также замеры каждой 20-й высокоточными инструментами, а затем отправляет их в MES. Это позволяет понять, что реально производит станок и какие тренды есть в его режиме на этом конкретном материале. По сути, рабочий выступает контуром обратной связи для станка.
Контроль качества в ОТК находится дальше по цепочке. У ОТК и оператора — разные задачи: первому практически всегда выгодна максимальная выработка, он проверяет только геометрию изделия, а для ОТК важно не пропустить ни одной бракованной детали.
Можно сказать, что рабочий склонен к ложноположительным ошибкам, а ОТК — к ложноотрицательным. Нужны оба этих фильтра.
Это первый вопрос, который надо задать при автоматизации такого рабочего места. Причина всё та же — экономический эффект.
База устройства-ассистента стоит несколько миллионов рублей, и ещё по нескольку миллионов за каждую часть обвеса. И не факт, что для каких-то операций такой измерительный инструмент вообще существует.
Мы примерно прикидывали: нужно около 30–40 миллионов, чтобы просто оснастить автоматикой каждый станок. Ситуация сильно осложняется тем, что для этого нужно делать НИОКР, получать патенты на способы измерения и т. п., чтобы укладываться в строгие госстандарты. То есть устройство, которое даёт обратную связь станку, стоит ещё примерно полугода разработки инженерами, довольно сложной работы с документами и требует сложного внедрения. Ну и к тому же будет нуждаться в обслуживании.
Бегло прикинув эти цифры, мы поняли, что копать глубже нет никакого смысла.
В общем, живые человеки экономически в разы выгоднее и в разы понятнее производству.
Человеки надёжны. Человеки могут научиться мерить новую муфту за секунды, надо просто дать им покрутить её в руках. Человеки хорошо резервированы: достаточно четверых с учётом смен, отпусков и болезней.
Но они же и создают узкое место, потому что каждый раз, когда идут к терминалу, станок не работает. Иначе из него пойдут муфты, которые рабочий не отсмотрит вовремя.
То есть наша задача — уменьшить время простоя станка.
Второй логичный вопрос: а зачем мы канителимся с голосовым вводом, если каждому на рабочее место можно поставить терминал? Было два защищённых компьютера на четыре станка, стало четыре — по одному у каждого. В чём проблема?
Проблема в том, что на рабочем месте человек сидит в специальных перчатках, и вводить данные на компьютере всё равно не может. Зато может карандашом ставить отметки в бумаге.
Сначала ему нужно сделать все замеры, потом он уже снимает перчатки и начинает щёлкать по клавиатуре, щурясь на бумажку.
То есть фактическая экономия составила бы ровно время ходьбы от станка к терминалу. Да, она была бы, но это не очень значительный эффект.
Как я уже говорил, куда дешевле было поставить ещё одного члена профсоюза у терминалов, чтобы он вводил то, что ему передают с места событий. Это и быстрее, и нет остановки, потому что, пока оператор измеряет деталь, он видит, что выдаёт станок.
В этот момент мы поняли: человек на терминале — это и есть интерфейс голосового ввода.
Появились варианты задачи, где можно сделать по-человечески. Их можно тиражировать, и в них хорошо сходится экономика. Сходиться, кстати, она стала с появлением дефицита людей рабочих специальностей.
Первое, что мы делали, — считали экономику. Для этого надо было понять, как вообще может выглядеть рабочий процесс. Взяли салфетки, палки, гугловскую голосовую приблуду и пошли ставить эксперименты.
На терминале крутится фронтенд MES-системы, который по API общается со своим бэком и получает-отдаёт данные для конкретной базы, связанной с этим участком производства.
Мы использовали те же методы API, просто написав свою довольно простую обёртку.
Выглядела она как чат-бот, который задаёт вопросы оператору.
Сценарий такой: оператор жмякает на большую заметную кнопку перчаткой, робот спрашивает голосом:
— Какой диаметр?
Рабочий измеряет диаметр и говорит:
— 72!
Робот задаёт следующий вопрос:
— Какой тип резьбы?
Рабочий смотрит на муфту и сообщает тип резьбы.
В этом месте мы сломались первый раз, потому что рабочие знают такие слова, которых не знают стандартные словари распознавалок. Тем не менее с числами всё прошло хорошо, и стало принципиально понятно, что проект возможен.
Мы беспокоились, что в цехе шумно, но микрофон около оператора (петличка или устройство на столе перед ним) полностью решал проблему. Оставался только один тип шума — это когда одна муфта бьётся в другую. Случается это не так чтобы постоянно, но если это произойдёт в момент ответа, то распознаться может криво. Это решается!
Во время тестов сама гугловая тулза не знала, когда останавливать запись, не могла корректно разбирать концы фраз, поэтому пришлось останавливать её вручную — тоже кнопкой.
Посчитали проект, защитили его, пошли собирать прототип. Взяли спичкит от Яндекса. На рынке есть ещё несколько готовых решений, например, из подходящих нам точно был ещё Сбер. Что приятно, у обоих были и пакетные, и посекундные тарифы. То есть пока проект не стал промышленным, нам выгодно платить не за год, а по факту использованного времени распознавания.
Тут дальше надо сказать, что подключение поставщика облачных услуг — это отдельный вид танцев с бубном. Там изрядно бюрократии (нужно обосновать выбор, согласовать с безопасниками, заключить договор и прочее), а ещё надо решить и технические вопросы (описать и наладить сетевую связанность, настроить мониторинг, логи, разобраться с особенностями тарификации и биллинга). Это занимает от двух месяцев до полугода.
Выбор между Яндексом и Сбером был сделан в пользу Яндекса, т. к. весь путь подключения мы с ними уже прошли, есть канал связи до их ЦОДа — не через публичный Интернет. А это суперважно для защиты передаваемого голоса! Есть договор. Есть интеграция инфраструктур.
В общем, дальше, может быть, и сменим поставщика, если понадобится, но пока выбрали их.
Вторая важная особенность — они легко дообучают свой спичкит. Все те сложные слова и термины, которыми просто сыпали рабочие, мы аккуратно занесли в словарь.
Например, рабочий может сказать: «НКТН», «ОТТГ», «ОМК ПОЛАР», «МНС 5-1-1 муфты под фосфатное покрытие», «168 батресс группы прочности Д». Ну и ещё спичкит обижается на слово «соосность». Но нет, это не пожелание роботу и не оценка качества его работы.
Самого робота сделали на готовой платформе для чат-ботов. Просто нарисовали сценарий, и он по нему бегает. Добавили простой фронт на Vue, бэк для связи с API MES на Питоне. Пока всё очень и очень просто. Поставили в тестах на обычные телефоны. Рабочий жмякает кнопку, робот его опрашивает, в конце данные заносятся в MES.
Сначала хотели сделать навык для Алисы вместо всего этого, но там «из коробки» мало что подходит. Во-первых, оператор станка после дня тестов дома назвал жену Алисой, за что жестоко пострадал. Правда, он так называл всех встречных, кажется, но с женой — очень зря. Во-вторых, есть проблема «лакей-пугало» (это слово для вызова гугл-ассистента: «Окей, гугл»). Алиса «из коробки» ничего не сечёт в производстве, увы, никак.
Во-первых, устройства — те, которые телефоны или планшеты. Сначала мы искали промышленного класса в ударопрочном корпусе, но потом решили, что достаточно обычных планшетов.
Во-вторых, надо было прорабатывать варианты, как сотрудник мог бы, не снимая перчаток, стартануть диалог. Рабочие посоветовались и попросили специальную палку, чтобы тыкать ею в кнопку: так им удобнее, чем снимать перчатку. А если тачскрин будет неудобен, то можно будет использовать и просто карандаш с ластиком.
В-третьих, рабочие начали воспринимать робота как крайне тупое существо, которое всё же должно реагировать на команды. Пришлось добавлять ветки диалога на повторный ввод данных и понимать, что некоторые одинаковые слова в разных частях диалога значат разное.
— Диаметр?
— 71. #% твою мать! ?%#@r%(@, %#ка, то есть 72!
— Не разобрал, какой диаметр?
— Да 72, блин, 72!
— Диаметр 72, верно?
— Да.
Сразу скажу, что такие диалоги — редкость, и операторы станков — вежливые интеллигентные люди. Но при виде дефекта они могут быть очень взволнованы и требовать немедленной реакции на специальном заводском языке, преимущественно состоящем из коротких специальных контекстно зависимых терминов.
То есть, если робот не уверен, он должен повторить то, что разобрал за человеком, и попросить подтверждения.
В-четвёртых, нужна ещё одна защита на случай неверного распознавания. Например, если диаметр вдруг стал 74 мм при нормативе производства до 72,3 мм, то робот удивляется, останавливает оператора и спрашивает, уверен ли тот. То есть случайные неверные распознавания ещё контролируются тем, что робот ожидает, в каком довольно жёстком интервале они будут. Это ещё больше логики бэка и ещё одна связка с MES.
В-пятых, тот самый лязг соударяющихся муфт. Разработчики разных спичкитов говорили: они могут докрутить инструменты так, что некоторые эти частоты будут давиться, либо что можно переобучить с учётом этих звуков и перекрытий ими, и проблема решится. Похоже, что проблема действительно решится, но пока её особо и нет: лязг редко попадает на числа, а если он помешал, то робот переспрашивает.
В-шестых, оказалось, что операторы могут сказать роботу: «Стой, я там пять минут назад не то сказал». Тут уж его полномочия — всё: робот грустно сообщает, что если накосячил, — надо вставать, идти к терминалу и там всё исправлять, как обычно.
В-седьмых, мы хотим определение ключевого слова. «Эй, железяка!» — и дальше уже включается запись. Вот эта пусковая часть «Эй, железяка!» должна быть полностью на нашей стороне, потому что мы точно не хотим, чтобы какой-то сторонний софт постоянно слушал завод.
Понадобится простой ASR-движок для локального распознавания прямо в приложении.
В эксплуатацию ещё не сдавали, потому что вон сколько доработок! А мужики в цехе ждут, ведь им очень не нравится возиться с терминалом.
Через несколько коррекций сценария (он становится всё разветвлённее) мы выйдем на тестовую эксплуатацию. Думаю, что к концу ноября. Но уже сейчас понятно, что даже тот MVP, который есть сейчас, отлично решает нашу локальную задачу. Операторы уже не останавливают станок, весело препираются с роботом, если что-то не нравится — по старинке идут к терминалу. Теперь всё это надо сделать не на коленке, а с нормальной архитектурой, без костылей, правильно с точки зрения ИБ, задокументировать, настроить бекапы и резервирование на случай отказа и всё такое.
Удивительно то, что это задача, где голосовой ввод — не для того, чтобы он был, а потому, что оказался самым практичным и удобным вариантом. И это точно покажет реальный экономический эффект!
За помощь в подготовке поста большое спасибо Эдуарду Голубеву.
Человек с рацией неизменно побеждал по экономическому эффекту.
Но у нас есть станок, выдающий муфту за муфтой для трубопроводов. Муфты сверхответственные, под давление 150 атмосфер, поэтому около станка стоит оператор и наблюдает, что же оттуда выходит.
Он внимательно смотрит на 19 муфт, а двадцатую берёт и начинает измерять разными точными инструментами. Делает он от 20 до 27 замеров, а результаты записывает на бумажке.
Затем останавливает станок, идёт к терминалу и вводит в систему данные замеров.
Возвращается и снова смотрит на муфты.
Можно было поставить второго человека — у терминала, но теперь мир поменялся: дефицит рабочих специальностей, вот это всё. Квалифицированные рабочие нужны в других местах.
Понадобилось добраться с автоматизацией до этого самого станка.
Первым сюрпризом стало то, что нужно распознавать
Устройство-ассистент должно понимать специалиста цеха буквально с полуслова.
Сейчас я расскажу отличную историю, как мы всё это внедряли.
Вот схема участка. Как видите, терминалы находятся между станками. На типовую муфту нужно плюс-минус 26 параметров: номер МНС/номер партии, тип резьбы, наружный диаметр, отклонение высоты профиля, отклонение шага, конусность, диаметр расточки, диаметр резьбы, резьбовой калибр, заключение годности и т. п. Ввод их в терминал занимает примерно полторы минуты.
Зачем измеряется деталь
Поскольку изделие очень ответственное, тут и замеры, и несколько систем контроля.
Одна из основных задач оператора — осматривать муфты и визуально искать брак. Ну и тут же, как я уже говорил, он делает также замеры каждой 20-й высокоточными инструментами, а затем отправляет их в MES. Это позволяет понять, что реально производит станок и какие тренды есть в его режиме на этом конкретном материале. По сути, рабочий выступает контуром обратной связи для станка.
Контроль качества в ОТК находится дальше по цепочке. У ОТК и оператора — разные задачи: первому практически всегда выгодна максимальная выработка, он проверяет только геометрию изделия, а для ОТК важно не пропустить ни одной бракованной детали.
Можно сказать, что рабочий склонен к ложноположительным ошибкам, а ОТК — к ложноотрицательным. Нужны оба этих фильтра.
Почему деталь измеряет рабочий, а не автоматика?
Это первый вопрос, который надо задать при автоматизации такого рабочего места. Причина всё та же — экономический эффект.
База устройства-ассистента стоит несколько миллионов рублей, и ещё по нескольку миллионов за каждую часть обвеса. И не факт, что для каких-то операций такой измерительный инструмент вообще существует.
Мы примерно прикидывали: нужно около 30–40 миллионов, чтобы просто оснастить автоматикой каждый станок. Ситуация сильно осложняется тем, что для этого нужно делать НИОКР, получать патенты на способы измерения и т. п., чтобы укладываться в строгие госстандарты. То есть устройство, которое даёт обратную связь станку, стоит ещё примерно полугода разработки инженерами, довольно сложной работы с документами и требует сложного внедрения. Ну и к тому же будет нуждаться в обслуживании.
Бегло прикинув эти цифры, мы поняли, что копать глубже нет никакого смысла.
В общем, живые человеки экономически в разы выгоднее и в разы понятнее производству.
Человеки надёжны. Человеки могут научиться мерить новую муфту за секунды, надо просто дать им покрутить её в руках. Человеки хорошо резервированы: достаточно четверых с учётом смен, отпусков и болезней.
Но они же и создают узкое место, потому что каждый раз, когда идут к терминалу, станок не работает. Иначе из него пойдут муфты, которые рабочий не отсмотрит вовремя.
То есть наша задача — уменьшить время простоя станка.
Почему не поставили компьютер ближе?
Второй логичный вопрос: а зачем мы канителимся с голосовым вводом, если каждому на рабочее место можно поставить терминал? Было два защищённых компьютера на четыре станка, стало четыре — по одному у каждого. В чём проблема?
Проблема в том, что на рабочем месте человек сидит в специальных перчатках, и вводить данные на компьютере всё равно не может. Зато может карандашом ставить отметки в бумаге.
Сначала ему нужно сделать все замеры, потом он уже снимает перчатки и начинает щёлкать по клавиатуре, щурясь на бумажку.
То есть фактическая экономия составила бы ровно время ходьбы от станка к терминалу. Да, она была бы, но это не очень значительный эффект.
Как я уже говорил, куда дешевле было поставить ещё одного члена профсоюза у терминалов, чтобы он вводил то, что ему передают с места событий. Это и быстрее, и нет остановки, потому что, пока оператор измеряет деталь, он видит, что выдаёт станок.
В этот момент мы поняли: человек на терминале — это и есть интерфейс голосового ввода.
Появились варианты задачи, где можно сделать по-человечески. Их можно тиражировать, и в них хорошо сходится экономика. Сходиться, кстати, она стала с появлением дефицита людей рабочих специальностей.
Первые опыты
Первое, что мы делали, — считали экономику. Для этого надо было понять, как вообще может выглядеть рабочий процесс. Взяли салфетки, палки, гугловскую голосовую приблуду и пошли ставить эксперименты.
На терминале крутится фронтенд MES-системы, который по API общается со своим бэком и получает-отдаёт данные для конкретной базы, связанной с этим участком производства.
Мы использовали те же методы API, просто написав свою довольно простую обёртку.
Выглядела она как чат-бот, который задаёт вопросы оператору.
Сценарий такой: оператор жмякает на большую заметную кнопку перчаткой, робот спрашивает голосом:
— Какой диаметр?
Рабочий измеряет диаметр и говорит:
— 72!
Робот задаёт следующий вопрос:
— Какой тип резьбы?
Рабочий смотрит на муфту и сообщает тип резьбы.
В этом месте мы сломались первый раз, потому что рабочие знают такие слова, которых не знают стандартные словари распознавалок. Тем не менее с числами всё прошло хорошо, и стало принципиально понятно, что проект возможен.
Мы беспокоились, что в цехе шумно, но микрофон около оператора (петличка или устройство на столе перед ним) полностью решал проблему. Оставался только один тип шума — это когда одна муфта бьётся в другую. Случается это не так чтобы постоянно, но если это произойдёт в момент ответа, то распознаться может криво. Это решается!
Во время тестов сама гугловая тулза не знала, когда останавливать запись, не могла корректно разбирать концы фраз, поэтому пришлось останавливать её вручную — тоже кнопкой.
MVP
Посчитали проект, защитили его, пошли собирать прототип. Взяли спичкит от Яндекса. На рынке есть ещё несколько готовых решений, например, из подходящих нам точно был ещё Сбер. Что приятно, у обоих были и пакетные, и посекундные тарифы. То есть пока проект не стал промышленным, нам выгодно платить не за год, а по факту использованного времени распознавания.
Тут дальше надо сказать, что подключение поставщика облачных услуг — это отдельный вид танцев с бубном. Там изрядно бюрократии (нужно обосновать выбор, согласовать с безопасниками, заключить договор и прочее), а ещё надо решить и технические вопросы (описать и наладить сетевую связанность, настроить мониторинг, логи, разобраться с особенностями тарификации и биллинга). Это занимает от двух месяцев до полугода.
Выбор между Яндексом и Сбером был сделан в пользу Яндекса, т. к. весь путь подключения мы с ними уже прошли, есть канал связи до их ЦОДа — не через публичный Интернет. А это суперважно для защиты передаваемого голоса! Есть договор. Есть интеграция инфраструктур.
В общем, дальше, может быть, и сменим поставщика, если понадобится, но пока выбрали их.
Вторая важная особенность — они легко дообучают свой спичкит. Все те сложные слова и термины, которыми просто сыпали рабочие, мы аккуратно занесли в словарь.
Например, рабочий может сказать: «НКТН», «ОТТГ», «ОМК ПОЛАР», «МНС 5-1-1 муфты под фосфатное покрытие», «168 батресс группы прочности Д». Ну и ещё спичкит обижается на слово «соосность». Но нет, это не пожелание роботу и не оценка качества его работы.
Самого робота сделали на готовой платформе для чат-ботов. Просто нарисовали сценарий, и он по нему бегает. Добавили простой фронт на Vue, бэк для связи с API MES на Питоне. Пока всё очень и очень просто. Поставили в тестах на обычные телефоны. Рабочий жмякает кнопку, робот его опрашивает, в конце данные заносятся в MES.
Сначала хотели сделать навык для Алисы вместо всего этого, но там «из коробки» мало что подходит. Во-первых, оператор станка после дня тестов дома назвал жену Алисой, за что жестоко пострадал. Правда, он так называл всех встречных, кажется, но с женой — очень зря. Во-вторых, есть проблема «лакей-пугало» (это слово для вызова гугл-ассистента: «Окей, гугл»). Алиса «из коробки» ничего не сечёт в производстве, увы, никак.
Нюансы
Во-первых, устройства — те, которые телефоны или планшеты. Сначала мы искали промышленного класса в ударопрочном корпусе, но потом решили, что достаточно обычных планшетов.
Во-вторых, надо было прорабатывать варианты, как сотрудник мог бы, не снимая перчаток, стартануть диалог. Рабочие посоветовались и попросили специальную палку, чтобы тыкать ею в кнопку: так им удобнее, чем снимать перчатку. А если тачскрин будет неудобен, то можно будет использовать и просто карандаш с ластиком.
В-третьих, рабочие начали воспринимать робота как крайне тупое существо, которое всё же должно реагировать на команды. Пришлось добавлять ветки диалога на повторный ввод данных и понимать, что некоторые одинаковые слова в разных частях диалога значат разное.
— Диаметр?
— 71. #% твою мать! ?%#@r%(@, %#ка, то есть 72!
— Не разобрал, какой диаметр?
— Да 72, блин, 72!
— Диаметр 72, верно?
— Да.
Сразу скажу, что такие диалоги — редкость, и операторы станков — вежливые интеллигентные люди. Но при виде дефекта они могут быть очень взволнованы и требовать немедленной реакции на специальном заводском языке, преимущественно состоящем из коротких специальных контекстно зависимых терминов.
То есть, если робот не уверен, он должен повторить то, что разобрал за человеком, и попросить подтверждения.
В-четвёртых, нужна ещё одна защита на случай неверного распознавания. Например, если диаметр вдруг стал 74 мм при нормативе производства до 72,3 мм, то робот удивляется, останавливает оператора и спрашивает, уверен ли тот. То есть случайные неверные распознавания ещё контролируются тем, что робот ожидает, в каком довольно жёстком интервале они будут. Это ещё больше логики бэка и ещё одна связка с MES.
В-пятых, тот самый лязг соударяющихся муфт. Разработчики разных спичкитов говорили: они могут докрутить инструменты так, что некоторые эти частоты будут давиться, либо что можно переобучить с учётом этих звуков и перекрытий ими, и проблема решится. Похоже, что проблема действительно решится, но пока её особо и нет: лязг редко попадает на числа, а если он помешал, то робот переспрашивает.
В-шестых, оказалось, что операторы могут сказать роботу: «Стой, я там пять минут назад не то сказал». Тут уж его полномочия — всё: робот грустно сообщает, что если накосячил, — надо вставать, идти к терминалу и там всё исправлять, как обычно.
В-седьмых, мы хотим определение ключевого слова. «Эй, железяка!» — и дальше уже включается запись. Вот эта пусковая часть «Эй, железяка!» должна быть полностью на нашей стороне, потому что мы точно не хотим, чтобы какой-то сторонний софт постоянно слушал завод.
Понадобится простой ASR-движок для локального распознавания прямо в приложении.
Практика внедрения
В эксплуатацию ещё не сдавали, потому что вон сколько доработок! А мужики в цехе ждут, ведь им очень не нравится возиться с терминалом.
Через несколько коррекций сценария (он становится всё разветвлённее) мы выйдем на тестовую эксплуатацию. Думаю, что к концу ноября. Но уже сейчас понятно, что даже тот MVP, который есть сейчас, отлично решает нашу локальную задачу. Операторы уже не останавливают станок, весело препираются с роботом, если что-то не нравится — по старинке идут к терминалу. Теперь всё это надо сделать не на коленке, а с нормальной архитектурой, без костылей, правильно с точки зрения ИБ, задокументировать, настроить бекапы и резервирование на случай отказа и всё такое.
Удивительно то, что это задача, где голосовой ввод — не для того, чтобы он был, а потому, что оказался самым практичным и удобным вариантом. И это точно покажет реальный экономический эффект!
За помощь в подготовке поста большое спасибо Эдуарду Голубеву.