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

Все бы ничего, только с помощью такого отчета сложно управлять. Анализировать – можно, если есть куча свободного времени. А у кого есть куча свободного времени? У аналитика есть, например. Ладно, если он по должности аналитик. Есть ведь по призванию души аналитики. Должность у него, например, менеджер по продажам, но продавать он не хочет или не умеет, а вот в цифрах ковыряться – милое дело.

У руководителя времени на ковыряние в отчете, увы, нет. По крайней мере, в рамках регулярного менеджмента. Ему нужна короткая, емкая информация, отвечающая на простой вопрос: как идут дела? Или по-другому: у нас все хорошо?

Как на такой вопрос ответить с помощью портянки? Да никак. Портянка как бы говорит руководителю: ты хотел информацию? Ну вот она. ВСЯ! Давай, разбирайся, и ищи ответ на свой вопрос.

Если руководитель докапывается до программиста со своей задачей, тот пытается «помочь». Например, делает отчет план/факт продаж. Красивый, удобный, настраиваемый. Там можно не просто сравнить план с фактом, а еще и факт с фактом за разные периоды, и вообще – любое количество таблиц. Что получается в итоге? Еще одна портянка, только более сложная.

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

Ок, программист, скрепя сердце, и скрипя костями, настроит отчет сам. И скажет: все, на, подавись. Вслух не скажет, конечно, но подумает. Все, счастье наступило?
Нет. Во-первых, с первого раза не настроит – придется сбегать несколько раз. Либо писать хорошее, качественное тех.задание. А это, почти всегда, невозможно, потому что руководитель на берегу не знает, в каком виде ему нужен отчет.

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

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

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

Руководитель захочет смотреть отчеты удаленно, через интернет. Желательно – со смартфона. Это же так удобно – хоть на обеде, хоть в пробке, хоть на скучном совещании. Программисту опять придется расстараться.

В-четвертых, отчетов-то несколько получилось. Каждый отвечает на свой вопрос. Каждый надо открывать и смотреть отдельно. Один открыл, второй закроется. Максимум – сделал сплит-скрин и увидел два сразу.

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

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

А если отчетов три? Или четыре? Получается задница-с. Руководителю ничего не остается, кроме традиционного просмотра отчетов – одного за другим, на полном экране.

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

А в чем проблема-то? И есть ли она?

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

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

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

Друзья программисты. Я тоже программист. Я тоже люблю делать портянки. Это просто, интересно, даже по-своему красиво. Но портянки не годятся для управления.

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

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

Это невероятно интересно. И это все легко поддается алгоритмизации. Принцип очень простой – воронка «а что, если?».

Вот есть у нас план и факт продаж – отдельные таблицы с данными. Рисуем два отчета – план и факт продаж.

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

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

А что, если пересчитывать план на текущий день? Ведь мы вывалили в первый столбик весь месячный план, и факт его догонит только к концу месяца. В течение всего месяца, глядя на диаграмму, руководитель будет думать, что все плохо. Или ему придется в уме прикидывать, какая часть месяца уже прошла. Нет, давайте выводить не весь месячный план, а его часть. Десятого числа – одну треть, пятнадцатого числа – половину, и т.д. Тогда диаграмма станет понятнее и интереснее.

А что, если мы раскрасим столбики в зависимости от того, хорошо все или нет? Мы ведь знаем, хорошо план выполняется, или нет – надо лишь две цифры сравнить. Сделаем столбик красным, если все плохо. Желтым – если опасно. Зеленым – если хорошо.

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

А что, если вообще убрать диаграмму? Мы же почти все столбики уже попрятали, в чем смысл диаграммы, как способа представления информации тогда? Выведем короткую табличку, в которой будут только проблемные группы номенклатуры – желтые и красные. Ну и цифры, процент выполнения плана.

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

А что, если ему не нужна информация по некоторым номенклатурным группам? Ну вот знает он, что не продаются они, и всегда будут или красными, или желтыми. Чего зря человека дергать ненужными сигналами? Убираем.

А что, если мы будем сообщать не перечень плохих групп, а одну строчку – все хорошо или все плохо? Зная важность конкретных номенклатурных групп, и общий план продаж, введем весовые коэффициенты и простенькую функцию, которая будет вычислять ответ на вопрос: у нас все хорошо? Неинтересным группам дадим коэффициент 0.1, интересным – 0.5 или 0.7, и все, получается у нас одна большая, красивая цифра. Если основная группа продается хорошо, то у нас все хорошо.

