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