Дмитрий Бочаров /IT/Управление/Результаты

День рождения Вчера был мой день рождения и начался тот самый 47й год (см картинку). Наконец-то! Теперь только вверх!

НАВИГАЦИЯ С чего начать читать канал: Впервые здесь? 😔 Закреп — кто я и чем занимаюсь. Хотите понять, есть ли проблема с IT? 😔 6 вопросов, которые я задаю на каждом аудите. Про деньги и бюджет в IT: 😔 Как не потратить 50 млн на ненужное. 😔 Автоматизация никогда не снижает расходы. 😔 Эффективное IT и полезное IT — не одно и то же. Про ИИ и автоматизацию: 😔 Часть 1: 450 часов в год. Куда уходит время ваших сотрудников? 😔 Часть 2: почему пилот не становится инструментом. 😔 Часть 3: как внедрять ИИ, чтобы он работал на бизнес. Про проекты и управление: 😔 3 причины, почему IT-проекты буксуют. 😔 Когда проект пора остановить, а не дотянуть. 😔 Кейс: сопротивление внутри бизнеса — управляемый фактор. 😔 Внешнее управление IT-проектом. Перед покупкой бизнеса: 😔 Что проверить в IT перед сделкой. 😔 Кейс: IT-аудит перед сделкой — как защита ваших денег. Как проходит IT-аудит: 😔 Весь процесс по шагам. 😔 Кейс: IT-реформа. Про работу с IT-директором: 😔 6 тем, которые я всегда обсуждаю с IT-директором. Вопросы и консультация: @dm_bocharov

Шесть тем, которые я всегда обсуждаю с IT-директором. Вот ключевые вопросы, я делю их на шесть тем. 1.) Про бизнес-результат. «Какие IT-проекты за последние полгода реально повлияли на выручку или маржу с цифрами?» Это смещает фокус с «сдали в срок» на реальный бизнес-результат. 2.) Про риски. «Насколько полна наша модель угроз? К каким рискам мы готовы и с какими SLA, а к каким нет?» Как мы убеждаемся в том, что при наступлении негативного сценария все сработает так, как мы предполагаем? Как поддерживаем актуальность? «Какая наша главная слепая зона в безопасности прямо сейчас, о которой ты думаешь, но не выносишь на совещания?» Здесь видим реальные риски для компании. 3.) Операционная надёжность. «Сколько бизнес-процессов полностью зависят от одного конкретного человека в IT? Назови их поимённо.» Это уязвимость, которая не лечится бюджетами. Вынуждает управлять знаниями, а не только серверами. «Какой процент инцидентов мы находим сами до того, как об этом сообщил клиент?» Если клиент сообщает о проблемах раньше, нам это повод для серьёзного разговора. 4.) Бюджет и экономика. «Как меняется стоимость обслуживания одного клиента в нашей IT-системе год к году?» Это связывает IT-расходы с юнит-экономикой. «Если бюджет урежут на 15% — что отключим первым, и когда и как бизнес это почувствует?» Проверяю, понимает ли IT-директор приоритеты компании и управляет ли он портфелем, а не просто защищает бюджет. 5.) Инновации и будущее. «Какую технологию уже используют конкуренты, а мы нет? Почему мы ещё не там?» Держу IT-директора в тонусе внешнего мира, а не только внутренних задач. «Что в нашей архитектуре мешает запускать новые продукты быстро?» Скорость - это конкурентное оружие. IT-ландшафт не должен его отбирать. 6.) Про команду. «Если ты уйдёшь завтра, кто изнутри готов занять твоё место через 6 месяцев? Что мы для этого делаем?» Преемственность - это моя ответственность как первого лица. «Сколько людей в твоей команде могут объяснить, как именно наш IT-ландшафт зарабатывает деньги для компании?» Люди, которые понимают бизнес, принимают лучшие технические решения. Это практика, проверенная годами. Такой ритм и такие вопросы превращают IT-директора в партнёра. А мне дают понимание реальной ситуации не из отчётов, а из живого диалога. Если хотите разобраться, как выстроить такое взаимодействие у себя, пишите @dm_bocharov, обсудим. 😔 А если хотите сначала понять, есть ли у вас системная проблема с IT - вот 6 вопросов, которые я задаю на каждом аудите. Хорошая точка входа перед разговором с IT-директором. 📌 Впервые на канале? Начните с закрепа.

