Три распространённые ошибки цифровой трансформации

📍 Технология - самое главное

Помогают ли технологии решать сложные задачи? Конечно! Все мы знаем массу успешных примеров, о таких ещё часто рассказывают на конференциях. Например, о том, как технологии искусственного интеллекта сэкономили десятки миллионов рублей на обслуживании оборудования. Но сколько неудачных примеров вам известно? Их много. И часто они случаются из-за неправильной оценки применимости технологии или конкретного продукта для решения поставленной задачи. Может существовать отличное технологическое решение, которое работает на многих предприятиях, но оно не интегрируется с вашими системами, или, что ещё хуже, не разрабатывалось с учетом требований вашей отрасли или бизнес-процессов. В этом случае начинается процесс забивания гвоздей микроскопом. Конечно, в некоторых случаях это работает. Можно решить отдельные задачи, цифровизовать некоторые функции, но построить цифровое решение, способное к масштабированию и адаптации к новым потребностям компании уже не получится.

📍 Быстрые проекты - быстрые результаты

Наверное, все любят “быстрые победы”. Кажется, что это магическое словосочетание звучит в каждом втором проекте. Давайте по-быстрому внедрим виртуальную реальность в процесс обучения и улучшим нашу работу в 10 раз! Это понятное и правильное стремление - краткосрочные выгоды придают дополнительные импульсы развитию цифровой трансформации в организации. Но строить всю дорожную карту трансформации короткими планами - ошибочный путь. Изначально нужно строить планы хотя бы на 3-5 лет. Долгосрочное планирование и возможность внесения корректировок в первоначальные планы - один из самых важных пунктов в успехе цифровой трансформации.

📍 Всё делаем сами

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

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

Сегодня поговорим про две из них – менеджмент и попытки обхитрить время.
Объясню на примере нашего проекта.

В Rubius мы сделали систему, которая отслеживает местоположение персонала и техники под землёй. Заказчик впервые покупал разработку, а не готовое ПО. Проект был комплексным: мы писали код, партнёры монтировали железо, а заказчик контролировал и ставил задачи.

🙅При правильном менджменте все понимают, кто за что отвечает и качество чего контролирует. И есть главный менеджер проекта, у которого в голове есть вся картинка с ролями, дедлайнами и артефактами. Но в этом проекте зоны ответственности были максимально размыты, и все надеялись друг на друга. В результате на этапе тестирования системы мы обнаружили, что датчики установили неправильно. Заказчик предположил, что пока ПО неготово – их нет смысла проверять. А мы не проговорили требования к проверке датчиков. В итоге все потеряли время на переустановке и отладке.


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

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

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

Как увеличить прибыль за счёт цифровой трансформации клиентского опыта? – Кажется, что у рынка уже есть примеры и ответы.

Цифровизация бизнеса – это тренд, который нельзя игнорировать. По прогнозам агентства "Research and Markets", инвестиции в этот сектор к 2025 году достигнут 1009,8 миллиардов долларов.

Что в тренде? Фокус на клиентском опыте. Так что, если хотите держать руку на пульсе, уделяйте внимание не только качеству продукта, но и удобству процесса покупки.

Идеальный пример – Квартиротека IKEA

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

В России 60% людей живут в стандартных советских квартирах с однотипными дизайнами и планировками. IKEA воспроизвела эти планировки в 3D-конструкторе “Квартиротека”. Сервис помогает клиентам подобрать мебель от IKEA и увидеть, как она будет смотреться у них дома, просто кликая мышкой.

Решение привлекло 2,8 миллиона посетителей на сайт IKEA, большинство из которых стали новыми клиентами. Это способствовало росту продаж в России на 17% в 2020 году.

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

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

“Илья, мы хотим начать с себя, а потом вывести продукт на рынок”

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

🔎 Попробуем разобраться.

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

Поэтому первый этап не подробное ТЗ, а исследования. Рынка, аудитории, проблем, трендов. Всегда. Даже если вам кажется, что вы на 100% знаете, в чём проблема таких компаний, как ваша. Ваша экспертиза сыграет с вами злую шутку, мы тоже в такой ситуации бывали – дорого и больно.

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

Что нужно анализировать:

📍Проблему, требующую решения, и целевую аудиторию. Здесь вы предполагаете, кто и в каких условиях сталкивается с какой-то трудностью в работе и насколько сильно она его беспокоит. Это называется гипотеза о проблеме.

Например, вы предполагаете, что бизнесу сложно контролировать удалённых сотрудников, он несёт убытки, а проблему можно починить внедрением HRM системы. Разобраться поможет глубинное интервью. Надо определиться, с кем вы будете говорить, чтобы понять, действительно ли удалёнщики – это головная боль. Это менеджеры, HR, руководители подразделений. А затем узнать ответ на главный вопрос, готовы ли они чинить эту проблему.

📍Объём рынка. Можно обойтись исследованием статистики в интернете. Например, использовать данные Росстата, Tadviser, Вышки, на английском можно почитать PwC, Gartner, Deloitte. В своих проектах мы миксуем все эти источники.

📍Конкурентов и аналоги. На кого позиционируются, сколько стоят, какие задачи уже решают? Растут или не растут? Здесь нужно смотреть отдельно русский рынок и зарубежный. Первую группу на Rusprofile, СБИС, Rusbase. Для анализа зарубежных проектов подойдут Techcrunch и Crunchbase. Сайты, статьи о продуктах, интервью основателей тоже ок.

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

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

