Цифровая трансформация

Конспект семинара "Информационная модель организации", который проводил в "Иннополисе" (вдруг кому )

Поднимая тему цифровизации организации или процессов важно не упускать контекст

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

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

Каждая организация - уникальна!

Данные - первичны - они отражают факты, из которых соткана жизнь

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

Один из ключевых управленческих вопросов - на каком качественном уровне находится инфраструктура по сбору, обработке и передаче данных о всех значимых фактах в организации (в контексте ключевых процессов)

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

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

Прежде чем разрабатывать или покупать какое-либо программное обеспечение - в организации должна наступить относительная ясность и согласованность в вопросе о данных (какие данные нужны? кому? зачем? по каким правилам их обрабатывать?)

Необходимо отрефлексировать ключевые факты и объекты управления в организации и сформулировать понимание, как их отразить в цифре (данные в цифровом формате)

Качество процесса и результата рефлексии во многом зависит от используемого языка участниками процесса

Новые опьяняющие возможности "цифры" повышают требования к процессу и результату начального проектирования целевой информационной системы

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

Требования и необходимость создания "Информационной модели здания" (BIM, building information model) - яркий практический пример смещения акцентов в рамках новой парадигмы проектирования в конкретной отрасли - строительство

Эра информационных моделей организаций - уже началась

Один из ключевых вопросов текущей повестки дня - не про наличие или отсутствие информационной модели в конкретной организации, а - про качество компетенций в сфере построения информационной модели (мир постоянно меняется)

Одни из ключевых составляющих общей информационной модели организации являются:

1. Модель процессов

2. Модель данных (объектов управления)

Как показывает практика - феномен "модели процессов" худо-бедно существует в массовом сознании и фигурирует в российской управленческой культуре

Модели BPM-схем - не являются нераспознаваемыми египетскими иероглифами со стороны большинства руководителей и аналитиков

Ключевая атомарная единица в модели процесса - действие или условие

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

Вместе с тем - "под капотом" любого программного обеспечения "сидит" модель данных (1С, SAP, Битрикс24 и др.)

Модель данных - это система, отражающая ключевые сущности (объекты управления), их атрибуты и связи

Модель данных - логическое отражение конкретной управленческой (жизненной) ситуации (системы), которая рассматривается как совокупность объектов (сущностей) и их связей

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

Атомарная единица модели данных - полка для факта

Мало кто знает, но сказку "О рыбаке и рыбке" я создавал на основе модели данных. Коллегам из NL!A удалось найти мои тайные рукописи и восстановить эту модель данных (ссылка в Михайловское)
Александр Сергеевич Пушкин

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

Как и в любой проектной деятельности - ключевой риск-следствие низкого качества проектной документации - срыв проекта; существенное отклонение реальности от ожиданий (по сроку, бюджету, итоговому результату)

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

Игнорирование же моделей на этапе проектирования - приводит к росту энтропии

Анти-пример из практики - Техническое задание на разработку информационной системы объемом 280 страниц, в котором словосочетание "база данных" встречается лишь два раза (в тезаурусе); модель данных - отсутствует; модель процессов - описано 4 частных процесса (из десятков)

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

Резюме по данном конкретному ТЗ - все 280 страниц нужно перекладывать с языка "Елена должна" на языки модели данных, процессов, машины состояний, UX и иные

Переходим к языкам "модели данных" и "модели процессов"

Возьмем конкретный пример-факт: моя Дочь собирается сдавать ОГЭ по информатике, а в нашем замечательном НГУ есть Высший колледж информатики, в котором есть актуальный для нее курс:

Кратко - процесс "трудоустройства" на курс происходил следующим образом:

1. Изучение сайта и нахождение программы

2. Звонок - переговоры с менеджером

3. Заполнение договора (обсуждение по email)

4. Оплата

5. Получение паролей и явок для обучающегося

Ничего сложно

Теперь - переложим данную фактическую ситуацию на язык модели данных

Модель данных состоит из категорий-объектов (полок для размещения на них существенных фактов) и связей между ними

Информация - это различие

Проверьте себя: в представленной ниже модели данных (рисунок-схема) не хватает как минимум одного ключевого объекта (категории для фиксации факта), сможете "увидеть" какого?

Очень смахивает на настольную игру - не находите?

Обратите внимание на следующие различия:

1. Описание ситуации антропоморфным языком у меня состояло из 5 пунктов (буллит-поинтов)

2. Описание ситуации языком модели данных состоит из... одной картинки

