Loginom: fast to market

Время — бесценный ресурс

Я, наверное, начну с каких-то общеизвестных банальных вещей. Заранее прошу меня за это извинить. Просто, чтобы вам был понятен ход мыслей при создании нашей аналитической платформы.

Мы все прекрасно знаем, что время – бесценный ресурс. Наверное, это единственный ресурс, который не восполним. С детства мы привыкли к расхожей фразе о том, что время — это деньги. Мы к ней привыкли и, наверное, это понимаем и принимаем. Использовать время как-то бездарно – непозволительно.

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

В начале любого действия, как правило, лежит какая-то идея, или мысль. Идея (как мне подсказала Википедия) – это некий мысленный образ некоего действия, предмета или явления. Допустим: у нас появилась какая-то идея. Если мы вспомним о том, что, если мы занимаемся бизнесом, то бизнес направлен на то, чтобы получать прибыль и, соответственно, бизнес-идея призвана зарабатывать какие-то деньги.

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

Даже если мы дойдем до последнего этапа этого пути и составим для себя какое-то мнение о полезности или бесполезности идеи, которой занимаемся, — это все равно не будет до конца полной информацией. Все, что мы делаем – мы делаем, как правило, не для себя. Мы делаем для людей.

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

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

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

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

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

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

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

Говоря проще, за определенные деньги, в определенные сроки надо добиться определенного результата. Чем быстрее вы это делаете, чем больше «сжимаете» время, тем больше у вас шансов этого результата добиться.

Можно привести такой пример: все мы знаем об успехах китайской экономики. Я взял цитату Яна Хатчисона: «Причиной успеха китайских компаний на рынке смартфонов является специальная «китайская скорость», с которой не в силах конкурировать европейские и американские производители», который говорит о том, что китайцы добились невероятных успехов в разработке программного обеспечения для смартфонов, в частности. И, вообще, в производстве смартфонов. За счет чего происходит такое выдвижение китайских компаний на ведущие роли в мировом рынке?

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

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

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

Если кто-то знаком с методологий Agile-работы в проектах, то, о чем я говорил, — очень похоже. Agile переходит из использования в IT-сфере, в сферу производства. Если вернуться к методологии Agile… (Вы видите на экране схематичные изображения).

Она появилась неспроста. Agile-методология появилась в качестве реакции рынка, на те быстрые изменения, которые эти рынки испытывают. Мы все знаем: методологий управления проектами на самом деле много. Вы, наверное, помните: PMBOK популярный, PRINCE2 и так далее. Это обобщенный опыт человечества по управлению проектами, бог знает с каких времен.

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

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

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

Поэтому мы от такого подхода уже отказались. Мы не используем это словосочетание – техническое задание, мы говорим — требования заказчика. Дайте ваши требования в понятном нам виде. Мы их персонализируем — со стороны заказчика в составлении списка требований, обычно, участвует несколько человек. Напротив каждого буквально ставим – кто автор, и если вдруг он отменяет или добавляет свои требования, мы имеем дело с одним человеком, не со всей этой большой машиной, со стороны заказчика. Это приводит к тому, что мы потихоньку отходим от традиционных методик управления и переходим к таким.

Как я уже говорил, стартапы работают по методологии Agile, потому что по-другому у них вообще не получается. Очень трудно найти заказчика, который будет платить по договору, допустим, Time & Material. Неважно, что вы в проекте делаете: полезные или вредные вещи, он все равно повременную оплату вам платит. Таких добрых все меньше и меньше. Я сейчас, вообще, таких не вижу.

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

Это почему важно? Потому что, если действовать напролом: у меня есть ТЗ, и я его сейчас его сделаю. Хорошо, пройдет большой промежуток времени, в конце выявляется, что то, что вы сделали, мягко говоря, заказчику не нужно. Он отказывается за это платить. Это называется — мы реализовали самый максимальный риск на всю «катушку», в полной сумме контракта. Это вряд ли кому-то понравится.

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

Содержание проекта

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

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

Беда в том, что этим опытом трудно воспользоваться, потому что мы сделали для заказчика что-то, у нас в договоре написано, что все, что мы реализовали за это время за его деньги, является его интеллектуальной собственностью. Мы сделали — он забрал. Я понимаю, что какие-то исходники могут остаться, но в принципе – это его. Более того, если человек, который у нас это разрабатывал, перешел в другую компанию — все. Если вы занимались программированием — понимаете: «копаться» в коде другого человека — это себе дороже. Проще разработать заново, чем понять, как человек думал в предыдущем проекте. Отсюда возникают затраты времени на повторное создание того, что мы уже делали многократно.

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

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

