SPb BA/SA: накапливая знания

В конце июля Strategy Quest вместе с Никитой Мошкаловым провели открытую бизнес-игру с новым кейсом.

По легенде, группа аналитиков была приглашена на три дня в производственную компанию, занимающуюся электроникой. Компания быстро выросла с 90 до 250 сотрудников, что привело к проблемам с управлением и увеличению погрешности себестоимости с 15% до более чем 40%.
Участники разбились на четыре команды для анализа ситуации и разработки решений.
🔹К1 предложила эволюционную модель цифровизации с переходом на 3 года.
🔹К2 сфокусировалась на повышении осознанности сотрудников.
🔹К3 сделала ставку на обучение и воспитание кадров.
🔹К4 предложила четкое разграничение обязанностей и разработку KPI.

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

Материалы с игры (фото, кейсы, полезные ссылки) – тут👈
Видеозапись встречи по рефлексии – тут👈

Завтра в 12.00 состоится бизнес-игра по решению сложного кейса. В этот раз мы разбираем новый кейс и новую ситуацию.

Уже можно раскрыть некоторые подробности.

С 2009 года на пепелище кризиса «08» начали образовываться небольшие ИП/ООО, которые жили по правилам «семейный бизнес» и «лучше меньше, но спокойнее». Кто-то вырастал в средний бизнес, большинство гибло. И вот с 21 года этот тренд плавного развития резко изменяется. Государство и частные инверторы начали массово вливать деньги в производство внутри страны. Заказов на 50 лет вперед, но нельзя увеличивать пропускную способность и производство по ряду весомых причин: модель семейного бизнеса для этого не подходит, нет процессов, нет кадрового резерва и понимания как это все делается. А самое важное, что есть недоверие ко всему новому.
Это происходит повсеместно, и кто научится решать такие задачи будет иметь конкурентные преимущества в ближайшие 5 лет.

📍До встречи на игре!

После последнего поста несколько человек оставили отзывы: «Я не готов решать бизнес-проблемы за свои же деньги». Сначала я не понял, откуда возникло такое впечатление, но потом осознал. Дело в том, что в описании в одном абзаце используются слова «реальный бизнес-кейс» и «хакатон». С одной стороны, мне нравятся люди с высоким самомнением, с другой — наивно полагать, что можно собрать в одном помещении пару аналитиков с 1+ годом опыта и за несколько часов создать готовое бизнес-решение. Хочу внести ясность.

Я беру реальные бизнес-кейсы, потому что:

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

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

🔹Понимание настоящих бизнес-проблем. В реальном времени обмениваться опытом и получить обратную связь от экспертов по бизнес-анализу и владельцев бизнеса. Это позволяет наращивать опыт в режиме «1 год за 3 часа».

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

И да, запись на игру все еще открыта (‼️ссылка в закрепе). Приходите 27.07 и убедитесь, что это лучший опыт.

Всем, привет!

Делюсь материалами с трека BA/SA на ProITFest

Все презентации тут - 👈

Наши спикеры:
🔹Ира Ильюшко. Фокус на данные, а не исследования.
Аналитики создают решения на основе данных, которые они нашли и собрали сами. Однако суть исследований на разных стадиях бизнес-анализа сильно отличается от маркетинговых, продуктовых и стратегических исследований. Приглашаем вас присоединиться к нам, чтобы вместе разобраться в типах заказчиков и зонах ответственности в процессе исследований. Мы совместно ответим на важные вопросы: какие исследования вообще бывают у аналитиков? Какие данные существуют и какие из них нам действительно нужны?
🔹Елизавета Акманова. Преимущества использования OpenAPI для системного дизайна.
Как использование OpenAPI в проектировании делает системный дизайн гибким и легко адаптируемым? Мы обсудим, как создание тяжелой обвязки вокруг проектирования упрощает поддержку и масштабирование системы. Участники узнают, как внедрить работу с OpenAPI в процесс системного дизайна, что позволит вносить изменения практически в реальном времени. Разберем преимущества этого подхода и то, кому стоит его использовать.
🔹Татьяна Долгина. Почему рефакторинг документации так важен для успешного продукта.
Попробуем в игровой и поэтому безопасной форме заняться развитием документации, совместно выделить моменты, когда рефакторинг нужен, а также принципы его проведения. Активность будет интересна в первую очередь аналитикам, чей проект находится в стадии развития. В итоге получим представление, как начать делать рефакторинг документации регулярно, а также продать идею рефакторинга не только команде, но и бизнесу.
🔹Булат Абдуллин. Код и архитектура: шаги по улучшению масштабируемости и качества.
Поговорим про то, как не допустить снижение скорости разработки на проекте. На живых примерах разберем подход к адаптации системного дизайна, через разбор архитектурных схем и внесению изменений в проект.
🔹Наталья Гусева. Мотивация: больше, не значит лучше.
Посмотрим на процесс работы с задачами изнутри: почему сложные задачи мы делаем охотнее, чем простые, правда ли, что чем более мы заинтересованы в результате, тем больше вероятность достижения цели, и как сделать так, чтобы хватало сил и мотивации на решение каждой поставленной задачи.
А также, как исследования британских ученых вековой давности помогут нам в этом.
🔹Николай Прохоров. Как микроэвентами облегчаем процессинг, хранение и обратную совместимость.
Поговорим как не попадать в ловушки некорректных продуктовых решений из-за кривых поступающих аналитических данных. Порассуждаем как можно сделать сбор данных для аналитики простым, отказоустойчивым и недорогим. В результате мы выработаем набор лучших практик, которые вы сможете применить у себя в продукте.