3. При этом в модели данных выделены 9 ключевых объектов управления (полок для учета фактов) - что более полно отражает ситуацию

4. Картинка с моделью данных - не требует дополнительных письменных разъяснений традиционным языком для извлечения из нее смыслов (данные -- > информация --> знание)

P.S. У вас еще есть шанс найти пропущенный объект / сущность (полку для складирования значимого факта). Ответ - далее

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

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

В итоге - полученная модель данных отражает логику CRM-решений

Кант давно уже говорил, что этот кусок мела содержит миллион потенциальных фактов (Tatsachen) , но лишь очень немногие станут подлинными фактами, воздействуя на поведение сущностей, способных реагировать на факты. Вместо кантовых Tatsachen я бы употребил слово различия и заметил бы, что количество потенциальных различий в этом меле бесконечно, но очень немногие из них станут эффективными различиями (т.е. единицами информации) в умственном процессе некоторой большей сущности. Информация состоит из действенных различий.
Грегори Бейтсон, "Разум и природа. Неизбежное единство", 1979г.

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

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

В ответ на вопрос "где болит"? Руководители имеют возможность просто "ткнуть пальцем" в рентгеновский снимок организации

Коммуникация происходит на принципиально ином языке

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

Для иллюстрация контраста между логикой и сутью моделей (данные VS процесс) - отразим пример с курсом - языком модели процесса (оригинал модели по ссылке)

Карта (модель) всего процесса выглядит следующим образом:

Детализация начала модели процесса (для понимания логики, без погружения в оригинал) - каждый элемент модели - это действие/событие (тоже факт) или условие ("все устраивает?")

Обратите внимание - язык модели процессов имеет строгую последовательность - в отличии от языка модели данных (важный нюанс!!!)

Модель процесса ВСЕГДА СЛОЖНЕЕ модели данных (см. количество элементов)

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

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

Спроектированная (нарисованная) модель данных становится новым языком (объектом и средством коммуникации) для обсуждения системы управления в организации, понимания сути ее деятельности, актуальных проблем и болей руководства; линейного персонала

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

Оригинал статьи у нас на сайте (есть дополнительные примеры моделей данных)

Наш телеграм-канал - "Восстание машин"

Записали видео с демонстрацией разработки бизнес-приложения (веб-сервис) для магазина электротехники (хронометраж - 11:45)

Разработка ведется на основе нашей open-source платформы NL!A Framework, использование которой позволяет увеличить скорость разработки в 50 раз

Разработка ведется по принципу единого окна - кодогенератор платформы создает сразу код, как back-end’а, так и font-end’a (тот самый Low-code, о котором так долго говорили Большевики!)

Используемый стек технологий:

1. Интерфейс - Интерфейс создается при помощи Vue.js в современном стиле Material design от Google

2. Веб-сервер создается на языке Go (также от Google)

3. Создается система управления базой данных (СУБД) - PostgreSQL

Платформа open-source. Исходник размещен на GitHub’e

Наш телеграм-канал - "Восстание машин"

Рефлексия собственного опыта изменения подходов к бегу

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

При чем цифровая трансформация моего подхода к управлению бегом происходила именно постепенно - в течение 3 лет (2018-2021). Постепенно возникали новые сущности, новые данные, трансформировалось мое целеполагание в беге

Ламповый бег

До "цифры" (датчиков и гаджетов) мой подход к бегу выглядел следующим образом: у меня был один единственный маршрут - размеченные лесные тропинки Академгородка на карте в 2gis

Это был маршрут протяженностью около 5 километров. Я знал, что это плюс-минус комфортное расстояние для меня и если силы и будут покидать меня, то покинут меня они не далеко от дома)

Дальше весь управленческий интерес забега сводился к одной единственной метрике - за какое время я пробегу данный фиксированный маршрут

С приобретением фитнес-браслета в 2018 году мой подход к бегу начал претерпевать постепенные изменения

Бег на основе данных

В 2018 году я обзавелся фитнес-браслетом Mi Fit 3, который неожиданно поспособствовал созданию и эксплуатации моей цифровой беговой инфраструктурой

Ядром цифровой инфраструктуры стало мобильное приложение Mi Fit

Теперь во время каждого забега данные о шагах и пульсе отправлялись с браслета в телефон и далее - в приложение

Функционал телефона в забеге:

1. передача данных с GPS-трекера в приложение

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

Первая стадия цифровой трансформации бега - бег в режиме свободной охоты