А что, если дать руководителю две разные цифры? Ведь понятно, что задачи по разным группам могут быть принципиально разными. Например, основная группа – это тупо вал продаж. А вот группа с новой номенклатурой, например – новым оборудованием – вала не дает и давать не может по определению. Там благом считается одна-две продажи в месяц. Понимаете? Даже не сумма важна, а количество. Продали единицу нового оборудования – уже праздник! Если работать только с суммами, то эта единица нового оборудования всегда будет прятаться среди основной номенклатуры. Нам это зачем? Пусть будет две цифры: как идут дела по основной линейке, и как идут дела по новому оборудованию. Разные критерии оценки, разная шкала.

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

А что, если учитывать два фактора: и план/факт в конкретной точке, и динамику за последние дни? Оно ведь как бывает. Первого числа месяца сделали большую отгрузку – сразу 20 % месячного плана. И все наши диаграммы в течение шести дней будут показывать, что все хорошо. А на самом деле, у нас продажи встали колом – ни одной отгрузки почти неделю. С формальной точки зрения все неплохо, но мы же тут не для формальностей собрались? Руководитель должен знать, что менеджеры балду пинают, не удерживая динамику продаж. Для нас ничего сложного нет – мы просто в функцию добавляем еще одну переменную, динамику продаж, со своим весовым коэффициентом. И все, красота.

А что, если мы в нашей функции учтем не только план/факт продаж, но и план/факт движения денег? Выведем руководителю бесконечно прекрасную цифру, или человеко-читаемую строку – «все хорошо», «продажи хорошо, деньги – так себе», «продажи 120 %, деньги 90 %» и т.д.

А что, если…

Так можно продолжать до бесконечности. Главное – вовремя остановиться, и дать руководителю воспользоваться инструментом, привыкнуть к нему, сформулировать обратную связь. Я, как программист, понимаю – при решении задач по воронке «а что, если?» возникает неудержимое желание сделать проще, лучше, информативнее, полезнее. Надо уметь себя останавливать.

Главное – воспринимать эту задачу, как инженерную. Потому что она таковой и является. Это не красивости или бантики, это – построение системы управления.

Руководитель сам с такой задачей не справится, увы. Он не знает всех возможностей, всех данных, всех взаимосвязей. А программист – знает. Но молчит.

Давайте, вылезайте из своего темного угла. Вы, программисты, можете принести невероятную пользу управлению компанией. Вы – инженеры. Система управления, автоматизация менеджмента – это инженерная работа. А руководитель будет ее пользователем. Он будет осуществлять управление с помощью вашей системы.

