Юрий Грибанов
Методология цифровой трансформации

Пять векторов управления

От бизнес-идеи к динамической модели управления на цифровой платформе

Введение. О тумане, цифровых фасадах и реальной трансформации

Я пишу эту книгу в состоянии, которое трудно передать словами. Это смесь усталости от многолетних наблюдений, горечи от тысяч разрушенных проектов и одновременно — жёсткой, холодной решимости.

С 2014 года я исследую цифровую трансформацию. Защитил докторскую. Создал научную группу. Консультировал десятки компаний — от малого бизнеса до крупнейших госкорпораций. И с каждым годом моё беспокойство только росло.

Потому что я видел одно и то же.

Миллиарды рублей, потраченные на «цифровую трансформацию». Килограммы отчётов с красивыми графиками. Тысячи «цифровых платформ», которые никто не использует. Горы серверов, на которых крутятся никому не нужные приложения.

И главное — полное отсутствие результата.

Показатели не растут. Процессы не ускоряются. Клиенты не становятся лояльнее. Сотрудники ненавидят новые системы и обходят их любыми способами.

А руководители продолжают говорить: «Мы провели цифровую трансформацию».

Нет. Не провели.

Вы купили дорогую имитацию. Вы построили цифровой фасад. Вы автоматизировали хаос и назвали это трансформацией.

Почему 84% проектов проваливаются

Исследования говорят: 84% инициатив в области цифровой трансформации терпят неудачу. 70% цифровых преобразований не приносят ожидаемых результатов.

Я не верю в эти цифры.

Они занижены.

Я видел проекты, которые формально считались «успешными» — системы внедрены, бюджеты освоены, отчёты сданы. Но бизнес не изменился. Ни на йоту.

Это не «успех». Это «дорогостоящая имитация».

Почему это происходит? Я отвечу кратко.

Потому что никто не понимает, что такое цифровая трансформация на самом деле.

Её путают с автоматизацией. Путают с цифровизацией. Сводят к закупке систем управления взаимоотношениями с клиентами или мобильных приложений. Делегируют IT-отделам, которые не имеют полномочий менять бизнес-процессы и KPI.

А главное — начинают не с того конца.

Что вы найдёте в этой книге

Эта книга — не учебник. Не сборник «лучших практик». Не мотивационный трактат.

Это методология. Жёсткая, пошаговая, проверенная.

Методология, которая начинается с понятийного аппарата — потому что без единого языка невозможно никакое действие. Методология, которая строит цифровую трансформацию как последовательность пяти векторов, а не как хаотичный набор инициатив.

Вот эти пять векторов:

Вектор 1. Продукт. Вы определяете, что именно вы делаете и для кого. Какую ценность создаёте. Как измеряете успех.

Вектор 2. Сквозной бизнес-процесс. Вы проектируете процесс создания этой ценности — от клиента до клиента, через все подразделения.

Вектор 3. Роли и интерфейс пользователя. Вы вычленяете роли из процесса и рисуете интерфейс для каждой роли. Этот интерфейс, утверждённый бизнесом, становится техническим заданием для IT.

Вектор 4. Цифровая платформа. IT строит платформу по этому заданию. Не придумывает, не «улучшает», а строит ровно то, что заказано.

Вектор 5. Динамическая модель управления. Платформа внедряется в реальную деятельность, собирает данные, анализирует отклонения, формирует управляющие воздействия. Система начинает настраиваться сама.

Это всё.

Не магия. Не «искусственный интеллект решит всё за нас». Не «облака спасут мир».

А чёткая, инженерная, дисциплинированная работа.

Ключевые тезисы, которые нужно принять до чтения

Прежде чем двигаться дальше, я обязан предупредить вас. Эта книга будет неудобной. Она будет ломать ваши привычные представления. Готовьтесь.

Тезис первый. Цифровая трансформация — это не про технологии. Это про смену модели управления. Если вы не меняете модель управления — вы не проводите цифровую трансформацию. Вы занимаетесь автоматизацией или цифровизацией. И это нормально — но не называйте это цифровой трансформацией.

Тезис второй. Заказчик цифровой трансформации — бизнес, а не IT. IT получает задание, но не придумывает его. Если вы отдали цифровую трансформацию IT-директору — вы уже проиграли.

Тезис третий. Интерфейс пользователя, согласованный с бизнесом, — это и есть техническое задание. Не текстовый документ на двести страниц. А прототип, который бизнес увидел, потрогал и утвердил. Только после этого IT начинает писать код.

Тезис четвёртый. Сначала процесс, потом автоматизация. Нельзя автоматизировать хаос. Сначала спроектируйте идеальный процесс. Потом автоматизируйте его.

Тезис пятый. Измеряйте способности к будущему, а не деньги прошлого. ROI не работает для цифровой трансформации. Измеряйте скорость адаптации, эффективность использования ресурсов, антихрупкость.

Примите эти тезисы. Или закройте книгу. Третьего не дано.

Кому адресована эта книга

Эта книга для тех, кто принимает решения и несёт ответственность.

Для собственников и генеральных директоров — тех, кто выделяет бюджеты и отвечает за результат. Вы узнаете, почему цифровая трансформация не может быть делегирована IT, и как лично провести компанию через пять векторов.

Для руководителей цифровой трансформации (CDTO) — тех, кто отвечает за реализацию. Вы получите пошаговую методологию, чек-листы и шаблоны документов.

Для бизнес-аналитиков и продуктовых менеджеров — тех, кто проектирует процессы и интерфейсы. Вы узнаете, как вычленять роли, рисовать прототипы и формулировать техническое задание.

Для IT-директоров и архитекторов — тех, кто строит платформу. Вы получите чёткое понимание, что именно от вас требуется, и почему нельзя начинать разработку без утверждённого прототипа.

Если вы ищете лёгких рецептов — закройте книгу. Здесь их нет. Если вы готовы к серьёзной, трудной, но благодарной работе — читайте дальше.

Как построена эта книга

Книга разделена на три части.

Часть первая. Понятийный аппарат. Здесь я ввожу все ключевые термины. Без этого мы не сможем говорить на одном языке. Каждое определение разобрано по словам, каждое слово имеет смысл. Особое внимание — цифровой зрелости, понятию, которое на рынке исковеркано до неузнаваемости.

Часть вторая. Методология пяти векторов. Это сердце книги. Пять глав — пять векторов. Каждый вектор имеет чёткий вход, конкретные шаги и измеримый результат. Результат предыдущего вектора — вход для следующего. Пропустить нельзя. Поменять порядок нельзя.

Часть третья. Управление изменениями и запуск. Здесь я рассказываю, как преодолеть сопротивление людей, как менять KPI и регламенты, как запускать пилотные проекты и масштабировать успех. А также — как измерить результат, если старый добрый ROI не работает.

В конце книги — глоссарий и чек-листы. Вы можете использовать их в своей работе.

Моё обещание читателю

Я не буду вас развлекать. Не буду рассказывать байки «как я помог одной компании». Не буду обещать «лёгкий путь к миллиарду».

Я буду давать методологию. Жёсткую, местами сухую, но рабочую.

Каждый тезис в этой книге проверен практикой. Каждая ошибка, о которой я пишу, совершена кем-то из моих клиентов (или мной самим). Каждый принцип выстрадан.

Я не гарантирую успеха. Успех зависит от вашей воли, дисциплины и готовности меняться. Но я гарантирую: если вы будете следовать этой методологии, вы не потратите деньги впустую. Вы не построите «цифровой фасад». Вы проведёте реальную цифровую трансформацию.

Юрий Грибанов

Москва

Часть первая. Понятийный аппарат

