Комментарии по теме

«5 ра­спро­стра­не­нных за­блу­жде­ний при внедрении SAP»
Тимур Баймульдин:
Спасибо за ваши комментарии! Я ни разу не сомневался, что затронутая мною тема, уже поднималась и не раз. И тут я полностью согласен с Олегом Кашуба: Каждый раз одни и те же грабли. :) Про...
«5 ра­спро­стра­не­нных за­блу­жде­ний при внедрении SAP»
Олег Точенюк:
Опыт штука хорошая, но иногда бывает полезнее прочитать, написанное кем-то, причем уже давно :-) А потом уже изобретать вИлосИпеду... кстати там как раз чистый запад, но грабли и мысли у автора те...
«Игровой ролик: SAP для Retail»
Александр Дублин:
Суть ролика: если хотите спать в рабочее время, унижать подчиненных, то с решением от SAP вам это будет удобно. Сценарий ролика - продолжения истории: top-lap.livejournal.com/502664.html

База знаний

Операционная эффективность — скрытый эффект от внедрения ИТ-решений

Предыдущая Следующая
Просмотров 2882 Комментариев 0

Операционная эффективность — скрытый эффект от внедрения ИТ решений

Операционная эффективность на практике

Докладчик: Николай Ситников, директор по развитию продуктов, RAMEX

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

Вторая часть — это организационные факторы. Насколько детально проработаны первоначальные требования, насколько эффективен проект? В любой большой компании всегда возникает некий промежуточный слой: повседневную деятельность хотят вписать в идеальный процесс. Но реальность всегда отличается от идеала. Если в ходе проекта их удалось синхронизировать — замечательно. Но на практике половина проектов приводит к тому, что внедрение состоялось, но при этом реальный пользователь системы пытается адаптировать то, что умеет и предоставляет ему информационная система, к тому, что ему надо делать. Например, это данные, которые хранятся в Excel и агрегируются перед тем, как их ввести в основную информационную систему. Либо промежуточные отчеты, которые строятся, чтобы соотнести реальную потребность бизнеса и реальную возможность информационной системы. Во что это выливается? Рано или поздно вы слышите, что внедрение информационных систем не дало тот экономический эффект, который планировался изначально. И даже если все считают, что проект в целом завершен успешно, «осадочек остается».

Более того, когда мы говорим о KPI, достаточно сложно оценить, какое влияние на формирование того или иного показателя оказала собственно информационная система. Особенно видно это на верхнеуровневых KPI. Допустим, вы внедрили информационную систему, но в стране в это время что‑то произошло — положительное или отрицательное. И при оценке, например, финансовых показателей возникает вопрос: с чем связан достигнутый экономический эффект? Произошел ли он из‑за того, что мы вовремя внедрили нужную информационную систему, или потому, что рынок изменился и общая ситуация стала более благоприятной?

Ряд показателей крайне сложно сделать количественными: мы понимаем, что какие‑то операции в компании стали лучше, быстрее, удобнее, но нам сложно сказать, насколько лучше, насколько быстрее. Это нормальная ситуация. Не всегда можно дать конкретную оценку. Но можно, внедрив ту или иную информационную систему, продолжать увеличивать эффективность ее использования. И здесь получается интересная синергия в том случае, если бизнес и IT начнут работать вместе дальше — искать способы использования этой информационной системы и дополнения к тому функционалу, который уже внедрен, продолжать продвигаться к тем результатам, которые были обозначены в бизнес-кейсе. И одна из таких областей — это управление операционной эффективностью предприятия, где IT может оказаться источником дополнительных данных. Как правило, о них не думают, закупая информационную систему. Но, если правильно выстроить взаимоотношения IT с бизнесом, эти данные могут привести к очень интересным результатам.