Что можно читать и смотреть:
1. Про анализ конкурентов https://www.youtube.com/watch?v=6nPRgTfYqJA
2. Про глубинные интервью “Роберт Фицпатрик “Спроси маму”
3. Про оценку объёма рынка https://scrumtrek.ru/blog/product-management/product-glossary/6005/tam-sam-som-model/

Исследования в продуктовой разработке

Тренд на производство собственных цифровых продуктов у крупных промышленных компаний только набирает обороты. Например, Family Manager от строительной компаний ПИК. Сервис помогает спроектировать строительство дома до мельчайших деталей: окна, дверные ручки и др. Поэтому делимся некоторыми особенностями продуктовой разработки.

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

Что нужно сделать, чтобы от идеи перейти к продукту, не закопав миллионы в разработку
📌Сформулировать и проверить гипотезу потребности. На этом этапе нужно ответить на вопросы: Какую проблему/задачу пользователя сервис будет решать? Как много таких людей/компаний на рынке?
📌Сформулировать и проверить гипотезу ценности для пользователя
📌Сформулировать гипотезу решения. Определить, как должен выглядеть будущий продукт, какие функции для него важнее всего, а какие можно отбросить

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

На сайте Rubius написали подробную статью по теме с примерами из нашей практики.
→ Приходите почитать

Коллеги, меня хорошо слышно… А теперь?

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

Но мы не просто выдержали этот год, мы его прокачали!

Так что давайте на миг отложим все эти "BIMы” и “CADы” в сторону. Пусть наступающий год будет годом не только новых идей, но и годом заслуженного отдыха. Пора зарядиться новой энергией, чтобы в следующем году мы смогли создать что-то ещё более дерзкое и впечатляющее.

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

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

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

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

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

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

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

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

Так не бывает: инновации разработали, а производство внедрило 🙂

Самый болезненный/сложный этап в разработке инновационного проекта – это внедрение. Многие инновационные проекты в крупных компаниях терпят неудачу после перехода от отдела инноваций или исследований и разработок (R&D) к бизнес-юнитам.

Пример. Хорошая, большая, цифровизованная компания – просто пять звёзд. Отдел инноваций разрабатывает крутейшее передовое ПО для контроля качества монтажа коммуникаций на промышленных объектах. А потом наступает момент, когда надо это ПО передать в ответственный отдел условному ГИПу. И вот этот хороший в общем-то человек сидит и смотрит на новый приказ. И нет у него ни денег, ни ресурсов, ни понимания зачем, как, что. И начинается мелкий тихий саботаж. А у инноваторов и разработчиков начинается сыпаться KPI и картинка светлого будущего.

“Почему” тут несколько:
– недостаток коммуникации
– недостаточное вовлечение бизнес-юнитов
– недостаток ресурсов и недостаточная ответственность за успех проектов.

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

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

Если знаете другие инструменты, рад обсудить!

В отличном подкасте наших партнёров PRO-ТИМ рассказал всё самое интересное из истории Rubius и нашего пути в разработке инженерного ПО. Кто мы и почему до сих пор не закрылись, знаковые продукты и проекты, что мы умеем в BIM и облаках точек, какие сегодня тренды видим и почему не боимся работать со стартапами в столь нестабильные времена. Ребята сделали очень удобную навигацию по видео – приятного просмотра. И большой респект команде за качественный продакшн
https://www.youtube.com/watch?v=Nwm95Jm8pJM

Почему сотрудники сопротивляются внедрению цифровых проектов?

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

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

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

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

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

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

Наш хороший заказчик объявил тендер на проект, который являлся
небольшой частью глобального проекта цифровизации – разработка системы моделирования химического процесса. На тендер пригласили весь рынок. А победителем стала малоизвестная компания, предложившая "непобедимый" ценник на порядок ниже всех. Однако вскоре выяснилось, что она либо недооценила объём работы, либо не обладала необходимым опытом для его выполнения. В конечном итоге, проект был свернут после разработки только упрощённой версии модели. Упрощённая модель химпроцесса оказалась непригодной для использования в промышленных условиях.

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

Чтобы застраховаться от таких ситуаций, следует проводить тендеры в несколько этапов:

📍Техническая и технологическая проверка

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

📍 Проверка опыта на рынке

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

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

📍Оценка стоимости

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

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

Про директора по цифровизации

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

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

Классно же? Конечно классно и очень удобно! Но вот только… не особо реализуемо. Во-первых, естественно подробных корпоративных инструкций на все случаи нет. Во-вторых, что такое все случае жизни? А это почти дословное требование HR-директора (он являлся главным заказчиком системы).

И что делать когда от тебя ждут мини ChatGPT с полной информацией о всех процессах компании? Работать с ожиданиями. Чем и занялся наш директор по цифровизации. Планомерная методическая работа над ожиданиями позволила оформить проект в весьма классическую базу знаний с “элементами” искусственного интеллекта. Так и бизнес-требования по решению вопросов сотрудников выполнялись, и главный заказчик остался доволен “интеллектом” системы.

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

Если вам интересно, как работать с ожиданиями, то вот два моих любимых подхода:

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

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

Вместе два подхода работают идеально.