Loginom - первая модель, первая миграция, первые впечатления. Выступление Владимира Гридчина на Loginom Day 2018

Меня зовут Гридчин Владимир. Я - руководитель отдела системного анализа банка ДельтаКредит. Сегодня я выступаю в бизнес-секции. Немножко непривычно для меня, что я представляю свой бизнес, хотя всю жизнь был IT. Но сегодня такой день, что все мы - немножко бизнес.

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

И сейчас вы прослушали реальный кейс того, как коллеги из Ситилинк решали задачу Data Mining, то есть настоящую аналитическую задачу.

Но давайте не будем забывать, что и предыдущее приложение рязанцев - Deductor и текущее Loginom, это, на самом деле, система поддержки принятия решений. Это нечто, что должно помочь принять решение. И не важно, либо это решение связано с копанием больших объемов данных, либо это что-то очень быстрое. То есть, эта система может использоваться как OLAP, так и как OLTP.

Банк Дельтакредит (монобанк) находится на ипотечном рынке 1998 года, с 2007 года сотрудничаем BaseGroup Labs, которая теперь уже называется Loginom. У нас есть два рода задач, которые решаются в банке. То есть, есть действительно задачи аналитические, когда риск-технологи разрабатывают портрет потенциального клиента, какие у них категории риска, где точка безубыточности, где риск-зоны, какой клиентский скоринг.

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

Я не буду совсем «в глубь веков» углубляться и начну с того, например, что коллеги из Ситилинк решали только на новой платформе, а я расскажу ретроспективу, зачем вообще вся эта кухня была нужна. Запуск кредитного конвейера, то есть разработка набора сценарий по оценке кредитоспособности заемщика у нас состоялся в 2012 году.

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

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

Требования к СППР

Я расскажу, какие требования к этой СППР предъявлялись тогда и сейчас, и будут предъявляться в дальнейшем. Почему мы выбрали, и чем у нас всё сейчас закончилось. Вообще, было хорошо меньше прилегать разработчиков, по той простой причине, что визуальное программирование более простое, и аналитики дешевле, чем разработчики на современном рынке труда.

Естественно, на платформе нужен Data Mining, как я сказал, потому что есть два типа задач, которые сейчас решаются в банке: это задачи аналитические и задачи по быстрому принятию решения.

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

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

Нам нужна была перспективность и масштабируемость системы, и, забегай вперёд, ещё в 12 году, когда мы только запускали систему, у нас было порядка 100-200 обращений к системе поддержки принятия решений. Сейчас у нас 25.000 обращений в день, то есть, когда мы ее выбирали – не прогадали.

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

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

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

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

Я вкратце привел все сервисы, с которыми он мы взаимодействием:

• бюро кредитных историй,
• сервис «Право.ру» (данные по организации, по работодателям, по заемщикам или по другим юридическим лицам),
• сервис взаимодействия страховыми компаниями,
• Crona(сервис взаимодействие с оценочными компаниями),
• Cronos (базы данных по физическим лицам и по юридическим лицам),
• Integrum (базы данных по физическим лицам и по юридическим лицам).

Со всем этим мы интегрируем.

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

Я попытался отобразить все вызовы, которые перед нами стоят. Почему нам всё время нужно быть на коне. Почему всё время надо что-то подкручивать, подвинчивать, «держать нос по ветру» и так далее:

1. Увеличение количества доступной информации. Государство так или иначе говорит о том, что мы идем в цифровизацию. И Медведев это говорил, и Путин это говорил, и Сколково у нас есть, и худо-бедно они в эту цифровизацию идут. Они говорят о том, что мы настаиваем на электронном взаимодействии с гражданским населением Российской Федерации. Давайте уберем людей, давайте уберем очереди, давайте уберём бюрократию. И мы видим, что, на самом деле, что сервер межведомственного электронного взаимодействия запущен, все сейчас через электронный дневник своих детей смотрят в школе, к врачу мы записываемся через госуслуги, налоги смотрим, штрафы смотрим, - очень много, что они действительно сделали. Много что там плохо. Конкретно я, как простой человек, простой пользователь, имею много нареканий к госуслугам, но, в то же время, есть куча удобств, которые оттуда можно вытянуть. Можно посмотреть, сколько штрафов у нашего клиента, если эта информация открытая. Долго время банки борются за то, чтобы как-то связываться с пенсионным фондом. Только Пенсионный фонд Российской Федерации более-менее внятно говорит о том, с каких доходов клиент заплатил налог, сколько у него реальный доход, потому что нарисовать можно всё, что угодно.
2. Ужесточение требований регулятора. Центробанк тоже не дремлет, он тоже постоят выпускают новые федеральные законы, новые требования к резервам, новые требования к расчету рисков. Сейчас всё банковское сообщество за голову хватается, потому что идет огромный проект СФО 9 (Международный стандарт финансовой отчетности 9). Никто толком не знает, как это считать, но отчетность правильную подавать надо.
3. Изменение банковских продуктов. Когда я пришел в банк, мы кредитовали только готовые квартиры. Просто были готовые квартиры, мы их на вторичном рынке реализовывали, и под них выдавали кредиты. За то время, пока я нахожусь в банке, за 10 лет, мы уже что только не кредитуем: мы уже кредитуем гаражи, мы кредитуем новостройки, мы кредитуем апартаменты, мы кредитуем загородную недвижимость, мы кредитуем землю. Я хожу к нашим продуктовикам и говорю, а вы вообще в курсе, что в Москве на кладбищах земля дорогая, давайте ее кредитовать будем. Я ради шутки говорю, но они ухватились. Ну а почему нет? Это - бизнес, если это приносит деньги – почему нет? Все эти продукты усложняются, понимаете, что продуктовая линейка банка растет, за всем надо наблюдать, всё рассчитывать, поддерживать, оценивать и очень быстро подкручивать, если что-то меняется. Как выясняется, будет заседание Центробанка: понизят ключевую ставку, повысят, не изменят. В зависимости от этого подкручивают свои продукты. Или США сказали: «Сейчас будем санкции вводить», - всё уже, все руку на пульсе. Как только там Белый дом скажет, здесь летит меморандум: «Срочно за 3 дня всем ставки поднять или опустить». Все банки друг за другом следят, везде ходят тайные клиенты, наши сотрудники под видом простых клиентов проникают в Сбербанк, сбербанковские – к нам, чтобы знать, кто там чем дышит, как клиентов обслуживает.
4. Индивидуальный подход к клиентам. Есть, например, Сбербанк, он может себе позволить работать конвейерно. У него все на одно лицо: они всё получают белую зарплату в Сбербанке на зарплатные карты, и вот они у него потоком идут. Они идут потоком, и он их потоком оценивает. Мы себе это позволить не можем, мы должны индивидуально рассматривать людей, которые к нам пришли, потому что, быть может, они по каким-то там параметрам отклоняются. Может быть, мы ему дадим чуть поменьше, может, мы ему на чуть больший срок, может, мы подкрутим ему соотношение кредит-залог. Всё это индивидуально, всё надо подсчитывать.
5. Новая схема мошенничества. Мошенники тоже не дремлют. То есть, когда я пришел в банк, основной схемой мошенничества являлась двойная запись, когда люди сканировали свою трудовую книжку, после чего уже на скане писали какое-то сладкое место работы, повторно сканировали и подавали нам как-будто всегда так было. Такие были методы мошенничества, с этим этого нелегко боролись: смотрели серии трудовой книжки. Так как у нас всё в цифровизацию шагнуло, мошенники шагнули туда же. Они чем занимаются сейчас: они замеряют, с какой скоростью 1 банк узнает про то, что человек взял кредит в другом банке. Мы же, когда выдаем кредит, должны оценить, насколько человек загружен, на сколько у него расходы выросли. Если он уже в другом банке ипотеку взял, понятно, что он нашу не потянет. И вот эти ребятки ходят и смотрят, сколько времени понадобится для кредитных историй, чтобы другой банк узнал. Если всего ничего, то он подает сразу в несколько банков, пытается взять сразу несколько кредитов и всем сказать «Пока». Центробанк тоже не дремлет, он тоже пытается бороться с этим. Он сейчас требует от всех банков, чтобы мы сообщали в Бюро кредитных историй не только о клиенте, которому выдали кредит, но и когда он только пришел, мы вот только его смотреть начали. И мы уже должны в бюро сказать: «Уважаемые товарищи банковского сообщества, вот этот человек пытается взять кредит, имейте ввиду»,  чтобы он вас не обманул.
6. Все уходит в электронное взаимодействие. У нас растет поколение смартфонов, растет поколение людей, которые не желают ножками ходить в отделение. Государство тоже к этому идет, оно требует, чтобы все сервисы становились так иначе электронными. Сейчас идет огромный государственный проект по геометрии, то есть по тому, чтобы можно было счета открывать, банковские операции, всё делать без явки в банк.