Вообще операционная эффективность — это термин, который, может быть, не во всех компаниях в ходу, но само это явление всегда находится в фокусе внимания — либо у бизнес-руководителей, либо у специального департамента. Есть формальное определение именно термина «операционная эффективность», появившееся в Японии примерно тогда же, когда возникли всевозможные концепции из серии «шести сигм», lean manufacturing и так далее. У этой системы управления операционной эффективностью, естественно, как водится, есть руководство, сертификация и так далее. Но это не значит, что, внедрив ее, можно что‑то глобально изменить в компании. Есть несколько ключевых вещей, которые бизнесу и IT в любой ситуации стоит осмыслить — независимо от того, идет ли речь о повышении эффективности и производительности труда, следует ли компания этой концепции или нет.

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

1. Это позволяет достаточно ясно понимать, для чего мы это делаем, во что это выльется.

2. Это позволяет балансировать на уровне бизнеса, когда идет выбор между той или иной стратегией.

Что любая компания хочет предоставить клиенту? Продукт приемлемого качества по интересной для себя себестоимости. То есть мы хотели бы, конечно, давать суперкачественный продукт, не считаясь с нашими затратами, но этого мы не можем делать. С другой стороны, мы хотели бы максимально сократить свои затраты на продажу этого продукта, на его производство, но где‑то нам надо остановиться для того, чтобы качество продукта не упало настолько, что люди его не будут брать. Здесь мы четко постулируем, что не можем достичь идеальной ситуации. Когда мы получаем, допустим, 100‑процентное качество и 100‑процентную востребованность рынком конечного продукта деятельности нашего предприятия, мы выясняем, что настолько задираем свои затраты на производство, что это становится для нас не слишком рентабельно. И наоборот.

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

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

Поставщиком этой информации выступает IT. И на текущий момент у IT появляется возможность поставлять данные на большем уровне детализации, чем раньше. За счет этого увеличивается степень свободы маневра в управлении операционной эффективностью. Использовать системный подход, анализировать ситуацию в комплексе — в этом IT может зачастую помочь бизнесу. Потому что очень часто происходит реакция на результат без понимания причины. Показатель вырос на 3 %. Если это плохо — побежали исправлять. Если это хорошо — побежали это праздновать. И очень многие компании не задумываются, что это может быть статистический всплеск.

Важный момент в управлении эффективностью — IT должны иметь возможность предоставлять каждому человеку с правами принятия решения ту информацию, которая ему нужна. И, собственно, это должно быть непрерывно (то, о чем говорили): необходимы новые итерации, тесты. У SAP есть отраслевые бенчмарки, есть лучшая мировая практика, но у каждого клиента есть индивидуальные особенности. После того, как были сделаны большие ключевые изменения в компании, необходимо оптимизировать и дополнительно настроить эти изменения за счет дополнительных настроек. И вот эту информацию может поставлять IT.

Операционная эффективность — это возможность минимальными ресурсами достигать необходимого уровня качества и других важных показателей. Если мы снижаем затраты и изымаем ресурсы — мы их либо используем для увеличения роста, либо сохраняем существующее качество и объемы. Как научиться балансировать без проб и ошибок, без больших инвестиций, используя то, что уже есть? Любая зрелая компания, на наш взгляд, обладает необходимым уровнем автоматизации для того, чтобы эту информацию видеть. Вопрос в том, как производятся замеры. Часто все говорят: «У нас же не 100 % людей на производстве, у нас люди не сидят только за компьютерами. Они что‑то делают, они занимаются промышленной деятельностью, и про это мы ничего не знаем, это находится вне зоны автоматизации». Как правило, люди дают либо минимальную, либо максимальную экспертную оценку. Но при работе в этих диапазонах лучше приходить к более точным значениям — это гораздо эффективнее получается. Когда мы пытаемся что‑то изменить, даже если мы не можем измерить это точно — важно хотя бы понимать диапазон. Когда мы выходим на тактический уровень, можно достаточно достоверно сравнивать бенчмаркинг на уровне показателей предприятия, типа прибыли или каких‑то вещей. Как только мы выходим на уровень ниже, надо быть с бенчмаркингом осторожнее.