Один из самых дорогих управленческих просчётов — продолжать проект, который давно стоит остановить. За 20 лет я видел много проектов. И в большинстве из тех, что закончились неудачно, была одна общая черта: их можно было остановить раньше. Значительно раньше. Но почему этого никто не делает или делают в очень редких случаях? Потому что легко сказать - остановить. Но на практике это одно из самых тяжёлых решений любого управленца - признать такую ошибку. Для кого-то такая остановка - это потеря денег, для кого-то - серьёзный промах в карьере, для кого-то - признание собственной некомпетентности. А для кого-то - всё вместе. Вот и тянут до последнего, и даже как-то завершают внедрение, и в некоторых случаях даже признают проект успешным. Но на практике получившееся решение сильно отличается от первоначальной задумки и постепенно «отмирает». Что же с этим можно сделать, кроме банального «оценивать на старте более качественно»? 1. Действительно оценивать на старте более качественно. Как ТЗ, так и стоимость владения решением и потенциальный эффект от него в деньгах. 2. На старте же договориться о симптомах, которые могут сигнализировать, что проект пошёл не так, как планировалось. И, конечно, договориться о действиях в этих случаях. 3. Договориться о критериях остановки проекта. Заранее, на берегу. Не сделать в паспорте проекта раздел по управлению рисками, где напишем, что будем эскалировать, если что. Нет! Зафиксировать конкретные метрики, которые будут означать, что экономическая целесообразность проекта перестала быть приемлемой. 4. Заранее определить опережающие показатели для п. 3, которые будут сигнализировать о переходе из «зелёной» в «жёлтую» зону, а потом и в красную. 5. Договориться о регулярной отчётности по п. 2-4 для всех участников проекта. Интересно, что п. 3 — это часто обратная сторона критерия успешности проекта. И мегаполезно, чтобы вся команда, даже техническая, знала об этом критерии с самого начала проекта. Это точно снизит вероятность, что команда будет предлагать решения, которые могут завести проект в точку невозврата. Что же делать, если ваш проект уже в активной фазе и п. 1-5 заранее не были определены? ➡ Во-первых, определить эти пункты хотя бы сейчас. ➡ Во-вторых, честно ответить себе на вопрос: где мы сейчас с точки зрения достижения цели проекта и критериев остановки? ➡ В-третьих, обратить внимание на некоторые симптомы: 🟡 Действительно ли цель проекта ещё актуальна для компании? Не изменилось ли соотношение ожидаемого эффекта к ожидаемой стоимости проекта? 🟡 Понимает ли команда цель проекта одинаково? 🟡 Не появились ли в ходе проекта новые вводные, которые изменили условия, в которых реализуется проект? 🟡 Есть ли сдвиг по сроку реализации и влияет ли он на достижение цели проекта? 🟡 Текущий темп движения к целевому результату позволяет реализовать проект в ожидаемые сроки или хотя бы приемлемые? В общем, что я хочу сказать: остановить проект — это не провал. Это управленческое решение, которое в ряде случаев экономит больше, чем любое другое. Принятое вовремя, оно позволяет перенаправить ресурсы туда, где они дадут реальный результат. Если у вас сейчас есть проект, по которому возникают такие вопросы, и хотелось бы получить независимую обратную связь и рекомендации по наилучшим шагам, пишите в личку @dm_bocharov слово «КОНСУЛЬТАЦИЯ». Это совершенно бесплатно. 😔 Про то, как правильно оценивать проект на старте: кейс про 50 млн. 😔 А про три причины, почему проекты незаметно доходят до точки невозврата, здесь. 📌 Впервые на канале? Начните с закрепа.

Автоматизация процессов НИКОГДА не снижает расходы! Единственное, что делает автоматизация (если все было сделано правильно), - это повышает производительность труда. Больше ничего. Главное заблуждение, с которым я сталкиваюсь, звучит так: «Сейчас мы автоматизируем это и сэкономим». Мой опыт показал, что в 98% случаев это не работает (2% - это те случаи, когда вместо автоматизации процесс когда-то масштабировали за счет найма большого количества людей для выполнения относительно простой работы и теперь, конечно, их увольнение даст экономию). Почему так происходит? Я уже писал про окупаемость и TCO тут. Здесь повторюсь, что любая автоматизация - это игра в долгую. Ни одна система не живет самостоятельно. Обязательно нужны люди (= инвестиции), чтобы ставить задачи, вносить изменения, обеспечивать работоспособность, сопровождать оборудование, обеспечивать совместимость с остальными системами (которые, как назло, либо уходят вперед, либо отстают по темпам развития и технологиям), резервировать на случай аварий, документировать процессы, обучать персонал и обеспечивать преемственность знаний о том, как устроена система, перестраивать процессы под систему (если обратное невозможно) и так далее, и тому подобное. В общем, с точки зрения расходов, платеж на входе при покупке IT-решения - это всегда вершина айсберга, и часто оставить ручной процесс гораздо эффективнее, чем его автоматизировать. Второе заблуждение, которое я встречаю, звучит так: «У нас такой сложный процесс, давайте его автоматизируем, и будет легче его поддерживать». Предполагается, что легче - значит дешевле. Вот тут кроется тот самый дьявол, который в деталях. На практике я ни разу не видел, чтобы автоматизированный сложный процесс было легче поддерживать, чем неавтоматизированный. Собственно, по тем же причинам, что и в первом случае. Первое, что, на мой взгляд, имеет смысл делать - это заниматься самим процессом. Разбираться: почему он стал сложным? Откуда взялось столько ветвлений алгоритма, сложные расчеты или перепроверки? Как их избежать? Когда я сам этим занимаюсь, в большинстве случаев оказывается, что либо «так исторически сложилось», либо «мы сделали неправильный процесс раньше и теперь вынуждены здесь усложнять, чтобы поправить ошибки предыдущих этапов». Формулировки бывают разные, но суть, я думаю, вы поняли. Если хотите разобраться, какая автоматизация у вас даст реальный результат, а какая создаст новые расходы, пишите @dm_bocharov, обсудим. 😔 Про то, как правильно считать экономику IT-проекта до старта кейс про 50 млн, которые не стоило тратить. 📌 Впервые на канале? Начните с закрепа.

