Деревянность решений, или Есть ли пределы совершенству

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

На старте было дано:

1. Торговая компания, занимающаяся продажей стройматериалов.

2. Три небольших склада (они же офисы продаж, тысяч по 8–12 «квадратов») в радиусе до 30 км от города.

3. Самописная торговая система (централизованная) плюс всем известная бухгалтерия, частично с ней интегрирова.

4. Ярко выраженная сезонность продаж (как выяснилось, три летних месяца давали до 65% от годового оборота).

5. Довольно большое количество контрагентов (порядка 10 000).

6. Около 6000 активной номенклатуры.

7. Десяток единиц собственного автотранспорта от «газелей» до длинномеров и около полусотни привлеченного.

8. Ну и конечно, гигантские планы по развитию.

Остальное — примерно как у всех. Еженедельно у генерального собирались директора по направлениям, а также директор по логистике генеральный и финансовый; каждый приносил свою распечатку (листов на 15–20) из самого распространенного табличного редактора, куда сведения, поступившие из торговой системы и бухгалтерии, вручную заносили сотрудники подразделений. Далее происходило обычное совещание на тему выполнения планов продаж, где у каждого из участников была «своя правда». С использованием местных идиоматических выражений, периодическим переходом на личности и общим повышенным звуковым фоном. Заканчивались они, в общем-то, ничем, то есть генеральный принимал решения на основании собственной мудрости и раздавал кому что считал нужным. Решения в такой ситуации были, естественно, достаточно «дубовыми», часто опаздывали.

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

И «вот это все», в общем, не сильно управляемое хозяйство, позволяло «держать» до 40% своего сегмента рынка. То есть у остальных «деревья решений» росли еще интереснее…

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

Про ИТ-архитектуру

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

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

Что и привело к примерно такой ситуации: в очереди постоянно стояло 10–20 разнообразных отчетов, иногда отличающихся одним-двумя полями (без которых, конечно же, невозможно работать), в системе уже было около 1200 готовых отчетов, из них регулярно использовалось в лучшем случае 100. И «слегка уставшие» от этого, вечно виноватые во всем программисты...

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

========================

Кстати № 1

Как показала дальнейшая практика работы на других проектах, вопросы производительности различных систем — это какая-то эпидемия. И как показала та же практика, «лобовое» решение вопроса путем «умножения железа» в два, три и более раз далеко не всегда является оптимальным, а чаще и почти бесполезным — бывает, что удвоение параметров «железа» может ускорить работу собственно программы на 5–10%, а то и меньше. Опыт на эту тему был весьма разнообразный.

И исследования производительности одной из самых больших систем консолидации отчетности при использовании виртуализации. Когда выделенный под задачу консолидированной отчетности «железный» сервер (около 512 процессорных ядер и несколько терабайт RAM) был явно избыточен и его, естественно, виртуализировали. Не будем показывать пальцем, но производителем системы виртуализации было официально признано, что при большом объеме выделенных виртуальной машине ресурсов (что-то вроде 256 ядер и 1 Тбайт памяти и выше) производительность виртуальной машины вовсе не растет, а деградирует. Кто бы мог подумать... И выделение под отчетную базу терабайтного размера (целой отрасли нашей экономики) чуть ли не обычной персоналки. В режиме в energo save... И «окончание» производительности весьма известной ERP-системы при нагрузке в 25% от плановой на «железе» в конфигурации, больше напоминающей суперкомпьютер даже сейчас.

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

==========================

Сотворение системы

Проблема смены торговой OLTP-системы была слишком серьезной и сложной на данном этапе – нужно было переделывать все процессы и переучивать всех, включая продавцов. После некоторых технических экспериментов и расчетов «лобовое» решение вопросов производительности «железом» признали неперспективным: прогнозы объемов транзакций в торговле и потребностей в аналитике (с учетом дальнейшего запуска процессов транспортной логистики и CRM, а также трех складов и десятка-двух розничных магазинов) и текущей двухзвенной архитектуре со 100%-ной загрузкой логики сервера базы данных говорили, что через два-три года понадобится сервер размером с холодильник. И в отказоустойчивом исполнении. И без гарантий этой самой производительности хоть в какой-то дальнейшей перспективе.

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

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

Читайте также

Как установить банковские приложения на iOS, удаленные из App Store?