В этой части я ввожу все ключевые термины, без которых невозможно говорить о цифровой трансформации. Без единого языка невозможно ни понимание, ни действие. Каждое определение будет развёрнуто — слово за словом, смысл за смыслом. Читатель, освоивший эту часть, уже будет знать о цифровой трансформации больше, чем большинство руководителей.

Введение. О словах, которые убивают проекты

Прежде чем строить новую систему управления, мы должны договориться о словах.

Это не бюрократическое требование. Это не «давайте унифицируем терминологию для удобства отчётности». Это вопрос выживания.

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

Они говорят на разных языках. Они используют одни и те же слова, но вкладывают в них разный смысл. Они искренне уверены, что договорились. Но это иллюзия.

Это — вавилонское столпотворение. И оно разрушает проекты.

Пока мы говорим на разных языках, мы не можем двигаться в одном направлении. Пока «цифровая трансформация» для собственника — «рост капитализации», для IT-директора — «обновление серверного парка», для руководителя производства — «ещё одна отчётность», а для финансового директора — «статья расходов», — никакой трансформации не будет. Будет имитация. Будет хаос. Будут потрачены миллиарды.

Вот почему я начинаю эту книгу не с «быстрых побед», не с «успешных кейсов», не с «вдохновляющих историй». Я начинаю с понятийного аппарата.

Это скучно? Возможно.

Это трудно? Да.

Это необходимо? Абсолютно.

Что вы найдёте в этой части

В этой части я ввожу все ключевые понятия, которые будут использоваться в книге. Каждое определение я разбираю на составные части. Объясняю каждое слово. Показываю, как это понятие связано с другими. Привожу примеры. Указываю типичные ошибки.

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

После прочтения этой части у вас не останется «белых пятен».

Вы будете знать:

Что такое цифровая экономика — и почему это «система управления», а не «совокупность технологий».

Чем цифровая трансформация отличается от цифровизации и автоматизации — и почему их путаница — главная причина провалов.

Кто такой Идеолог — и чем он отличается от собственника, топ-менеджера и архитектора.

Что такое динамическая модель управления (ДМУ) — и чем она отличается от статических отчётов и KPI.

Что такое цифровая зрелость — и почему это не «уровень автоматизации», а комплексный индикатор развития управления, ИТ и культуры.

Что такое онтология — и почему без её смены нет трансформации.

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

Как читать эту часть

Я рекомендую читать эту часть не торопясь. Не пролистывайте определения, даже если вам кажется, что вы знаете, о чём речь.

Каждое определение в этой книге — не случайный набор слов. Каждое слово в определении выбрано не случайно. Я объясняю, почему использовано именно это слово, а не другое. Потому что замена слова меняет смысл. А изменение смысла меняет действия. А изменение действий меняет результат.

Возьмите ручку. Подчёркивайте. Делайте пометки на полях. Возвращайтесь к уже прочитанному. Сверяйтесь с примерами.

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

В конце части — контрольные вопросы. Ответьте на них честно. Если не можете ответить — перечитайте главу.

Фундамент, на котором всё держится

Представьте, что вы строите дом.

Можно начать с крыши. Поставить красивые стропила, покрыть дорогой черепицей. Дом будет выглядеть как дом. Пока не подует ветер.

Можно начать со стен. Возвести их из самого современного кирпича. Дом будет казаться надёжным. Пока не пойдёт дождь.

А можно начать с фундамента. Скучного, незаметного, уходящего глубоко в землю. На него уходит много времени и сил. Его не видно, когда дом готов. Но именно он держит всё остальное.

Эта часть — ваш фундамент.

Без неё все последующие главы — просто красивые слова. Без неё методология пяти векторов рассыплется при первой же нестандартной ситуации. Без неё вы будете имитировать движение, а не двигаться.

Я не обещаю, что эта часть будет лёгкой. Она требует сосредоточенности, вдумчивости, дисциплины. Но я обещаю: после неё вы будете знать о цифровой трансформации больше, чем 99% руководителей, которые «внедряют цифру».

Глава 1. Базовые определения

«Цифровая трансформация — это не про технологии. Это про смену модели управления. Если вы не меняете модель управления — вы не проводите цифровую трансформацию. Вы занимаетесь автоматизацией или цифровизацией. И это нормально — но не называйте это трансформацией».

Введение. Три слова, которые нельзя путать

В этой главе я даю определения трём процессам, которые постоянно путают – это цифровизации, автоматизации и цифровой трансформации.

Путаница этих понятий — причина многих провалов проектов, которые называют «цифровой трансформацией», но таковыми не являются.

Я видел это много раз. Собственник компании говорит: «Мы начинаем цифровую трансформацию». Выделяется бюджет. Создаётся команда. Через год система внедрена. Отчёты сданы. Бюджет освоен.

А бизнес-показатели не выросли.

Потому что на самом деле провели не трансформацию. Провели автоматизацию. Или цифровизацию. Или, что чаще всего, — дорогостоящую имитацию, не являющуюся ни тем, ни другим, ни третьим.

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

Разница не академическая. Она практическая. Она меняет цели, методы, ресурсы, результаты и — самое главное — роль каждого участника.

Что вы найдёте в этой главе

Я даю определения не только трём ключевым процессам, но и понятиям, которые лежат в основе всего дальнейшего изложения:

Хозяйствующий субъект — универсальное понятие, которое охватывает и индивидуального предпринимателя, и транснациональную корпорацию, и государство. Без него мы не можем говорить о масштабировании методологии.

Ресурс — в моём определении это не «труд, земля, капитал», как в учебниках XIX века. Ресурс — это любой элемент системы, потенциал которого может быть использован для достижения цели. Данные, время, внимание — тоже ресурсы. И часто они важнее денег.

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

Идеолог — ключевая фигура цифровой экономики. Не собственник, не топ-менеджер, не архитектор. Идеолог задаёт цели и ценности. Он — источник замысла. Без него система слепа.

Цифровая платформа — целостный аппаратно-программный комплекс. Не «облако», не «набор сервисов», не «интеграция». Целостная среда, в которой живёт и работает динамическая модель управления.

Динамическая модель управления (ДМУ) — постоянно обновляемое цифровое отражение управляемого объекта. Не статический план, не отчёт, не KPI. Живая модель, которая учится, адаптируется, предсказывает.

Каждое слово имеет смысл

Я разбираю каждое определение до уровня «каждое слово имеет смысл».

Почему это важно?

Потому что в управленческой литературе сложилась традиция, что определения даются «для галочки». Автор пишет: «Цифровая трансформация — это процесс изменений...» — и идёт дальше. Читатель проглатывает определение, не задумываясь.

Я поступаю иначе.

Каждое определение в этой главе — результат многолетней работы. Я подбирал каждое слово так, чтобы оно несло смысловую нагрузку. Я проверял, нельзя ли его убрать или заменить. Нельзя.

Поэтому я не просто даю определение. Я объясняю, почему выбрано именно это слово, а не другое. Я показываю, что случится, если его заменить. Я привожу примеры правильного и неправильного понимания.

Читатель, освоивший эту главу, получит понятийный аппарат, который не уступает по строгости академическим стандартам, но при этом остаётся пригодным для практического использования.

Это не «теория ради теории». Это инструмент. Вы будете использовать эти понятия каждый день, принимая решения о том, куда вкладывать миллионы, кого нанимать, что автоматизировать, а что трансформировать.

Мост между теорией и практикой

Академическая строгость нужна, чтобы не ошибаться в фундаментальных вещах. Практическая применимость нужна, чтобы не застревать в бесплодных дискуссиях.

Я строю мост между ними.