От Deductor к Loginom

Возвращаясь к Loginom, мы хотим сказать, что выбор современной платформы, это не то, чтобы наша какая-то блажь. Стоят вызовы, их надо решать, каким образом их надо решать и почему их нельзя решить на предыдущей платформе? У нас банке, как я уже сказал, когда мы начинали, было порядка 100-200 запросов в Deductor, сейчас это 25.000 в день. Когда то добыло 7 сценариев, сейчас уже 45 сценариев. Сейчас чего только на Deductor не написано.

Но Deductor - это платформа предыдущего поколения, не лишенная недостатков. В чем у неё были трудности? Основные я отметил:

1. Сложность декомпозиции большой задачи, то есть это огромное дерево принятия решений, такая вот ступенчатая модель.
2. Deductor плохо предполагал режим работы в режиме «черного ящика», то есть нельзя было модель кому-то отдать, и чтобы этот кто-то не мог засунуть свой любопытный нос.
3. С веб-сервисами было тоже очень нетривиально работать. Сейчас существуют сотни сервисов. На одном только СМЭВе выставили сотню сервисов: выписки можно смотреть, штрафы, налоги. В Deductor работа с веб-сервисами была достаточно трудоемкой. Мы попросили наших разработчиков писать так называемый прокси-сервисы. Реально, во вне обращался CRM, что-то забирал из внешнего сервиса, а Deductorу отдавал в обработанном виде, который Deductor дальше уже дообрабатывал и смотрел. Вот это всё довольно трудоемко и неудобно, но это - некая плата за универсальность.
4. Было трудно обрабатывать большие объемы данных, особенно, когда мы первую скоринговую модель строили, и нам приходилось загружать миллионы всяких проводок, истории просрочек по клиентам, проводить винтажный анализ, смотреть срок возревания кредита.
5. Главная проблема - это то, что жизненный цикл любого программного обеспечения конечен, то есть нет ничего бесконечного в мире. Deductor тоже себя изживает, и нужно переходить на что-то другое. В первую очередь, это, конечно же, Loginom.Это новое поколений системы поддержки принятия решений. Нам его презентовали, Арустамов приезжал к нам в банк еще два года назад. Там нам уже показывали, рассказывали, что будет, как будет, но, когда нам уже показали готовый вариант, хотелось отметить.
6. Работа в браузере. Если кто то работал на предыдущей системе поддержки принятия решений, то он должен помнить, каково это - возиться с ключами, устанавливать ключи лицензирования, устанавливать лицензионный сервер, прошивать эти лицензии. Здесь всё в браузере, всё инкапсулировано от конечного пользователя. Зашёл и работает: по принципу «plug-and-play» - включи и работай. Не задумывайся, что там на сервере происходит, как он там кому-то лицензии выдает. Вообще не думай, тебе выдали твой логин и пароль, сколько хочешь и что хочешь, то и делай.
7. Удобный интерфейс. Сейчас всё идёт в работу мышкой и пальчиком. Вверху всякие кнопочки, слева все узлы сценария (то, что Арустамов показывал).
8. Полностью изменена парадигма проектирования. То есть, даже мне очень тяжело сейчас свои мозги перестроить и сказать себе: «Володя, Loginom  - это не Deductor красиво перерисованный, это другая платформа, у неё другая архитектура, у нее поддерживаются принципы объектно-ориентированного программирования, у нее просто принцип наследования поддерживаться, принцип инкапсуляции поддерживается, принцип полиморфизма поддерживается, и, самое главное, - повторное использование поддерживается». То есть, если я написал какую-то модель, я могу ее объявить отдельно, и она будет как «черный ящик» для чего-то другого. То есть, я могу отдать другому подразделению и сказать: «Если вы на вход поставите свою процентную ставку и поставите количество периодов, то я скажу, какую сумму кредита дам». Формула аннуитета там где-то зашита неявно, вам не надо знать, какая это формула. Вы получите то, что вам надо. Я могу написать это один раз, положить его и назвать его крупными буквами «АННУИТЕТ». И пускай все пользуются. Сейчас сколько надо ануитетов, столько можно написать. Сейчас как делает аналитик: зашёл в предыдущий сценарий: ctrl+C, пошёл в другой – ctrl+V. И, если там какие-то поправки к руководству вышли, то надо идти по сценариям, смотреть, где это было прописано, и везде поправлять. А сейчас, в Loginom, - сделаем подмодель и забудем, надо будет поправить, в одном месте поправим, и все пользуются, для них бесшовно произойдут всякие изменения.
9. Есть такие вещи, как «Ленивые вычисления» и «Параллельные вычисления», если какие-то ветки должны выполнятся параллельно, они будут выполняться параллельно. Если для вычисления какой-то ветки не требуется, она не будет вычисляться и лишние ресурсы машины есть тоже не будет.

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

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

