УправлениеИТ в бизнесе

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

Михаил Сусоров | 05.06.2017

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

Правило Парето сработало в чистом виде:— приведение в порядок 20% наиболее значимой информации дало 80% управляемости. Дерево выросло.

Недавно я посетил мероприятие СОДИТ, название одной из частей которого звучало примерно как «большие данные в банковской сфере». Во время докладов выступающие постоянно оперировали выражениями «поддержка принятия решений», «кластерный анализ», «правила сочетаний» и тому подобными применительно к банковской сфере, и у меня возникло довольно сильное дежавю. Я где-то уже наблюдал подобное, примерно лет 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 кубов. Попутно приведя в порядок справочники номенклатуры, контрагентов, сотрудников и прочие. Попутно отловив множество ошибок в первичных данных старых периодов. Попутно формализовав расчеты показателей. Попутно положив в кубы статистику с СКД, распределенного кол-центра и сотовых телефонов, прокси-сервера и принтеров… много чего еще общественно полезного было сделано «попутно». И вот, после завершения всех технических дел, обучения директоров и начальников отделов продукт был запущен в эксплуатацию.

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

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

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

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

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

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

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

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

Кстати № 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Темы:

Журнал: Журнал IT-Manager [№ 05/2017], Подписка на журналы

Об авторах

Михаил Сусоров

Михаил Сусоров

Член клуба 4CIO
Заведующий Центра правовой поддержки потребителей ИТ.


Поделиться:

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Также по теме

Мысли вслух

Мы много и часто говорим о том, что "ИТ меняют наш мир". Посмотрим, как это происходит в Китае с применением конкретных инструментов и затрагивает сотни миллионов человек.
Согласно прогнозам Gartner, к 2022 г. 75% организаций, использующих инфраструктуру как сервис (IaaS), будут реализовывать продуманную мультиоблачную стратегию, в то время как в 2017 г. доля таких компаний составляла 49%.
Все жалуются на нехватку времени. Особенно обидно, что его не хватает на самые важные вещи. Совещания, созвоны, подготовка внутренних отчетов, непонятно, насколько нужных, но которые начальство требует так, как будто это именно то, ради чего мы работаем.

Компании сообщают

Мероприятия

Apple Tech Business Week
Санкт-Петербург, IT-пространство для бизнеса Resonance Space
22.06.2021 — 24.06.2021
Выставка «EXPO-RUSSIA KAZAKHSTAN 2021»
Республика Казахстан
23.06.2021 — 25.06.2021
10:00–18:00
ЖКХ Будущего. Актуальные вопросы и решения
ОНЛАЙН
10 500 руб
24.06.2021 — 25.06.2021
10:00–18:00
XII форум инновационных технологий InfoSpace 2021
Москва, Космодамианская наб., 52/7, «Центр Цифрового Лидерства»
25.06.2021
09:00