Автоматизация против Excel: уроки из Формулы 1

Для многих компаний Excel остаётся незаменимым инструментом для обработки данных, учёта и планирования. Однако чем больше компания развивается, чем больше заказов выполняет, тем больше проблем в работе на базе Excel. Но через боль и страдания многие остаются на привычном инструменте. Почему же так сложно отказаться от Excel и чем это чревато, можно понять, проанализировав опыт команды Формулы 1 Williams.

Williams – легендарная команда в Мире Формулы 1 с годовым бюджетом в районе 200 млн $ в последнее десятилетие переживает не лучшие времена и не показывает высоких результатов. В сезоне 2022 года и вовсе заняла последнее место в итоговом зачёте. Недавно новый генеральный директор Джеймс Воулз рассказал о проблемах, которые есть в команде, и одна из них – учёт деталей и комплектующих для гоночных автомобилей в Excel. Таблица в 20 000 строк никак не помогала в сборке автомобиля. Как отмечал один из механиков завода: “Я не знал, где находится компонент, и мне приходилось физически осматривать весь завод в поисках нужных деталей. И я не всегда находил их.”

Ключевые причины, по которым организации откладывают или вовсе избегают перехода к автоматизированным системам:

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

📍Боязнь новых рисков и неопределённости
Автоматизация влечёт за собой изменения в устоявшихся процессах и, как следствие, определённые риски. Компании могут бояться, что использование новых сервисов приведёт к сбоям и ошибкам, потере денег. Здесь важно трезво оценить то, как процесс работает сейчас. Конечно, работа идёт, но насколько эффективно полдня сверять 10 версий одного файла и по 3 раза переделывать КП или спецификацию?

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

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

Разработка программного обеспечения – это сложный и многострадальный процесс, который требует взаимодействия множества участников. Без определения общих целей разработки с заинтересованными сторонами и ЛПРами ничего не выйдет. Что даёт такая вроде бы простая вещь, как синхронизация по целям.

📍Все знают, чего от них ждут: Это помогает избежать недоразумений и несоответствий во взаимодействии между разработчиками, заказчиком и другими заинтересованными сторонами.

📍У всех есть мотивация быть в проекте: Работа на одну цель сплачивает, но хорошо бы, чтобы все понимали, а зачем это лично им. За идею люди не так долго способны шагать вместе. Личные цели тоже нужно прояснять.

📍Все видят риски и работают с ними: Все понимают, что будет, если не сделать проект или сделать плохо. Все согласны со списком рисков и их весами. Тогда с вероятностью 99% команда честно отработает всё, что сможет, для их минимизации.

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

📍Все играют в win-win: Синхронизация по целям как ни странно даёт доверие и желание того, чтобы все остались в выигрыше. А это залог успеха и в моменте, и в будущем. Согласитесь, не хочется потом всю жизнь избегать встреч с участниками проекта на всех бизнес-тусовках, куда всё равно придётся ходить.

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

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

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

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

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

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

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

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

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

Провели вебинар "Облака точек". Обсудили кейсы облаков точек в строительстве и добыче, посмотрели демо. Было много вопросов про то, как работать с облаками без спец ПО и восстанавливать облака точек из фото и видео 360. Запись вебинара по ссылке.
Буду рад продолжить обсуждение!

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

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

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

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

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

К слову мне эти аргументы не помогли😁

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

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

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

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

Что делать ИТ-директорам, чтобы им давали денег и людей и видели их вклад?

📍Инициируйте инновации
ИТ-директор должен быть не только исполнителем, но и инициатором изменений. Должно быть видение, предложения и аргументы к ним. Следите за трендами, посещайте конференции, спикерам которых вы доверяете. Я люблю инженерные, типа 100Build Tech, но уверен, что в каждой отрасли есть свои классные. Присмотрите для себя пару-тройку технологий и найдите тех, кто или такое уже внедрял, или кому-то делать. Точно будет полезно поговорить часок.

📍Не пытайтесь сразу построить “Байкал” за 200+ млн
Начните с малых инициатив, которые могут продемонстрировать положительный эффект от внедрения технологии. Да, все говорят, что концепция пилотов устарела. Но это работает. Каждый день вижу, что да.

📍Синхронизуйтесь с топ-менеджментом по бизнес-целям компании
Предлагать инновации, не понимая глобальных целей компании, – путь в никуда. ИТ-директор должен знать не только о текущих проектах, но и о долгосрочных планах. Цифровизация – это всё-таки про завтра. Самый простой шаг – участвовать в стратегических встречах, какими бы длинными и хаотичными порой они ни были.

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

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

📍Ищите правильных людей в команду. Под себя и под проекты
ИТ-директор “Бытпласт” Александр Громов:

Успешный ИТ-директор – это не только технарь, но и бизнес-партнёр, стремящийся к созданию ценности для всей компании. Эта деятельность невозможна без сильной команды, поэтому построение команды, её развитие – это один из ключевых пунктов успешности ИТ-директора

В перерывах между докладами родился пост с кодовым названием "3 строчки для расчёта КП” 🙂

Вчера коллеги переслали мне далеко не первый в моей жизни супер лаконичный запрос клиента

Ознакомились с вашим портфолио. У нас 300 проектировщиков, нужна система для контроля эффективности работы. 40% – удалёнщики за пределами РФ. Ждём КП.

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

Что точно нужно знать мне как подрядчику, чтобы выдать корректное КП на задачу. Даже если я сделал уже 30 таких проектов:

📍Какую самую главную задачу мы решаем. Даже если заказчик выбрал тип ИТ-решения и уверен, что его проблему это решит, мне тоже нужно знать, с какими злом мы боремся. Вдруг я знаю способ быстрее и дешевле?

📍Как выглядит бизнес-процесс в компании: ключевые этапы и участники. Россия – огромная страна и важных нюансов в процессах – десятки. И часть из них точно повлияет на стоимость разработки.

📍С чем и кем нам нужно “подружить” наше решение: интеграции, требования надзорных органов, правила ИБ. Это у всех тоже разное. Кому-то, например, можно опенсорс, а кому-то в эту сторону даже смотреть нельзя.

📍Когда должен быть результат. Сажать одновременно 10 разработчиков на 2 месяца работы и 1 на год – это разные КП.

И у любого цифровизатора эти вопросы будут. Просто у опытного будет готовый опросник с вариантами ответов. А с неопытным придётся поговорить 2-3 часа, чтобы всё собрать.

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

У программистов термин "костыль" почти всегда имеет негативную окраску. Да что там у каких-то программистов, я сам когда активно занимался программированием с задором на ревью кода находил "костыли" и весело стебался над авторами (тайно надеясь, что мои “костыли” никто не найдёт).

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

Сегодня про такой "костыль".

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

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

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

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