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

«Каноничный» подход к организации работы ИТ или почему автоматизация не приносит денег

По большей части работа ИТ-подразделения в компании выстроена по одному сценарию: в определённый момент компания осознает необходимость внедрения информационной системы (далее – ИС) – будь то CRM, ERP, MES и т. д. – для последующего ожидаемо продуктивного управления бизнес-процессами. Для реализации задачи заинтересованным подразделением создается ТЗ, которое затем передается ИТ-специалистам. Они же, зачастую в кооперации с вендором, занимаются подбором решений, закупкой, внедрением и последующей передачей системы в полноценную эксплуатацию внутреннему заказчику, оставляя себе задачи по поддержке ИТ-инфраструктуры. Тогда как поддержка системы, как правило, осуществляется вендором.

При этом важно понимать, что экономический, финансово подкрепленный эффект от внедрения таких ИС описывается – и ожидается – как максимально положительный, достигаемый, однако, через n-ный период времени, и никаким образом не гарантируемый. Такой подход назвать плодотворным затруднительно: в описанных обстоятельствах сложно проследить появление ценности и бизнес-эффекта. «Мы внедрили систему ERP и в течение следующих трех лет сократим себестоимость нашего производства в 7 раз» – история, которой не суждено сбыться.

Более того, ключевой ошибкой внедрения всех описываемых систем является зеркалирование в них реальных процессов, происходящих на условном производстве (той самой «гембе»). Я имею в виду процессы по производству ценности, которые есть в абсолютно любой, даже самой непроизводственной компании. То есть, ключевая ценность продолжает создаваться конкретными людьми на конкретных местах, а новый сложный дорогостоящий инструмент используется как «записная книжка», куда конкретные исполнители заносят какие-то данные о результатах (в «хороших» внедрениях ещё и промежуточных) своей деятельности. В итоге имеем увеличение нагрузки на исполнителя (мало того, что ему надо работать свою работу, так теперь ещё что-то там вносить в новую непонятную систему) без очевидного экономического эффекта и отчёты (генерируемые новой информационный системой), которые отражают не реальное положение дел в компании, а видение этого самого положения дел через призму конкретных исполнителей на местах.

Но нужно ли уходить от классического «проектного» метода? Заранее отвечу, что нет, но в деталях раскрою этот ответ ниже, после разбора истории с портфелями.

Базовая схема цифровизации: «портфельный» подход к организации работы цифровых инструментов или «где деньги, Зин?»

В противовес вышеописанному «каноничному» подходу рассмотрим иной – портфельный, ключевое отличие которого в функциональности и проактивности участников и объектов процесса. Здесь ИТ-подразделение получает функциональную задачу по повышению эффективности работы с заранее выбранным производственным инструментом, с понятной экономикой (например, повышение среднего времени работы одного станка на 20 часов в месяц поспособствует увеличению общего объёма выработки на 80%). При этом задача не отдается на так называемый «внутренний аутсорс», но реализуется техническими специалистами совместно с заказчиком: в рамках производства генерируется некоторое количество гипотез о решении, из них выбираются лучшие, под выбранные гипотезы готовятся прототипы, на успешные прототипы – пилоты, а затем по успешным пилотам выпускается полноценный продукт в виде цифрового инструмента.

Ровно в этот момент, с запуском первого подобного инструмента, в компании появляется полноценный цифровой актив (как нечто, что однозначным образом помогает организации создавать ценность), а ИТ-подразделение к своей поддерживающей функции добавляет также и функцию зарабатывающую. Бизнес-эффект решения виден сразу – с самых первых дней его работы, и экономическая составляющая максимально прозрачна: видны как расходы на создание и поддержку инструмента, так и доходы, генерируемые с его помощью. С учётом того, что подобных функциональных задач в организации любых размеров – масса (и чем больших размеров организация, тем больше эта масса), портфель сгенерированных гипотез может быть очень объёмным.

Почему же именно «портфель», а не просто «список проектов»? Всё просто: этот самый «список проектов» имеет одну крайне важную характеристику, - доход, выраженный в конкретном изменении показателей, отвечающих за операционную прибыль, чего вы никогда ни в одном классическом ИТ-проекте не увидите (у проекта есть некий «результат», который где-то далеко за пределами проекта кто-то как-то должен ещё потрудиться перевести в деньги).

Дальше – больше. В нашем примере с уменьшением времени простоя производственного оборудования мы пришли к тому, что теперь наша выработка увеличена на 80%. Но теперь у нас встаёт второй вопрос – а как теперь всё это продать? И мы начинаем генерировать новые гипотезы о том, какими инструментами можно дооснастить нашу службу продаж, создавая ещё один цифровой актив, но уже не по переводу сырья в изделие, а по переводу изделия в деньги.

Так, портфельный подход к организации работы ИТ-подразделения, как и ИТ-специалистов в частности – это и есть та самая рабочая базовая схема цифровизации. А главное, что мы приходим к ответу на вопрос «где деньги»: деньги лежат в реализации цифровых инициатив, нацеленных на решение наших функциональных задач.

ИТ-проекты vs Цифровой портфель