Что проверить в IT перед покупкой бизнеса. Сделки по слиянию и поглощению - это отдельная область, в которой я работаю с собственниками как сопровождающий консультант. И вот что я замечаю. В таких сделках покупатели проверяют несколько раз отчетность, разбирают бизнес-модель, документы, операционные процессы и всё, что касается продуктов и продаж. А IT остаётся в слепой зоне. По крайней мере, на момент покупки. Причина понятна: IT воспринимается как техническая область, которая не так важна в момент покупки, да и в которой непросто разобраться без специальных знаний. Обычно думают, что после покупки «мой IT-директор разберется». Но именно в этой зоне после закрытия сделки чаще всего обнаруживаются скрытые обязательства, завышенная оценка активов и инфраструктура, которая потребует серьёзных вложений, возможно, уже в ближайшее время. Поделюсь, на что я смотрю в первую очередь - возможно, пригодится как ориентир. Портфель IT-проектов. Что сейчас в работе, с каким обоснованием и насколько это соответствует актуальным приоритетам бизнеса. На практике значительная часть портфеля в большинстве компаний формировалась в другое время, под другие задачи. Приоритеты бизнеса с тех пор сместились, но проекты продолжаются без пересмотра целесообразности. Это прямые затраты, которые переходят к новому собственнику вместе с компанией. Нематериальные активы на балансе. Собственные разработки, права на программное обеспечение, IT-системы, купленные или созданные внутри компании. Их балансовая стоимость и реальная рыночная стоимость - нередко существенно разные цифры. Именно здесь есть возможность обоснованно скорректировать оценку компании и закрыть сделку на более выгодных для покупателя условиях. Состояние IT-архитектуры. Насколько актуальна технологическая база: используемые платформы, степень амортизации оборудования, наличие устаревших решений, которые удерживают всю систему. То, что сейчас обеспечивает стабильную работу, может в скором времени потребовать полного перехода на новую архитектуру со всеми сопутствующими затратами на миграцию данных, переобучение команды и простои. Концентрация экспертизы. Бывает так, что ключевые знания о том, как устроена IT-архитектура, её логика, интеграции, нестандартные решения - сосредоточены в одном-двух людях. После смены собственника такие люди нередко уходят. И вместе с ними уходит понимание того, как всё работает, - понимание, которое нигде не задокументировано и которое невозможно быстро восстановить. Подрядчики и контрактные обязательства. Кто поддерживает критически важные системы — учётные, производственные, логистические - и на каких условиях. Есть ли долгосрочные контракты с условиями, которые ограничивают свободу действий нового собственника. Есть ли зависимость от единственного подрядчика без альтернатив на рынке. Всё это, как правило, не отражено в общем описании компании и открывается только при детальном разборе. Всё перечисленное не требует многомесячного аудита. Но требует человека, который знает, где именно смотреть, и который не связан интересами ни одной из сторон сделки. Если готовитесь к покупке бизнеса и хотите понять реальное состояние его IT до закрытия сделки, пишите @dm_bocharov, обсудим. 😔 Как это выглядит на практике, в реальном кейсе здесь. 😔 А про то, как вообще проходит IT-аудит по шагам, читайте в этом посте. 📌 Впервые на канале? Начните с закрепа.

Эффективно работающее IT-подразделение и полезное для бизнеса IT-подразделение — не одно и то же. Вот что я имею в виду. IT умеет хорошо измерять то, что происходит внутри: количество закрытых задач, скорость выхода новых версий продукта, проценты выполнения плана, время реакции на инциденты и прочее. Всё это реальные цифры, и они могут выглядеть вполне достойно. Но есть вопрос, который в этих отчётах почти никогда не звучит: КАК то, что делает IT, влияет на выручку, на клиента, на скорость бизнеса? Мой опыт показывает такую статистику: в среднем 70% задач, которые IT закрывает каждый месяц, - это задачи поддержки и разработки новых функций для обеспечивающих подразделений: учет, логистика, отчетность и пр. А те подразделения, которые генерируют основную выручку, как правило, так заняты делом, что им не до IT. Им некогда отстаивать свои потребности и обосновывать автоматизацию. Они как раз из тех, кто изменяет всё деньгами и не берется подписываться под решениями, которые могут не окупиться. Это негласный порядок, который складывается сам по себе, когда в компании нет методологии приоритизации задач. В длинной очереди на доработки коммерческие задачи нередко оказываются позади административных просто потому, что административные подразделения исторически громче и настойчивее обозначают свои потребности. В итоге IT в основном работает на минимальное снижение себестоимости, а не на генерацию выручки (если, конечно, у компании не цифровая бизнес-модель), и даже очень сильная IT-команда не приносит ожидаемого эффекта. Один вопрос, который даёт быструю диагностику: назовите три IT-задачи за последний месяц, которые напрямую повлияли на выручку или скорость в работе с клиентами - именно коммерческий результат. Если ответ формулируется без усилий, связь между IT и бизнесом выстроена. Если нет — это точка, на которую стоит обратить внимание отдельно. Если хотите обсудить, как устроено это у вас и где есть точки роста, пишите @dm_bocharov, разберём вместе. 😔 Про то, как независимая оценка помогла не вложить 50 млн в проект, который принёс бы максимум 35, реальный кейс здесь. 😔 Впервые на канале? Начните с закрепа.