Благодаря тому, что по факту каждого освоенного километра я теперь стал получать голосовой отчет от телефона, а быстрый взгляд на браслет позволял получать данные о километраже с точностью до десяти метров в режиме реального времени - я отвязался от своей "ламповой карты" и стал бегать по рандомным маршрутам, принимая управленческое решение в моменте

Как результат - вышел из зоны комфортного лампового пробега в 5 километров. Целеполагание по освоенному километражу корректировалось уже в процессе забега. так сказать - в режиме реального времени

В результате нового подхода объем пробежки увеличился на 50%+ (средняя температура по больнице)

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

Благодаря изучениям отчетов в телефоне открыл для себя великое знание - оказывается - пульс меняется в процессе бега :)))

Вторая стадия цифровой трансформации бега - бег по пульсу

Открыв для себя такую новую сущность, как пульс - приступил к изучению, что это такое и про что он в процессе бега

Собственно уже отчет в приложении тонко намекал, что в зависимости от значений твоего пульса, бег будет иметь различную направленность (аэробные/анаэробные нагрузки, сжигание жира и др.)

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

По теме пульса при беге ключевое управленческое внимание было направлено на то, чтобы не бегать в "красной зоне" пульса - контролируем риск отбросить копыта

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

Тут мы мы подходим к теме качества и достоверности данных

До сих пор помню этот забег по зимнему лесу в 2020 году: начав с оповещения о пульсе в 180 ударов, уже через 5-10 минут последующего забега телефон спокойно и методично рапортовал мне о пульсе в 210+

Забег пришлось остановить. Вот он - конкретный пример принятия управленческих решений на основе данных (data-driven management)

Последующие тестовые забеги также быстро загоняли меня в критическую зону пульса (по версии датчика и приложения), что весьма меня не радовало, мягко говоря

По итогам концентрации своего мыслительного процесса на теме высокого пульса при беге удалось изобрести велосипед - пульс можно замерить "ламповым" способом и сравнить с "цифрой"

Был оперативно проведен эксперимент со следующими результатами:

1. "Цифровой" пульс ~ 200

2. "Ламповый" пульс - 140-150

Вывод: мобильные цифровые датчики не очень точно (мягко говоря) справляются с задачей сбора данных о нашем пульсе (процесс сердцебиения)

Изучив тему пульса обратил внимание на следующую метрику процесса бега - каденс

Третья стадия цифровой трансформации бега - бег по каденсу

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

Оказалось, что каденс - это фактическое количество шагов в минуту, которое ты совершаешь. Все просто

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

Благодаря тому, что все ключевые данные о моих забегах хранятся в базы данных приложения - поднял метрики каденса в "докаденсную эпоху"

В общем мой фактический каденс (средний по больнице) при забегах находился на уровне ~120 шагов в минуту

Чтобы понять, насколько я каденс-молодец, а также чтобы быть во всеоружии в ситуации когда мне придется меряться своим каденсом с кем-либо, я направил все свои исследовательские ресурсы на ютуб и выяснил следующее:

Просвещенные люди бегают с каденсом 180

Продифференцировалась интересная диалектика бега:

1. Меньшее количество шагов, но зато шаг - от души - бег прыжками

2. Большее количество мелких шагов - логика швейной машинки

После каденс-просветления для меня стало чуть более понятнее - зачем разработчики приложения зашили в приложение метроном

Первый же забег с метрономом на 180 - показал значимый контраст с предыдущими забегами непросветленного человека (каденс 120)

Гипотеза, что рост частоты топанья ногами на 50% измотает значительно быстрее - не подтвердилась. Наоборот - случился определенный сдвиг в сторону состояния потока, явно снизилась нагрузка на колени, бегать стало лучше - бегать стало веселее!

Практикую бег под метроном уже больше года - качество процесса и результат - явно улучшили по сравнению с "ламповым" и непросвещенным бегом

Обратите внимание, как уменьшился разброс фактических значений каденса с бегом под менторством мудрого метронома - 174-177 шагов в минуту

Что такое метроном с 180 ударами в мнинуту - можете услышать в этом ролике:

Резюме

1. Практикуя ламповый бег, неожиданного - через покупку датчика на руку - погрузился во вселенную различных сущностей, отражающих качество такого бизнес-процесса как бег

2. Дэшборд с отчетом по каждому забегу - теперь неотъемлемая компонента бега

3. Без без цифры - деньги на ветер