Определения в этой главе достаточно строги, чтобы быть однозначными, и достаточно просты, чтобы быть понятными человеку без степени доктора наук.

Вы сможете объяснить разницу между цифровизацией и цифровой трансформацией своему подчинённому. Вы сможете доказать собственнику, почему «внедрение системы управления взаимоотношениями с клиентами» — это не трансформация. Вы сможете объяснить IT-директору, почему он не может начинать разработку без утверждённого прототипа.

Потому что у вас будет язык. Чёткий, однозначный, обоснованный.

1.1. Хозяйствующий субъект

Начнём с самого широкого понятия — того, к чему вообще применима цифровая трансформация.

Хозяйствующий субъект — это любой носитель экономической деятельности, который обладает ресурсами, принимает решения и несёт ответственность за результаты своей деятельности.

Разберём это определение по словам.

«Любой носитель экономической деятельности» — это значит, что понятие охватывает всё, начиная от индивидуального предпринимателя, который торгует на рынке, до транснациональной корпорации с оборотом в триллионы долларов, от муниципалитета до государства в целом. Слово «любой» здесь означает универсальность. Методология работает на любом масштабе.

«Который обладает ресурсами» — хозяйствующий субъект не существует в вакууме. У него есть то, чем он распоряжается – это деньги, люди, оборудование, информация, время. Без ресурсов нет деятельности. Подробно о видах ресурсов — в главе 3.

«Принимает решения» — это ключевой признак субъекта. Он не просто реагирует на внешние раздражители. Он выбирает из альтернатив. Он ставит цели. Он определяет, что делать, а чего не делать. Пассивный наблюдатель, который ничего не решает, не является субъектом. Он — объект.

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

Почему это понятие важно

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

Частные случаи, которые мы привыкли использовать

В повседневной речи и даже в управленческой литературе мы используем разные слова для разных масштабов и типов организаций.

Вот эти слова:

«Компания» — обычно о коммерческой организации, часто средней или крупной.

«Предприятие» — чаще о производственном объекте, заводе, фабрике.

«Организация» — более широко, но чаще о некоммерческих структурах или бюджетных учреждениях.

«Фирма» — о небольшом или среднем коммерческом предприятии.

«Корпорация» — о крупной, часто международной структуре с акционерным капиталом.

«Государство» — о суверенной политико-экономической системе.

«Учреждение» — о бюджетной или государственной структуре.

«Индивидуальный предприниматель» — о физическом лице, ведущем бизнес без образования юридического лица.

Каждое из этих слов — частный случай. Оно описывает конкретный тип хозяйствующего субъекта, но не покрывает все типы.

И в этом кроется проблема.

Проблема частных случаев

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

Методология ломается.

Представьте, что методология написана для «корпораций». Вы пытаетесь применить её к малому бизнесу с пятью сотрудниками. И вдруг понимаете, что предлагаемые инструменты и процедуры нереалистичны для такого масштаба. «Совет директоров»? У ИП его нет. «Департамент информационных технологий»? Его нет. «Комитет по цифровой трансформации»? Смешно.

Методология снова ломается.

В чём проблема? В том, что методология привязана к частному случаю. Она не универсальна.

Решение: родовое понятие

«Хозяйствующий субъект» — это родовое понятие. Оно охватывает все перечисленные выше частные случаи и множество других.

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

Универсальность требует универсального языка

Когда мы говорим о цифровой трансформации, мы должны понимать, что методология должна работать на любом масштабе.

Она должна работать для индивидуального предпринимателя, который торгует на рынке, потому что он тоже должен трансформироваться, чтобы выжить.

Она должна работать для малого бизнеса с десятью сотрудниками, потому что это самая многочисленная категория.

Она должна работать для средней производственной компании, потому что именно здесь чаще всего возникает потребность в трансформации.

Она должна работать для корпорации с тысячами сотрудников, потому что они уже начали этот путь, но часто идут неправильно.

Она должна работать для государственного учреждения, потому что государство тоже должно меняться.

Она должна работать для региона и государства в целом, потому что цифровая экономика не признаёт границ между «бизнесом» и «государством».

Если методология привязана к одному масштабу или одному типу организации, она бесполезна для остальных.

«Хозяйствующий субъект» даёт нам язык, который работает везде.

Пример: как это работает на практике

Возьмём простой термин «владелец процесса». В коммерческой компании это может быть «директор департамента». В государственном учреждении — «начальник управления». В ИП — сам предприниматель. В корпорации — «вице-президент по направлению».

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

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

Универсальный язык не привязывается к деталям, которые меняются от случая к случаю. Он выделяет суть.

Что вы получаете, используя понятие «хозяйствующий субъект»

Возможность масштабировать методологию. Вы можете применять её и к ИП, и к государству. Логика не меняется. Меняется только детализация и время.

Чистоту мышления. Вы перестаёте цепляться за слова «компания», «организация», «предприятие» и спорить о том, какое из них подходит. Вы используете одно слово для всего.

Фокус на сути. Вы перестаёте думать об организационно-правовой форме и начинаете думать о том, что действительно важно: ресурсы, цели, решения, ответственность.

Язык, понятный всем. Юрист говорит «ООО», экономист — «предприятие», управленец — «организация». Вы говорите «хозяйствующий субъект». И все понимают, о чём речь, потому что понятие родовое и нейтральное.

Главный тезис

«Цифровая трансформация не спрашивает, как называется ваша организация — „компания“, „предприятие“, „корпорация“ или „государство“. Она спрашивает, обладаете ли вы ресурсами, принимаете ли решения и несёте ли ответственность. Если да — методология работает. «Хозяйствующий субъект» — это язык, на котором цифровая трансформация говорит с любым масштабом. Без этого языка мы обречены создавать отдельные методологии для каждого случая — и каждый раз начинать сначала».

1.2. Ресурс

Следующее базовое понятие — то, чем субъект распоряжается.

Ресурс — это любой элемент системы, потенциал которого может быть использован для достижения цели управляющего субъекта.

Разберём определение.

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

«Потенциал которого» — важное уточнение. Ресурс — это не то, что уже использовано. Это то, что можно использовать в будущем. Зарплата сотрудника, которую вы ещё не выплатили, но можете направить на обучение — это потенциал. Информация, которую вы ещё не проанализировали — потенциал.

«Может быть использован» — возможность, а не необходимость. Ресурс не обязан быть использован. Он может лежать мёртвым грузом. Но если его нельзя использовать в принципе — это не ресурс. Бесполезный элемент системы — не ресурс, а балласт.

«Для достижения цели» — ресурс всегда определён относительно цели. Одно и то же количество денег может быть ресурсом для запуска нового продукта и не быть ресурсом для завоевания рынка (если его недостаточно). Без цели понятие «ресурс» теряет смысл.

«Управляющего субъекта» — ресурс всегда чей-то. Он принадлежит субъекту или находится в его распоряжении. Нет «ресурсов вообще». Есть ресурсы конкретного хозяйствующего субъекта.

Ключевое отличие от классического определения

Я намеренно дал расширенное определение ресурса. Теперь я должен объяснить, почему это расширение критически важно. Потому что без него вы будете мыслить категориями XIX века, пытаясь управлять цифровой экономикой.

Классическое определение: закрытый набор

В классической экономической теории ресурсы — это «труд, земля, капитал, предпринимательские способности».

Этот список сформировался в индустриальную эпоху. Он описывал экономику заводов, фабрик, железных дорог и сельского хозяйства. Он работал. Он был достаточен для своего времени.

Но обратите внимание на главную характеристику этого списка: он закрыт.