Поделюсь тем, с чем сталкиваюсь регулярно и что, судя по разговорам с коллегами, становится всё более распространённой историей. Компания растёт. Проектов становится больше. И в какой-то момент выясняется, что людей, которые умеют этими проектами управлять, катастрофически не хватает. Не разработчиков. Не аналитиков. Именно управленцев - тех, кто способен держать в голове всю картину, слышать бизнес, видеть риски заранее и не давать проекту уходить в сторону. Найти такого человека на рынке сейчас очень сложно. И даже если найдётся, то это ещё не гарантия, что он разберётся в вашей специфике за разумное время. Именно в таких ситуациях ко мне и обращаются. У меня есть отдельная услуга - внешнее управление IT-проектом. Это не консалтинг в привычном смысле, когда приходят, дают рекомендации и уходят. Я захожу в проект как полноценный руководитель: держу план, контролирую подрядчиков, провожу еженедельные совещания, решаю проблемы по мере появления. Постоянно держу руку на пульсе. Контролирую сроки, слежу за движением, при первых признаках проблемы собираю нужных людей и разбираемся, что именно тормозит. Не жду, пока ситуация станет критической - это, кстати, одна из ключевых вещей в управлении проектами. В первый же момент, когда что-то пошло не по плану, - это сигнал действовать сразу, а не надеяться, что само рассосётся. Когда проект завершается, я ухожу. В итоге для компании это существенно дешевле: без найма в штат, без онбординга и без риска. В среднем такие проекты длятся от 6 до 12 месяцев. Если у вас сейчас есть сложный IT-проект, а нормального управленца под него нет, напишите @dm_bocharov, обсудим вашу ситуацию. 😔 Про три главные причины, почему IT-проекты буксуют даже при сильной команде писал здесь. 😔 А если хотите сначала понять, есть ли у вас системная проблема с IT в целом, вот 6 вопросов, которые я задаю на каждом аудите. 📌 Впервые на канале? Начните с закрепа.

Поделюсь одним из своих самых интересных кейсов. Международная торговая компания, 28 стран присутствия, 1000+ сотрудников. Собственники пришли с конкретной проблемой: внутренняя разработка работает слишком медленно, бизнес не получает то, что просит, в нужные сроки. Хотели получить независимое мнение о том, в чём причина и что с этим делать. Начали с комплексного аудита — смотрели на IT-процессы и архитектуру целиком. Когда речь идет о низких темпах изменений - причины всегда одинаковые, и их немного: 1.      либо нехватка людей; 2.      либо низкое качество орг. процессов; 3.      либо исторически сложившаяся и неоптимальная архитектура и инструменты; 4.      разные комбинации первых трех. Собственно, это всё. В этом моём кейсе все три причины имели место. В итоге разработка шла почти в 2 раза медленнее, чем могла бы. Руководство компании, конечно, это всё понимало, но что с этим делать, было непонятно. В качестве решения мы подготовили предложения по полноценной IT-реформе: разработали новую целевую архитектуру, предложили новую структуру IT-департамента и новые процессы. Всё это упаковали в обоснования с дорожной картой и защитили на совете директоров. Это, кстати, отдельная история — донести до совета директоров целесообразность реформ, которые не дают немедленного видимого результата, но критически важны в перспективе нескольких лет. Не всегда просто. Но в этом случае всё прошло хорошо. Дальше «дело за малым»: с IT-директора - реализация IT-стратегии, с нас – его поддержка, архитектурный надзор, помощь в принятии сложных решений и объективная обратная связь для Совета директоров. Если у вас похожая ситуация — пишите @dm_bocharov, обсудим. Разберем вашу ситуацию персонально. 😔 КАК проходит у меня IT - аудит. Рассказал здесь. 😔 Кейс - как после аудита увеличили выручку в 2 раза.

Поделюсь, как у меня проходит IT-аудит по шагам.   Что вообще происходит, когда внешний человек приходит «разбираться с IT». Расскажу, как это устроено на практике.   1) Начинаю всегда с интервью внутри IT-команды. Разговариваю с начальниками отделов, с ключевыми людьми в департаменте. Задача на этом этапе понять общую картину: как устроены процессы, кто за что отвечает, где узкие места. Это обычный разговор, в котором постепенно становится видно реальное положение дел. И чем большее количество людей участвует в таких интервью, тем «объемнее» становится картинка и объективнее моя оценка. 2) Далее изучаю нормативную базу: внутреннюю документацию по IТ-процессам, архитектуру сетей и серверов, схемы интеграционных потоков. На этом этапе я не проверяю их корректность, скорее моя задача понять, насколько в жизни актуально то, что отражено на бумаге. Обычно именно это расхождение сигнализирует о большей части проблем. 3) Далее разговариваю с бизнесом ключевыми заказчиками для IТ. Моя задача на этом этапе понять: совпадают ли ожидания бизнеса с текущими возможностями IТ. Достижимы ли тактические и стратегические цели с тем уровнем IТ, который есть на текущий момент. Подходит ли IТ-архитектура и процессы для решения тех задач, которые требуются бизнесу сейчас и в перспективе. 4) И финал: готовлю заключение. Честно, как есть. И без прикрас, и без лишнего обесценивания. Стараюсь быть максимально объективным. Не сравниваю текущее IТ с каким-то «идеальным IТ в вакууме», а аргументированно отвечаю на несколько вопросов: ➡ Что имеет смысл поменять в процессах, оргструктуре и инструментах, чтобы быстрее и дешевле решать задачи бизнеса. ➡ Где я вижу «узкое место» в процессах, убрав которое, можно повысить производительность без существенных затрат. ➡ Как усилить команду, чтобы она начала справляться с темпом роста бизнеса. ➡ Какие IТ-решения целесообразно применить именно для этого вида бизнеса. ➡ Какие риски стоит устранить прямо сейчас, чтобы не пожалеть об этом в будущем.   Вот и весь аудит. Последовательная работа, которая в итоге даёт собственнику ответ на вопрос: как можно увеличить пользу для бизнеса от его IТ прямо сейчас.   Кстати, частый вопрос от собственников: как мне понять, что пора бы уже сделать внешний аудит? Обычно это видно по следующим симптомам: медленное решение IТ-задач; частые сбои в IT-системах, из-за которых бизнес теряет деньги; расхождение данных в отчетности; высокие IТ-бюджеты при слабых результатах.   Если узнаёте здесь свою компанию, скорее всего, есть что разобрать. Если хотите понять, что происходит с IT именно у вас пишите @dm_bocharov.   Первая консультация бесплатно.   Разберём вашу ситуацию и определим: — где сейчас возникают потери эффективности в IT и какие шаги имеет смысл сделать в первую очередь, чтобы стабилизировать ситуацию. 😔 Впервые на канале? Начните с закрепа

