Почему автоматизация декларирования не сильно распространена или несколько аргументов в копилку Эллы Владиленовны.

Сначала определимся, что такое автоматизация декларирования в моем понимании.
Это не просто использование программ для декларирования для подготовки и подачи ДТ в таможенный орган. Это минимизация ручных операций, которые делает специалист по таможенным операциям в процессе подготовки ДТ.

Можно выделить несколько уровней такой автоматизации (начнем от максимума к минимуму):

1) возможный максимум – из входящей информации по товарной поставке без участия человека формируется готовая для подачи в таможенный орган ДТ

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

3) разумный минимум (на примере ПС Альта-ГТД) – использование заполнителя с набором шаблонов под различных заказчиков (исходя из входящих документов и специфики обработки)

4) неразумный минимум – руками набиваем ДТ, не пользуемся заполнителем (или функцией переноса данных из таблицы в ДТ/мастер-инвойс), ранее оформленные товары ищем поиском в списке ранее оформленных.

Что с практикой в рынке и какой процент использования возможностей (статистика интуитивная, но с учетом того, что так или иначе я много с кем из участников ВЭД в различных ролях взаимодействую, то она приближена к реальности):

- возможный максимум – не более 10% компаний

- что-то среднее в различных вариациях – около 40% компаний (у кого на что фантазии хватило)

- разумный минимум – 30%

- неразумный минимум – 20%.

Почему так? В следующей публикации.

ПС: и в качестве менее интуитивного аргумента того, что с автоматизацией декларирования дела обстоят достаточно грустно. Это результаты запросов в ту же нейросеть. В комментариях к посту дам несколько вариантов ответов на запрос «Какие инструменты автоматизации подготовки таможенной декларации на товары есть? Как можно автоматизировать подготовку таможенной декларации на товары, чтобы снизить нагрузку на сотрудников?»
Они все очень поверхностные, а местами даже абсурдные. Это свидетельствует о том, что тема не раскрыта в общедоступных источниках и ограничивается лозунгами про ЭДО.

То, что с автоматизацией декларирования все не очень – понятно.
А почему так?

Ответы тезисно, более подробно будет в двух видео, ссылки на которые выложу сюда.

Тезисно:
1. Нет широкого освещения кейсов и лучших практик (80% СПТО знают где-то 20-30% уже реализованных возможностей альты, 5% СПТО могут сформулировать идею как максимально автоматизировать подготовку ДТ);

2. Цифровая сознательность СПТО и цифровое вдохновение сотрудников минимальны (был ранее отдельный пост про цифровую сознательность и позже будет ссылка на отдельное видео);

3. Автоматизацией декларирования (в максимальном понимании) почти никто не хочет заниматься из аутсорсинговых ИТ-команд (см. видео по ссылке в конце поста), а внутри компании почти никто не может (см. п.1 и п.2);

4. Утяжеляющие факторы:
- далеко не любой клиентский объем таможенного оформления можно автоматизировать (должны быть соблюдены минимальные 3 фактора, о них будет тоже отдельно)
- высокий уровень ответственности за ошибки
- консервативность мышления сотрудников
- финансовая целесообразность таких проектов сложна в вычислении и не так часто находится компромиссная цена «интересы заказчика»/«интересы исполнителя»
- общая сложность таких проектов, в первую очередь, в силу разрыва компетенций и отраслевых знаний между заказчиком и исполнителем.

Ссылка на предыдущий пост про цифровую сознательность

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

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

И этой причиной не является ни отсутствие освещения кейсов, ни конфликт стоимостных интересов, когда стоимость реализации проекта в размере приблизительно 100-150 тыс. руб. это дорого для заказчика, (тем более в формате за 1 проект под конкретного заказчика) и слишком мало для исполнителя (с учётом, что проект как правило является не простым и не шаблонным), ни турбулентность внешней среды.

Основную причину я формулирую, как низкий уровень цифровой сознательности сотрудников.

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

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

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

Ссылка на запись этого выступления.