Из реальных примеров: банки любят мерить среднее время обслуживания клиента по той или иной операции. И когда вы пытаетесь сравнивать это время между банками — можно, конечно, сделать mystery shopping и посмотреть: ага, тут люди получают кредит наличными за 10 минут, а здесь за 30 минут. Если у нас 30 минут — значит что, посыпать голову пеплом? Не факт: разные процессы у разных компаний, разные этапы туда включены. Поэтому, когда мы хотим видеть бенчмарки и говорим: «А давайте посмотрим, как это происходит на рынке», — надо быть очень аккуратным с тем, что мы мерим у себя и конкурентов, что мы включаем в тот или иной термин производственного цикла или какой‑то операции.

Что можно делать с информационными системами, что интересно и бизнесу, и IT, если они работают вместе. Начнем мы с самого низкого уровня — измерения эффективности IT-решений. Что можно делать с IT-решениями? Вот мы внедрили новую информационную систему — и тут же слышим слова о том, что она не очень удобна в работе, что снизилась производительность труда и так далее. Что может делать IT? Подготовить статистику, например, по пользователям информационной системы. Мы можем смотреть, сколько людей совершают ошибки и насколько часто это происходит. Мы можем понимать, что недоучили мы их, и в этом проблема. Потому что любой модуль SAP — это вещь достаточно сложная. Если мы не делали привязки к конкретной карте технологической процедуры, может быть ситуация, что человек ошибается — не в том смысле, что система сбоит, а в том смысле, что он совершает неправильные действия, он вынужден их повторять и повторять, то есть система выдает сообщение о том, что что‑то не так и так далее.

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

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

Как определить реалистичные значения для KPI? Например, если 30‑40 % сотрудников могут выполнять ту или иную операцию быстро и качественно, их темп выполнения можно взять за основу для общего KPI по данной операции. С остальными сотрудникаии нужно поработать, чтобы дать им возможность достигнуть такой же скорости. Благодаря этому произойдет улучшение, увеличение производительности работы.

Что нужно для того, чтобы это работало?

Аналитики, которые будут выявлять и исследовать явления.

Доступность информации для руководства, позволяющая руководителям принимать обоснованные решения.

Выявление ситуаций, когда изменение информационных систем (например, установка сервис-пака) повлияло на производительность.

Например, в результате очередного обновления изменилось расположение одного из полей для ввода данных в интерфейсе. Возможно даже, была выпущена соответствующая документация. Но люди, для которых в привычном процессе произошли изменения, отреагируют на это изменением своей производительности: на поиск нового местонахождения поля им потребуется время. Что в связи с этим предпринять? Добавлять в систему custom code (что увеличит стоимость обслуживания системы)? Или подождать, пока пользователи привыкнут и производительность выровняется? В этой ситуации IT может стать поставщиком информации для бизнеса, предоставить данные, обозначить тренд — и бизнес, с учетом этой информации, сможет принять решение о дальнейших действиях. Возможно, надо провести дополнительный тренинг, людей обучить и сделать так, чтобы они привыкли к новому интерфейсу. И сейчас IT может дать эту информацию раньше, чем накопится та критическая масса недовольства пользователей, за которой начинается конфликт.

Что может сделать IT на этапе проведения изменений? Дать информацию в достаточном объеме и в той форме, которую может воспринимать конкретный человек, принимающий решения на определенном уровне. В одном из проектов был определен обязательный KPI, и инициативная группа со стороны головного офиса еженедельно общалась с отстающими регионами, пытаясь понять их проблемы и возможности изменить ситуацию. Основой для этих обсуждений были информационные панели, показатели на которых менялись в режиме реального времени. Замеряя посещаемость этих интерактивных панелей, мы увидели, что чем больше подразделения изучали эту информацию,чем чаще заходили на эту веб-страницу, тем лучше становились показатели. Вот пример реальной пользы, которую информация от IT может предоставить бизнесу.

Бизнес-процессы: как поднять операционную эффективность?

