Как [пере]собрать цифровой портфель для выживания бизнеса

«КАНОНИЧНЫЙ» ПОДХОД К ОРГАНИЗАЦИИ РАБОТЫ ИТ ИЛИ ПОЧЕМУ АВТОМАТИЗАЦИЯ НЕ ПРИНОСИТ ДЕНЕГ

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



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

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

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

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

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

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

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

Продолжение читайте в блоге ICL Services на Хабр.