Дальше я попробую подробнее объяснить, что мы тут предлагаем. Какие мы видим проблемы со стороны заказчиков. Поскольку я работаю в службе маркетинга, занимаюсь продажами — нахожусь на «переднем» крае. Обратную связь от заказчика мы получаем в первую очередь.

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

Рынок специалистов не так уж широк. Они, как правило, востребованы, чем-то заняты. Когда вам кто-то нужен, найти это не так-то просто и если вы нашли, то это не очень дешево. Мы видим, сложности интеграции. Почему? Потому что количество и разнообразие источников все время увеличивается. Надо за этим следить, появляются источники с какими-то нюансами. Они бывают между собой связаны. За этим тоже надо постоянно следить. Нужно привлекать людей определенной квалификации, которые в состоянии в этом забраться.

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

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

Потому что все мы люди, мы как-то коммуницируем. В процессе коммуникации искажаем информацию, даже когда этого не хотим. Потому что заказчик думает — у него один образ мышления, он что-то нам сказал. Мы что-то услышали, что-то не услышали, что-то поняли, что-то поняли не так. В итоге то, что мы сделали практически никогда на 100% не является тем, что у заказчика в голове.

То есть всегда есть различия, какие-то искажения в процессе. Мы подумали о том, что, если бы заказчик со своим мышлением мог сам этот созданный продукт адаптировать к своим процессам, было бы куда проще. Ему не надо было бы никому ничего объяснять. Это человек, который его слышит, ему не надо было ничего понимать, ничего искажать. И не ошибаться в процессе выполнения требования заказчика.

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

Вы видите перечень факторов. Они перекликаются напрямую с перечнем проблем, о которых я только что говорил. Начну по порядку: простота использования. Алексей в презентации (кто был в общей секции, вы слышали), он приводил пример простого продукта: это продукт компании Microsoft — Excel. Известный нам всем.

Я думаю, что все с этим продуктом знакомы, все им пользуются. Чтобы построить этот график, мы условно для себя за 100% доступности для пользователя имели в голове именно продукт такого класса, который может открыть любой, даже школьник, и сделать какие-то элементарные операции. Он все равно это сможет сделать.

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

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

Поэтому Loginom нами был задуман, как продукт, который мог бы освоить человек, с минимальным количеством специальной подготовки. Как проходит «входное» тестирования при поступлении на работу в нашу компанию. По документам понятно, что человек обучился в техническом вузе, значит, у него как минимум четыре семестра высшей математики есть, значит, он не будет «лазить» в словарь, читая, что мы будем показывать на экране. Он проходит внутреннее обучение, по курсу бизнес-аналитики в течение 10 дней, максимум – 14, и — все, после этого он приступает к работе. Так было у нас с аналитической платформой Deductor.

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

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

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

Следующий тезис – удобство интеграции. Сейчас на слайде приведена круговая диаграмма из журнала Forbes. Журнал провел опрос бизнес-аналитиков. Вопрос был такой: «По вашему мнению, какие этапы проекта, сколько процентов времени занимают». Был получен такой ответ: самая большая часть и следующая за ней, соответственно, — это сбор данных и очистка данных их структурирование, вместе занимают порядка 80% времени.

Мы, прикладывая на себя эту картинку, можем с этим согласиться. На самом деле, эти два интеграционных этапа, занимает порядка 80% времени. Мы подумали, о том, что есть ли смысл прилагать какие-то сверхусилия, допустим, оптимизировать этапы улучшения алгоритмов или поиска каких-то ключевых закономерностей. Один занимает 9%, а другой 1 или 4%. Они занимают мало времени и так, и даже если мы эти этапы оптимизируем наполовину, в общем, времени проекта — это будет ничтожно малой величиной. Отсюда простой вывод — надо оптимизировать этапы, которые занимают львиную долю.

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

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

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

По поводу веб-сервиса я немножко забежал вперед, сказал, что буквально так: мы выбираем сценарий, который хотим сделать доступным для своих сотрудников в другой организации; выбираем, где мы хотим его опубликовать, нажимаем кнопку «опубликовать». Все. Мы получаем ссылку, которую мы можем отправить, кому считаем нужным, и он по этой ссылке может зайти внутрь нашего сценария и делать там ровно то же, что и мы. Такие возможности есть у Loginom.

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

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

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

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

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

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

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

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

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