4. Все данные о забегах с 2018 года хранятся в базе данных и доступны в любой момент времени (вплоть до статистики по конкретному километру)

5. Телефон стал не только пассивно фиксировать информацию о беге, но и стал субъектом управления бегом - через импульсы метронома

6. Через изучение зоопарка сущностей и эксперименты (забеги-гипотезы) удалось прокачать свои беговые компетенции, равно как и улучшить качество процесса - бега

7. Процесс цифровой трансформации бега занял 3 года

8. Важно - обобщить! Бег - это просто частный процесс! Аналогичная магия и метаморфозы начинают возникать, если плотно взяться за цифровизацию любого процесса в любой организации

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

Оригинал статьи на нашем сайте

Наш телеграм-канал "Восстание машин"

В рамках повышения технологической грамотности наших заказчиков - подготовили материал с пошаговым описанием создания модели данных по произведению А.С. Пушкина "Сказка о рыбаке и рыбке" (Золотая рыбка). Вдруг кому :)

Модель данных - ядро информационной системы

Давайте спроектируем модель данных на примере сказки (кейса) "О рыбаке и рыбке" Александра Сергеевича Пушкина

Модель данных - это система, отражающая ключевые сущности (объекты управления), их атрибуты и связи

Модель данных - логическое отражение конкретной управленческой (жизненной) ситуации (системы), которая рассматривается как совокупность объектов (сущностей) и их связей

Давайте разберем - какие ключевые сущности (объекты) мы видим?

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

oldWoman - Старуха

oldMan - Старик

Движемся дальше. Тезис, что "Старуха своя" - толкуем таки, что Старик и Старуха сформировали ячейку общества - Family

Уже возникают интересные нюансы в проектировании и построении учетной информационной системы

Связь oldWoman - oldMan можно реализовать и без таблицы Family добавив Старику и Старухе по атрибуту (строке), содержащему ссылку на супруга spouseId и

указав взаимные связи между объектами

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

Использование же таблицы Family (для учета семей), позволяет нам хранить в базе данных всю актуальную и архивную информацию о таком важно объекте управления, как - семья

Движемся дальше - фиксируем новые сущности (объекты)

See - море (которое "самое синие")

Land - суша, на которой живут Старик со Старухой

По сути - это два фундаментальных объекта управления в кейсе про "Золотую рыбку". Так что игнорирование данных объектов значительно снизит качество нашей будущей информационной системы

p.s. По уму See и Land это просто два разных представителя (конкретизация) такой сущности как Пространство (как Старик и Старуха - Человек), однако для простоты восприятия мы их различим

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

Видим, что живут они не в чистом поле (Land), а в ветхой землянке - Building (называем так, потом что Building будет претерпевать значимые физические и информационные изменения; сорри за спойлер)

Стаж проживания в тридцать лет и три года можно отнести как к свойству Family, так и к связи Family - Building (Тонкое отличие: семье может быть 33 года, но проживали они в разных локациях). Однако не будем перегружать нашу модель в виду несущественности данной информации в нашем кейсе. Равно как и проигнорим пряжу, но не - невод

FishingTool - невод

Обратите внимание на связи:

Family связана (проживают) с Building, а Building в свою очередь находится (связано) на Land.

Ну а инвентарный номер fishingToolId логически закреплен за oldMan

Далее. От статической картинки дошли до процессов - "старик ловил"

Обратите внимание - бизнес-процесс "ловля неводом рыбы" (и его результат) пока никак не могут быть отражены в нашей модели данных. Пока у нас имеется только oldMan, fishingTool и связь между ними

Раз он в море закинул невод, —
Пришел невод с одною тиной.
Он в другой раз закинул невод,
Пришел невод с травой морскою

Заброс невода в море - транзакция

Дошли до более тонкой темы - как организовать учет процесса и его результата

FishingAct - один заброс невода в море

Обратите внимание на параметры (атрибуты) FishingAct:

id - уникальный идентификационный номер (уже случилось два FishingAct)

fisher_id - идентификационный номер рыбака (у нас рыбак один - oldMan, но в теории их может же быть много )

fishingTool_id - идентификационный номер FishingTool (у нас это - невод, но может быть и удочка и запрещенка же всякая с разными инвентарными номерами)

sea_id - идентификационный номер Sea, в котором рыбачим (предусмотрим возможность рыбалки в различных водоемах)

startTime - дата и время заброса FishingTool в Sea

endTime - дата и время извлечения FishingTool в Sea (по разнице endTime - startTime - можно вычислить продолжительность операции)

