Программисты любят рисовать портянки.
Если вам нужен отчет о продажах, они выгрузят всю таблицу продаж с указанием контрагентов, товаров, организаций, контрактов, сумм и объемов.
Все бы ничего, но управляться с помощью такого отчета сложно.
Анализировать можно, если у вас много свободного времени.
У кого много свободного времени? У аналитика, например.
Хорошо, если он по должности аналитик.
Есть ведь аналитики по призванию.
Должность у него, например, менеджер по продажам, но он не хочет продавать или не умеет продавать, а вот ковыряться в цифрах - занятие приятное.
К сожалению, у руководителя нет времени возиться с отчетом.
По крайней мере в рамках штатного управления.
Ему нужна короткая, емкая информация, отвечающая на простой вопрос: как идут дела? Или другими словами: все ли у нас хорошо? Как ответить на такой вопрос с помощью портянки? Ни за что.
Портянка как бы говорит менеджеру: вам нужна была информация? Ну вот она.
ВСЕ! Давай, разбирайся и ищи ответ на свой вопрос.
Если менеджер докопается до программиста со своей задачей, он старается «помочь».
Например, составляет план продаж/фактический отчет. Красивый, удобный, настраиваемый.
Там можно не только сравнить план с фактом, но и факт с фактом за разные периоды, и вообще - любое количество таблиц.
Какой результат? Другая портянка, только более сложная.
Если еще раз докопаться до программиста, он скажет: блин, давай настрой отчет под себя, а настройку сохрани.
Фильтруйте данные, выбирайте период, чтобы отображались только нужные вам данные.
Ну, как вариант, сойдёт. Но только в том случае, если менеджер знает, как все настроить.
Что, если он не сможет? Ок, программист неохотно и скрипя костями настроит отчет сам.
А он скажет: все, подавись.
Он, конечно, не скажет этого вслух, но подумает. Всё, счастье пришло? Нет. Во-первых, с первого раза не настроится - придется пробегать несколько раз.
Или написать хорошее, качественное техническое задание.
А это практически всегда невозможно, поскольку менеджер на берегу не знает, в каком виде ему нужен отчет. Пока у менеджера есть портянка, ему кажется, что достаточно настроить группировки, и он сможет управлять с помощью отчета.
Как только у него будут группировки, ему понадобится фильтр.
Получив фильтр, он поймет, что сортировка нужна.
И так далее.
Во-вторых, одного отчета недостаточно.
Менеджер заинтересован не только в продажах, верно? Вам также необходимо движение денег.
И работа сотрудников.
И просроченные заказы – как от покупателей, так и от поставщиков.
Вы получите несколько отчетов, каждый с одной или несколькими настройками.
В-третьих, в большинстве случаев информационная система является настольной.
Чтобы узнать, как идут дела, нужно включить компьютер.
Вам еще нужно туда добраться.
Если руководитель из тех, кто целыми днями сидит за компьютером, то проблем нет. Много ли таких лидеров? Менеджер захочет просматривать отчеты удаленно через Интернет. Желательно со смартфона.
Это так удобно – хоть в обед, хоть в пробке, хоть на скучной встрече.
Программисту снова придется потрудиться.
В-четвертых, было несколько отчетов.
Каждый отвечает на свой вопрос.
Каждый из них необходимо открывать и просматривать отдельно.
Один открылся, второй закроется.
Максимум — я сделал разделенный экран и увидел сразу два.
В десктопных системах их даже просмотреть нельзя, как на смартфоне — ну чтобы все отчеты валялись в одну длинную портянку, и можно было прокручивать пальцами сверху вниз.
Менеджер захочет видеть все отчеты на одном экране.
Это нормальное человеческое желание.
Но для программиста это ад. Обычный большой отчет, даже настроенный и отфильтрованный, хорошо смотрится только на полном экране.
Если сузить его вдвое, сразу появляются полосы прокрутки, которые портят все впечатление - даже если за видимой областью экрана ничего нет, рука сама тянется прокрутить вниз или в сторону, чтобы убедиться этого.
Что делать, если есть три отчета? Или четыре? Оказывается, это осел, сэр.
Менеджеру ничего не остается, как традиционно просматривать отчеты — один за другим, на весь экран.
Даже представление информации в виде схемы не помогает, если она отображается, как в 1С, в табличном документе.
Появляются одни и те же полосы прокрутки, масштабом диаграммы невозможно управлять разумно, эмоции зашкаливают. В чем проблема? И существует ли она? Есть, и очень просто: программист слишком любит портянки.
Его так учили, ему дали такую систему ценностей: вкладывай в отчет все, что имеешь, и даже больше.
И предусмотреть шикарный механизм регулировки.
Этот подход хорош для разработчиков пакетных решений, поскольку у них нет выбора.
Они не знают, какую информацию и в каком виде захочет видеть конкретный менеджер, поэтому делают накладки+настройку сами.
Но программисты есть на месте, т.е.
конкретные клиенты почему-то слепо следуют этой парадигме.
Они ведут себя так, как будто сами являются разработчиками пакетных решений.
И портянки делают все новые.
Товарищи программисты.
Я тоже программист. Еще я люблю делать обертывания для ног.
Это просто, интересно и даже по-своему красиво.
Но портянки для управления не подходят. Я не говорю, что с вами или с нами что-то не так.
Я просто предлагаю решить новую, интересную инженерную задачу: нарисовать небольшой отчет. Не большая портянка с тысячей строк, а маленькая табличка в два столбца и три строки.
Не огромный график, не помещающийся на экране, а крохотный с тремя столбиками, четко отвечающими на конкретный вопрос.
Не выбрасывайте кучу цифр, чтобы человек мог исходя из них ответить на вопрос, а дайте сразу ответ на вопрос – короткий, лаконичный, понятный.
Это невероятно интересно.
И все это легко можно алгоритмизировать.
Принцип очень прост: «А что, еслиЭ».
воронка.
Здесь у нас есть план и факт продаж — отдельные таблицы с данными.
Рисуем два отчета – план продаж и фактические продажи.
А что, если объединить их и нарисовать в одном отчете и план, и факт? Что ж, это неплохо.
Что если свернуть по группам элементов? Тогда отчет будет небольшим, по крайней мере по высоте.
Хорошо давай сделаем это.
А что, если тот же отчет нарисовать в виде диаграммы? Обычная гистограмма из двух столбцов.
Первое будет планом, второе фактом.
Смотришь и сразу понимаешь, где план выполняется, а где проваливается.
А что если пересчитать план на текущий день? Ведь мы весь месячный план свалили в первую колонку, а факт догонит его только к концу месяца.
На протяжении месяца, глядя на график, руководитель будет думать, что все плохо.
Или ему придется мысленно прикинуть, сколько месяца уже прошло.
Нет, давайте отображать не весь месячный план, а его часть.
В десятый день – одну треть, в пятнадцатый день – половину и т. д. Тогда схема станет понятнее и интереснее.
Что, если мы раскрасим столбцы в зависимости от того, все ли хорошо или нет? Мы знаем, хорошо реализуется план или нет — нам достаточно сравнить две цифры.
Сделаем полоску красной, если все плохо.
Желтый – если это опасно.
Зеленый – если все в порядке.
Что делать, если не отображать столбцы, где все хорошо? Например, если у нас есть диаграмма, разбитая по группам товаров.
Мы будем отображать только те, которые желтые или красные.
Ну и скажем менеджеру, что если колонки нет, то все в порядке.
Поймет ли он? Нужна ли ему информация, чтобы реагировать и принимать решения? Расставьте задачи, расставьте акценты, позовите кого-нибудь на ковер.
Так что пусть система говорит только о том, на что нужно реагировать.
Что, если мы вообще удалим диаграмму? Мы уже скрыли почти все столбцы, какой тогда смысл в диаграмме как способе представления информации? Выведем небольшую таблицу, содержащую только проблемные номенклатурные группы – желтую и красную.
Ну и цифры, процент выполнения плана.
Что делать, если вы вообще не отправляете отчет своему руководителю? Зачем заставлять его смотреть куда-то каждый день? Давайте сделаем так: если возникнет проблема, мы подаём ему сигнал.
Не мы, а система, которую мы разрабатываем.
Если появился желтый или красный цвет – пишем письмо, или Вайбер, или СМС, не важно.
Менеджер будет знать: если сигналов нет – все в порядке.
Не надо тратить время на анализ, лучше просто поработать, сделать что-нибудь полезное.
Конечно, поначалу он все равно зайдет и посмотрит — программистам не доверяет. Мало ли, вдруг письма прекратились.
Ну пусть ковыряется и привыкает. Что делать, если ему не нужна информация по некоторым группам товаров? Ну, он знает, что они не продаются и всегда будут либо красными, либо желтыми.
Зачем дергать людей ненужными сигналами? Давайте удалим его.
А что, если мы сообщим не список плохих групп, а одну строчку – все хорошо или все плохо? Зная важность конкретных групп товаров и общего плана продаж, введем весовые коэффициенты и простую функцию, которая рассчитает ответ на вопрос: все ли у нас хорошо? Неинтересным группам дадим коэффициент 0,1, интересным – 0,5 или 0,7, и все, мы получим одно большое красивое число.
Если основная группа хорошо продается, значит, дела у нас идут хорошо.
Что, если вы дадите менеджеру два разных номера? Ведь понятно, что задачи для разных групп могут принципиально отличаться.
Например, основная группа — это просто отдел продаж.
Но группа с новой номенклатурой, например, новым оборудованием, не дает и не может по определению дать никакого вклада.
Там одна-две продажи в месяц считаются благом.
Вы понимаете? Важна не сумма, а количество.
Продали единицу новой техники – уже праздник! Если вы работаете только с суммами, то эта новая техника всегда будет спрятана среди основной номенклатуры.
Зачем нам это надо? Пусть будет две цифры: как обстоят дела с основной линией и как обстоят дела с новым оборудованием.
Разные критерии оценки, разный масштаб.
А что, если сложить эти два числа в одно? Перепишем нашу функцию с весовыми коэффициентами, заменив абсолютные числа относительными.
Пусть основной товар рассчитывается по сумме, а новый — по количеству.
И все это переводится в проценты.
Потом весовые коэффициенты можно будет скорректировать — увеличить под новую номенклатуру, так как для нас это важно.
А что, если принять во внимание два фактора: и план/факт в конкретной точке, и динамику за последние дни? Вот как это происходит. В первый день месяца мы сделали крупную отгрузку - сразу 20% от месячного плана.
И все наши графики в течение шести дней покажут, что все в порядке.
Но на самом деле наши продажи зашли в тупик - почти неделю ни одной поставки.
С формальной точки зрения все неплохо, но мы же здесь не для формальностей, не так ли? Менеджер должен знать, что менеджеры бьют по пушкам, а не поддерживают динамику продаж.
Для нас нет ничего сложного — мы просто добавляем в функцию еще одну переменную, динамику продаж, со своим весовым коэффициентом.
И всё, красота.
А что, если в нашей функции мы учтем не только план/факт продаж, но и план/факт движения денежных средств? Дадим менеджеру бесконечно красивую цифру, или человекочитаемую строку - «все хорошо», «продажи хорошие, деньги так себе», «продажи 120%, деньги 90%» и т.д. Что, если… Это может продолжаться до бесконечности.
Главное — вовремя остановиться и дать менеджеру воспользоваться инструментом, привыкнуть к нему и сформулировать обратную связь.
Как программист, я понимаю, что при решении задач воронки вопрос «а что, еслиЭ» есть неконтролируемое желание сделать проще, лучше, информативнее, полезнее.
Вы должны уметь остановить себя.
Главное – воспринимать эту задачу как инженерную.
Потому что она такая.
Речь идет не о красивых вещах или бантиках, речь идет о построении системы управления.
Сам менеджер с такой задачей справиться, увы, не сможет. Он не знает всех возможностей, всех данных, всех связей.
И программист знает. Но он молчит. Давай, вылезай из своего темного угла.
Вы, программисты, можете принести невероятную пользу управлению компанией.
Вы инженеры.
Система контроля и автоматизация управления – это инженерная работа.
А его пользователем будет менеджер.
Он будет контролировать использование вашей системы.
Теги: #программирование #Визуализация данных #отчеты #автоматизация управления
-
Thinkpad X21: Между Прошлым И Будущим
19 Oct, 24 -
Идея Проекта
19 Oct, 24