Помощь IT может быть полезной и в оценке состояния бизнес-процессов: оценив, сколько времени сотрудник тратит на те или иные процессы, входящие в его обязанности, можно выявить его вклад в общий результат предприятия, в основные и вспомогательные задачи, которые невозможно напрямую соотнести с получением прибыли. Приведу пример из банковской сферы: показатели менеджера, работающего с клиентами. Он принимает депозиты, выдает кредиты, а также готовит различные документы к отправке в бэк-офис. По предварительной оценке, доля этой работы с документами составляла не более 20 %. Однако замеры показали, что реально она составляла 40 % — вдвое больше. То есть появилось понимание, что есть область для улучшений непосредственно внутри компании. К чему это может привести на выходе? Может быть, к перераспределению должностных обязанностей между сотрудниками. Может быть, к изменению бизнес-процесса. В любом случае, основой для этого изменения являются данные, которые бизнес получил от IT.

Важный момент — это разовые акции. Если мы идем анализировать показатели в цех или точку продаж, может оказаться, что в этот день сотрудники покажут максимум возможного и показатели их работы будут, условно говоря, на 30 % лучше реальных. Но если информация будет поступать от IT, на основании логов системы, это будет единая, непрерывная информация по всем подразделениям компании, причем без лишних затрат: ведь информационные системы уже внедрены и задача — получить из них информацию и обработать эти данные. Глядя на активность человека в информационных системах, можно оценить интенсивность его работы в течение дня. Что вам это дает? Информацию для оптимизации рабочего графика — его можно соотнести с показателями работы сотрудника.

Можно также соотносить данные о работе человека со статистикой сбоев или ошибок и таким образом выявить риски, связанные с человеческим фактором — например, с усталостью. Человек, проработавший без перерыва несколько часов, начинает совершать больше пользовательских ошибок, среднее время операции увеличивается, например, на 40 % — зная эти данные, можно легко посчитать, во сколько компании обходится усталость или неоптимальная организация труда. И после этого уже посчитать, зная конкретное время, во что же мне это выливается. Стоит ли мне, может быть, как‑то поменять график или что‑то еще сделать? Это информация, которая есть, она есть в информационных системах, которую бизнес хотел бы видеть, но не видит. И здесь создание совместной такой синергии может приносить пользу.

Еще одна вещь — взаимодействие между информационными системами в рамках сквозных процессов между активами холдинга, разными департаментами предприятий, в разных системах. Многие вещи, выявляемые на уровне IT, могут здесь значительно помочь бизнесу. Рассмотрим два типовых сценария.

1. Пинг-понг: подразделение А передало некий комплект документов подразделению Б (неважно, бумажный, или через систему электронного документооборота, или через какую‑то заяву), подразделение Б это взяло и продолжило работать. Зачастую бывает, что подразделение А неправильно составило эту документацию, и поэтому подразделение Б вернуло ее на доработку. И такой пинг-понг может какое‑то время происходить. Стандартный отчет информационной системы этого не покажет. Он может показать, сколько времени эти документы провели в одной системе, сколько заявок перешло, но эту ситуацию он не выявит. Например, в одном из банков, с которым я работал, комплект документов на предоставление кредита юридическому лицу в 20 % случаев требовал 6 итераций, что, безусловно, слишком много. В рамках статистики, которую даст IT, можндо посмотреть, как процесс организован. Возможно, проблема в людях: недоучили, недостаточно четко контролируем. Либо сами сотрудники неэффективно работают.

2. Календарное планирование. Допустим, на склад направлено свободное транспортное средство. Есть центральный склад, где компонуются паллеты с грузом и доставляются в торговую точку. Но моменты комплектования заказа и прибытия транспорта на склад не синхронизированы. И свободный грузовик простаивает у склада в ожидании, потому что паллеты на маршруте, на который он назначен, еще не готовы. Вроде нормативы по изготовлению паллет соблюдаются (надо собирать во столько — она собирается), нормативы по грузовику тоже соблюдаются, то есть он выполняет то время на маршруте, которое мы ожидаем получить. Но четкого взаимодействия нет. А ведь есть и третья сторона — торговая точка. Она должна провести инвентаризацию, посмотреть на автоматический заказ, скорректировать его с учетом того, что реально нужно для торговли. Все эти три сегмента работают независимо друг от друга, несогласованно. Либо простаивает транспорт, либо нарушаются сроки поставки в магазин, либо менеджер склада направляет свободный грузовик по другому маршруту и все запланированное рассыпается.

