📰 Китай переходит от ИИ-экспериментов к токен-экономике

Китай обрабатывает 140 трлн токенов в сутки - против 100 млрд в начале 2024 года. Регулятор, Национальная администрация данных КНР, официально ввёл термин «цийюань» (токен) как расчётную единицу между технологическим предложением и коммерческим спросом. Модели Qwen от Alibaba обошли американские на OpenRouter - популярном маркетплейсе ИИ-моделей.

15-й пятилетний план КНР (2026-2030) упоминает ИИ более 50 раз. Приоритеты: мультимодальность, ИИ-агенты, воплощённый ИИ, роевой интеллект. Параллельно - прорывы по всей цепочке в микроэлектронике, биопроизводстве, новых материалах.

🇷🇺 Россия формирует национальный план внедрения ИИ до 2030 года с аналогичной логикой межотраслевой интеграции, но без публичной метрики по объёму обработки токенов.

Подписаться на канал Кластера цифровой экспертизы ВШЮА НИУ ВШЭ

In Tech We Trust, но есть нюанс. Почему технологии часто не решают проблемы юристов

На лекциях по цифровизации юрфункции мы часто слышим один и тот же вопрос: «Какой конструктор документов лучше?».

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

Разберем четыре основных фактора, о которые чаще всего спотыкаются проекты по цифровизации.

👥 Люди
Компания закупает конструктор договоров и ждет роста производительности. Но вместо этого сталкивается с тихим саботажем. Команда находит одну незначительную ошибку алгоритма, публично объявляет систему сырой и по старинке продолжает работать со своими личными шаблонами в Word.

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

⚙ Процессы
Департамент внедряет проекты по электронному согласованию договоров, чтобы ускорить работу. Но старые регламенты никто не переписывал. В итоге типовой договор всё так же должен собрать пять избыточных виз и предсказуемо виснет на этапе «согласование со службой безопасности».

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

📄 Данные
Руководству презентуют наглядный дашборд с аналитикой. Но если в исходных реестрах кочуют ошибки, неверные статусы и дубли, система просто визуализирует плохие данные. В какой-то момент красивые графики начинают расходиться с реальностью. Из-за ручного ввода одни юристы заносят контрагента как «ООО Ромашка», другие — как «РомаШка ООО». В итоге дашборд дробит статистику, искажает суммы рисков по ключевым партнерам, и общая картина просто разваливается на части.

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

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

Вместо экономии времени получается дополнительная рутина по обслуживанию софта.

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

С какими из этих барьеров — саботаж команды, кривые процессы, «грязные» данные или разрозненные ИТ-системы — вы сталкиваетесь чаще всего? И как вы их преодолеваете?

⭐️Пятница — хорошее время поговорить о цифровизации, в которой все заняты, но никто никуда не едет.

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

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

https://telegra.ph/Cifrovizaciya-kak-hobbihorsing-pochemu-mozhno-mnogo-skakat-i-nikuda-ne-priehat-09-04

❓Как обстучать идею цифровизации о реальность

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

Идея нравится, пользователи в целом за, серьёзных возражений нет. А потом по ходу реализации выясняется: система есть, а работа идёт рядом с ней. Никто не врал — все так думали в тот момент.

Этот механизм хорошо разобран в книге «Спроси маму» Роба Фицпатрика, и подход из неё применим в проектах

Главная мысль: мнения почти бесполезны. На вопрос «вам будет удобно?» мы получаем вежливость, догадки и пожелания. Надёжны только факты о прошлом: что человек уже сделал сам, чем обходился, на что тратил время. Мнение бесплатно, а поведение дорого.

По-хорошему идею стоило бы не обстукивать, а выращивать из таких разговоров. Но в наших проектах она обычно появляется раньше нас: бюджет защищён, вендор выбран. Значит, проверяем то, что уже есть.

Отсюда приём: не спрашивать, чего людям не хватает, а искать костыли— то, что они изобрели себе сами, без нас и без регламента.

Рассмотрим два примера.

В компании есть типовые формы договоров, утверждённые регламентом. Менять их долго, а запросы от бизнеса прилетают каждый день. Юристы готовят свои формы — неофициальные, но с закрытыми основными рисками — и отдают контрагентам. Потому что согласовать правки к своей форме проще, чем писать протокол разногласий на десять страниц к чужой, скачанной из интернета. Костыль? Да. Но работает.

Боль пользователя реальная, только лечится она не запретом, а скоростью: правильный вывод не «привести в соответствие с регламентом», а сделать подготовку и обновление форм быстрыми и небюрократичными. Костыль показал, где жмёт процесс.

Второй пример. Есть система учёта судебных дел, но юристы параллельно ведут дела в своих таблицах. Разбираемся: нужный функционал в системе есть, просто на обучении о нём упомянули в двух словах.

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

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

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

Только не переносите костыль в систему «как есть» он говорит о боли, но не о решении.


В следующем посте расскажем подробнее про процесс поиска таких костылей.

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

https://telegra.ph/Inventarizaciya-kostylej-kak-eyo-provesti-09-17