В компаниях часто случается следующая ситуация. Вложили миллионы рублей в новую корпоративную систему. Проходит полгода, собственник спрашивает: «А сколько денег она нам принесла?». Выясняется, что напрямую – нисколько. Возникает ложный вывод: проект оказался бесполезным. На самом деле, 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». Такие расчеты выглядят убедительно на бумаге, но далеко не всегда отражают реальную ценность.
Также читайте:
Вы не могли бы пояснить, что такое "глобальное качество"? И "глобальное несоотвествие"? Лучше - на паре примеров.
Если крупными мазками: возьмем предприятие, которое хотело бы решить одну или несколько уже известных проблем. При выборе вариантов решения используются сформулированные менеджментом предприятия критерии и принимается обоснованное решение в пользу выбора одного или нескольких продуктов, доступных на рынке (COTS, SaaS), или собственной разработки и интеграции своими силами или внешними ресурсами.
На другом предприятии сравнимого размера в той же отрасли критерии могут быть другими, решение приниматься иначе. У всех своя история, планы и идеи.
И примеров неплохо работающих систем во всех отраслях и компаниях - сколько угодно. В космос летаем, самолётами и поездами пользуемся, банки работают, такси заказываем, в библиотеку ходим и кино смотрим, не вставая с дивана, далее везде.
Как, впрочем, и проваленных проектов и систем, которые не оправдали ожидания, несмотря на все усилия. Но это ничего заранее не говорит о качестве продуктов и решений. Основные вопросы - к менеджменту. Причин неуспеха много, они известны.
Что с этим глобально (!) не так?
Скорее всего, есть третья точка зрения, которая допускает разные варианты в разных случаях.
Обычно на этом многие прорывы в работе сознания делаются.
Да вроде бы нет, за 6 страниц препираний, Владимир не допустил и мысли о том, что название ERP можно оставить как есть, у ERP очевидно ущербная концепция (которую под страхом ликвидации обязаны соблюдать "вендоры", от себя ни грамма не добавляя в решения), и пока IT отрасль не осознает свои ошибки и не сменит название на ERR, а так же не обучится у Владимира чему-то важному, ничего путного у нас не получится аксиоматически.
Просто для понимания хода мыслей Владимира:
https://www.e-xecutive.ru/education/korporativnoe-obuchenie/2000336-chemu-uchit-it-komandy-krome-tehnologii?page=6#comments
Это ваша позиция. Если вам нужна матмодель для расчета самоокупаемости внедрения IT-решений как инвестиционный проект, то становитесь в очередь, мне уже такой запрос поступал. Спасибо, "слона" не надо.
Все компании разные - с этим никто не спорит!
Более того, если возможно было бы провести такой эксперимент: "сравнить итоговые IT-релизы, например, 1С.Управление предприятием, которые были бы сделаны разными проектными командами от одного и того же франчайзи для одного и того же предприятия", уверен, они были бы тоже разными (точно не были бы идентичными).
Но я и не про эту понятно объяснимую изменчивость говорю.
Я говорю о том, что на самом деле, не смотря на выше описанную изменчивость, такие релизы для одного и того же предприятия были бы концептуально идентичными. Потому что они были бы разработаны на одинаковых шаблонах и одних и тех же методах решений (подетальное пооперационное планирование слева-направо (на склад), справа-налево (под заказ), периодичное или скользящее планирование, ...) заложенных платформой 1С. Управление предприятием.
Я говорю о том, что на самом деле, у этого многообразия решений - один "корень=ERP-движок" - подетальное пооперационное планирование на основе нормативов. Т.е. не смотря на вариативность методов, они все основаны на сущностях "план" и "норматив", без которых управления предприятием нет (даже если они не указываются в явном виде, то эмулируются системой из доступных данных (котловой метод, по наихудшему сценарию и т.п.) для получения необходимых сущностей "сгенерированный план" и "сгенерированный норматив" и далее реализуется ERP-логика управления предприятием).
Но тогда, с т.з. единого корня=ERP-движка, родственными/идентичными являются и все ERP-релизы для разных компаний (все построены на сущностях "план"/"норматив" как признаке родства). Понятно, что комбинация и конкретные настройки у всех предприятий разные, и вместе с тем, они все ERP-родственники.
Чем точнее соответствие факту плана и норматива, тем эффективнее ERP-управление предприятием. Эта приемлемая степень соответствия образует область эффективного применения этой управленческой парадигмы на основе сущностей "план/норматив".
Тогда встают закономерные исследовательские вопросы:
Теоретический ответ на вопрос "Существует ли такая среда" сконструировать очень легко - это среда, в которой "нет плана" (план никогда не совпадет с фактом) и "нет норматива" (норматив "плавает" в большом диапазоне значений - непрерывно меняется).
Можно ли "встретить" такую среду "в бизнес-природе" и имеет ли задача эффективного управления предприятиями в такой среде прикладное значение?
Как "показывает жизнь" (изменения характеристик бизнес-среды) практически во всех промотраслях наблюдается устойчивые тенденции: существенного повышения изменчивости (по срокам, по требованиям, номенклатуре, возможностям производства,...), уменьшение горизонтов точного прогнозирования (вплоть до таких величин, в которых привычные методы плановой подготовки не могут быть реализованы по срокам).
Т.е. среда такая существует в природе и имеет все большее прикладное значение. Я для краткого обозначения назвал ее "турбулентной", как антипод области эффективного применения ERP-парадигмы управления, котоую назвал "стационарной" средой. За классификационные названия не держусь.
Так как исследования и практические эксперименты/решения работы в такой турбулентной среде в промышленности ведутся уже давно, то это уже давно не пустая, а уже существенно огромная прикладная область знаний (в т.ч. описанных в виде международных стандартов и концепций).
Важно: эти решения (по практике реализации первопроходцами) по организации произвоства и методам управления существенно (вплоть до противоположны) отличны от тех, которые требуются/применяются в ERP-парадигме управления.
Родственный признак этого комплекса решений можно классифицировать как управление предприятием на основе реагирования (нет возможности планировать, значит, учимся быстро и эффективно реагировать). Я опять же "легкомысленно"))) назвал ее для целей быстрой классификации ERR - парадигмой управления
Получается, что как минимум на текущий момент времени можно выделить два подхода альтернативных по области эффективного применения и методам/принципам управления предприятием:
Исходя из существования этих двух альтернативных решений и формулируется мой тезис про "глобальное качество IT" как корректности применения управленческих парадигм в своих областях эффективного применения. Т.е. если предприятие находится в сационарной среде и применяет ERP IT-релиз для управления (соответственно ERR для турбулентной), то глобальное качество IT решения есть. Если же предприятие применяет не подходящий управленческий IT релиз для своей бизнес среды, то глобального качества IT решения не будет.
В качестве примера:
Ну или на "атомарном уровне":
План в виде последовательности заказов от клиентов в модели "подбрасывания кубика с 64K сторонами клиентами, какая грань выпала - такую и заказывают" - не прогнозируем (случайная последовательность). Поэтому попытка работать плановыми последовательностями/партиями - это гарантированные потери из-за:
а цепи поставок длинные, сроки производства большие, запасы по всем 64К цветам/комплектациям по цепям поставок создавать экономически нецелесообразно или физически не возможно, а клиенты ждать не будут (купят у конкурентов) и т.п. сложные условия для организации деятельности и управления (на порядки более сложные)
Так извратить смыслы и переврать позицию оппонента - это нужно очень постараться, и у Вас, Никита, - это отлично получается (не поздравляю с этим)!
Я призываю Вас учиться не у меня (хоть одну цитату сможете в подтверждение своего тезиса привести!?), а изучить (где и как - выбор за Вами, разве я Вас каким-либо образом ограничивал!? цитату пожалуйста?) те методы/решения, которые сейчас являются мейнстримом в промышленности, чтобы Вы смогли самостоятельно принять не голословное (все и так сделано), а обоснованное решение справиться ли ERP платформа с поддержкой этих решений, как много нужно "допиливать" ее тогда, не проще ли написать новую платформу ERR с нуля, а не впихивать в ERP невпихуемое!?
Разве это запрещенная тема для обсуждения? В чем здесь криминал с моей стороны!?
Я спокойно буду жить и смирюсь с тем, что Никита Андреев со мной не согласен!
И Вас призываю к тому же - угомонитесь уже, и избавьте меня от своих хамских нападок к любому моему комментарию?
Спасибо!
Иметь разные точки зрения - абсолютно нормально и полезно!
Поделюсь своими соображениями на тему "как есть слона":
1. В соответствии с концепцией Бережливое производство базовым критерием экономической эффективности организации производства является показатель Время производства - средний интервал времени с момента поступления комплекта материалов на единицу готовой продукции в производственную систему, до момента отправки изготовленной из этого комплекта материалов готовой продукции клиенту. Физический смысл понятен - чем быстрее оборачиваемость материальных активов в ПС, тем лучше экономическая эффективность (меньше затрат, меньше оборотных средств, быстрее возврат денег, выше прибыль - экономический эффект по каждому показателю можно оценить).
IT решение может/должно влиять на показатель Время производства (например: через уменьшение затрат времени на заказ логистической транзакции, на оповещение службы техподдержки на аварийное обслуживание оборудования, на оповещение команды наладчиков для проведения переналадки и т.п.)
Т.е. можно сделать оценку экономического эффекта от того, как изменится Время производства от внедрения такого то IT решения. Если Время производства не меняется, то это затратная инвестиция (возможно есть аргументация, почему его нужно сделать, но оценить экономическую эффективность сложно/не возможно). Если Время производства уменьшится, то экономический эффект от внедрения можно оценить, и в этом случае внедрение IT вписывается в рамки принятия решений для инвестиционных проектов.
Тогда для управления развитием IT нужно поставить цель - выбирать такие направления развития, которые будут приводить к снижению показателя Время производства = инвестиционный путь развития. Возможно, за счет полученных экономических эффектов от внедрения IT организовать финансирование прочих (в явном виде не влияющих на показатель Время производства) направлений в IT = модель самоокупаемости
2. В силу цифровизации и роботизации производства (станки сами себя диагностируют, сообщают об этапах процесса, и т.п.) IT решения становятся такой же инфраструктурной встроенной частью производства, как и станки. Поэтому рассуждения зачем/почему/выгодно ли покупать новый станок,можно/придется распространять по аналогии и к IT.
Т.е. ИМХО, тенденции таковы, что "слона" рано или поздно придется научиться "есть")))
Но, если в основе один и тот же продукт, а речь идёт о вариантах кастомизации, то именно такой результат и является правильным. Вы же не меняете базовый функционал.
Если выбран продукт из коробки, он работает так, как ему велели.
ERP - это категория продуктов с определённым функционалом. Обычно они модульные. Конкретная конфигурация выбирается заказчиком и кем-то в дальгейшем дорабатывается в зависимости от меняющихся требований и масштабов. Выбор большой, вариантов много. Нужны далеко не всем.
Никакой ERP-логики я не видел. Есть принципы и правила корпоративного управления, включающие планы, нормативы и прочее.
ERP-управление не существует. Мы же не говорим об Excel-управлении, CRM-управлении или MRP-управлении. Есть задачи, есть инструменты для их решения. Нет готового на рынке - сделай сам.
В чём смысл введения ERP-парадигмы как термина - честно не понимаю.
Единственное, почему Ford Motor предлагался только чёрный цвет для модели T - химический состав красок в то время. Черная сохла существенно быстрее всех прочих, что позволяло увеличить продажи в период роста спроса. Многих покупателей это устраивало, понятно,что не всех. И скоро благосостояние выросло, все полюбили разнообразие.
Как это связано с обсуждаемым?
Производство под заказ - не новость, так работают многие отрасли. Исторически - со времен первых мастерских и цехов. Из наших современников возьмите Dell, которая выросла как компания именно на идее сборки под заказ. JIT о другом, но тоже не новость уже несколько десятилетий.
Я предлагаю различать и оценивать две характеристики IT-решения
Вы, как я воспринял, говорите о п.1, а я пытаюсь найти решение для п.2
Одна из проблем выбора IT-решений по управлению предприятиями от разных вендоров:
Т.е.
В таких сложных условиях я предлагаю оценивать продукты прежде всего по степени их соответствия бизнес-среде предприятия, чтобы не попасть в зону заведомой неэффективности (когда сделан выбор управления предприятием на основе планирования, а предприятие работает в турбулентной среде, или выбрано управление на основе реагирования для стационарной среды)
ERP-логика - это последовательное развертывание и согласование подетальных пооперационных планов деятельности структурных подразделений предприятия (и его поставщиков) на основе прогноза/плана продаж. Цель - получить систему согласованных планов для всех структурных подразделений на период планирования.
ERP -управление, это управление на основе мониторинга (сравнения план/факт) степени реализации планов структурных подразделений и запуск цикла перепланирования при обнаружении существенных изменений.
Планы формируюися на основе нормативов (расхода материалов, времени обработки, времени поставки, ...)
Эта модель ERP управления жестко регламентирована своим базисом MRPII = основной своей составной частью, которая концепцию управления на основе планирования через план/норматив задает:
Все вместе, как Вы и назвали, - это и формирует концепцию управления предприятием (правила, принципы,...) на основе ПЛАНИРОВАНИЯ (рассчитываются и согласуются планы на основе нормативов) = это платформа для конструирования релизов под условия и специфику конкретных предприятий. И да, готовых решений, по определению, в "конструкторе" нет - из меню "деталей" каждый под себя разрабатывает "что хочет". Но это "что хочет" - это ограниченное "деталями конструктора" пространство решений.
Такая аналогия ERP - конструктор из треугольников, ERR - конструктор из кружочков:
Есть конструктор из деталей-треугольников, чтобы строить устойчивые прочные изделия (умеет рассчитывать сопромат, ориентирован не создание жестких связей,...). Этот конструктор не может эмулировать создание изделий для быстрого качения. Для этого нужен конструктор из деталей-кружочков, в которых есть принципы соединения кружочков в шасси, есть инструментарий расчета скорости движения, углов поворота, ...
Разнообразие вендоров конструкторов ERP: у каждого вендора свой уникальный конструктор (свой набор треугольничков по размерам, цвету, способам соединения,...), но при этом все эти конструкторы решают одинаковую задачу идентичными способами - строят выносливые сооружения из треугольников
Смысл говорить о разных подходах к управлению появился, как только стационарные среды работы пром предприятий, которые господствовали 300 лет, стали трансформироваться в турбулентные (вместо одной среды, стали две разных). Появилась необходимость понять различия в подходах, их устройство/механизмы, для того чтобы понять как трансформироваться, как управляться, ...
БИНГО! вот мы и нашли причину по которой FORD решил, что самое рациональное бизнес решение в такой среде (дефицит, купят все что произведут, поэтому можно "наплевать" на цветовые предпочнения потребителей, можно планировать работу "от своих возможностей" ) = стационарная среда в которой ERP - это то, что доктор прописал!
Конечно, производство под заказ не новость!
И те кто работал под заказ в стационарной среде, и продолжили работать под заказ в "турбулентной" - для них изменния не стали радикальными (хотя они все же есть), т.е. у них уже была выстроена система единичного потока заказов (очередь заказов) и навыки работы в такой системе, в т.ч. взаимодействию с поставщиками и потребителями.
А вот оказывается, что для тех предприятий, которые в эпоху стационарной среды попадали в разряд массового и разной степени серийности производства (не работали под заказ), перейти на позаказное производство - это оказалась задача со звездочкой: просто так с работы партиями по плану, на работу в единичном потоке случайных персонализированных заказов не перестроишься (в лоб решения по позаказному производству не применишь) - т.к. попытка лобового переноса приведет к катастрофическому падению производительности (как минимум из-за большего числа переналадок), при радикальном увеличении межоперационных запасов и столь же радикальном росте времени исполнения заказа и падении качества. Т.е. бизнесу - капут (продажи меньше в разы, стоимость/затраты больше в разы, сроки изготовления больше в разы, качество деградирует, клиенты ушли, занавес, расходимся).
А бизнес-задача выживания для этих предприятий (требования рынка) естественно другие: вырасти в объемах продаж, снизить стоимость/затраты, сократить размеры оборотных материальных активов при увеличении их оборачиваемости, радикально сократить сроки и повысить качество.
Еще раз: прямой перенос - бизнес-капут, Тойота и разработанные в промышленности решения, которые я рекомендую изучать - это новая организация производства м управления, которые позволяют перестроится на позаказное вытягивающее производство перестроится с выходом на требуемые для выживания бизнес-характеристиками.
И в классических позаказных производствах этих новаций/разработок не было (подсказок там не найти).
Вот зачем здесь Даймлер со своей ни разу не повторившейся за полгода цепью заказов!
Приятного аппетита!)))