Русин пишет


Гео и язык канала: Россия, Русский
Категория: Блоги


Сергей Русин — руководитель цифровой трансформации. Практик применения AI в управлении.
О том, как руководителям использовать AI, данные и автоматизацию для быстрых решений и управляемых бизнес-процессов.
Сайт: https://rusinpishet.ru

Связанные каналы

Гео и язык канала
Россия, Русский
Категория
Блоги
Статистика
Фильтр публикаций


Самое полезное в новой профессиональной среде — не визитки и не список контактов.

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

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

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


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

Маркетинг предложил, чтобы менеджеры по продажам опрашивали покупателей. Составили анкету из 15 вопросов. Большинство из них не относились к покупке и со стороны клиента звучали странно.

Покупатели отвечали неохотно. Менеджеры тоже не видели в опросе смысла: их KPI зависел от объёма продаж, а не от заполнения дополнительных данных.

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

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

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


У новостей об аккредитации обычно довольно официальный язык. Но эта для меня вполне личная.

Программа MBA IT-Лидер (CIO, CISO, CDO), на которой я сейчас учусь, продлила профессионально-общественную аккредитацию АПКИТ сразу на шесть лет.

Программа подтвердила соответствие восьмому, высшему уровню профессионального стандарта «Менеджер по информационным технологиям». За этой формулировкой стоят вполне конкретные компетенции: управление цифровой трансформацией, стратегическое развитие IT, крупные проекты и кросс-функциональные команды.

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

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

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

Источник: https://t.me/itmschool/126


На MBA я иногда прихожу не за ответом, а за сопротивлением своему привычному ответу.

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

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

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


Иногда путь из Excel начинается с Excel.

На днях на совещании приняли решение автоматизировать финансовый блок. Если сильно упростить задачу — «уйти от Excel».

И что стало первым шагом? Новый Excel-файл.

В нем собрали все источники данных, ответственных за них и системы, в которых эти данные хранятся.

На первый взгляд — парадокс. Но только если считать проблемой сам Excel.

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

У нового файла другая роль. Это карта текущего состояния. Она показывает:

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

Без такой карты автоматизация легко превращается в перенос прежнего хаоса в новую систему.

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

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


Недавно я писал в канале о теории нечётких множеств на MBA CDTO. Тогда речь шла о том, что в управлении редко бывает чистое «да» или «нет»: готовность проекта, уровень риска или интерес клиента обычно находятся где-то между нулём и единицей.

Я решил применить эту теорию на практике и собрал интерактивную модель оценки потенциала покупки квартиры в новом жилом комплексе.

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

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

Важно: текущая версия 0.1 — экспертная модель, а не статистическая вероятность покупки. Пока она нужна для приоритизации клиентов и поиска барьеров. После накопления завершённых циклов продаж её можно будет проверить на фактических результатах и откалибровать по горизонтам 30, 90 и 180 дней.

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

Открыть интерактивную модель

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


Ускорять решение полезно не всегда. Иногда скорость просто раньше делает ошибку дорогой.

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

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

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

Но перед необратимым решением полезно спросить не только «успеем ли к сроку», но и «что нам придётся сломать или объяснить, если через месяц окажется, что мы ошиблись».

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


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

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

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

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

Именно за такие столкновения мне и важна MBA CDTO: они не дают слишком быстро поверить, что понятная модель уже равна применимому ответу.


Самая рискованная цифра в отчёте — не та, которая выглядит странно. А та, которая выглядит слишком убедительно.

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

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

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

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

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


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

Заявки на оплату оформляли в 1С. Акционер согласовывал их через отдельный чат в Telegram. Личный помощник брал из поля «Примечание» объяснение, для чего нужна закупка, приводил текст в порядок и отправлял его вместе с заявкой. Каждый раз вручную.

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

Идея выглядела логично. Но она упрощала работу только помощнику. Всем остальным пришлось бы заполнять дополнительное поле и подстраивать описание под новый формат.