Четыре элемента. Точка. Ничего нового добавить нельзя. Всё, что не входит в этот список, в экономической теории считается «внешними факторами» — то есть чем-то, что находится за пределами системы. Влияет, но не является её частью. Учитывать? Да. Управлять? Нет.

И вот здесь начинается главная проблема.

Что классическая экономика оставила за скобками

Классическая экономика не учитывает как ресурсы (или считает «внешними факторами»):

Данные. В индустриальную эпоху данные были побочным продуктом — учёт для налоговой, ведомости для начальника. Сегодня данные — это топливо для управления. Без них вы слепы. Но в классической четвёрке «труд, земля, капитал, предпринимательские способности» для данных нет места.

Время. В классике время — это просто горизонт планирования. Но время — это самый ограниченный ресурс. Деньги можно напечатать или занять. Время — нет. Классическая экономика этого не учитывает.

Внимание. У руководителя, у менеджера, у сотрудника есть ограниченный ресурс внимания. Вы можете иметь лучшие данные в мире, но если никто не обратит на них внимания — они бесполезны. Классика игнорирует этот ресурс.

Репутация. Репутация компании или человека влияет на продажи, на найм, на партнёрства. Это реальный актив. Но в балансе вы его не увидите. Классика не считает репутацию ресурсом.

Доверие. Доверие между партнёрами снижает транзакционные издержки. Доверие клиентов увеличивает лояльность и готовность платить больше. Но классическая экономика не знает, что с этим делать.

Все эти элементы — данные, время, внимание, репутация, доверие — в цифровой экономике становятся главными ресурсами.

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

Сравнительная таблица

Почему расширение определения — не «теоретизирование», а практическая необходимость

Вы можете подумать: «Юрий, зачем мне это расширение? Я бизнес веду, а не философствую».

Отвечу прямо.

Если вы не считаете данные ресурсом, вы не будете их собирать, хранить в порядке и использовать для решений. Вы будете полагаться на интуицию. Конкуренты, которые используют данные, будут принимать решения быстрее и точнее. Вы проиграете.

Если вы не считаете время ресурсом, вы не будете его измерять и оптимизировать. Вы будете тянуть с решениями, затягивать согласования, тратить часы на совещания, которые можно было провести за 15 минут. Конкуренты, которые управляют временем, будут быстрее. Вы проиграете.

Если вы не считаете внимание ресурсом, вы будете заваливать сотрудников отчётами, уведомлениями, лишними встречами. Их внимание распылится. Они перестанут замечать главное. Конкуренты, которые берегут внимание, будут эффективнее. Вы проиграете.

Если вы не считаете репутацию и доверие ресурсами, вы будете экономить на качестве, на сервисе, на честности. Клиенты уйдут к тем, кому доверяют. Партнёры — к тем, у кого репутация выше. Вы проиграете.

Расширение определения «ресурс» — это не игра в слова. Это признание реальности, в которой мы уже живём. Классическая экономика описывала мир XIX–XX веков. Мир изменился. Определения должны измениться вместе с ним.

Открытый список

В моём определении ресурса — «любой элемент системы, потенциал которого может быть использован для достижения цели» — список ресурсов открыт.

Вы сами определяете, что для вас является ресурсом.

Для логистической компании ресурсом может быть «свободный километраж грузовиков».

Для интернет-магазина — «время курьера».

Для колл-центра — «терпение оператора». Для стартапа — «энтузиазм команды».

Всё, что можно измерить и использовать для достижения цели, — ресурс.

Это открытое определение даёт вам свободу. Не ждите, пока экономисты «включат» что-то в учебники. Включайте сами.

Главный тезис

«В цифровой экономике главные ресурсы не входят в классический список «труд, земля, капитал, предпринимательские способности». Данные, время, внимание, репутация, доверие — вот что определяет успех. Тот, кто продолжает мыслить четырьмя ресурсами XIX века, обречён проиграть тому, кто мыслит открытым списком XXI века».

1.3. Данные. Определение

Данные — это зафиксированная информация о состоянии объекта управления, его свойствах, поведении или окружающей среде, которая может быть использована для принятия управляющих решений.

Разберём это определение по словам. Каждое слово здесь выбрано не случайно.

«Зафиксированная» — данные не существуют в «чистом виде» как эфир. Они всегда записаны где-то: на бумаге, в памяти компьютера, в показаниях датчика, в голове сотрудника. Фиксация позволяет передавать данные во времени (хранить историю) и в пространстве (передавать от одного участника другому). Если информация не зафиксирована — это не данные, это впечатление, мнение, воспоминание. Оно может быть верным, но его нельзя проверить, им нельзя поделиться, на него нельзя опереться в споре.

«Информация о состоянии объекта управления» — данные описывают реальность. Не придуманную, не желаемую, а ту, которая есть. Состояние — это «здесь и сейчас»: температура в реакторе, остаток товара на складе, текущая загрузка станка. Данные не говорят о том, «что должно быть». Они говорят о том, «что есть».

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

«Поведении» — действия, события, изменения: сколько заказов обработал менеджер за день, как часто ломается оборудование, когда клиент последний раз совершал покупку, какой маршрут выбрал курьер. Поведение — это динамика.

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

«Которая может быть использована для принятия управляющих решений» — это самое важное в определении. Данные — это не «архив» и не «отчётность ради отчётности». Данные собираются для того, чтобы на их основе принимать решения. Если данные не используются для решений — они бесполезны. Это не данные. Это информационный мусор. Хороший критерий: если вы не можете ответить на вопрос «какое решение мы примем на основе этих данных?», значит, вы собираете их зря.

Данные — это не «новая нефть»

Я должен остановиться здесь и разрушить одну опасную метафору, которая сегодня кочует из статьи в статью, из презентации в презентацию.

«Данные — это новая нефть».

Это звучит красиво. Это запоминается. Это создаёт образ богатства, которое можно добыть, продать, на котором можно построить империю.

И это глубоко ошибочно.

Метафора «данные — новая нефть» ориентирует на добычу, хранение и продажу данных. Она порождает «нефтяные вышки» в виде дата-центров и «нефтяные компании» в виде брокеров данных.

Но нефть и данные имеют разную онтологическую природу. Сравните:

Нефть — пассивный, исчерпаемый товар. Её ценность реализуется в акте продажи. После использования она исчезает. Её экономическая жизнь подчиняется линейной модели: добыча → переработка → продажа → потребление.

Данные — активный, неисчерпаемый ресурс. Их ценность раскрывается в акте использования для управления. Один и тот же набор данных может использоваться бесконечно много раз, при этом порождая новые данные. Их применение носит созидательный и синергетический характер.

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

Поэтому я отвергаю эту метафору.

Данные — это не нефть. Данные — это нервная система управления. И если вы хотите управлять, вы не продаёте нервную систему. Вы её используете.

Цепочка превращения данных в управляющее воздействие

Это самый важный механизм во всей книге. Поймите его — и вы поймёте, как работает управление в цифровой экономике.

Цепочка: Сырые данные → Верифицированные данные → Информация → Управляющее воздействие

Пропуск любого этапа ведёт к катастрофе. Ниже я разбираю каждый этап подробно.

Этап 1. Сырые данные

Определение: Сырые данные — это разрозненные, несистематизированные, необработанные факты, показания датчиков, сообщения, цифры в таблицах без контекста.

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

Примеры сырых данных:

«Температура в цехе +39°C»

«Сотрудник Иванов опоздал на 15 минут»

«Получено 100 негативных отзывов на портале»

«Давление в трубопроводе 7,5 атмосферы»

«Заказов вчера — 543»

Проблемы сырых данных:

Они могут быть неточными (датчик сломался, человек ошибся).

Могут быть неполными (измеряем не то, что нужно).

Могут быть противоречивыми (один датчик показывает +39°, другой — +35°).

Могут быть бессмысленными вне контекста (что значит «опоздал на 15 минут» — это много или мало для данного процесса?).

Характерная ошибка: Руководитель видит цифру и сразу принимает решение. Не проверив источник. Не сопоставив с другими данными. Не поняв контекст.

Вопрос для самопроверки: «Могу ли я принять решение, основываясь только на этих сырых цифрах, не зная их источника, контекста и достоверности?». Ответ всегда — нет.

Последствия остановки на этом этапе: Управление вслепую. Вы принимаете решение, не понимая, правдивы ли данные. Это как стрелять в темноте — можете попасть, но скорее всего нет. И даже если попали — не сможете повторить успех, потому что не знаете, в чём было дело.

Этап 2. Верифицированные данные

Определение: Верифицированные данные — это сырые данные, которые прошли проверку на достоверность, очистку от ошибок и выбросов, подтверждение из нескольких источников.

Что происходит на этом этапе:

Проверка источника: надёжен ли он? Не ангажирован ли?

Проверка технической исправности: не сломан ли датчик?

Сравнение с другими источниками: сходятся ли показания?

Отсев статистических выбросов: не аномалия ли это?

Проверка на соответствие здравому смыслу: может ли такое быть?

Пример превращения:

Характерная ошибка: Руководитель принимает данные на веру, потому что «так сказал начальник отдела» или «так написано в отчёте». Не перепроверяет. Не требует доказательств.

Вопрос для самопроверки: «Я уверен, что эти данные правдивы? Я могу указать источник и метод проверки?».

Последствия остановки на этом этапе: Управление на основе лжи. Вы принимаете решение, уверенные в его обоснованности, но фундамент — данные — может быть ложным. Хорошее решение на плохих данных — это плохое решение. Это как строить дом на болоте: фасад красивый, но конструкция рухнет.

Этап 3. Информация

Определение: Информация — это верифицированные данные, помещённые в контекст, установившие причинно-следственные связи, отвечающие на вопросы «почему?» и «что это значит?».

Что происходит на этом этапе:

Данные связываются между собой.

Данные накладываются на модель процесса.

Выявляются причины, а не только следствия.

Устанавливается, что является нормой, а что — отклонением.

Формируется понимание ситуации в целом.

Пример превращения:

Характерная ошибка: Руководитель видит данные, но не ищет связи. Он реагирует на следствия, а не на причины. Это лечение симптомов, а не болезни.

Вопрос для самопроверки: «Я понимаю, почему это произошло? Я вижу связь между причиной и следствием? Я могу объяснить это другому человеку за одну минуту?».

Последствия остановки на этом этапе: Бессмысленная суета. Вы видите, что произошло («температура высокая», «опоздания», «негативные отзывы»), но не понимаете, почему. Вы принимаете меры — но они бьют мимо цели. Включите дополнительное охлаждение? А проблема в кондиционере, его нужно чинить. Накажите Иванова? А проблема в графике. Смените дизайн продукта? А проблема в упаковке. Действия есть, результата нет.

Этап 4. Управляющее воздействие

Определение: Управляющее воздействие — это решение, принятое на основе информации, переведённое в форму команды, приказа, рекомендации или автоматического сигнала, направленного на объект управления.

Что происходит на этом этапе:

Формируется конкретная команда.

Команда адресуется конкретному исполнителю (человеку или системе).

Команда имеет чёткие параметры (что сделать, к какому сроку, с какими ресурсами).

Определяется уровень автоматизации (информирование, рекомендация, автоматическое действие, полная автоматизация).

Команда передаётся по каналу связи.

Пример превращения:

Характерная ошибка: Руководитель знает, что нужно сделать, но не формулирует чёткую команду. «Разберитесь там», «Примите меры», «Как-то это решите». Без адресата, без срока, без параметров. Такая команда — не управляющее воздействие. Это передача ответственности.

Вопрос для самопроверки: «Моё решение основано на информации (а не на сырых данных или интуиции)? Оно адресовано конкретному исполнителю? У него есть всё необходимое для исполнения? Я могу проконтролировать исполнение?».

Последствия отсутствия этого этапа: Управления нет. Есть анализ, есть понимание, есть благие намерения — но нет действия. Система остаётся в прежнем состоянии, пока проблема не перерастает в катастрофу. Анализ без действия — это интеллектуальное удовольствие, а не управление.

«Сырые данные — это руда. Верифицированные данные — это очищенная руда. Информация — это выплавленный металл. Управляющее воздействие — это деталь, выточенная из металла. Пропуск любого этапа: руда без очистки — мусор, металл без обработки — болванка. А без управления — всё бесполезно».

1.4. Цифровая экономика

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

Цифровая экономика — это система управления всеми ресурсами хозяйствующего субъекта на основе сбора и анализа данных с помощью интеллектуальных вычислительных систем — цифровых платформ.

Разберём определение по словам — это крайне важно.

«Система управления» — это родовое понятие. Цифровая экономика — это не «совокупность технологий», не «хозяйственный уклад», не «способ производства». Это именно система управления. Почему это принципиально?

Любая экономика, по своей сути, есть способ управления ограниченными ресурсами для удовлетворения потребностей. Меняются лишь инструменты и парадигмы. Сначала управляли мускульной силой рабов и волов. Затем — конвейером и паровым двигателем. Затем — деньгами и финансовыми инструментами. Сегодня мы управляем данными и алгоритмами. Но суть — управление — всегда остаётся константой.

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

«Всеми ресурсами» — не только финансовыми, не только материальными. Все виды ресурсов: информационные, технологические, человеческие, временные. Подробно о классификации ресурсов — в главе 3. Цифровая экономика не отменяет старые ресурсы. Она добавляет новые и меняет способы управления старыми.

«Хозяйствующего субъекта» — универсальность. Цифровая экономика работает на любом масштабе: от индивидуального предпринимателя до государства. Никаких исключений.

«На основе сбора и анализа данных» — это «топливо» системы. Без данных нет управления. Без анализа — нет решений. Цифровая экономика не терпит «пустоты». Она требует постоянного, непрерывного, верифицированного потока данных.

«С помощью интеллектуальных вычислительных систем» — это «двигатель» системы. Не просто «компьютеры» и не просто «программы». Интеллектуальные системы — те, которые способны к анализу, обучению, адаптации. Простой скрипт, который переносит данные из A в B, — это не интеллектуальная система. Алгоритм, который выявляет скрытые закономерности и предлагает решения, — да.

«Цифровых платформ» — это «тело» системы. Цифровая платформа — конкретная техническая реализация. О ней — отдельное определение ниже.

Почему это определение — ключевое

Я дал определение цифровой экономики как системы управления. Это не просто одно из возможных определений. Это выбор, который определяет всё остальное.

В этом разделе я покажу, почему этот выбор критичен. Потому что из определения следуют действия. Из одного определения — одни действия. Из другого — прямо противоположные. И от того, какое определение вы примете, зависит, будет ли ваша «цифровая трансформация» реальной трансформацией или дорогостоящей имитацией.

Если цифровая экономика — система управления (моё определение)

Допустим, вы приняли это определение.

Вы согласились, что цифровая экономика — это не про технологии, не про серверы, не про «цифровые услуги». А про то, как принимаются решения, как распределяются ресурсы, как измеряется успех.

Тогда из этого определения логически вытекают четыре следствия. Они не придуманы мной — они выведены.

Следствие первое. Вам нужен процесс перехода к этой системе.