Все предыдущие посты Элла Владиленовна радостно потирала руки, и многозначительно кивала головой в формате «ну я же говорила».
В это время Надежда (Вера или Любовь) никак не могла понять ну неужели «без вариантов».

Пора дать Надежде надежду (этот оборот считаю топчиком графоманского мастерства🤣🤣🤣)

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

Вы, кстати, знаете, что имя и фамилию автора блога (некто Иван Макарчук) в середине 2000х годов ненавидела добрая половина сотрудников таможенных органов, да и участников ВЭД тоже (тех кто ДСП приказы каким-то волшебным образом читали). Этот самый Иван Макарчук был исполнителем по большинству приказов, регламентирующих порядок действий в рамках применения системы управления рисками в таможенных органах. Не стоит преувеличивать мою роль в написании этих технологий. Конечно я не писал их единолично. Там были и рабочие группы, и мнения регионов и историческое наследие предыдущих авторов, но… Все это сводить, дорабатывать/перерабатывать и логично воплощать в единый документ приходилось мне. (Про пройти 10 кругов ада с согласованием документа у правовом управлении и у редакторов молчу).

Так вот, пардон, отвлекся на воспоминания.

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

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

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

Да, подвох в нюансах, но если бы мне эту информацию дали 7 лет назад, когда я директорствовал в компаниях логистических операторах, то сейчас эти компании 70% своего объема оформляли почти автоматически. Но тогда мне эту информацию не мог дать никто, а сейчас я ее наработал ценой взаимодействия с Эллами Владиленовнами.

Делюсь, как сейчас принято говорить, от души и во благо😇

Пусть у Надежды будет надежда😈

Действую, как добропорядочный блогер.
Сегодня буду выступать на юбилейной конференции ВТЛ (ВЭД, логистика, таможня).

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

Также в сессии заявлено выступление очень уважаемых людей, представителей Альта Софт и СТМ.

Темы к обсуждению:
Плюсы и минусы действующей системы
Принципы сбора и обмена данными для контроля и организации процесса товарообмена
Возможен ли контроль без деклараций?
Достижима ли реализация модели единого окна для России
Нейросетевой хайп и ВЭД. Ожидания и реальность

Доступны живой формат + онлайн.

https://onlineuniver.ru/confavtl

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

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

Я рад поприветствовать всех присоединившихся к этой группе.

Для тех, кто пришел за списками нейросетей, который я обещал на конференции – ссылка на пост (он же в закрепе), где эти самые ссылки указаны.

В целом последнее, что происходит на этом канале

у нас постепенно раскрывается нейросетевой HR-хоррор «я не знаю, что Вы будете делать следующим летом» , где мы оцениваем на сколько нейросети смогут поддержать/заменить какие-либо функции в компаниях таможенно-логистической отрасли.

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

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

По этому поводу немного подробнее напишу/расскажу где ключевое заблуждение, и как имеет смысл рассматривать технологии, чтобы не было «либо черное» (все отстой ничего не работает), «либо белое» (робот работает, человек не работает, что тоже по факту отстой).

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

Да, я не пишу каждый день по 3 раза в день, лишь бы поддерживать эфир и подогревать ажиотаж. Этот блог не ведет нейросеть «водяным контентом». Все что пишется – пишется человеком, но человеком, который работает с цифровыми инструментами.

Как в свое время сказал один из топов очень крупного таможенного представителя, с которым мы начали делать совместный проект: «ЦифроВЭД – это для ценителей».

До недавнего времени из всех возможных задачи по автоматизации - автоматизация декларирования была моя самая нелюбимая.

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

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

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

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

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

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

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

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

Но, ситуацию радикально изменилась, когда я изменил подход к этим проектам. Об этом в следующем посте.

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

Этап интервьюирования и поиска решения прошли хорошо.

Этап уточнения логики автоматизации подбора кода прошли в 2 этапа:
гипотеза 1, хорошая, но не оправдалась, гипотеза 2, не самая лучшая, но жизненная в контексте специфики товара была принята за рабочую.

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

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

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

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

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

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

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