IT-аудит перед сделкой — как защита ваших денег. Производственный холдинг, 3000+ сотрудников. IT-департамент вынесен в отдельное юридическое лицо. Новый собственник попросил провести анализ IT-проектов и IT-процессов группы компаний в рамках подготовки к сделке. Задача дать оценку зрелости IT-процессов, текущему состоянию и перспективам развития IT-инфраструктуры. Независимым взглядом, без прикрас. Охватили все ключевые направления и разбирали всё, что влияет на результат. Оценивали связанность бизнеса и IT-стратегии, зрелость процессов по модели Gartner, качество IT-процессов через практики ITIL 4.0, степень автоматизации, риски информационной безопасности, компетенции руководителей и внутренний климат в подразделении, соответствие ФОТ рыночным медианам, расходы на обеспечение деятельности департамента. И вот тут началось самое интересное. Когда дошли до портфеля проектов, стало очевидно, что значительная его часть не соответствует актуальной ситуации бизнеса. Проекты существовали по инерции, обоснования устарели, приоритеты давно сместились. По итогам разбора обосновали сокращение портфеля проектов на 55%. Но главный результат оказался неожиданным даже для меня. На балансе компании стояли нематериальные активы: разработки, права на ПО, IT-системы. При расчёте стоимости компании они учитывались по балансовой стоимости и напрямую влияли на итоговую цену сделки. Мы произвели анализ этих активов на предмет реальности их учёта и рыночной стоимости. Это позволило снизить оценочную стоимость компании и закрыть сделку по её покупке на более выгодных для нового собственника условиях. Пришли проверить IT-процессы, помогли сэкономить на самой сделке. Чем крупнее сделка, тем дороже стоит правильная независимая оценка до её закрытия. И тем дороже обходится её отсутствие. Пишите @dm_bocharov, проведу первую консультацию бесплатно. На встрече покажем структуру нашей работы и точно скажем, сможем ли помочь: — с оценкой текущего состояния IT-процессов, аудитом IT-систем или комплексной оценкой IT-инфраструктуры в целом (если да наметим дальнейшие шаги); — дадим понимание, где скрыты риски и неоптимальности, влияющие на стоимость бизнеса; — дадим честный ответ, что с этим делать и с чего начать. @dm_bocharov на связи! ➡ Здесь кейс - как сэкономили собственнику 50 млн рублей. ➡ Узнать реальное состояние своего IT, можно по 6 вопросам, которые я задаю на каждом аудите.

Один из самых показательных кейсов в моей практике. Крупная компания. Масштабный проект автоматизации, внедрение одновременно нескольких десятков взаимосвязанных модулей. Подобных внедрений на рынке на тот момент практически не было. Сильная команда, понятная бизнес-задача, высокий уровень амбиций. Но с самого начала стало очевидно: основной риск не в технологиях. Руководители ключевых подразделений понимали, что успешная автоматизация неизбежно приведёт к изменению их команд. В результате — системное сопротивление: давление на первое лицо, попытки дискредитации, постоянное создание напряжения вокруг проекта. Работа шла в условиях, где, помимо внедрения, нужно было ежедневно удерживать управляемость и доверие. В какой-то момент стало понятно: техническая часть — лишь половина задачи. Вторая половина — управленческая. В итоге сработали три подхода. Первый — никакой прямой конфронтации. Вместо этого выстраивал ситуацию так, чтобы людям было попросту выгоднее быть на стороне проекта, чем против него. Когда человек видит личный интерес в успехе, его сопротивление само собой снижается. Не нужно давить, не нужно конфликтовать. Нужно правильно выстроить систему стимулов. Второй — полная прозрачность по проблемам. Любой риск или сбой сразу выносился в публичное поле с фактами и планом действий. Это убирает возможность использовать проблемы как инструмент давления и переводит диалог в конструктив. Третий — поэтапная реализация. Не пытались сделать всё сразу. Запускали модули последовательно, фиксировали результат. Как только появились первые результаты, начали формироваться внутренние союзники, и сопротивление стало снижаться естественным образом. Проект был завершён в полном объёме. Но ключевой результат был не в этом. После такого уровня сложности формируется другое качество доверия. Этот клиент стал одним из самых долгосрочных в работе. Если в вашем проекте есть сопротивление внутри бизнеса — это управляемый фактор. Вопрос только в том, как именно с ним работать. Если хотите разобрать вашу ситуацию и посмотреть, где сейчас точка напряжения, пишите @dm_bocharov. ➡ О 3 причинах проблем в проектах, я рассказывал здесь. ➡ А если хотите сначала понять, есть ли у вас системная проблема с IT — вот 6 вопросов, которые я задаю на каждом аудите. 📌 Впервые на канале? Начните с закрепа.