Мы должны понимать: какие бы данные IT ни предоставляли, без участия людей, принимающих решения на уровне бизнеса, эта информация не будет работать. Поэтому IT нужно научиться работать вместе с бизнес-пользователями. Но как это можно сделать на практике? Например, созданием двухуровневой группы. Верхнеуровневая группа — это управляющий комитет, проектный комитет. Эта группа должна работать постоянно, и состав ее не слишком масштабный: координатор со стороны бизнеса, координатор со стороны IT и какое‑то количество бизнес-пользователей, которые привлекаются попроектно в рамках того, над чем мы сейчас работаем.

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

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

Анализ статистики по пользователям позволил выявить причину. В первых двух точках 90 % консультантов, судя по последовательности операций, знали о новой, и только 10 % придерживались старых правил. А на третьей точке было соотношение 50 на 50: половина людей была в курсе того, что теперь надо делать по‑другому, и работала быстрее, а половина — нет. Было видно, что сначала они пытались работать по‑старому, затем наступала пауза — очевидно, консультировались с более знающими коллегами, и только потом сотрудник выполнял все действия уже по новому порядку. Как следствие, все мешали друг другу, и процесс оформления продажи товара занимал еще больше времени, чем раньше. И именно IT-статистика позволила увидеть эту ситуацию в полном объеме.

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

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

Как может быть построена такая итерация? Например, в распределении рабочего времени среднестатистического сотрудника предприятия одна операция может занимать 45 % всего времени, причем находиться вне поля зрения информационной системы. Например, в ней сотрудник зарегистрировал заявку, а работу выполняет вне системы — чинит оборудование, что‑нибудь грузит и так далее. Но есть и другие операции, и они как раз находятся в поле зрения информационной системы. Смотрим, сколько часов в рабочем дне такого сотрудника занимает эта операция. Сравнивая среднюю длительность шага с количеством операций, можно выявить операцию, которая по длительности занимает мало времени, выполняется чаще всего.

И может оказаться, что лучше оптимизировать не длинную или редкую операцию, а вот такие частые: их улучшения, за счет частоты выполнения, могут дать значительно больший экономический эффект. Часто такие массовые и простые операции можно реально ускорить, просто оптимизировав среду. А вот эти операции, которые длинные, они сложные: там какая‑то и творческая составляющая, там человек думает. Мы не можем заставить резко увеличить скорость, с которой человек думает. То есть лучше поднять эту на 1 %, но за счет массовости она нам поможет.

В одном из проектов оптимизация массовой операции позволила сократить затраты времени на 15 % как раз сокращали за счет обрубания вот этого хвоста. Просто мы посмотрели распределение, проверили, что происходит — и узнали, что часть людей выполняет работу объективно дольше. Были предприняты мотивирующие меры по увеличению производительности работы. По остальным операциям удалось получить еще 10 % экономии и, по экспертной оценке, половина этого результата была получена просто в результате информирования сотрудников, что за их работой ведется наблюдение в системе. С помощью системы были выверены показатели затрат человеко-часов, а затем уже руководство компании умножило количество сэкономленных часов на их стоимость и таким образом определило экономический эффект. Например, в той компании, о которой идет речь, было принято решение о децентрализации колл-центра, на который шли заявки и входящие обращения. Выявив, что сотрудники в отделениях недозагружены работой, руководство приняло решение использовать эти ресурсы как вторую линию поддержки в колл-центре, так как это кадры опытные, они знают, как работать с клиентами, и умеют решать сложные проблемы. Соответственно, была внедрена система поиска свободного консультанта из отделения, что позволило эффективнее решать клиентские проблемы. И в дополнение к оптимизации загрузки сотрудников был получен такой важный эффект, как сокращение оттока клиентов. Приче в таких ситуациях, как нормирование времени, важно учитывать нюансы. Почему время может быть превышено? Например, у клиента была очень сложная, нетиповая проблема. Либо сотрудник не справлялся с нормативом. Обе эти ситуации требуют разной реакции и оценки.

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

