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

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

Докладчик: Николай Ситников, директор по развитию продуктов, 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-статистика позволила увидеть эту ситуацию в полном объеме.

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

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