Создание веб-сервисов по одному ключу, можно кучу узлов взять, объединить, право кнопку нажать - и у тебя готовая подмодель, еще раз нажать – готовый веб-сервис. CRM может обратиться к этому веб-сервису, потому что ушки этого веб-сервиса начинают торчать наружу, и CRM может дотянутся до него, за ушки взять, и тот ему даст ответ.

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

Такие возможности Loginom позволяет делать.

Первые впечатления

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

Я решил взять сценарий попроще и посмотреть, как долго я буду плеваться. Я взял сценарий под названием «Дополнительные условия». Фактически у любого человека возникают дополнительные условия. То есть, если он не какой то типичный заемщик, его нужно проконтролировать или проверить, или у неё какие-то дополнительные условия того, что если он потом принесет документы, подтверждающие право собственности, мы понизим ему ставку.

Этот сценарий я решил переложить на Loginom. Не надо думать, что древовидная система просто поменялась на графическую. Здесь поменялась парадигма работы с переменными, принципы выполнения поменялись.

Самое первое впечатление скажу, когда я только начал: я открыл и подумал: «Куда я попал?» Раньше в Deductor добавил узел и все, а здесь я узел кинул на рабочий стол, у нее слева и справа иконки разной формы, по середине четыре пентаграммы, - один значок, как пол кабины стратегического бомбардировщика. А потом начинает быть интересно. Думаешь, как эта штука работает, как сделать, чтобы она зазеленела, потому что, если неправильно построили, она будет красной. Я начинаешь себя чувствовать как ребёнок, который начинает собирать по микросхеме радио.

Потом, когда уже два-три узла соединил, начинается счастье, как в Лого играешь. У нас сейчас кроме дегитализации всё куда уходит (еще есть такое модное слово – «геймификация»), у нас любят, чтобы всё было виде игры, чтобы у нас какие-то бейджики выдавались.

Можно предложить Loginom Company в своих аналитических курсах ввести какие-нибудь ачивки. «Я написал 10 сценариев», - и какая-нибудь ачивка загорелась, «Я научился делать трансформацию данных», - вторая ачивка. Какая-нибудь мега ачивка - это написать сто сценариев, в каждому не менее 20 узлов. В конце концов, все у нас из игр вырастали.

Первое, с чем я столкнулся, когда мы начали с компанией Loginom взаимодействать – это подмодели. Мне стало места не хватать на экране, они все посворачивали, и у меня осталось всего ничего. Чтобы посмотреть, что там внутри происходит, просто ныряешь и переходишь на другой лист.