Процессные вещи, требующие улучшения, можно выявлять как раз на уровне сотрудников. Если отдел продаж постарался, а отдел производства не справляется, возможно сделать кейс-анализ какой‑то ситуации и понять, в чем проблема: с каким‑то заводом, подразделением, линией, отделением, или просто вся сеть перегружена из‑за неточных расчетов. При этом значительный объем информации для анализа уже есть — это логи системы, например, SAP Solution Manager или веб-frontend. Если вам кажется, что проблема в несинхронизированности циклов доставки и производства, или каких‑либо двух технологических процессов — эти данные можно получить и сравнить.

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

Отмечу, что у SAP есть решение User Experience Management by Knoa, которое позволяет мониторить действия пользователя — движения мышью, клики — как на уровне систем SAP или других информационных систем. Это удобно, так как позволяет наладить централизованный сбор данных независимо от изменений бизнес-пероцессов. Вы можете, поговорив с бизнес-пользователями, примерно себе представить бизнес-процесс, даже его не расписывая, и определить реперные точки. Для того чтобы работать в реальности с эффективностью, нужно понимать, в каких точках и сколько раз сотрудник процесс проходил. Если есть эти данные системах — замечательно, но даже если их нет и при этом развернут мониторинг того, что делает пользователь — всегда можно сделать выводы из этой информации.

Понятно, что ее нужно будет очищать и трансформировать, переводить в единый формат и так далее. Самая сложная часть — это корреляция каждой бизнес-операции или каждого бизнес-шага с конкретным экраном операционной системы, номером транзакции в SAP и так далее. Как правило, этого нет в готовом виде. Если эта последовательность операций по счастливому стечению обстоятельств соответствует какой‑то аналитике, которую умеет делать бизнес-система — замечательно. Хотя крайне редко в этом случае эта система дает информацию о длительности. Вы можете узнать время, когда она была окончательно проведена. Может быть, вы видите время изменения конкретного статуса, если это были какие‑то статусы или заявки, но это все равно нужно специально собирать и анализировать. Очень часто система вообще не соответствует один в один вашим бизнес-процессам. Здесь вопрос в том, что должен быть коррелятор, который умеет выполнять эти вещи.

Почему это важно? Например, основной эффективный сценарий — это сценарий, на который мы не хотим идти, но приходится, он для нас менее выгодный. Пример: обращение клиента в случае, когда человек знает номер своего договора, контракта или еще какие‑то идентификаторы. Мы внесли их в систему и сразу получили информацию, и можем работать с этим запросом. Вторая ситуация — когда информации у клиента нет. Например, в колл-центрах частые обращения — когда у человека нет при себе необходимых документов или что‑то изменилось в его данных или он не помнит какую‑то важную информацию, а документы для ее проверки ему недоступны. Для того чтобы повышать эффективность, надо понимать, что произошло: выполняли ли мы идеальный сценарий или отступали от него? Если нам система не даст достаточно информации, сколько раз шла итерация по поиску, по уникальному идентификатору (мы пытались его найти), нам хотя бы факт того, что сотрудник пытался это сделать. Тогда можно было бы утверждать аргументированно, что процесс по первому сценарию занимает три минуты, по второму — десять минут, и если этот сценарий проявляется в 30 % случаев — значит, надо с этим делать что‑то.

Что такое исполнение? Например, отправка сообщения по электронной почте или SMS о каких‑то отклонениях. Руководитель при необходимости мог оперативно вмешаться — например, при задержке транспорта на складе. Если грузовик ждет — значит, автоматическое распределение заказов не сработало, и тогда руководству направляется SMS.

Увидеть проблемы и возможности

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