За последние 20 лет через мои руки прошло множество IT-проектов. И почти всегда причина проблем оказывалась не в технологиях и не в командах. Управление проектами — тема, в которой даже очень опытные эксперты не всё могут запланировать. Проекты откладываются, растягиваются, выходят за рамки бюджета, терпят неудачу. Я не буду утверждать, что знаю универсальное решение — это было бы неправдой. Но три причины, которые повторяются чаще всего, назову. Первая — недооценка проекта на старте. Не до конца поняли задачу, не оценили реальные возможности команды, не просчитали бюджет. В любом проекте есть то, чего заранее не знаешь, и под это обычно закладывают резерв. Проблема в том, что резерв часто занижают. А когда реальный объём отклонений оказывается больше, чем заложили, проект начинает требовать ресурсов, которых уже нет. Вот тогда он «захлёбывается». Вторая — отсутствие проактивного управления. Как правило, проект оценивают те же люди, которые потом им управляют. И когда начинаются задержки, у них возникает внутренний конфликт: признать проблему или попробовать "вытянуть" ситуацию, "пока никто не заметил". Почти всегда выбирают второе. А поскольку в проектах часто бывают не прописаны метрики, не выстроены механизмы эскалации, то задержку действительно никто сначала не замечает, и руководитель тянет до последнего, надеясь, что само образуется. Не образуется никогда. Первый же момент, который пошёл не по плану, — это сигнал действовать немедленно: подключать ресурсы и принимать решения. Не через неделю. Сразу. Третья — коммуникация. Большинство задержек, простоев и взаимных недопониманий — это не конфликты и не некомпетентность. Это плохо выстроенная коммуникация внутри команды и между командой и заказчиком. Даже очевидные вещи люди воспринимают по-разному. Любые договорённости нужно фиксировать и проверять, чтобы каждый понял их именно так, как нужно. Основная работа руководителя проекта — это не технические решения. Это качественная, регулярная, прозрачная коммуникация без задержек и недосказанности. Это не исчерпывающий список: тема гораздо шире. Но именно эти три вещи создают большую часть проблем, которые я видел. Что я могу вам дать: независимую оценку и подсказать, где ещё можно усилить свою внутреннюю IT-команду, чтобы не допустить в реализации возникновения тех или иных рисков, о которых я говорил раньше. Если хотите пройтись по своему текущему проекту и посмотреть, где сейчас нет ясности, пишите @dm_bocharov. На встрече расскажем о структуре нашей работы и честно ответим, сможем ли помочь: с оценкой текущего состояния IT-процессов, аудитом систем или комплексной оценкой инфраструктуры. Если да подскажем, что нужно изменить в первую очередь, и наметим дальнейшие шаги. ➡ Прежде чем запускать проект, полезно честно ответить на 6 вопросов про состояние вашего IT. ➡ А если задача - вернуть время команды через автоматизацию, вот как внедрять ИИ, чтобы не попасть в ловушку «успешного пилота», который так и не стал рабочим инструментом. 📌 Впервые на канале? Начните с закрепа.

6 вопросов, которые я задаю на каждом аудите. Просто ответьте себе честно на них, и вы поймёте, есть ли у вас системная проблема с IT или всё в порядке. Я использую их в начале почти каждого проекта. Первый вопрос: знаете ли вы точно, что является узким местом в ваших бизнес-процессах с точки зрения денежного потока? Ту точку, расширив которую, бизнес начнёт зарабатывать больше. Второй вопрос: можете назвать три IT-проекта за последний год, которые дали измеримый результат для бизнеса? Не «внедрили систему» и не «запустили модуль», а конкретно: сократили цикл сделки, выросла выручка, снизились затраты — с цифрами. Если не можете, то IT и бизнес, скорее всего, живут параллельными жизнями. А это, поверьте, очень дорого стоит. Третий вопрос: есть ли в вашей компании IT-стратегия, направленная на реализацию бизнес-задач? Именно стратегия с чётким пониманием, как IT помогает бизнесу зарабатывать больше, работать быстрее или снижать риски на горизонте двух-трёх лет. Четвёртый вопрос: бизнес получает то, что просит? Если нет, это уже не история про отдельные неудачные проекты. Это структурная проблема в управлении потребностями, приоритизации или распределении ресурсов. И она не решается сама по себе. Пятый вопрос: понимаете ли вы критерии оценки критичности IT-системы для бизнеса? Критичная система — та, остановка которой напрямую «бьёт» по выручке, по клиенту или по операционной непрерывности. Шестой вопрос: знаете ли вы, что конкретно произойдёт с бизнесом, если ключевая система будет недоступна в течение 24 часов? Не догадываетесь, а именно знаете, с оценкой потерь в деньгах. Если нет, значит, плана на этот случай тоже нет. А это уже вопрос выживаемости бизнеса. Если захотите разобраться, где именно теряется время и IT-бюджет в вашем конкретном случае, пишите @dm_bocharov, обсудим. Первая консультация - бесплатно. Разберём вашу ситуацию и определим: — где сейчас возникают лишние расходы или потери эффективности в IT; — есть ли системная проблема или вопрос можно решить локально; — какие шаги имеет смысл сделать в первую очередь, чтобы стабилизировать ситуацию. 📌 здесь кейс - как в производственной компании увеличили выручку по одному из направлений в 2 раза после проведения IT-аудита; 📌 здесь - как сэкономили собственнику 50 млн рублей.