Если у вас есть целевая система (цифровая экономика как система управления), и у вас есть текущее состояние (старая модель управления на основе интуиции и бумажек), вам нужен процесс перехода из точки А в точку Б.

Этот процесс называется цифровая трансформация.

Она отвечает на вопрос «как перейти от старой модели управления к новой?».

Трансформация — это не «внедрить CRM» и не «купить серверы». Это последовательное изменение онтологии (того, как вы мыслите), ресурсов (тем, чем вы управляете) и процессов (того, как вы действуете).

Без процесса перехода целевая система остаётся мечтой.

Следствие второе. Вам нужен инструмент, реализующий эту систему.

Система управления не может существовать в голове у директора. Она не может существовать в виде текстовых регламентов, которые пылятся на полке. Она должна быть материализована в работающем инструменте.

Этот инструмент называется цифровая платформа.

Она отвечает на вопрос «в какой среде работает новая система управления?».

Цифровая платформа — это не «просто программа». Это целостный аппаратно-программный комплекс, который собирает данные, анализирует их, формирует управляющие воздействия. Это нервная система организации.

Без платформы новая система управления остаётся теорией.

Следствие третье. Вам нужно «сердце» этой системы.

Платформа — это тело. Но тело должно иметь сердце — то, что заставляет его жить, учиться, адаптироваться.

Это сердце называется динамическая модель управления.

Она отвечает на вопрос «как именно система принимает решения?».

Динамическая модель — это не статический план и не отчёт. Это постоянно обновляемое цифровое отражение управляемого объекта, которое живёт внутри платформы. Оно сравнивает текущее состояние с целевым, вычисляет отклонения, генерирует корректирующие воздействия.

Без динамической модели платформа — просто дорогой калькулятор.

Следствие четвёртое. Вам нужен измеритель прогресса.

Если вы что-то меняете, вы должны знать, идёте ли вы в правильном направлении. Нужен инструмент, который показывает, насколько вы продвинулись и что ещё нужно сделать.

Этот инструмент называется цифровая зрелость.

Она отвечает на вопрос «насколько мы близки к целевой модели управления?».

Цифровая зрелость — это не «уровень автоматизации». Это комплексный показатель, который оценивает развитие управления, информационных технологий и цифровой культуры.

Без измерителя прогресса вы не узнаете, успешна ваша трансформация или нет.

Цепочка следствий (схематично)

Примите определение: Цифровая экономика = система управления

↓

Вам нужен процесс перехода → это цифровая трансформация

↓

Вам нужен инструмент → это цифровая платформа

↓

Вам нужно сердце → это динамическая модель управления

↓

Вам нужен измеритель → это цифровая зрелость

Всё логично. Всё вытекает одно из другого. Нет лишних сущностей. Нет противоречий.

Если цифровая экономика — «совокупность технологий» (альтернативное определение)

А теперь давайте посмотрим, что происходит, если вы принимаете другое определение — то, которое сегодня доминирует в публичном дискурсе и в головах большинства руководителей.

«Цифровая экономика — это совокупность технологий (большие данные, искусственный интеллект, блокчейн, интернет вещей), которые трансформируют хозяйственную деятельность».

Это определение тоже порождает следствия. Но другие.

Следствие первое (альтернативное). Вам нужны технологии.

Если цифровая экономика — это про технологии, то ваш первый шаг — закупка оборудования и программного обеспечения.

Вы покупаете серверы. Вы покупаете лицензии. Вы нанимаете программистов.

Вы отвечаете на вопрос «какие технологии нам нужны?».

Следствие второе (альтернативное). Вам нужен отчёт о внедрении.

Если вы купили технологии, вы должны отчитаться об их внедрении.

Вы готовите отчёт: «внедрена система управления взаимоотношениями с клиентами», «запущено мобильное приложение», «создано хранилище данных».

Вы отвечаете на вопрос «что мы внедрили?».

Следствие третье (альтернативное). Вам нужен показатель «цифровизации».

Если вы отчитались о внедрении, вам нужен показатель, который подтвердит ваш успех.

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

Вы отвечаете на вопрос «сколько мы оцифровали?».

Следствие четвёртое (альтернативное). Процесс заканчивается.

Вы купили технологии, внедрили, отчитались. Проект завершён. Можно переходить к следующему.

Вы отвечаете на вопрос «что дальше?» — а дальше следующий проект.

Сравнение двух подходов

Чем опасен альтернативный подход

Альтернативное определение не просто «неправильное» в теоретическом смысле. Оно опасное на практике.

Потому что оно порождает иллюзию движения там, где движения нет.

Компания покупает технологии. Внедряет системы. Сдаёт отчёты. Руководство довольно: «мы проводим цифровую трансформацию».

А бизнес-показатели не растут. Процессы не ускоряются. Клиенты не становятся лояльнее.

Почему?

Потому что модель управления не изменилась. Те же интуитивные решения. Те же функциональные «окопы». Та же культура страха ошибок.

Технологии есть. А управления нет.

Это называется цифровой фасад. Красивая витрина при старых, гнилых внутренностях.

Что вы выбираете на самом деле

Когда вы выбираете определение цифровой экономики, вы не выбираете «термин». Вы выбираете логику действий.

Выберите «систему управления» → вы будете менять модель управления, перестраивать процессы, переопределять роли, внедрять платформу под задачи бизнеса. Это трудно. Это долго. Это требует дисциплины. Но это работает.

Выберите «совокупность технологий» → вы будете покупать технологии, автоматизировать хаос, сдавать отчёты, рапортовать об успехах — и через год обнаружить, что ничего не изменилось. Это легко. Это быстро. Это не требует изменения мышления. Но это не работает.

Выбор за вами.

Главный тезис

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

1.5. Цифровая платформа

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

Разберём определение по составляющим.

«Целостный аппаратно-программный комплекс» — это не «набор сервисов» и не «облачная среда». Целостность означает, что все компоненты спроектированы как единое целое, а не склеены из кусков. Аппаратно-программный — включает и «железо» (серверы, сети, датчики), и «софт» (операционные системы, базы данных, приложения). Комплекс — не отдельная программа, а совокупность взаимосвязанных компонентов.

«Реализующий динамическую модель управления» — платформа — это не «просто база данных» и не «просто интерфейс». Она является материальным воплощением динамической модели управления (о ней — отдельное определение). Без модели платформа — дорогой калькулятор. Без платформы модель — философия, не способная действовать.

«Через замкнутый цикл» — управление не бывает «разовым». Это непрерывный процесс: сбор → анализ → воздействие → снова сбор. Замкнутость означает, что нет «разрыва» между действием и результатом. Система видит последствия своих решений и корректирует их.

«Сбора, анализа данных» — вход системы. Без данных платформа слепа. Без анализа — глупа.

«Формирования управляющих воздействий» — выход системы. Платформа не просто выдаёт «отчёт» для человека. Она формирует команды, которые либо автоматически исполняются, либо передаются человеку для исполнения.

«На основе алгоритмов» — не «интуиции» и не «ручного ввода». Алгоритмы — формализованные, проверяемые, воспроизводимые правила преобразования данных в решения.

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

Обязательные модули цифровой платформы

Цифровая платформа — это не «чёрный ящик» и не «набор сервисов». Это целостная система, состоящая из пяти обязательных модулей. Без любого из них платформа не является полноценной.

Ниже я описываю каждый модуль. Что он делает. Зачем нужен. Что будет, если его нет.

Модуль 1. Ядро онтологии

Что это такое

Ядро онтологии — это хранилище формализованных правил, ценностей, принципов, по которым работает платформа. Это «конституция» системы. Это то, что отличает одну платформу от другой даже при одинаковых технологиях.

