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

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

Казалось бы, архитектору 1С следует позаботиться о том, чтобы в будущей системе были все необходимые пользователям отчеты. А так как предусмотреть все заранее невозможно, надо спроектировать систему так, чтобы добавление любого мыслимого и немыслимого отчета давалось, что называется, «малой кровью».

Но тут на сцене появляются большие языковые модели (LLM GPT), именуемые в просторечии искусственным интеллектом. И выясняется, что теперь проектировать будущую учетную систему можно почти как угодно. Ну будут у вас какие-то таблицы с данными. Придет пользователь, скажет что ему надо на человеческом языке. Вы возьмете этот вопрос от пользователя, прицепите к нему структуру таблиц и отдадите большой языковой модели. На выходе получите готовый запрос. Останется только выполнить его и визуализироваить результат. Будут таблицы с данными такими или эдакими, большой языковой модели до определенного предела все равно. Делай как хочешь! Искусственный интеллект разберется.

На этом моменте некоторые поспешили с заявлениями, что скоро и специалисты будут не нужны. Но нет. Это не конец истории для архитекторов 1С, а скорее начало.

Рассмотрим это на одном конкретном примере. В типовых конфигурациях 1С есть такая замечательная таблица, в которой отражаются данные о продажах. В УТ, КА и ERP это регистр накопления под названием ВыручкаИСебестоимостьПродаж. Таблица хороша тем, что в ней собрана вся необходимая информация о продажах: товар, количество, сумма, покупатель, дата продажи, себестоимость, менеджер. В сочетании с большой языковой моделью это дает нам возможность получить ответ на практически любой вопрос пользователя о продажах. Все мыслимые и немыслимые отчеты, весь этот Business Intelligence можно было бы получить легко и просто, если бы не одно «но».

Дело в названиях. Сам регистр называется не то, чтобы очень просто и понятно. Но дальше больше. Товар в регистре называется… АналитикаУчетаНоменклатуры. Покупатель, АналитикаУчетаПоПартнерам. Большие языковые модели, конечно, могут многое. Они запросто «проглатывают» орфографические ошибки, пропуски букв и т.д. Но «это» им уже не прожевать. Из всего, что я упомянул выше, один только «менеджер» называется по человечески «менеджером».

В другой типовой конфигурации, УНФ, этот же регистр имеет уже нормальное название, «Продажи». Покупатель там называется «Контрагентом». Ну, куда ни шло. Для товара используется любимое разработчиками типовых словечко «Номенклатура». И это уже неприемлемо. Менеджер под вопросом. Здесь он называется «Ответственным». Может для большой языковой модели это не будет проблемой, а может и будет. И слово «Ответственный» будет сбивать ее с толку. Да, и во всех типовых дата операции в регистре называется «Период». Что тоже может быть источником проблем.

Думаю, вы уже поняли, к чему я веду разговор. В самом ближайшем будущем, если не сказать уже сейчас, архитектору 1С потребуется такой чисто гуманитарный навык, как владение естественным языком. Все должно называться просто и понятно. Это, кстати, не такая уж простая задача. А для некоторых и вообще недостижимая. Умение изъясняться просто и доходчиво не всем дается. И, при этом, требуются определенные усилия для того, чтобы его развить. Эта тема становится еще более интересной, если учесть, что «просто и понятно» должно быть не только людям, но и большим языковым моделям. Таким образом вырисовывается необходимость развивать довольно специфический навык на стыке гуманитарного и инженерного. Помимо владения языком потребуется знание того, какие конструкции языка являются рабочими для больших языковых моделей, а какие лучше избегать.

В завершение хочу пригласить вас на бесплатный вебинар курса Архитектор 1С про нотации моделирования бизнес-процессов. Регистрация доступна по ссылке.