Как внедрять ИИ так, чтобы он действительно начал работать на бизнес? За последний год я видел как успешные AI-проекты, так и те, которые остались на стадии эксперимента. И если смотреть на них ретроспективно, то разница чаще всего была не в технологии и не в размере бюджета, а в подходе к внедрению. Обычно лучше всего работают проекты, которые начинают не с самых амбициозных сценариев, а с базовых процессов, где эффект можно получить относительно быстро: 👌 поиск внутренних документов; 👌 работа с базой знаний; 👌 подготовка типовых писем и предложений; 👌 онбординг новых сотрудников; 👌 визуальный контроль физических процессов. Как правило, для таких задач не требуется сложная разработка — большинство языковых моделей уже многое из этого умеют. Следующий этап: более глубокая интеграция и кастомные решения. Но здесь важно, чтобы экономика проекта считалась через конкретный бизнес-эффект: сокращение времени операций, снижение нагрузки на команды, рост скорости обработки, влияние на выручку или качество сервиса. Потому что интеграция ИИ в реальные процессы почти всегда оказывается сложнее, чем выглядит на старте. И ещё один важный момент: на практике ИИ никогда не заменит сильных сотрудников. Зато он довольно хорошо убирает рутину, которая мешает им заниматься основной работой. Для коммерческих команд это особенно заметно: когда менеджеры меньше времени тратят на поиск информации, ручную подготовку документов и повторяющиеся задачи, высвобождается время на клиентов, сделки и управление процессом продаж. Если вам интересно посмотреть на вашу ситуацию со стороны и разобраться, с чего начать именно в вашей компании, пишите @dm_bocharov. Первая консультация бесплатно. На ней вы получите: - анализ основных узких мест с точки зрения автоматизации; - понимание того, какой инструмент подойдёт вашему бизнесу и почему; - оценку того, сколько реально можно сэкономить или заработать на автоматизации именно в вашей задаче. Пишите «КОНСУЛЬТАЦИЯ» @dm_bocharov — разберёмся. 📌 Это финал трилогии про ИИ. Начало здесь. 📌 А если хотите сначала понять, есть ли у вас системная проблема с IT — вот 6 вопросов, которые я задаю на каждом аудите.

Почему хороший эксперимент с ИИ не становится рабочим инструментом. За последний год часто обсуждал это с коллегами и клиентами. Сценарий повторяется довольно регулярно. Компания видит проблему, запускает пилот с ИИ. Команда собирает решение, появляются первые результаты, пилот выглядит успешным. А дальше начинается то, что в сам пилот обычно не попадает. Потому что успешный эксперимент и промышленное решение — это всё-таки разные задачи. На этапе пилота обычно важно быстро проверить гипотезу: может ли ИИ решить конкретную задачу и есть ли в этом практический смысл. Но после этого появляются вопросы другого уровня. Инфраструктура. Чтобы ИИ нормально работал внутри компании, нужны вычислительные ресурсы, архитектура, доступы, контуры безопасности. Без этого сотрудники продолжают пользоваться внешними сервисами и решать задачи «вручную», просто потому что так быстрее. Интеграция. Подключение к ERP, CRM и другим внутренним системам часто оказывается отдельным большим проектом. Причём по трудоёмкости он нередко превышает разработку самого ИИ-решения. Информационная безопасность. Между «модель работает» и «решение допущено в промышленную эксплуатацию» стоит большой объём функциональности, связанной с обеспечением безопасности: авторизация, контроль доступа, ролевые модели, работа с персональными данными и многое другое. В итоге возникает ситуация, которую, возможно, многие уже видели: пилот формально успешен, но бизнес-задача по-прежнему остаётся нерешённой. Просто переход от эксперимента к рабочему инструменту — это отдельная программа изменений, которую важно планировать заранее. Если у вас сейчас есть пилот, который застрял на этом пути — пишите @dm_bocharov. Разберёмся вместе, что мешает, как двигаться дальше и как внедрить ИИ в ваш проект без временных и денежных потерь. ➡ Это вторая часть трилогии про ИИ. Здесь три направления внутри компании, которые съедают время и деньги; Продолжение - как внедрять ИИ, чтобы он начал работать на бизнес. А если хотите сначала понять, есть ли у вас системная проблема с IT — вот 6 вопросов, которые я задаю на каждом аудите. 📌 Впервые на канале? Начните с закрепа.

Сколько времени ваши люди тратят на то, что не приносит финансового результата? Поделюсь наблюдением, которое вижу регулярно в компаниях с серьёзными оборотами и которое, мне кажется, будет узнаваемым. Люди заняты, все при деле, все устают. А когда начинаешь разбираться, куда именно уходит время, картина оказывается примерно одинаковой, вне зависимости от масштаба бизнеса. Три направления, которые съедают время тихо и незаметно. Поиск информации внутри компании. McKinsey измерили это ещё в 2012 году: сотрудники тратят в среднем 1,8 часа в день только на поиск и сбор информации. Около 450 часов в год на человека. Если в отделе 50 человек - это 22 500 часов в год, которые уходят на поиск нужного файла или согласование чего-либо. Составление типовых документов. Коммерческие предложения, отчёты, письма - каждый делает это заново, хотя 80% таких текстов похожи друг на друга. IDC оценивают потери производительности от этого в 21,3%, а для любого бизнеса это существенно. Потеря знаний при уходе людей — пожалуй, самая дорогая и при этом почти невидимая статья потерь. Уходит опытный менеджер, и вместе с ним уходят его подходы, понимание клиентов, процессов, его наработки. Всё это не передаётся автоматически следующему человеку, и всё это восстанавливается заново, со всеми сопутствующими затратами. Если пересчитать по современным показателям московского рынка труда, потери составляют около 1 млн рублей на человека в год. Возьмите количество ваших сотрудников и посчитайте сами: 100 человек — это 100 млн рублей, которые могли бы быть инвестированы во что-то полезное. Мне кажется, здесь как раз то место, где ИИ может дать реальный результат: не как замена людей и не как модный эксперимент, а как инструмент, который берёт на себя рутину и возвращает время на работу, которая действительно влияет на выручку. Отдельно разберу в следующем посте, почему эксперименты с ИИ часто не дают результата, даже когда начинаются очень многообещающе. ➡ Это первый пост трилогии про ИИ. Дальше - как внедрять ИИ, чтобы он работал на бизнес. А если хотите сначала понять, есть ли у вас системная проблема с IT — вот 6 вопросов, которые я задаю на каждом аудите. 📌 Впервые на канале? Начните с закрепа.