Что хранится в ядре онтологии

Определения ключевых сущностей: что для нас «клиент», «успех», «качество», «эффективность».

Целевые показатели и их приоритеты: что важнее — скорость или надёжность? Прибыль сегодня или устойчивость завтра?

Правила принятия решений: при каких условиях включается тот или иной алгоритм.

Этические ограничения: что нельзя делать ни при каких обстоятельствах.

Бизнес-правила: формулы расчётов, пороги срабатывания, условия переключения.

Почему это «ядро»

Потому что без онтологии платформа не знает, какие цели преследовать. Она может собирать данные, анализировать, даже формировать какие-то воздействия — но она не будет знать, что правильно, а что нет. Хорошо ли, что продажи выросли, если качество упало? Стоит ли экономить на доставке, если это увеличивает время ожидания?

Ядро онтологии даёт ответы на эти вопросы. Оно — источник смысла для всей платформы.

Что будет, если этого модуля нет

Платформа не знает, какие цели преследовать. Она будет работать «по умолчанию» — а кто задал это умолчание? Скорее всего, разработчики, которые понятия не имеют о вашей стратегии.

Платформа без ядра онтологии — это автомобиль без руля. Двигатель работает, колёса крутятся, а куда ехать — непонятно.

Модуль 2. Механизм обработки данных

Что это такое

Механизм обработки данных — это конвейер приёма, очистки, верификации, обогащения и хранения данных. Это «пищеварительная система» платформы. Данные поступают сырыми, а выходят готовыми к использованию — очищенными, проверенными, структурированными.

Этапы обработки данных

Почему это важно

Без механизма обработки данных платформа будет работать с «грязными» данными. Ошибки на входе приведут к ошибкам на выходе. Мусор на входе — мусор на выходе.

Что будет, если этого модуля нет

Платформа не может доверять своим данным. Качество решений падает. Люди перестают доверять системе и начинают перепроверять всё вручную. Ценность платформы обнуляется.

Модуль 3. Моделирующий полигон

Что это такое

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

Что можно делать на моделирующем полигоне

Тестировать новый алгоритм на исторических данных: «сработал бы он так, как мы ожидаем?».

Сравнивать несколько алгоритмов: какой даёт лучший результат?

Проверять, как поведёт себя система при нештатных ситуациях: что будет, если поставщик сорвёт поставку? Что будет, если нагрузка вырастет в 10 раз?

Обучать модели машинного обучения на безопасных данных.

Почему это важно

Без моделирующего полигона каждое изменение алгоритмов происходит «вслепую». Вы загружаете новый алгоритм в реальную платформу и смотрите, что получится. Если ошибка — страдает реальный бизнес.

С моделирующим полигоном вы сначала проверяете. Потом убеждаетесь, что всё работает. Потом переносите в реальную платформу.

Что будет, если этого модуля нет

Каждое изменение алгоритмов — риск для реальной системы. Команда боится вносить изменения. Платформа застывает. Развитие останавливается. Технический долг растёт.

Модуль 4. Блок принятия решений

Что это такое

Блок принятия решений — это набор алгоритмов, которые преобразуют данные и онтологию в управляющие воздействия. Это «мозг» платформы. Он получает на вход очищенные данные и правила из ядра онтологии, а выдаёт — команды.

Что происходит в блоке принятия решений

Сравнение текущих показателей с целевыми (из ядра онтологии).

Вычисление отклонения (вектора ошибки).

Выбор алгоритма для данного типа отклонения.

Расчёт параметров управляющего воздействия (что сделать, в каком объёме, к какому сроку).

Определение уровня автоматизации (информирование, рекомендация, автоматическое действие, полная автоматизация).

Пример

Входные данные: «температура в цехе +39°C (норма +22…+25°C)».

Онтология: «при превышении температуры выше +35°C включать аварийный протокол».

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

Что будет, если этого модуля нет

Платформа умеет собирать и анализировать данные, но не умеет действовать. Она — дорогой дашборд, не более. Человек смотрит на красивые графики и сам принимает решения. Управление остаётся ручным. Ценность платформы близка к нулю.

Модуль 5. Интерфейс трансляции воздействий

Что это такое

Интерфейс трансляции воздействий — это механизм передачи команд из блока принятия решений в исполнительные системы и людям. Это «нервы» платформы. Решение принято — нужно, чтобы оно достигло адресата в понятном для него виде.

Что делает этот модуль

Преобразует решение в формат, понятный исполнителю:

Человеку: задача в системе, уведомление в чат, электронное письмо, СМС.

Системе: вызов API (программного интерфейса), запись в очередь сообщений, команда на контроллер.

Отслеживает, дошло ли воздействие до адресата.

Фиксирует факт и время доставки.

При необходимости — повторяет отправку, если ответа нет.

Примеры трансляции

Что будет, если этого модуля нет

Решение принято, но до исполнителя не дошло. Или дошло в непонятном виде. Управление не происходит. Платформа превращается в «генератор благих намерений». Решения есть, действий нет.

Сводная таблица модулей

Почему все пять модулей обязательны

Платформа — это система. Система — это целое, которое нельзя уменьшить, не разрушив.

Если убрать ядро онтологии — платформа не знает, зачем она. Она будет работать, но бессмысленно.

Если убрать механизм обработки данных — платформа не может доверять своим данным. Она будет принимать решения на основе лжи.

Если убрать моделирующий полигон — платформа не может развиваться. Каждое изменение — риск. Команда застывает в страхе.

Если убрать блок принятия решений — платформа не умеет действовать. Она — дорогой дашборд.

Если убрать интерфейс трансляции воздействий — решения не доходят до исполнителей. Платформа — генератор благих намерений.

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

Главный тезис

«Цифровая платформа — это не «облако» и не «набор сервисов». Это пять обязательных модулей. Ядро онтологии задаёт смысл. Механизм обработки данных обеспечивает качество. Моделирующий полигон позволяет развиваться без страха. Блок принятия решений превращает анализ в действие. Интерфейс трансляции воздействий доставляет команды адресату. Без любого из них платформа — не платформа, а дорогостоящая имитация».

1.6. Динамическая модель управления

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

Разберём определение.

«Постоянно обновляемое» — модель не статична. Она не «рисуется» один раз и не используется годами. Она обновляется в реальном времени или с минимальной задержкой — по мере поступления новых данных.

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

«Управляемого объекта» — моделируется не «всё подряд», а именно тот объект, которым нужно управлять: производственная линия, цепочка поставок, клиентская база, городское хозяйство, экономика региона.

«Которое живёт внутри цифровой платформы» — модель не отдельная программа. Она встроена в платформу, является её «мозгом» и «сердцем».

«Служит для прогнозирования, анализа и генерации управляющих воздействий» — три функции:

Прогнозирование: что будет, если ничего не менять? Что будет, если применить то или иное воздействие?

Анализ: почему произошло отклонение? Где узкое место? Какая причина?

Генерация воздействий: что нужно сделать, чтобы вернуться к цели?

«На основе актуальных данных» — не «отчётов за прошлый месяц». Данные должны быть «здесь и сейчас». Устаревшие данные — источник ложных решений.

«И заданной онтологии» — цели, ценности, принципы, ограничения. Онтология задаётся Идеологом. Без онтологии модель не знает, к чему стремиться.

Ключевое отличие ДМУ от статических моделей управления

Я начну с простой аналогии. Она поможет понять суть раз и навсегда.

Статическая модель управления (например, система сбалансированных показателей) — это фотоснимок.