result - описание того бесполезного, что оказалось в FishingTool по результатам fishingAct (типа, трава морская и прочее)

isGoldFish - оказалась ли в FishingTool gGoldFish? (boolean)

Пока ход бизнес-процесса "ловля рыбы" и его результаты отражаются следующими данными в нашей информационной системе:

В третий раз закинул он невод, —
Пришел невод с одною рыбкой,
С непростою рыбкой, — золотою.
Как взмолится золотая рыбка!
Голосом молвит человечьим:
«Отпусти ты, старче, меня в море,
Дорогой за себя дам откуп:
Откуплюсь чем только пожелаешь.»
Удивился старик, испугался:
Он рыбачил тридцать лет и три года
И не слыхивал, чтоб рыба говорила.
Отпустил он рыбку золотую
И сказал ей ласковое слово:
«Бог с тобою, золотая рыбка!
Твоего мне откупа не надо;
Ступай себе в синее море,
Гуляй там себе на просторе».

Очевидно, что у нас возникает объект GoldFish. Но это еще не все!

Также возникает уже "невидимый" объект - обязательства GoldFish перед OldMan. И это будет отдельный объект, при чем он будет спроектирован в логике связей - "многие к многим" (Для сравнения - связь OldMan - FishingTool - "один ко многим" - у одного рыбака может быть несколько девайсов для рыбалки, но у каждого девайса будет ровно один хозяин-рыбак)

GoldFish_OldMan_commitment - таблица по учету обязательств GoldFish (могу быть разные) перед OldMan (тоже могут быть разные; отсюда и логика связи "многие-к-многим"). Таблица для учета "рыбьей дебиторки" OldMan'а

При этом пока эта таблица - пуста («Бог с тобою, золотая рыбка! Твоего мне откупа не надо; Ступай себе в синее море, Гуляй там себе на просторе»)

Обратите внимание, что мы установили связь между GoldFish и Sea (убираем риск, что oldMan может забыть к какому Sea потом идти с каждым новым Commitment; сорри - спойлер)

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

Также обращаем внимание, что дальше меняется структура бизнес-процессов. FishingAct более не происходит - вся дальнейшая движуха происходит на связях OldMan с OldWoman и GoldFish

Воротился старик ко старухе,
Рассказал ей великое чудо.
«Я сегодня поймал было рыбку,
Золотую рыбку, не простую;
По-нашему говорила рыбка,
Домой в море синее просилась,
Дорогою ценою откупалась:
Откупалась чем только пожелаю.
Не посмел я взять с нее выкуп;
Так пустил ее в синее море».
Старика старуха забранила:
«Дурачина ты, простофиля!
Не умел ты взять выкупа с рыбки!
Хоть бы взял ты с нее корыто,
Наше-то совсем раскололось».

Не будем плодить новую информационную сущность про "коммуникационный акт" между OldMan и OldWoman (кстати, до этого и не коммуницировали в нашей кейс) - с управленческой точки зрения для нас важен факт того, что OldWoman формулирует содержание GoldFish_OldMan_Commitment и ставит соответствующую задач OldMan

Теперь у нас в базе данных появляется следующая запись (по аналогии с FishingAct)

Вот пошел он к синему морю;
Видит, — море слегка разыгралось.
Стал он кликать золотую рыбку,
Приплыла к нему рыбка и спросила:
«Чего тебе надобно, старче?»
Ей с поклоном старик отвечает:
«Смилуйся, государыня рыбка,
Разбранила меня моя старуха,
Не дает старику мне покою:
Надобно ей новое корыто;
Наше-то совсем раскололось».
Отвечает золотая рыбка:
«Не печалься, ступай себе с богом,
Будет вам новое корыто».
Воротился старик ко старухе,
У старухи новое корыто.

Еще пуще старуха бранится:
«Дурачина ты, простофиля!
Выпросил, дурачина, корыто!
В корыте много ль корысти?
Воротись, дурачина, ты к рыбке;
Поклонись ей, выпроси уж избу».

Ускорим сказку и сразу отразим всю историю транзакций в таблице GoldFish_OldMan_commitment (осторожно - много спойлеров!!!)

isKorytoExist - true

isKorytoBroken - true

Теперь вспомним вот эту фразу:

"По сути - Sea и Land это два фундаментальных объекта управления в кейсе про "Золотую рыбку". Так что игнорирование данных объектов значительно снизит качество нашей будущей информационной системы"

