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

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

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

Вы, кстати, знаете, что имя и фамилию автора блога (некто Иван Макарчук) в середине 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 тыр." стыкуются между собой "никак".
Но
Я продолжу в следующем посте.