В качестве примера хотелось привести такую вещь… (Я немножко сказал уже о прикладных решениях, которые компания разрабатывает). Они сами по себе полезны еще чем? Эти повторяющиеся вещи, нами разбиты на некие модели.

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

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

Мы хотели сохранить максимальную гибкость платформы, насколько это возможно. Я до сих пор говорил о работе со стандартными компонентами: вы берете что-то готовое, нами сделанное, и дальше мы будем говорить о том, что это готовое может быть и вами сделано. Но мы говорили о верхнеуровневых вещах.

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

Поэтому осталась возможность «спуститься» на уровень ниже. Здесь скриншот обработчика калькулятора. В калькулятор у нас «забита», вообще, вся возможная математика, которая есть. По крайней мере, что есть в Excel. Она точно там есть, плюс какие-то наши вещи, в общем, там больше чем в Excel. Если вам не хватает наших стандартных обработок, пожалуйста, — здесь вы можете реализовать дополнительную логику на уровне формул.

Более того, существует третий уровень. Если вдруг оказывается, что вы и таким путем не можете реализовать ту логику, которая вам нужна, вы можете «опуститься» на уровень кодирования. В Loginom можно на JavaScript писать свой код. Там уже гибкость максимальная, там ниже «спускаться» некуда. Вы понимаете — все возможности есть.

Создание компонента. Реализация собственной бизнес-логики.

Если вы создали в Loginom что-то полезное и чувствуете, что вам это когда-то пригодится в будущем, вы можете это зафиксировать, назвать как-то и положить в библиотеку готовых компонентов. Я не знаю, много ли здесь представителей представители финансовых структур… Пример хотелось привести достаточно простой: банки и микрофинансовые организации часто используют в своей работе оценку кредитоспособности заемщика по определенным бизнес-правилам, но сейчас это называется «процедура андеррайтинга». Когда «забиты» какие-то простые правила, допустим, возраст заемщика не менее 18, и не более 80… Паспорт, который он предъявил, существует… И так далее... Такого уровня несложные правила.

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

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

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

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

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

Что здесь интересно: она сама по себе работоспособна. И наша открытость позволяет, если вас это заинтересовало, и вы это приобрели не только пользоваться, но и усовершенствовать это решение. Вы можете добавлять сюда блоки, можете «влезать» внутрь созданных нами сценариев, управлять, настраивать — адаптировать конкретно к вашим потребностям.

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

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

А вам критично, чтобы разбиралась там не меньше 90%. Но заранее скажу, что 100% не разбирает никто. Это в принципе невозможно. Так в жизни устроено, но стремиться к этому мы обязаны. Поэтому возникает такой вопрос: вы об веб-сервис «ударились», он вам какой-то ответ дал, он вас может устраивать, может не устраивать. Хорошо, если он вас не устраивает, что вы будете делать, непонятно. Здесь решение что-то выдает, тоже 100% не почистит – сколько-то выдаст. Внизу есть ветка «отправка на ручной разбор».

Никто не мешает, если есть желание увеличить количество разобранных адресов, вставить туда дополнительную подмодель, внутри «зашить» какую-то более сложную логику разбора, и тогда у вас уменьшится объем ручной работы. То есть из этих 30 неразобранных адресов вы разберете еще 15–20 автоматически, и на ручной разбор у вас отправится 10. То есть человек, которому работу поручат, получит в 3 раза меньше работы. И он соответственно быстрее с этим справиться.

Системы принятия решений о выдаче кредита.

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

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

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

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

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

Оптимизация запасов: расчет рекомендованных заказов

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

Это решение разбито нами на отдельные компоненты, даже — на этапы, и все это «засунуто» в библиотеку. Вы можете таким же путем, как я рассказывал о системе принятия решений, пробовать компоненты, насколько они полезны конкретно для вас. Вы можете попробовать разные инструменты прогнозирования. Вы можете использовать какие-то вспомогательные вещи, допустим, — восстановление спроса при отсутствии продаж, хотите используйте, хотите – нет. Тут же вы можете смотреть: вам приносит этот какой-то гешефт, или не приносит. Берете ли вы это в систему или не берете.

Я хочу вас поблагодарить за внимание. Хочу вас призвать использовать Loginom и добиваться новых успехов. Спасибо!