Ручная работа при этом не исчезала. Она просто переходила от одного человека ко всем заявителям.

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


Сбер и «Самолет»: где заканчивается роль кредитора

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

В «Сигналах стройрынка» эта новость попала в число заметных тем дня. В доступной выборке она вышла как минимум в семи самостоятельных отраслевых каналах, собрала около 50 тысяч просмотров и более 800 пересылок. Такие цифры не доказывают, что обсуждаемый сценарий будет реализован, но показывают, насколько внимательно рынок следит за темой:
https://t.me/signaly_stroyrinka

По данным «Коммерсанта», пока речь идет именно о возможном сценарии, а не о завершенной сделке.

Для меня здесь важен вопрос, который выходит за рамки одной компании: где заканчивается роль кредитора и начинается участие в управлении?

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

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

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

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


Статус «в работе» удобен всем, кроме человека, которому нужен результат.

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

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

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

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

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

Если на этот вопрос пока нечего ответить, честнее назвать ситуацию неопределённостью, а не прогрессом.


Хорошая демонстрация иногда мешает проекту больше, чем плохая.

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

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

Мне нравятся демонстрации, когда они помогают задать эти вопросы, а не закрыть их аплодисментами.

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


Если вы думаете, что MBA — это только бизнес-кейсы, стратегии и управленческие практики, то у нас вчера всё пошло немного иначе.

На программе MBA CDTO начался курс «Технологии интеллектуального анализа данных (Аналитические системы)». Одну из частей первого занятия посвятили теории нечётких множеств.

Вместо привычного разбора бизнес-ситуации на экране появились функции принадлежности, пересечения, объединения и значения от 0 до 1.

Для руководителя это не такая уж отвлечённая математика. В управлении редко бывает чистое «да» или «нет». Проект может быть готов лишь частично. Риск не всегда можно однозначно назвать высоким или низким. Да и отношение клиента к продукту обычно находится где-то между «лоялен» и «не лоялен».

Большинство управленческих решений мы принимаем именно в этой зоне — между нулём и единицей.

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

Похоже, пора освежать математику.


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

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

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

Я считаю полезным не прятать решение за словом «компромисс». Нужно прямо сказать: что мы сохраняем, от чего отказываемся и чей результат в итоге защищаем.

Это не делает разговор легче. Зато не оставляет проект без автора в самый важный момент.


У дашборда есть опасное свойство: он может создать ощущение, что управленческая работа уже сделана.

На экране есть цифры, статусы и красные зоны. Значит, кажется, что ситуация прозрачна.

Но между «увидели отклонение» и «изменили ход работы» всё ещё остаются вопросы, которые не решает ни один отчёт. Кто имеет право вмешаться? Что именно он меняет? Как команда узнает о новом решении? Что будет считаться исправлением, а не очередным комментарием к цифре?

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

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


В цифровом проекте слово «срочно» часто звучит раньше, чем становится понятно, что именно надо сделать.

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

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

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

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


Продажа может быть завершена в системе, а клиентский опыт в этот момент только становится настоящим.

До сделки компанию интересуют обращение, выбор, условия, документы и сроки. После — совсем другие ожидания: понятно ли, что будет дальше; кому задавать вопрос; где увидеть статус; не придётся ли каждый раз заново рассказывать свою историю.

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

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

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


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

Новая система добавляет форму, маршрут, правило, уведомление. Это легко увидеть на демонстрации.

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

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

Поэтому для меня зрелая автоматизация — не та, которая добавила больше функций. А та, где команда понимает цену упрощения и приняла её сознательно.


Иногда самая трудная управленческая работа — не спасти цифровой проект.

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

Но у проекта может не остаться предмета. Изменился процесс. Ушёл внутренний заказчик. Появилось решение проще. Или стало ясно, что команда поддерживает инициативу только потому, что её когда-то начали.

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

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

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

Показано 20 последних публикаций.