Мне несколько раз приходилось сталкиваться с задачами, сформулированными примерно так: «Нужно построить информационное табло». Это были разные организации, использовать свои табло они планировали для различных целей; объединяло их только то, что все эти цели находились в плоскости управления. Использование термина «информационное табло» не совсем вяжется с управлением; оно ближе к «справочно-информационной» тематике, как например, здесь; поэтому далее буду использовать термин «индикативная система». Но суть статьи не в этом. Было интересно обобщить основные моменты построения автоматизированных систем информационных индикаторов для управления деятельностью предприятия.

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

Классификация индикаторов

Первый класс индикаторов

базируется на планируемых (или нормируемых) показателях деятельности. Для торговли это, например, сумма продаж, маржи, запаса в днях продажи и т.п. На самом деле показателей намного больше (их десятки), но сейчас нам интересны те из них, для которых задают плановые значения. В продвинутых конторах все чаще говорят не о «планах», а о «целевых значениях KPI» (в рамках BI-подхода к управлению, о чем коротко и ясно написано здесь). Для себя я разделил так: «целевые значениях KPI» используют в режиме развития, а «план» — в режиме функционирования предприятий. Но и в том, и в другом контекстах использование плана или целевого значения имманентно подразумевает проведение план-фактного анализа (ПФА).

ПФА дает информацию о рассогласовании фактических и плановых значений, но ее, как правило, еще недостаточно для принятия управленческого решения: ну видим мы, что план продаж заваливается; что делать-то, как исправить? Вдумчивый менеджер идет путем, который мудрые японцы обобщили в принцип «5 почему», и добирается до таких уровней детализации проблемы, когда понятно, какими действиями на ситуацию можно повлиять. И вот здесь-то очень к месту индикативная система. Формируется несколько типовых дорожек анализа ситуации по итогам ПФА, которые обставляются индикаторами. Бежать по таким дорожкам становится гораздо быстрее.

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

Уже проще, уже проглядывают деятельностные формы. Если снижается количество покупателей, наверное, маркетологи с рекламщиками намудрили или активизацию конкурента проморгали. Если количество товаров в чеке барахлит, то искать нужно в выкладке – покупатель не может найти нужное или товарную матрицу сломали – разъехались с потребностями покупателей. Со средней ценой в чеке тоже свои причины связаны, для наших целей неважно какие; а важно пока то, что растет количество индикаторов.
И этот набор индикаторов еще нужно посмотреть в глубину: в разрезе магазинов, отделов, товарных групп, категорийных менеджеров, поставщиков и т.д. Здесь «на глубине» очень хорошо работает сравнительный анализ и через индикаторы прогладывают проблемы с конкретным магазином, менеджером, поставщиком.

Вот и собрали мы часть индикативной системы, которая обслуживает ПФА (ПФА-индикаторы). Чем же она отличается от просто «информационной системы», которая в форме отчетов может выдать значения всех указанных показателей? Разница в том, что «индикативная система» тесно связана с бизнес-процессами (БП), а значит к ней применяются особые требования:

• типизации набора рассматриваемых показателей;
• их непосредственной связи с деятельность (на значение показателя можно повлиять такими-то и такими-то вполне определенными действиями);
• унификации форм их представления;
• оперативности их предоставления.

Подобная индикативная система класса ПФА хорошо вписывается в оперативные формы управления: в «еженедельные брифы» и «ежедневные пятиминутки». Менеджеры быстро проходят по типовым дорожкам ПФА и быстро находят типовые планы действий (ПД). Здесь ключевое слово – «быстро».

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

Второй класс индикаторов

ближе к «земле». Это те показатели, которые не просто «тесно связаны» с БП, а являются их непосредственной частью: по принципу «лампочка —> действие». Например, если оговоренный с поставщиком лимит по возвратам еще не выбрали, то бракер оформляет возврат бракованного товара; если уже выбрали – то оформляет списание.
Такие БП-индикаторы проектируются вместе с самим БП. Они предназначены для линейного персонала (уровня операторов). В отличие от ПФА-индикаторов они отличаются однозначностью влекущих за собой действий. Чем больше процессов компании будет покрыто такими БП-индикаторами, тем более предсказуемым будет поведение персонала нижнего звена; тем больше операций можно спустить вниз от менеджеров к операторам.

Третий класс индикаторов

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

Да он может потребовать от помощника формировать ему еженедельный отчет из ИС, но продвинутые топ-менеджеры автоматизируют это на своем «информационном табло»

(для Р-индикаторов такой термин уже вполне уместен).

Этапы проектирования индикативной системы

Они достаточно очевидны:

1. сформировать набор индикаторов (показателей);
2. построить механизмы сбора (расчета) этих индикаторов;
3. построить механизмы вывода этих индикаторов с учетом удобства использования и разделения прав доступа.

Формирование набора индикаторов

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

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