Что нас просто выбешивало в свое время в Deductor, если у нас нет данных на входе в какой-то узел, например, в узел проверки условия: если а=1, ниже хочется прописать какую-то логику, а у тебя сейчас а=2, ты сейчас ниже по логике этого решения не нырнешь, потому что а=1 и всё, оно тебя не пускает. Аналитики писали если а<>1, чтобы это обойти. Пока он это делал, он забыл, что он true на false поменял. Потом это всё летит в промышленную среду, и потом бизнеса очень сильно удивляются, почему так.

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

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

То, чего всегда не хватало - это настройка некоторые области видимости. Мы работаем в подразделениях, и одно подразделение не должно знать, как работает другое. Наш алгоритм - это какое-то ноу-хау, высшей категории степени. И нельзя, чтобы об этом узнало другое подразделение и «за 5 копеек» слило в прессу.

Здесь уже первые зачатки разграничения ролей безопасности, разграничения областей видимости уже есть. Я общался с Арустамовым, он пообещал, что они и дальше будут работать в этом направлении. Чтобы можно было разделять между собой людей, которые работают системой, как с «белым ящиком», когда они видят все ее внутреннюю начинку, и могут там «поковыряться», подкрутить любой винт. И люди, которые работают с системой, как с чёрным ящиком, когда им говорят: «Не важно, что там внутри, ты вот сюда подавай, вот отсюда забирай».

Что мне понравилось и что не понравилось (по свежим следам):

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

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

Сервисов очень много, мы сейчас идём к тому, чтобы одобрять кредитную заявку в течение нескольких минут, чтобы просто сказать клиенту, подходит он нам или нет. А вот какой-то глубокий анализ провести, миллионы данных перелопатить, какие-то модели аналитические построить, карты Кохонена, нейросети, - это всё нам не нужно. Нам надо очень-очень быстро сделать вывод.

Как вы считаете, какие узлы самые востребованные у аналитика, который работает с моделью, пишется сценарий? На самом деле, есть ровно 3 узла, которыми, в основном, пользуется разработчик сценария: это калькулятор, группировка и узел фильтрации (проверка условия). Если мы 70-80% времени занимаемся настройкой этих узлов, так пусть нам хотя бы будет удобно это настраивать. И, буквально, через 10-15 минут после первого удивления, когда первый шок проходит, становится хорошо и приятно, такое послевкусие остается.

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

«Попробуй-ка узел затолкать в правую область экрана». Я позвонил в поддержку Loginom, знаете, что они сказали: «Владимир, возьмите какой-нибудь узел, ничего не значащий, затолкайте его куда-нибудь далеко-далеко направо, и у вас будет большая-большая область, потому что Loginom будет думать, что туда надо тянуться. Не знаю, поправят или не поправят они это.

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

В Loginom мне сильно не хватает работы с глобальными переменными. Он использует идеологию «ленивых вычислений», если какая-то переменная сейчас не нужна, то не важно, что там в ней лежит. А мы привыкли, что у нас есть какой-нибудь контейнер, там собираем все сведения, и мы всегда знаем, что в этом контейнере лежит, и в любом узле в этот контейнер что-то доливается.

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

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

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

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

Ничего нового на старой платформе мы уже делать не будем. Все новые сценарии будем писать на Loginom. Обучать сотрудников и мигрировать старые сценарии также будем на Loginom.

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

Сейчас наша система сливается в единый цикл обработки данных. На СППР закольцовывается как фронт-офисная, так и мидл-офисная система, так и бэк-офисная система. Например, бэк-офис проверяет банкротство, на действительность паспортов.

У нас сейчас каждый второй брак распадается. И люди начинают исключать друг друга из созаемщиков по квартире. Бэк-офис проверяет, потянет ли человек один ипотеку со своей зарплатой. Я уже 10 лет работаю в банке, я еще ни разу не подошел в бэк-офис и не спросил: «А вот если не хватит, то что, мы запрещаем разводиться людям? Или что вообще происходит?»

Это все нас ждет в ближайшем будущем. Мы уже сейчас приостановили «хотелки» бизнеса, чтобы разобраться с Loginom. Мы их заразили тем, что это будет по-новому, по-модному, и они нас готовы ждать.

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