Про интерпретацию информации и визуализацию. Это уже меньше бизнес, больше IT. Мы всегда исходим из того, что бизнес хочет информацию — как правило, одним из стандартных требований является выгрузка данных в Excel. Почему об этом просят? Это сигнал, что IT не дает эффективную информацию. Другое дело, что бизнес не совсем понимает, почему ему эта информация неудобна, но то, что он ее просит в Excel, означает, что ему не совсем удобно для работы то, что вы ему даете — неважно, насколько оно интерактивно, фильтруется и так далее. Почему так происходит?

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

Если мы человека постоянно информируем, например, по почте: «А у вас нарушено это пороговое значение, это пороговое значение и это пороговое значение», — с определенного момента это начинает восприниматься как спам. Он никогда в этом не признается, потому что он сам же это заказал, но на практике это будет именно так — он будет фильтровать. Когда он получает очень большую таблицу, где очень много данных, он ее откладывает «на потом», когда на ее изучение появится больше свободного времени. Вторая ситуация: он не хочет в этом разбираться. Поэтому получается очень часто, что избыток данных эквивалентен их отсутствию.

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

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

Неверно выбранный формат визуализации может сказать больше, чем показатель. Там есть ряд примеров. Наверное, в 90 % случаев эти ошибки повторяются, потому что даже поставщики решений в своих примерах эти ошибки делают. Самый неудачный с точки зрения интерпретации график — это «пирожковая» диаграмма, она же pie chart. Проблема — в том, что человеческое зрение не слишком точно оценивает углы. Мы можем сказать приблизительно — это сегмент больше, чем тот. Но точно сказать, где 15 %, 25 % или 10 %, глазомер не поможет. Поэтому приходится добавлять всевозможные цифры, выноски, примечания, как‑то выделять реальное значение. И все, что вы будете делать — это считать эти маленькие циферки, а не смотреть на графики. Зачем же тогда рисовать графики?

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

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

Если сделана нормальная визуализация, оперировать информацией становится легче.

Например, в SAP BusinessObjects и многих других продуктах уже появились средства collaboration, кооперативного взаимодействия — когда можно что‑то выделить на графике, или на интерактивном графике выбрать фильтр и кому‑то послать. Кто это использует? Да никто. Почему? Потому что непонятно, сложно интерпретировать. Упрощение позволит более активно задействовать этот инструментт. Это не то что повышение операционной эффективности, это касается просто отчетности — но это важный момент, который мы, когда делаем отчеты, из‑за многообразия забываем.

Выводы:

• У IT есть возможность наладить сотрудничество с бизнесом, чтобы вместе повышать операционную эффективность.

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

• Это процесс итеративный. Не надо пытаться сделать много сразу, надо идти циклами. И надо концентрировать зоны внимания — для этого у процесса должен быть спонсор со стороны руководства. А чтобы спонсор был доволен, чтобы ему было не страшно продвигать этот процесс и продавливать эти решения, он должен понимать, что у него есть ключевые индикаторы, привязанные к конечным финансовым результатам компании. Прямо или косвенно вы должны объяснить: «Мы снижаем затраты времени, повышаем утилизацию ресурсов, и так далее».

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

• Чаще всего используется информация о времени, длительности операций, которые есть внутри систем. Так как мы храним данные, они имеют определенную стоимость. Как только вы начинаете использовать эти данные в целях операционной эффективности, они данные перестают быть вашим чистым расходом просто потому, что они накопились. Я не говорю никаких слов про big data, возможность на основе хитрого анализа этих данных повышать продажи и так далее — это отдельный вопрос. Но даже имея эту статистику, вы можете получить представление о деятельности сотрудников и их эффективности, то есть как бы окупаете тот факт, что вы их храните.

• Визуализация данных может помочь в их восприятии на каком‑то этапе, но нужно учитывать несколько простых правил. А когда данные понятны, эффективнее становится принятие решения на их основе. Как следствие, вы повышаете операционную эффективность, то есть вы учитесь, вы помогаете.

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