Построение механизма сбора (расчета) индикаторов

Это уже непосредственно айтишная задача, и видится здесь три пути-дороги.

Дорога первая: доработка транзакционных ИС – встраивание в них требуемого набора индикаторов

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

Из минусов. Не все ИС позволяют свою функциональность легко дорабатывать, не все из них являются «конструкторами» – многие «закрыты». Иногда эта закрытость оправдана и целенаправленна; иногда это ограничения платформы и архаичность. Но сейчас не об этом: факт, что не в каждую транзакционную ИС можно встроить индикативную ИС.
Еще минус – потребность в своих программистах или издержки внешней поддержки.
Дополнительная вычислительная нагрузка на ИС – тоже минус, например, когда при оформлении чеков приспичит видеть маржинальность продажи.

Дорога вторая: выгрузки в Excel

Дорогой ты наш Excel, как же ты хорош: гибкий, быстрый, доступный. Сегодня согласовали набор показателей; через день уже увидели прототип; а через неделю – мощный инструмент анализа. Все чудненько консолидируется или, по твоему желанию, разворачивается до магазина, до товара, до менеджера, до поставщика, до всего, что заложили. И фильтры универсальные и графики-диаграммки – видно все сразу.

Но как же ты зависим от человеческого фактора, как тебя губят многоступенчатые выгрузки-загрузки, предварительная подработка данных.
Довелось мне увидеть очень развитую и мощную (дух захватывает) индикативную систему, построенную на Excel. Но практически на каждой планерке (в основу которой эти система была положена) ответственный человек объявлял, что такие-то показатели неверны, требуют уточнения, проверки и т.п. А о скольких неточностях он не объявлял?..

В общем, Excel удобно использовать для тестовой проверки замысла индикативной системы. В рабочем режиме – только если вы очень доверяете человеку, за нее ответственному, ну и имеете внешние механизмы проверки значений индикаторов.

Дорога третья: системы бизнес аналитики

Еще их называют BI-системы. Они подключаются к транзакционным ИС (непосредственно к базам данных или через выгрузки), закачивают в себя данные, укладывают их в свои OLAP-кубы и дают пользователям удобные инструменты их просматривать.

Это такие пожиратели-оптимизаторы информации. Они заглатывают неимоверное количество чеков и прочих транзакций, а выдают аккуратно разложенные по нужным полочкам-разрезам индикаторы. Подключить их можно практически к любой, в т.ч. самой «закрытой» ИС. Очень удобным является то, что одна BI может одновременно собирать данные с различных и очень разнородных баз, коих даже в фирме среднего размера совсем немало бывает. Это все плюсы.
Есть еще один плюсик. Некоторые из них имеют настолько простые механизмы настройки индикаторов на основе закачанных в них данных, что не только местный программист с ними разберется, но и сам продвинутый руководитель их освоит – тогда он вполне самостоятельно может замкнуть задачу формирования интересующих его Р-индикаторов.

Среди минусов. Громоздкость: всегда отдельный сервер, отдельные процедуры загрузки данных, отдельные процедуры доступа к индикаторам (работаешь ты в транзакционной ИС, а посмотреть индикаторы нужно в BI).
Если работа построена через выгрузку данных из транзакционной ИС, то здесь мы ловим все ограничения этой выгрузки – в первую очередь по составу выгружаемых данных (но это скорее ограничение самих транзакционных ИС).
Если же работа построена через подключение к БД транзакционных ИС, то здесь вырастает интересная задача на понимание, а где, в каких таблицах и полях хранятся нужные нам данные. Интерес этой задаче придает отсутствие описания структур БД, что не такая уж и редкость. Аутсорсеры за подключение к нашим БД запрашивают такие нескромные вознаграждения, что мы посчитали целесообразным нанять еще одного программера, который бы с этим разобрался.

Построение механизмов вывода индикаторов

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

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

Итак, о чем это я

Индикативная система – это часть ИС, которая очень тесно связана с БП, с оперативной деятельностью. Поэтому к индикаторам предъявляются особые требования по типизации формы представления и скорости их формирования.

Существует три основных класса индикаторов:

• ПФА – индикаторы, которые вытекают из план-фактного анализа и позволяют в ходе этого ПФА быстро находить типовые причины отклонений и, соответствующие действия по их устранению.
• БП-индикаторы, которые непосредственно встроены в бизнес-процессы по принципу «лампочка-действие» и позволяют, таким образом, многие действия спустить от менеджеров к операторам.
• Р-индикаторы – индикаторы развития, которыми менеджеры верхнего звена проверяют свои гипотезы и прогнозы.

Реализовать индикативную систему можно тремя путями:

• встройкой индикаторов в транзакционные ИС,
• использованием Excel,
• использованием систем бизнес-аналитики (BI-систем).

С наступающим НОВЫМ ГОДОМ! Такая вот вам индикативная елка.

Автор: Borisenko

Источник