Вы берёте камеру. Фиксируете момент. Получаете картинку. На этой картинке есть всё, что было в момент съёмки. Но она не меняется. Она не дышит. Она не реагирует на то, что происходит за её пределами. Если через час начнётся дождь, на фотоснимке его не будет. Если вы собьётесь с курса, фотоснимок не подскажет, как вернуться.

Система сбалансированных показателей фиксирует показатели и их целевые значения на определённый момент времени. Она отвечает на вопрос: «Куда мы хотим прийти?».

Это важный вопрос. Но он не единственный.

И главное — система сбалансированных показателей не говорит, как туда добраться. И не меняет маршрут, если дорогу размыло дождём. Она статична.

Динамическая модель управления (ДМУ) — это навигатор с онлайн-картами.

Вы открываете приложение. Оно знает, где вы находитесь сейчас. Оно знает, куда вы хотите приехать. Оно видит пробки, аварии, перекрытия дорог. Оно прокладывает маршрут. Если вы свернули не туда — оно перестраивается. Если впереди образовалась пробка — оно предлагает объехать. Если дорогу перекрыли — оно ищет альтернативу.

ДМУ не только знает цель. Она знает текущее состояние. Она видит отклонения. Она предлагает (или сама применяет) корректирующие воздействия. Она учится на ошибках.

Сравнительная таблица

Ключевые возможности ДМУ (развёрнуто)

ДМУ — это не просто «усовершенствованная система отчётности». Это принципиально иной способ управления. Вот четыре ключевые возможности, которых нет у статических моделей.

Возможность 1. Постоянно отслеживает текущее местоположение

Статическая модель показывает, где вы были. ДМУ показывает, где вы есть.

Датчики, пользователи, внешние системы — всё это в реальном времени передаёт данные в платформу. Вы видите, не отчёт за вчера, а картину «прямо сейчас».

Пример: Не «в прошлом месяце средняя температура в цехе была +35°C», а «сейчас температура в цехе +39°C, и она растёт со скоростью +1°C в час».

Возможность 2. Просчитывает маршрут с учётом пробок и аварий

Статическая модель знает цель. ДМУ знает, как к ней идти — с учётом текущих условий.

Алгоритмы прокладывают оптимальный маршрут. Не теоретический, не из учебника, а тот, который работает прямо сейчас, при тех ограничениях, которые есть.

Пример: Не «нужно сократить время доставки до 24 часов», а «сейчас на маршруте Москва — Санкт-Петербург пробка на М11, переключаем доставку на поезд, время в пути увеличится на 2 часа, пересчитываем обещание клиенту».

Возможность 3. Мгновенно перестраивает маршрут, если условия изменились

Статическая модель видит отклонение, когда оно уже произошло. ДМУ реагирует в момент изменения.

Как только условия меняются, система пересчитывает маршрут. Не через час, не на плановом совещании, а автоматически.

Пример: «Поставщик сообщил о задержке отгрузки на два дня. Система автоматически переключает заказ на альтернативного поставщика и уведомляет клиента о переносе срока».

Возможность 4. Предлагает альтернативные пути

Статическая модель показывает проблему. ДМУ показывает решения.

Система генерирует варианты. Не один, а два-три. С оценкой последствий каждого. Человек выбирает. Или система выбирает сама, если уровень автоматизации позволяет.

Пример: «Складской запас товара X ниже порога. Варианты: (1) срочный заказ у текущего поставщика — срок 3 дня, цена +10%; (2) заказ у альтернативного поставщика — срок 5 дней, цена 0%; (3) переключение клиентов на товар Y — срок 0 дней, риск потери лояльности 5%».

Как работает ДМУ (жизненный цикл управляющего воздействия)

Теперь — самое важное. Я описываю полный цикл работы ДМУ. От обнаружения проблемы до обучения на ошибках. Семь шагов. Ни одного лишнего. Без любого — цикл разрывается.

Шаг 1. Обнаружение отклонения

Платформа постоянно сравнивает текущие показатели с целевыми, которые хранятся в ядре онтологии.

Если показатель в норме — система наблюдает, но не вмешивается.

Если показатель выходит за допустимые границы — система фиксирует вектор ошибки.

Вектор ошибки — это величина и направление отклонения. Не просто «плохо», а «температура выше нормы на 2°C», «время доставки больше целевого на 3 часа», «остаток товара ниже порога на 50 единиц».

Вопрос, на который отвечает этот шаг: «Что не так?».

Пример: «Время цикла обработки заявки — 15 минут при норме 10 минут. Отклонение +5 минут».

Шаг 2. Диагностика причины

Отклонение обнаружено. Теперь нужно понять, почему оно возникло.

Алгоритмы анализируют:

Может быть, проблема в данных (датчик сломался, источник врёт)?

Может быть, внешний фактор (поставщик задержал, клиент изменил условия)?

Может быть, ошибка в процессе (шаг выполняется дольше нормы, сотрудник не обучен)?

Может быть, ошибка в алгоритме (система выбрала неоптимальное действие)?

Вопрос, на который отвечает этот шаг: «Почему это произошло?».

Пример (продолжение): «Анализ показал, что задержка возникает на шаге „согласование с руководителем“. Руководитель сейчас в командировке и не проверяет заявки. Причина — отсутствие заместителя и автоматической эскалации».

Шаг 3. Генерация вариантов

Причина выявлена. Теперь нужно решить, что делать.

Моделирующий полигон (изолированная среда) просчитывает 2–3 варианта действий. Для каждого варианта:

Ожидаемый результат.

Время достижения.

Необходимые ресурсы.

Побочные эффекты и риски.

Вопрос, на который отвечает этот шаг: «Что можно сделать и к чему это приведёт?».

Пример (продолжение):

Вариант 1: Назначить временного согласующего из отдела. Результат: заявки обрабатываются за 10 минут. Риск: временный сотрудник может ошибиться.

Вариант 2: Снизить порог суммы, которая требует согласования, временно до 5000 руб. Результат: 70% заявок идут без согласования. Риск: финансовые потери до 5000 руб. по каждой ошибочной заявке.

Вариант 3: Настроить автоматическую эскалацию — если ответа нет 30 минут, заявка идёт выше. Результат: обработка за 10 минут. Риск: вышестоящий руководитель перегружен.

Шаг 4. Выбор воздействия

Варианты сгенерированы. Теперь нужно выбрать один.

Уровень автоматизации определяется для каждого типа ситуаций заранее (записано в ядре онтологии):

Вопрос, на который отвечает этот шаг: «Кто принимает решение — система или человек?».

Пример (продолжение): Для ситуации «задержка на согласовании» установлен уровень «автоматическое действие с правом вето». Система выбирает вариант 3 (автоматическая эскалация) и применяет его. У руководителя есть 15 минут, чтобы отменить.

Шаг 5. Применение воздействия

Решение принято. Теперь его нужно доставить до исполнителя в понятном для него виде.

Интерфейс трансляции воздействий преобразует команду в нужный формат:

Человеку: задача в системе управления задачами, уведомление в чат, электронное письмо.

Станку: команда по промышленному протоколу.

Программе: вызов API (программного интерфейса).

Вопрос, на который отвечает этот шаг: «Как команда достигает исполнителя?».

Пример (продолжение): Система отправляет: (1) руководителю — уведомление в чат: «Назначен временный согласующий Иванов на период командировки. Есть 15 минут, чтобы отменить». (2) Иванову — задачу в системе: «Согласовывать заявки отдела Х до 20 мая». (3) В процесс — изменение маршрута заявок.

Шаг 6. Контроль результата

Воздействие применено. Но это не конец. Система продолжает собирать данные и оценивать, устранено ли отклонение.