Итак, ключевыми параметрами привычного многим компаниям ИТ-проекта являются: Результат (как правило сам по себе факт внедрения чего-либо), Стоимость, Время на реализацию. Показателями же Цифрового портфеля становятся: Цель (дельта целевого стратегического показателя, над которым мы работаем, например «размер активной клиентской базы» или «процент повышения дохода»), Расход на MVP (от англ. Minimal viable product – минимально жизнеспособный продукт), Time to Value (Время до получения MVP), Доход от MVP (в деньгах).

Учитывая эту разницу, можно переосмыслить существование ИТ-проектов в компании в сосуществовании их с «цифровым портфелем» и сделать следующий вывод: рассматривать ИТ-проекты как инфраструктурные, а портфель цифровых инициатив как экономическое обоснование для запуска инфраструктурного проекта. Как пример: если внедрение IoT на заводе стоит условные 150-200 миллионов рублей, то запускать этот проект можно только в том случае, если сгенерировано цифровых инициатив, утилизирующих IoT инфраструктуру с ожидаемым доходом за три (один, пять, семь, четыре – нужное подчеркнуть) года на сумму не менее, чем 400 миллионов.

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

Как работает цифровая трансформация

В большинстве случаев процесс работы ИС в компаниях антропоцентричен. Предприятие располагает:

  • во-первых, бизнес-процессом, протекающим непосредственно на производстве (например, в финансовом или плановом отделе);

  • во-вторых, живым процессом, по которому работают люди;

  • и, в-третьих, отражением второго в той или иной учетной информационной системе.

Де-факто получается следующее: даже при непредвиденном или нарочитом отключении предприятия от Сети процессы продолжат осуществляться в MS Word/Excel, журналах учета и т. п. Да, это отразится на текущей производительности, но процесс не «встанет» – ведь он изначально реализован в аналоговом мире, однако подобная схема работы далека от продуктивной, и бизнес-процессы, которые могут быть изначально реализованы исключительно в единой, цифровой реальности, раскладываются и пролонгируются на две такие реальности и более.

Хорошим примером цифровой трансформации при таких условиях работы является полноценное делегирование административных решений (решений в рамках нормированного бизнес-процесса) самой ИС. Рассмотрим на примере CRM системы.

Система, внедренная на предприятии с большим числом сотрудников, начинает «впитывать» в себя массивы данных – о себестоимости продукции/услуг, заказчиках, сыгранных контрактах, объёмах потенциальных сделок и т.д.. А далее, при наличии дополнительных моделей управления с возможностью учитывать большое количество взаимосвязей с данными в других системах (например, о штатном расписании в ИС HR, о состоянии средств производства в EAM и т.д.), получается следующее: система сама начинает решать, кому,  что и когда продавать, анализируя комплексно ситуацию «изнутри» (то есть целиком, с учётом максимально возможного числа входных параметров из совершенно разных плоскостей существования компании; так, как никогда не сможет сделать даже очень хороший сотрудник отдела продаж, имеющий гораздо более «узкий взгляд» на происходящее), тем самым существенно упрощая бизнес-процессы и автоматизируя работу, ставя ее «на конвейер». То есть с продавцов снимается самая сложная нагрузка – право выбора. Но тем сильнее становятся востребованы самые важные для продавцов навыки – навык продаж. И при условии следования указаниям системы в случае наличия аналитических моделей (вот тут появляется место для AI, ML, BigData и ещё миллиарда современных хайповых аббревиатур и понятий – всего того, что по какой-то причине огромное число людей считает цифровой трансформацией) достаточного качества, конечная экономическая эффективность работы коллектива организации вырастает кратно (а в отдельных случаях – на порядки).

А можно теперь посмотреть на CRM с другой стороны – со стороны службы HR. И тогда можно, например, на основании воронки продаж строить воронку найма (это когда рекрутёры обозначают производственным подразделениям кого, когда и в каких количествах им (производственникам) надо будет завести на рабочие места.  

Правда, чтобы всего этого достичь, нужно будет пройти через мощнейшую «ломку» осознания себя винтиками совершенно новой системы (очень часто тут вместо «системы» употребляют термин «бизнес-модель», но для меня он несколько шире, о чём я, возможно, через некоторое время напишу ещё одну статью) у всех сотрудников организации вплоть до самого высшего менеджмента. Системы, в которой все сотрудники нацелены на снабжение нового «главного информационно-аналитического станка» организации (те самые аналитические модели) максимально качественными данными. Увы и ах, но правило «shit in - shit out» в цифровом мире появилось не просто так и зависимость конечного изделия/результата от сырья на входе у «цифровых станков» гораздо выше, чем у старого доброго 1Е61ПМ.

Комментарии (1)


  1. XaBoK
    25.05.2022 15:47
    +1

    Вы описали классический Agile подход с внедрением MVP. Можете назвать это хоть портфелем, хоть фазой, хоть версией. При этом обещаете то (оптимизацию в разы), что сами назвали ошибочным ожиданием в начале. Немного не стыкуются куски. Ну и то мы про станки, то про CRM. А это важный нюанс. Цифровая трансформация производственного/физического процесса, зачастую не возможна, в отличии бюрократического процесса (планирование, продажа, поддержка). В первом случае система строится вокруг станка, во втором система и есть станок.

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