Как установить на iOS приложения российских банков? Если на Android проблема решается в два свайпа, то на iOS придется сделать чуть больше движений. IT-World узнал, каких именно.

Ударной силой и «двигателем прогресса» стали, понятное дело, маркетологи, товарные логисты и, естественно, генеральный директор. Наконец-то увидевший маржу по сделке через час после ее совершения и в первичных документах. А не 15–20 числа следующего месяца и в виде сводной отчетности, полученной от финансистов, закрывших бухгалтерский период.

Опыт – сын ошибок трудных

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

Вторыми «противниками прогресса» стали транспортники. Вечно заваленные заказами продавцов на доставку и вечно не успевающие. Но после выяснения двукратного несоответствия плановых и фактических пробегов собственных водителей — все вопросы с их стороны тоже были сняты.

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

Сезон был отработан без особенных вопросов, коллектив ИТ-инженеров наловчился открывать новую площадку спустя два-три дня после ухода строителей. С монтажом СКС, видеонаблюдением, СКД и прочим.

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

==========================

Кстати № 2

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

В случае использования технологий типа OLAP c определенного момента времени количество запросов на отчетность резко падает и наступает «насыщение». Людям уже достаточно имеющейся информации для обоснования и принятия решений. Собственно, последующая разница между количеством запросов на отчеты и является разницей в стоимости систем «обычной» и «динамической» отчетности. При горизонте планирования в несколько лет — разница в ФОТ будет заметна невооруженным глазом. См.график 2.

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

==========================

Результаты работы

Что же изменилось в работе людей после всех этих технологических новшеств? Каким стало это самое «дерево решений» в конкретном примере?

Ежедневно в 18:15 нагрузка на систему отчетности была пиковой: к этому времени обновлялась информация по продажам за отработанный день и весь коллектив дружно смотрел на результаты.

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

Выяснилось, что директора настроили себе в табличном редакторе по 10–12 графиков и работали с ними. И этого оказалось достаточно...

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

?     Клиент должен нам или мы ему?

?     Какова суммарная дебиторская задолженность, по группе юрлиц и по каждому отдельно?

?     Оборачиваемость дебиторской задолженности клиента?

?     Кредитная история? Сколько чего и когда ему уже выдавали? Когда было оплачено?

?     Доходность клиента? Сколько маржи с него на данный момент, по каким товарам, какая была за какие периоды?

Читайте также

Ключевая ставка ЦБ РФ: ждем 25%?

Две недели, оставшиеся до очередного решения ЦБ РФ по ключевой ставке, эксперты продолжат строить прогнозы. Подавляющее большинство уверено – ставку повысят, и все ожидания сходятся в пределах 22-25%. Оптимистов, ожидающих сохранения ставки на текущем уровне, почти нет. Как будут развиваться события, мегарегулятор оценит в феврале 2025 г.

?     Дисконтированная доходность клиента? Есть ли запросы от других клиентов на то же самое, но более доходных?

?     Надежность клиента. Нет ли новостей о его кредитоспособности?

?     Условия кредитования. Что можем предложить, по какой колонке прайса, какая скидка или наценка на всю сумму поставки?

Ну еще ряд более специфических вопросов, если клиент не «стандартный».

И все это директор по продажам выяснял, не вынимая телефон из уха и глядя в экран, можно сказать «online». Обычно минут 15 было достаточно, чтобы поставить на документе в торговой системе пометку «отгрузка в кредит разрешена». В худшем случае общее собрание директоров разных товарных направлений выносило заключение к вечеру. Решения утрачивали прежнюю «деревянность», само «дерево решений» обросло ветками и обрело большую гибкость, не потеряв при этом цельности. Мотивы решений были однозначно понятны всем участникам процесса: дебиторка оборачивалась быстрее, число безнадежных кредитов сократилось, торговаться с клиентами стали быстрее в десятки раз и более аргументированно. Количественно это выражалось в очень круглых суммах.

Финишная черта

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

В итоге выяснилось, что до момента «хватит» в конкретной торговой компании достаточно собрать примерно 30 различных событий в 45 аналитиках. Причем аналитикой является, например, 6-этажный справочник номенклатуры, а событием — телефонный звонок. Правило Парето сработало в чистом виде:— приведение в порядок 20% наиболее значимой информации дало 80% управляемости. Дерево выросло.

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