Правильно спроектированная архитектура создает опору для бизнеса. Так было и в этом нашем кейсе. Сначала расскажу почему это так, а потом и про сам кейс. Итак: Во-первых, ИТ-архитектура это всегда отражение бизнес-модели компании. В этом месте они, наконец, встречаются, если есть противоречия, то они сразу становятся видны. Во-вторых, это предмет для обсуждения на всех уровнях бизнеса и повод свериться и оказаться "на одной странице". В-третьих, это модель, отражающая взаимосвязи процессов в компании. Глядя на неё легче понять, что произойдёт, если "дёрнуть за шнурок" или "вытащить кирпич". Если ИТ ланшафт зрелый, а архитектура не отрисована, то эти связи часто выясняются по "бразильской системе". Отвалилось, значит связь была). В-четвертых, целевая архитектура - это картина будущего и визуальная дорожная карта. Закрашивая квадратики, легко понять темп изменений и сроки наступления абсолютого счастья. В-пятых, это основа для понимания необходимых ресурсов для обслуживания всего этого добра. Глянешь на эту карту во всю стену, ужаснешься и сразу понимаешь - зачем столько айтишников и кто над чем работает (или не работает). Теперь про кейс. Большая компания, много лет на рынке. Есть и производство, и логистика и дистрибьюция. И все это в разных странах. Есть и покупные ИТ решения и своя разработка. В общем, мы взялись за модель ИТ архитектуры, чтобы "причесать" ИТ ландшафт и понять, где есть неоптимальнтсти и точки роста (а если компании 20+лет, то такие точки всегда есть). Начали проводить интервью с руководителями и заметили, что они называют разные цели на ближайшие 5 лет. Начали все это сводить и поняли, что текущей архитектурой все эти цели не достигаются. Либо цели, либо архитектуру, надо менять. Крутили, крутили, подключали нескольких архитекторов и, в итоге, свели это все в единую целевую модель, где видно как с помощью ИТ компания планирует достичь стратегических целей. И самое для нас приятное: модель стала основным инструментом коммуникации бизнес-подразделений между собой. На основе неё стали проводить совещания и сверять планы, обсуждать: бьются ли цели между собой и как это обеспечить, планировать проекты изменений. В общем, все довольны. Используйте инструменты моделирования архитектуры, чтобы быть всей компанией "на одной странице". Никак не могу здесь поделиться, деталями кейса (NDA!), но могу прикрепить иерархию модели, которая, по-сути, отражает стратегию. Есть вопросы, пишите смело @dm_bocharov. Недавно на канале? Начните с закрепа. Также в MAX. #кейс #итаудит

Друзья мои, внимание! Польза! Мой приятель, Денис Сметнев, сооснователь Skyeng, на своём канале встречается с разными интересными ребятами, и обсуждает стартапы, инвестиции и все, что с этим связано! Если у вас стартап или планы на него, возможно, вам понравится.

Как заработать 50 млн руб? Просто не потратить их на ненужное. Рассказываю про недавний кейс. Достаточно крупное предприятие, есть и производство и логистика и дистрибьюция. Началось все как обычно. Руководитель одного направления бизнеса видит подходящее решение на рынке и понимает, что работу его людей можно автоматизировать, и предлагает соответствующий проект: "если внедрим это решение, то это позволит сэкономить столько-то времени людей, а значит и денег". Вроде, звучит здраво. Обычно, если порядки расходов и экономии сопоставимы и деньги есть, все соглашаются и "поехали". И в этом нашем кейсе все было именно так, только собственник засомневался и попросил нас дать независимую оценку. Как вы наверное догадываетесь, мы посчитали и опять сильно удивились ). Пропускаю детали и сразу перечислю основные ошибки таких оценок (чему некоторые ИТ компании очень радуются): 1) Не полный расчёт ТСО (совокупной стоимости владения) решения. Даже если все составляющие учтены в моменте, стоимость поддержки на горизонте нескольких лет почему-то учитывается не для всех. 2) Забывают про стоимость внутренних людей, отвлеченных на проект и последующее сопровождение. 3) Забывают про простую экономику: деньги приносят деньги, а если не приносят, то это убытки. Короче говоря, нужны не просто сумма расходов, а чистая приведенная стоимость денег на текущий момент времени хотя бы за 5 летний горизонт. 4) Выбирают не ту ставку стоимости денег (WACC) для расчёта потока в предыдущем пункте. Если коротко, то главный вопрос тут - а если я не вложу эти 50 млн в ИТ решение, то сколько за это время я заработаю денег на этом капитале? 5) Не верно оценивают эффект от внедрения решения. Ведь это может быть не только экономия на людях, но и другие принципиальные изменения в бизнесе. В общем, если про наш кейс. Оказалось, что если качественно посчитать, то компания заработает максимум 35 млн, если вложит 50. Даже при допущении, что она получит максимально полезный эффект от внедрения. Вот так! Считайте деньги, не отходя от кассы. Знаете тех, кому это полезно? Отправляем лучи финансового благополучия за репост. Недавно на канале? Начните с закрепа. Также читайте в Max. Спросить, посоветоваться, уточнить: @dm_bocharov. На связи! #кейс #инвестиции #итаудит