В итоге у финальная модель данных кейса "Сказка о рыбаке и рыбке" сложилась следующим образом

Информация - это различие

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

Грегори Бейтсон, "Разум и природа. Неизбежное единство", 1979г.

Наш телеграм-канал - "Восстание машин"

Поскольку в управлении и бизнесе знания не представляют ценность саму в себе – дополним “пирамиду” двумя ключевыми сущностями – ”мыслью” и “действием” (С благодарностью позаимствовали из концепции «мыследеятельности» Щедровицкого Г.П.)

Как изящно подмечал Щедровицкий: «Мысль без действия – пустая болтовня, а действие без мысли – страшная вещь»

В контексте нашего повествования под действием следует понимать принятие конкретного управленческого решения в компании. Также представленная пятиуровневая пирамида есть логическая модель концепции data-driven менеджмента

Добавим еще теоретического контекста к иллюстрации:

1. Управленческие действия совершаются для достижения определенных целей; или же направлены на решение проблем (на что также можно посмотреть в логике достижения цели)

2. Данные (низ пирамиды) – это отражение реального мира – его объектов, фактов и процессов

Теперь наложим на модель контекст управления компанией (бизнесом) и получим ответ на вопрос – почему современные информационные технологии играют все бОльшую и бОльшую роль по мере своей стремительной эволюции

Данные и извлекаемая из них информация – это фундамент для принятия управленческих решений в любой системе, бизнесе

Постоянно развивающиеся информационные технологии позволяют оцифровывать все большее и большее количество данных

Ключевой вызов для каждого управленца любого бизнеса в 2021 году – можешь ли ты видеть свой бизнес в режиме реального времени на экране своего телефона?

Ключевые вопросы – насколько ты управленчески слеп? На основании чего ты принимаешь решение? Данные или авторитет и интуиция?

Почему критически важен фактор времени и качества данных?

...

Вы паркуете автомобиль задним ходом. У вас есть парктроник и камера заднего вида

Насколько вы будете счастливы, а ваш автомобиль - цел, если информация с камеры и сигналы от парктроника будут поступать с задержкой в 30-40 секунд?

...

Итак – разобрались с очевидной вещью, что данные важны для принятия качественных управленческих решений

Забрались по горке от данных к действиям

Теперь пройдемся по обратному склону – от действий к данным

Развернем ситуацию в обратную сторону и зададимся следующими вопросами: а как принимаются управленческие решения про данные?

- какие данные нужны?

- каких данных не хватает? (дефицит информации)

- все ли сотрудники видят необходимые им данные? (у каждого есть экран телефона)

- устраивает ли скорость прохождения данных в компании? (насколько real-time)

- С каким КПД извлекается информация из данных в компании (мусорные данные)

- Насколько стандартизированы данные в компании (информационная энтропия)

- Насколько надежны и защищены данные? (права доступа и резервное копирование)

Для рассмотрения ситуации добавим к нашей модели типовую характеристику традиционного IT-зоопарка, исторически сложившегося в каждой крупной (да и не только) российской компании

IT-зоопарк крупной компании: набор крупных систем “черных ящиков/монолитов” плюс информационные заплатки в виде практик работы с информацией в экселях

Цитата представителя крупного нефтегазового холдинга: «Мы сидим на SAP’е, а что не в нем – то в экселе»

Не будем разбирать все прелести лоскутной автоматизации – важно зафиксировать контекст – характеристики существующей; исторически-сложившейся информационной архитектуры и культуры

Итак, вызов: качество и количество информации в компании необходимо постоянно улучшать и повышать – как про это думать руководству и принимать решения?

Наличие существующей it-инфраструктуры и запрос на новую информацию в компании создают интересное диалектическое противоречие, качество и успех решения которого определяется уровнем «цифровых» компетенций руководства компании

Самый очевидный шаг, что на поверхности – купить очередную “коробку-черный ящик”, маркетологи которой с пеной у рта обещают закрытие всех незакрытых потребностей компании в данных, информации и функционале

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

1. Большинство руководителей уже имеет болезненный опыт попадания на удочку покупки «волшебной коробки» (и не одной). Как минимум интуитивно и где-то на уровне подсознания опытный руководитель понимает, что ему впарят что-то дорогое, таинственное, что будет жрать дополнительные ресурсы и энергию, будет вызывать раздражение и саботаж сотрудников; и далеко не факт, что изначальная потребность будет закрыта

