В компаниях часто случается следующая ситуация. Вложили миллионы рублей в новую корпоративную систему. Проходит полгода, собственник спрашивает: «А сколько денег она нам принесла?». Выясняется, что напрямую – нисколько. Возникает ложный вывод: проект оказался бесполезным. На самом деле, IT-система не создает новую выручку напрямую. Ее ценность в повышении продуктивности труда. В этой статье разберу, как руководителю понять, окупилось ли внедрение IT-продукта, в котором нет кнопки «заработать деньги».
Что измерять после внедрения IT-решения
С корпоративными IT-системами привычная схема оценки инвестиций не работает. Продукт может не увеличивать продажи, не привлекать клиентов и не генерировать отдельную прибыль. Но при этом сокращать время работы сотрудников, устранять ручной труд, уменьшать ошибки или давать руководству данные для решений. Поэтому сначала нужно определить, какой именно бизнес-показатель должна изменить автоматизация.
1. Экономия времени
Это самый простой и понятный показатель. Считается так: сколько времени занимал процесс до внедрения, сколько занимает после, сколько операций выполняется в месяц и сколько сотрудников участвует. Экономия времени = количество операций × сокращение трудозатрат на одну операцию.
Хороший пример – автоматизация командировок. Раньше процесс затрагивал несколько подразделений и занимал около 14 дней. После автоматизации – около трех дней. Важен не сам факт внедрения системы, а результат: высвобожденные часы сотрудников можно направить на более полезные задачи.
2. Рост производительности без расширения штата
Компания растет, объем работы увеличивается в три раза. Обычно пришлось бы нанимать дополнительных сотрудников. Но благодаря автоматизации существующая команда обрабатывает выросший объем. Например, раньше сотрудники обрабатывали 600 объектов, после внедрения – 2 тыс., при этом штат не вырос пропорционально. Экономический эффект заключается не в сокращении сотрудников, а в том, что их не пришлось дополнительно нанимать. Компания экономит на зарплатах, обучении и управлении новыми людьми.
3. Сокращение количества рабочих ошибок
Ручные процессы почти всегда сопровождаются ошибками: неправильное значение, потерянный документ, дублирование, ошибка при переносе данных, использование устаревших сведений. Чем больше ручных операций, тем выше вероятность проблем. Стоимость ошибки тоже можно оценить: количество ошибок до внедрения умножить на среднюю стоимость одной ошибки. Причем стоимость – это не только прямые деньги, но и часы работы сотрудников на исправление. Автоматизация убирает часть ручного труда, а встроенные проверки не позволяют ввести некорректные данные.
4. Скорость принятия решений
До автоматизации руководитель получает информацию раз в месяц, через Excel, после ручной подготовки отчета из нескольких источников. После внедрения он видит актуальные данные непосредственно в системе. Ценность IT-продукта – в сокращении времени между возникновением проблемы и решением руководителя. Это сложно напрямую перевести в рубли, но для бизнеса эффект может быть огромным.
5. Прозрачность бизнес-процессов
До внедрения корпоративной системы руководитель мог не знать, где находится заявка, кто ее задерживает, сколько времени занимает каждый этап, почему одни подразделения работают быстрее других. После внедрения появляется цифровой след. До автоматизации руководитель управляет процессом по рассказам сотрудников, после – по данным. Прозрачность сама по себе является бизнес-результатом, позволяя выявлять узкие места, перераспределять нагрузку, контролировать сроки.
6. Устранение лишнего процесса
Иногда лучший результат автоматизации – не ускорить работу сотрудника, а сделать так, чтобы эту работу вообще больше никто не выполнял.
- Плохая автоматизация: сотрудник нажимает кнопку и получает отчет быстрее.
- Хорошая автоматизация: отчет формируется автоматически, и сотрудник вообще перестает заниматься его подготовкой.
Нужно считать не только «насколько быстрее стало», но и «что мы вообще перестали делать». Если система убирает целый этап, эффект гораздо выше, чем просто ускорение работы.
Когда можно оценить результат автоматизации процессов
Пытаться доказать эффективность проекта через полгода после запуска – это ошибочный подход. Ведь никто не записал исходные показатели. До внедрения нужно зафиксировать хотя бы: длительность процесса, количество операций, число участвующих сотрудников, количество ручных действий, число ошибок, количество заявок, время подготовки отчетности, количество обращений в поддержку, стоимость процесса. После внедрения измеряются те же показатели. Схема простая: до → внедрение → после. Только так можно объективно говорить об эффекте.
Перед разработкой руководителю стоит ответить на пять вопросов:
- Какой процесс мы хотим изменить?
- Как он работает сейчас в цифрах?
- Какой показатель должен измениться после внедрения?
- Как мы его измерим?
- Какой результат будем считать успешным?
Не «нам нужна новая система командировок», а «мы хотим сократить оформление командировки с 14 до 5 дней и уменьшить количество ручных операций вдвое». Тогда IT-проект из абстрактной разработки превращается в управленческий инструмент.
Почему не каждый эффект автоматизации нужно переводить в деньги
Я выступаю против чрезмерного увлечения ROI. Некоторые показатели достаточно сравнить напрямую: 14 дней → 3 дня, 600 операций → 2000, 7 ручных этапов → 2, отчет раз в месяц → данные онлайн, 10 источников информации → одна система. Попытка любой ценой перевести каждый показатель в деньги приводит к искусственным расчетам вроде «мы сэкономили директору 17 минут, его зарплата составляет X рублей, значит проект принес Y». Такие расчеты выглядят убедительно на бумаге, но далеко не всегда отражают реальную ценность.
Также читайте:
Это - очень интересный вопрос. Риск-менеджмент как дисциплина пытается дать на него ответ: одним из способов управления рисками является передача их третьей стороне (страхование), другим - самострахование (создание резервов).
Чтобы понять, насколько нужно вообще содержать сторожа, следует определить вероятность и размер ущерба от возможного события. Если он окажется меньше, чем оплата сторожа, то и найм его не нужен.
Так, в Скандинавии еще есть мелкие магазины с недорогим ассортиментом, где люди берут товар и оставляют деньги в кассе. В последнее время, однако, из-за приезда лиц разной степени загара такая практика стала сворачиваться. Верно и обратное: если товар стоит дорого, то просто сторожем можно не обойтись - нужны люди, которые будут "пояснять" лучшие практики шоппинга посетителям на месте и даже в дневное время. По этой модели работает алкомагазин в Лондоне у одного из основателей "Евросети".
Обычно математически достаточно просто просчитать разные сценарии и сделать вывод.
Здесь сложнее. В отличие от прямого ущерба отсутствие автоматизации не приводит к единомоментным потерям: оно ведет к постепенной деградации бизнес-модели, в результате чего компанию обходят конкуренты, и возможности сохранить рынок у нее не остается. В терминах денег это можно оценить через сокращение NPV бизнеса, в терминах скорости деградации - через траекторию компании в матрице BCG, но применительно ко всему бизнесу, а не просто его продуктам.
Новый станок обычно покупается из сугубо рациональных соображений - сломался старый станок или на старом станке нельзя произвести необходимую продукцию или вообще старый станок снят с обслуживания, его невозможно чинить и заменять расходные материалы.
А с IT системой другая ситуация, без нее работа идет и может продолжаться дальше.
Тема экономики внедрения ИТ-решений, не являющихся средством труда для основного вида деятельности, интересна тем, что выходит за пределы “подписка на ИТ-сервис”.
Отмечу, что я согласна с вышеуказанными комментариями в части того, что
1) сумма вложений в такие ИТ-решения могут сильно различаться в зависимости от множества факторов, вариативности самих инструментов (пула) и бюджета организации;
2) для расчета реальной экономии необходимо знать внутренние процессы организации и их экономики. Например, для экономиста организации затраты на SOC - это просто необходимые сопутствующие ИТ-инфраструктуре организации затраты.
Предполагается, что пул затрат на весомые ИТ-системы - это финвложения организации, результаты внедрения которых в явном виде не идут на погашение отвлеченных/привлеченных средств организацией на их приобретение.
Поэтому я бы, как экономист, поставила вопрос так: если внедрение было решено и возмещение этих затрат последует за счет доходов самой организации, то следует определить каковы минимальные требования к доходности всех направлений организации в совокупности на определенный бюджетный срок (бизнес-цикл).
Это следует из того, что улучшение производственных процессов в разных областях деятельности организации благодаря таким ИТ-решениям могут наступать с разной степенью дискреции, иметь кумулятивный эффект, т.е. не одномоментно. А вот сроки возвращения в оборот организации вложенных средств (через норму доходности) необходимо учитывать при формировании бюджета на такие ИТ-решения.
Всё перечисленное - о целях внедрения. Они должны быть продуманы, сформулированы и понятны всем участникам беседы.
Монетизация - другой вопрос. Ответ зависит от исходных данных нескольких категорий и периодов.
Необходимость продуктов и решений IT на предприятии - третий вопрос. Иногда это вопрос удобства. Иногда - обеспечения устройчивости и непрерывности. Иногда - выживания.
Как уже говорилось выше, для обсуждения экономического эффекта нужны реальные данные за период. Что-то можно прогнозировать. Жизнь поправит.
Не будем смешивать качество и функционал.
Если система работает без сбоев в соответствии с переданной документацией - к качеству претензий немного или нет.
О связи концепций, заложенных в продукте, с какими-то параметрами среды, в которой работает предприятие, нужно говорить максимально конкретно. Теи более - для систем масштаба предприятия.
Требования в части гибкости, масшибируемости и адаптируемости, уже давно не новость в отрасли. Но среду, в которой не работают никакие методы планирования, я не могу себе предстваить. Речь может идти об изменении методологии, горизонта и необходимых данных, но не об отмене планов как таковых - им нет замены. А для их подготовки и выполнения нужны вполне определённые инструменты.
Выбор на рынке IT делает покупатель. Он же постепенно накапливает данные для определения реальной эффективности и изменений каких-то параметров во времени, если важна динамика. Что бы вендоры не предлагали, сами у себя они не покупают.
Владимир, только что в другой теме где мельном упомянули CRM, вы спамите и реакламируете т.н. APQP (Advanced Product Quality Planning), да и вообще повсеместно, где надо и где не надо - уж в контексте CMR точно нет.
Вас не смущает, что оно же "не работает" в данной "бизнес-среде", или у вас 2 противоположные точки зрения в голове нормально уживаются?
Если вернуться к теме замены старого станка на новый станок, то это может иметь смысл сделать в случае реконструкции всего цеха и замены оборудования в нем.
То есть в случае массовой замены можно заодно заменить и то, в замене чего нет острой необходимости, но есть смысл произвести комплектную замену, чтобы больше к этому не возвращаться, и чтобы все функционировало в едином стандарте или стиле, кому какой термин нравится.
В таком случае может иметь смысл и внедрить IT-систему.
Если конечно бюджет позволяет.
Да. Разовью:
для управления рисками у автомобилистов (в рамках упоминаемого мною процесса APQP) есть методика FMEA (анализ видов последствий потенциальных отказов). В ней используется количественная мера оценки последствий риска - показатель ПЧР (Приоритетное Число Риска). Эта оценка получается умножением 3х переменных: Частота проявления х Вероятность обнаружения х Последствия реализации риска. Каждая переменная оценивается по 10-бальной шкале. Наиболее значимые по ПЧР риски подлежат обязательной проработке. Это один из инструментов управления на основе предупреждения несоответствий. Еще не произведен ни один экземпляр продукции, еще не заключены контракты с поставщиками, а работа с потенциальными рисками активно ведется.
Протяну связь к обсуждению проблемы потери "сделок" в публикации "Как проигрывают проектные продажи" и инструмента CRM: При заключении контрактов B2B в автомобильной отрасли, анализ FMEA (рисков при работе с поставщиком) обязателен - приоритет будет отдан тому поставщику, рисков работы с которым будет меньше. Этого маленького фрагмента большой работы APQP процесса при заключении "сделки" нет в CRM от слова СОВСЕМ. Это как пример влияния функционала IT продукта на "сделки" и бизнес-результаты.
Это в т.ч. и ответ на комментарий
Функционал определяет глобальное качество IT-продукта (большое Q), есть еще малое q - это отсутствие ошибок в его работе. Мой тезис - про глобальное несоответствие функцинала IT решения задачам предприятия (про большое Q).
Тут нет противоречий (если бы Вы знали APQP то легко бы ее отличили от задачи оперативного планирования производства - разный контекст). Это процесс разработки продукта и производства адаптированным к изменчивости спроса, требований и состояний в турбулентной бизнес-среде (аналог AGILE подходу к управлению разработкой в IT отрасли, только на порядки более сложный, т.к. приходится разрабатывать решения по продукту и его физическим свойствам, по технологии его производства, по производственной инфраструктуре (цеха, оборудование, инструменты), по материалам и логистике, ... в турбулентной среде.
Классические решения Конструктор придумал продукт, затем Технологи придумали как его производить, потом Производственники придумали какие мощности и как организовать, потом ... которые зашиты в шаблоны ERP, этот процесс по определению эмулировать не могут.
Это опять к теме влияния функционала IT решения на эффективность бизнеса
Не совпадаем. Я выступаю за то, чтобы рассматривать IT проект не как затратный (сможем потом как-то компенсировать затраты за счет общих доходов организации), а как Инвестиционный (самоокупаемый, понятно каким образом IT продукт позволит вернуть потраченные средства на его внедрение и поддержку).
Так это тоже рациональное экономическое решение - остановить производство один раз на комплексную реконструкцию, или перманентно останавливать его каждый раз, когда возникнет неизбежная потребность поэлементной замены оборудования. И согласен, денег на 1-ый вариант здесь и сейчас нужно много, возможно он при всей своей обоснованности, будет неприемлем из-за физической невозможности привлечения средств в таких больших объемах (например, ставки сейчас не гуманные).