Естественно, у нас, как у IT-подразделения, есть большой соблазн: данные есть, их можно использовать. А насколько эти данные действительно нам принадлежат? А не связана ли их обработка и визуализация, и принятие решения на их основе с какими‑то проблемами более высокого уровня сложности? Звучало «Большой Брат» — а хотим ли мы быть компанией, в которой Большой Брат следит за своими сотрудниками? Это очень интересный вопрос, который у всех возникает. В России, по крайней мере, мне не известен ни один случай, когда кто‑то из сотрудников возмущался с юридической точки зрения: «Что же за мной следят?». Но когда я работал со шведами (компания мобильной связи), и у них была большая проблема, то возник вопрос даже не наблюдения за работой сотрудников, а отслеживания качества работы колл-центра. Поскольку у них часто менялись часто тарифы, они сделали регулярную аттестацию людей — проверку знаний по тарифам. И профсоюз сказал: «Вы заставляете людей что‑то учить и ранжируете их по уровню знаний! Это нарушение их прав». И даже то, что сотрудник может по незнанию выдать клиенту неверную информацию — это не повод его депремировать или какие‑то другие мотивационные методы применить.

В России мы тоже не хотим обижать людей и говорить, что мы за ними наблюдаем. Сейчас очень модно говорить о геймификации — концепции, позволяющей ввести игровые компоненты в рабочий процесс. И отслеживание действий пользователя — это классический пример, когда вы можете использовать геймификацию. Что такое геймификация? Мы говорим о том, что работа — это до какой‑то степени игра, то есть выполняя работу правильно, вы нарабатываете очки, получаете какие‑то бейджи лояльности, и так далее. Сейчас много говорят о поколении «игрек», это поколение, которое заканчивало институты в 2000 году и привыкло, в отличие от предыдущего поколения, к тому, что его результаты все время оцениваются, сравниваются с кем‑то. Они очень социальны. Если предыдущее поколение занимается самообразованием (это не мое измышление, цитирую этого консультанта) и расширяет сферы своего влияния, оно очень не любит, когда вмешиваются в его внутреннюю кухню, его как‑то оценивают и так далее.

А новое поколение, которое сейчас начинает доминировать в общей численности трудоспособного населения, хочет видеть: а) постоянную оценку своего труда (при этом они очень обижаются на плохие оценки, они хотят видеть мотивирующую оценку своего труда); и б) наставника, а не начальника — то есть того, кто им посоветует, что делать. Они не привыкли принимать решения сами и нести за них ответственность, они хотят его обсуждать. И в этом варианте геймификация — это, по сути дела, решение за них. Теперь это не Большой Брат, который за ними следит — это какая‑то оценка, которая выражается в количестве того, что он заработал и что выведено на табло достижений. Точно так же, как они пытаются в играх занять верхнюю позицию, точно так же они и в работе стремятся выиграть, к примеру, продержавшись три дня подряд на необходимом уровне KPI. Причем поколение «игрек» практически никогда не ожидает материальной компенсации. Как это работает в разновозрастных коллективах, состоящих из сотрудников нескольких поколений? Чем ниже позиция, тем активнее надо этим человеком управлять. Как правило, на массовые позиции ставят менее квалифицированных людей, и тем больше экономический эффект от этих людей. Практически все розничные банки, которые подобную вещь внедряли, делали это в форме KPI в рамках бонусной схемы. Этот показатель либо «висит» на руководителе отделения, и тогда он мотивирован уже какими‑то своими способами разгонять своих операционистов, либо непосредственно на операционисте.

Этично ли это? Мы ставим эти показатели, используя реальные значения. То есть они достижимы (если мы подошли к этому правильно, сначала померили, потом определили, какой показатель является для нас целевым), это может восприниматься нормально. Потому что мы не говорим о том, что ставим заведомо недостижимые цели. Хотя да, этический вопрос, Большой Брат, который по своему разумению манипулирует вами — он есть, и надо это учитывать. Но для этого у вас есть бизнес-пользователи в связке с IT, которые могут сказать, стоит ли использовать этот метод.