2. Количество «коробок» во многих компаниях достигло нормы управляемости, числа – 7. «Коробки» невозможно покупать бесконечно, природа об этом позаботилась

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

Еще одна иллюстрация: мы получили приглашение на участие в тендере на создание 14-й (!!!) it-системы для крупной пищевой компании, которая нацелена на нормализацию данных в используемых 13-ти it-системах (!!!)

Мир динамично меняется, а крупные компании в каком-то плане оказались в «цифровых кандалах» своего исторически приобретенного зоопарка it-систем

Альтернатива покупки новой «коробки» - допиливание существующих «коробок» под новые потребности силами внутренних разработчиков на фиксированном стеке технологий

Минусы такого подхода:

1. Программисты – дорожают быстрее газа

2. Использование устаревших технологий (legacy code)

3. Низкая производительность и мотивация программистов (товар дефицитный; на окладе; устаревшие технологии)

4. «Слепота» к новым технологическим возможностям, которые постоянно возникают во внешнем мире

Наконец третья альтернатива: решение текущих управленческих запросов за счет разработки и внедрения так называемых микросервисов

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

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

Плюсы микросервисного подхода к развитию it-инфраструктуры компании:

1. Высокие скорости (разработка, внедрение)

2. Низкая стоимость (меньше миллиона)

3. Наличие конкретного заказчика внутри компании (контроль качества, ответственность)

4. Бесшовная интеграция с существующими «коробками»

5. Использование современных информационных технологий

6. Работа именно с теми данными, которые нужны заказчику (ввод, вывод, визуализация)

7. Минимальные риски (прозрачность проектирования, разработки и эксплуатации)

8. Легкая возможность замены на иные решения в случае устаревания; потери актуальности

9. Современные user-friendly интерфейсы

10. Возможность работы с мобильных устройств (телефон, планшет)

Резюмируем – руководство компании в размышлениях о дальнейшей цифровой трансформации и последующих принимаемых управленческих решениях должно учитывать ключевые аспекты контекста, в котором находится компания

Ключевыми аспектами контекста являются:

1. Сформулированные и согласованные управленческие проблемы в компании, которые можно решить за счет расширения «фундамента пирамиды» - повышения количества и качества данных и информации (как основы принятия управленческих решений функциональным заказчиком)

2. Сформулированные гипотезы относительно возможных цифровых решений согласованных управленческих проблем (метрики: «было --> стало» - крайне желательны)

3. Сформулированный результат рефлексии к эксплуатируемому it-зоопарку всех ключевых стейкхолдеров в компании (Насколько устраивает? Каковы границы развития? Насколько устарели технологии? Разумно ли развивать? Оценка рисков эксплуатации)

4. Количество используемых в компании it-продуктов (коробок). Важно осознавать о норме управляемости – число 7

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

P.S. Напоследок – про информацию, как источник знания в управлении компанией

В первую очередь речь идет не про сакральные и тайные знания о мироздании. Речь про то – есть ли у вас здесь и сейчас информация о взмахе крыла той самой бабочки, которая уже запустила процесс, влияющий на ваш бизнес?

Наш телеграм канал - Восстание машин

Тема цифровой трансформации из элемента хайповой повестки уже конвертировалась в одну из пяти Национальных целей развития России до 2030 года (указ президента РФ)

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

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

Например - вчера я получил письмо от ГосУслуг с напоминанием и указанным дедлайном второго укола Спутником V

Никаких прозвонов и обходов квартир фельдшерами - просто сработала проверка записи в базе данных:

“дата первого укола + 21 день приближаются” = true --> выслать email пользователю c dmitry_markov

Просто?

Простейший функционал и логика!

Но, как показывает практика, для бизнеса такое - сложно…

Сложно для осознания, принятия и применения на практике - в своей бизнес-модели

Небольшое отступление:

В этом моменте мне пришла в голову мысль из книги Генриха Альтшуллера - автора ТРИЗ (Теория решения изобретательских задач):

В мире существует два вида систем:

1. природные (горы, реки, леса)

2. искусственные (страны, города, институты… созданные человеком)

Любая система - выполняет функцию (рассылка email’ов)

Идеальная система: системы нет, а функция - выполняется

Это очень важная методологическая диалектика - абстрактного (озеро) и конкретного (утолить жажду здесь и сейчас этому конкретному человеку)

Что мы видим, как активный участник процесса цифровизации бизнеса?

Тотальное доминирование абстрактного над конкретным.