Описанное выше яркий пример нескольких моментов:
1) разрыв в компетенциях и коммуникации между заказчиком – бизнес-аналитиком – разработчиком;
2) различные ожидания сторон от коммуникации, и что есть «нормальный вопрос», а что «излишний»
3) общая напряженность от совмещения «текущая работа» отвлечение на «что-то иное».

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

О разрывах компетенций и искажениях в процессе реализации проекта.

В видео часть выступления по этому вопросу. Ссылка на видео в конце поста. Это самая-самая боль. Я бы сказал, что это 90% успеха или неуспеха проекта. Она же причина и объяснение ситуации, которая была описана вчера.
И тут лучше посмотреть, чем пытаться это тезисно описывать.

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

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

2. С любой адекватной командой разработки можно синхронизироваться в контексте (то есть, если они не из ВЭД, то через +- 3-6 месяцев общее понимание того, что происходит придет). И если этот адаптационный период именно со стороны заказчика включить режим цифровой сознательности, то это может стать залогом дальнейшего длительного конструктивного обоюдоудобного взаимодействия.

Можно быстрее? - Да можно.
Можно еще быстрее? - Да. Ищите разработчиков из области.
Но уверенно говорю, все текущие уникальные разработчики из ВЭД когда-то ничего не понимали в специфики логичстических и таможенных бизнес-процессов.

Ссылка на видео.

Микро финал про то, как я нелюбимые проекты по автоматизации декларирования превратил в любимые.
(Часть 1)

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

По мере важности:
1. Сопротивления со стороны декларантов больше, чем помощи, высокий уровень скепсиса и недоверия
2. Много нюансов (почти каждый заказчик своя специфика обработки), которые часто вылезают не на старте обсуждения проекта, а в момент тестирования готового решения
3. Разный уровень подготовленности декларантов (в том числе владения программными средствами для декларирования)
4. Несоответствие финансовой оценки целесообразности проекта со стороны заказчика и исполнителя.
Об этом как раз сейчас немного подробнее.

Как я ранее писал, самая "ок" команда для такого проекта – это:
бизнес аналитик/руководитель проекта, декларант (со стороны разработки на подхвате), и программист.
В идеальном варианте совместить декларант+программист в 1 человека (но это скорее исключение из правил, чем правило). Бизнес-аналитика/руководителя проекта исключить вряд ли получится, потому что при прочих равных шероховатости в коммуникации необходимо компенсировать эмоциональным интеллектом, и, в очень большом количестве случаев, программист в этом плане не сильно «клиентоориентирован». То есть, в проекте, где и так все идет не гладко, эмпатию убирать не стоит.

И проект при хорошем раскладе (с учетом занятости декларанта клиента текучкой) будет длиться не менее 2х недель, а то и больше.
Сколько должен стоить такой проект для команды разработки, чтобы он был более-менее финансово интересен? 100 тыс. руб. это прям минимальный минимум, и то со скрипом с учетом того, что сроки, как правило, растягиваются. И это еще с учетом того, что не надо сильно придумывать изысканные способы формирования товарной базы и поиска хитрых ключей для подтягивания кода, описания и разрешиловки.
Предположим, что заказчику повезло, и за разработку отвечает команда стартующих фрилансеров (которые еще готовы хвататься за работу без излишних ожиданий), и возьмут подобный проект скорее для портфолио. Цена может составить 60-70 тыр.

А сколько готов платить заказчик за подобный проект, с учетом того, что по сути на каждого клиента поделка на этап 1 (обработка входящих документов и вычислительные операции) будет почти уникальная. 50 тыр. максимум. Заказчик хочет универсальный продукт, а в текущем контексте это мало осуществимо.

Кажется, что на этом месте. как я последнее время люблю говорить, доклад можно закончить. "До 50 тыр." и "от 100 тыр." стыкуются между собой "никак".
Но
Я продолжу в следующем посте.