Комментарии (25)


  1. zharikovpro
    05.03.2019 20:12
    +2

    > А в чем проблема-то? И есть ли она?

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


    1. eugene_bb
      05.03.2019 20:59
      +1

      Это называется «иллюзия контроля», это любят начальники нижнего-среднего звена.

      Высшее руководство любят дашбоарды.

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


      1. kapash
        06.03.2019 17:26

        Высшее руководство любят дашбоарды.

        Ну да она красивая и на мобильном гаджете смотреть можно. Поиграться и бросить )
        Только вот всё равно потом секретарь Маша приносит отчёт в Exсel — потому что, Маша так привыкла да и данные точней могу быть.
        Зато дашборды хорошо пендалей развешивать на совещаниях. Ой смотрите прибыль упала, роста нет и все побежали что-то делать. Неважно что, главное что побежали)


  1. Anei
    05.03.2019 20:49
    +2

    А в чем проблема-то? И есть ли она?

    Есть, и очень простая: программист слишком любит портянки.


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


  1. saipr
    05.03.2019 20:59

    У руководителя времени на ковыряние в отчете, увы, нет. По крайней мере, в рамках регулярного менеджмента. Ему нужна короткая, емкая информация, отвечающая на простой вопрос: как идут дела? Или по-другому: у нас все хорошо?

    Ключевые слова здесь: времени на ковыряние нет, нужна коротная и емкая информация, как идут дела.
    При чем здесь портяники — Загадка. Отчитывается портянками руководитель проекта, который может спросить у Программиста только что "мы не срываем сроки, укладываемся в календарный план" и все. Я не видел программистов, которые бы писали портянки отчеты!


  1. alexkuzko
    05.03.2019 21:00
    +5

    Не мог отделаться от мысли зачем такой руководитель, функции которого в этой парадигме выполняет… программист?


    1. dimkss
      05.03.2019 22:12

      [del]


    1. Palich239
      06.03.2019 08:29

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


  1. vadim_bv
    05.03.2019 22:09
    +1

    BI (например, но не обязательно, от Oracle)? Не, не слышали?


  1. dimkss
    05.03.2019 22:13
    +1

    Вы хорошо пишете, только я перестал понимать для кого эта статья.

    Для программиста который значительно лучше руководителя понимает какая руководителю нужна инфа?
    Тогда он просто сделает отчет какой лучше и все.

    Для программиста который не понимает какая руководителю нужна инфа?
    Так он и дальше не будет понимать, ведь для понимания нужно все это (планы, факты, пересчеты, номенклатуры, пересчеты и и т.д. и т.п.) понимать.

    Статья только для 1С-ников?


    1. GreyStrannik
      05.03.2019 23:33

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

      P.S. Взгляд прошаренного 1С-ника на Data Science и как его можно подать доставляет, да.


      1. dss_kalika
        06.03.2019 10:03

        Статья для тех, кто хочет заниматься не только своими, но и чужими обязанностями. (аналитика, менеджера и руководителя).

        К сожалению, обычно эти обязанности не приносят с собой денег вообще (зачем?).


      1. yudinetz
        06.03.2019 10:37
        +1

        Назовите вашу компанию, я так понял у вас дают +50% зп за скилл «умение клепать отчеты». Ближе к пенсии к вам перейду, когда мне уже пофиг будет на свою карьеру.


    1. qw1
      06.03.2019 10:51

      для кого эта статья
      Явно статья написана с оглядкой на реалии 20-летней давности, когда на заводе есть 2 тыж-программиста, которые могут заниматься чем хотят в перерывах между заменой картриджей.

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

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


  1. nuclight
    06.03.2019 01:07

    Анализировать – можно, если есть куча свободного времени. А у кого есть куча свободного времени? У аналитика есть, например. Ладно, если он по должности аналитик. Есть ведь по призванию души аналитики. Должность у него, например, менеджер по продажам, но продавать он не хочет или не умеет [...]
    У руководителя времени на ковыряние в отчете, увы, нет. По крайней мере, в рамках регулярного менеджмента. Ему нужна короткая, емкая информация, отвечающая на простой вопрос: как идут дела? Или по-другому: у нас все хорошо?
    [...] Портянка как бы говорит руководителю: ты хотел информацию? Ну вот она. ВСЯ! Давай, разбирайся, и ищи ответ на свой вопрос.
    [...] Либо писать хорошее, качественное тех.задание. А это, почти всегда, невозможно, потому что руководитель на берегу не знает, в каком виде ему нужен отчет.
    [...]
    Чтобы узнать, как дела, надо включать компьютер. Еще до него дойти нужно. Если руководитель такой, что весь день сидит за компьютеров, то проблемы нет. А много таких руководителей?
    Руководитель захочет смотреть отчеты удаленно, через интернет. Желательно – со смартфона. Это же так удобно – хоть на обеде, хоть в пробке, хоть на скучном совещании.


    Простите, а что за херней вместо работы страдает вот это самое говнецо, описанное в цитате как «руководитель» (курсивом выделена самая жесть)? Чем оно вообще занимается вместо своих прямых обязанностей? Штаны «на скучном совещании» просиживает?

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

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

    Ну и да, «дойти до компьютера»? В 2019 году? В конторе, где имеется программист (ладно бы еще речь шла о прорабе на стройке)? Серьезно?

    Руководитель сам с такой задачей не справится, увы. Он не знает всех возможностей, всех данных, всех взаимосвязей. А программист – знает. Но молчит.


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

    Давайте, вылезайте из своего темного угла. Вы, программисты, можете принести невероятную пользу управлению компанией. Вы – инженеры. Система управления, автоматизация менеджмента – это инженерная работа. А руководитель будет ее пользователем. Он будет осуществлять управление с помощью вашей системы


    Вот! Вот оно, собственно, ключевое — в описанной ситуации, как, собственно, и в большинстве случаев т.н. Эффективных Менеджеров (tm) — оные менеджеры суть просто дармоеды и паразиты, и в нормальной системе вовсе не нужны. Как и задумывался коммунизм (не что «хотели как лучше, получилось как всегда» в этой стране в XX веке, а как ожидалось), что управленцы не «максимизируют прибыль», а собственно решают инженерную задачу управления (и много их таких не требуется).


  1. michael_vostrikov
    06.03.2019 08:36
    +2

    Программисты любят рисовать отчеты-портянки

    Ваши программисты любят рисовать отчеты-портянки.


    в большинстве случаев информационная система – десктопная.

    У вас в большинстве случаев информационная система – десктопная.


    Каждый надо открывать и смотреть отдельно. Один открыл, второй закроется.

    У вас надо каждый открывать и смотреть отдельно.


    В десктопных системах их даже полистать нельзя

    В ваших десктопных системах.


    сразу появляются полосы прокрутки – даже если за видимой областью экрана ничего нет

    У вас появляются полосы прокрутки, даже если там ничего нет.


    Есть, и очень простая: программист слишком любит портянки.

    Есть, и очень простая: в 1С хреновый интерфейс системы отчетов. А еще кто-то пытается спихнуть свои обязанности руководителя по принятию решений на рядовых программистов.


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


  1. Cassiopeya
    06.03.2019 08:59
    +2

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


  1. paranoya_prod
    06.03.2019 10:25

    Хм, наша система уже сама определяет, что идёт хорошо и что идёт плохо, сама анализирует… Зачем нам тратить ресурсы на разработку графиков и отчётов? Давайте запилим базу знаний и ИИ, тогда руководитель не нужен. Экономии денег на ФОТе будет больше, плюс решения будут приниматься сразу, а не «завтра может посмотрю». И серых схем по обогащению руководящего состава тоже. Нужен только собственник, который выставит нужные циферки плана на год и всё, за всем остальным будет смотреть ИИ.
    Но это только начало — отдел маркетинга, зачем там столько людей? Все каналы продаж уже известны, формулы расчёта ROI известны. Стратегии развития известны и всё это давно фомализовано — бери и делай ИИ-маркетёра, который не только умеет по известным методам работать, но и мониторить новые идеи маркетинга, собирать данные, анализировать и внедрять на предприятии. Ну, можно оставить одного реального человека, который сам умеет генерировать идеи. А ИИ будет их просчитывать.
    Так, HR — мы все знаем, что HR-человек не нужен, схемы приёма есть, законы в трудовом кодексе прописаны. Всё, весь HR-отдел под увольнение. Написать собеседовальщика — это как два пальца — боты уже диагнозы медицинские ставят, что говорить о HR-ботах?
    Что та дальше? О! Бухгалтерия! Зачем нам там люди? Первичку вносят продажники, а система сама всё делает и это уже давно так, бухгалтер в наше время — это вносильщик данных в систему.
    Не хилая экономия на ФОТе вырисовывается.


  1. molec
    06.03.2019 11:03

    Я до последнего ждал рекламы очередного BI Tableau etc.
    Реальных проблем в этой ситуации несколько, по-моему.
    Руководитель не знает, какие данные ему нужны, чтобы руководить. До определенной степени это даже нормально, если бы он не делал крайним в этой ситуации программиста. Заковыка в том, что если он точно знает, какие данные ему нужны, то и знает список ситуаций, которые он в них ищет. А значит это автоматизируемая работа, достаточно объяснить, в каких случаях присылать большое красное письмо «здесь неОК», письмо «здесь все ОК» не то чтобы необходимо.
    Но руководитель правильно в общем-то боится пропустить нестандартную ошибку/проблему. И в общем-то понятно, что он не знает, как искать что-то нестандартное. Но при чем здесь программист все равно непонятно.

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


    1. kagarich
      06.03.2019 12:14

      Руководитель не знает, какие данные ему нужны, чтобы руководить.

      Странный руководитель.
      Обычно руководителю для его работы нужно три документа-отчета — БДДС, БДР и БИР.
      Все остальное — продажи, остатки на складах, маркетинг и т.п. — суть исходные для вышеназванных отчетов.


      1. molec
        06.03.2019 13:21

        Руководители бывают разных уровней. И задачи бывают у них разные. Не думаю, что мои руководители знают эти аббревиатуры.


    1. kapash
      06.03.2019 17:28
      +1

      Я до последнего ждал рекламы очередного BI.

      нас двое


      1. qw1
        06.03.2019 20:07

        Тоже мелькали мысли — можно это делать на MS SQL Analysis Services. Но от этого автора я определённо не ждал упоминания готовых инструментов. Если он велосипедит таск-трекер на 1с, куда ему до таких софтин.


  1. Materializator
    06.03.2019 11:19

    Это статья о том, как вырасти из программистов-на-кириллице в ключевые сотрудники предприятия.


  1. Laser42
    07.03.2019 09:27

    У руководителей как раз постоянно меняется фокус. Поэтому автоматизировать весь процесс подготовки отчёта невозможно. Я уже молчу про то, что обычно голых цифр мало — нужен комментарий, почему показатели поменялись и в целом что происходит на рынке, т.е. грамотный текст, написанный аналитиком