Игнорирование конкретного со стороны бизнеса и конкретных людей - неумение сфокусироваться и работать над конкретикой, деталями

Да вы и сами с этим все сталкиваетесь регулярно - вот типовой уровень повестки и постановки задач цифровизации:

“Что будем внедрять - 1С или SAP?”

“Какую CRM выберем - Битрикс или АМО?”

“У нас есть CRM и WMS-системы, но не хватает ERP и чат-бота в нашей архитектуре”

Какая конкретика стоит за этими абстракциями?

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

Так - руководители попадают в ловушку цифрового базара, кишащего цыганами-маркетологами, продающих “легендарные it-продукты”

При этом в 2021 году мы находимся в интересном моменте - российский бизнес накопил многолетний опыт использования цифровых продуктов в контексте своих бизнес-моделей

Большинство руководителей набили себе хороший объем шишек в процессе многочисленных попыток автоматизировать/цифровизировать свои процессы “легендарными it-продуктами”

Боль есть у каждого управленца

При этом, зачастую, управленец не может сформулировать - дать ответ на вопрос - что и где болит?

Пример из нашей практики:

Консалтинговая компания, ядром бизнес-модели которой является ведение длинных проектов, купила CRM-систему для контроля исполнения задач

Эксплуатируя систему в течение года - руководство компании пришло к выводу, что CRM-система не заточена под логику управления проектами (логика диаграммы Ганта)

Обратились к нам - мы разработали кастомную систему по управлению проектами (Гант), но на следующей итерации выяснилось, что руководству компании нужна система по управлению продажами (логика воронки продаж - CRM)

Такая ситуация - типовая для подавляющего количества российских компаний

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

Переходим к хорошим новостям

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

Все продукты на цифровом базаре перепробованы, многие боли не решены - крупные компании по сути опустились на уровень собирательства

Ключевыми элементами/ролями процесса собирательства являются:

1. Функциональный заказчик с болью

2. Технологический брокер (посредник)

3. Носитель/владелец технологии (доктор)

Процесс собирательства выглядит следующим образом:

1. Функциональный заказчик формулируют свою бизнес проблему (боль, задачи)

2. Формулируются гипотезы - как эту проблему можно решить

3. Формулируются ожидания относительно того - насколько станет лучше жить с решенной проблемой (метрики, финансовые эффекты и др.)

4. К процессу подключается технологический брокер (по сути - риэлтор)

5. Во вселенную посылается клич - “Доктор - найдись!”

5. Собираются разнообразные доктора

7. Запускается процесс диалога с вовлечением всех участников (ФЗ, брокер, доктор)

8. Формируется пул рецептов по лечению боли от всех докторов

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

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

11. Запускается локализованный процесс тестового лечения новым продуктом на 3 месяца (пилот со сформулированными метриками успеха/провала лечения)

12. По прошествии тестового периода - 3 месяца использования нового цифрового продукта (окончание пилота) функциональный заказчик совместно с технолоcическим брокером подводят итог лечения/пилота

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

Одна итерация цифровой трансформации закончена

Подходит ли данная технология/методология для цифровизации малого и среднего бизнеса?

Абсолютно! Ничего космического здесь нет

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

1. Наличие воли и интереса руководства/акционеров

2. Наличие организационного ресурса - сотрудники (функциональные заказчики) должны быть вовлечены в проект

3. Наличие посредника (технологического брокера) - умеющего понимать и разговаривать, как на языке заказчика - так и на языке носителя технологии

4. Связь/контакт с носителями технологий

5. Способность организовать процесс собирательства по перечисленным выше 13 пунктам

6. Толерантность к риску - тонкий момент связанный с культурой (пилот может и не выстрелить)

Разберемся с абстракцией - технологический брокер

На практике данная сущность может приобретать следующие формы:

1. In-house ТехБрокер в крупных корпорациях (центры инноваций, цифровизации, трансформации и т.п.)

2. Внешний посредник-институт - Акселераторы, консалтинговые компании (кстати, жизнь вынудила топовые консалтинговые компании идти именно по этому пути)

3. ТехБрокер-методолог со стороны технологической компании (мы по такому пути эволюционировали)

4. Независимый технологический эксперт с соответствующей репутацией, как в бизнес, так и в технологическом сообществе/среде

Резюмируем

Цифровизация - вполне конкретна

При этом успешность процесса цифровизации во многом зависит от слаженности и скоординированности деятельности следующих ее участников:

1. Функционального заказчика

2. Технологического брокера

3. Носителя/владельца технологии