2024-02-28: WAW-2024 - хороший старт: много хороших докладов и мастер-классов и интересных обсуждений
В середине февраля, 16-18.02 прошел первый Winter Analitycal Weekend (WAW). Это была давняя мечта организаторов Летнего аналитического фестиваля (ЛАФ) — сделать аналогичное событие зимой, и вот она, наконец, осуществилась. Мероприятие было относительно камерным, примерно 150 участников, проходило, как и ЛАФ в загородном отеле, так что можно было не только послушать доклады. но и отдохнуть и позаниматься всякими спортивными активностями. А также - активно общаться не только в перерывах, но и вечером в фойе отеля. Качество докладов было высокое, кроме докладов было много интересных мастер-классов. Кроме того, в замысле организаторов было обсуждение о будущем специализации аналитиков, для этого были организованы обсуждения в группах, которые прошли довольно активно.
Я выступал, слушал доклады и участвовал в обсуждениях, вел репортаж на своем телеграм-канале, а сейчас публикую единым отчетом. Организаторы поощряли активность по организации различных обсуждений, для этого было два отдельных зала, и они оказались заполнены довольно плотно.
В частности, Денис Бесков организовал очень интересное обсуждение про аналитиков: их область ответственности, хорошие практики, критерии выбора подходящих людей, способы обучения. Я активно участвовал, а участвовать и конспектировать у меня не получается. А Денис ухитрялся вести протокол в Миро А от меня — ссылка на мои доклады про разделение ответственности в разработке https://mtsepkov.org/Roles, которую я обещал участникам. Их было довольно много, тема развивалась.
В начале отчета — о моем выступлении. Мне был запрос от организаторов — поразмышлять о развитии ИТ и специализации аналитика. Доклад так и называется Место ИТ и аналитиков в будущем мире: Как учит системный подход, всякую систему надо прежде всего рассматривать в контексте объемлющей надсистемы. А значит, рассказ о будущем ИТ невозможен без рассмотрения развития мира в целом. Поэтому начинался доклад именно со сценариев развития человеческого общества в целом. С одной стороны. события последних лет показывают. что краткосрочные прогнозы тут сомнительны. С другой стороны. долговременные тренды примерно понятны. Все это было в докладе, презентация была сразу опубликована на моем сайте, а видео ожидается примерно в течении месяца после конференции. По отзывам участников, рассказ оказался интересным и полезным.
А теперь — про остальные доклады.
Содержание
- 1 Алишер Умаров. Аналитик 2.0 — Шестирукий Шива или как выжить в современных реалиях с ИИ
- 2 Дмитрий Безуглый. Трансформация отдела Анализа: Пути к Усилению роли и ценности в условиях интенсивной цифровизации
- 3 Наталья Семенова. Концептуальное мышление — драйвер развития и преодоления непреодолимого
- 4 Евгений Скориков. Модели автоматизации бизнес-процессов вместо функциональных требований
- 5 Борис Вольфсон. Ландшафт стратегий в большой компании
Алишер Умаров. Аналитик 2.0 — Шестирукий Шива или как выжить в современных реалиях с ИИ
Основной тезис: ИИ может стать помощником: переписывать текст в заданном формате, например, OpenAI; разбираться в коде или настройках конфигураций, писать SQL-запросы, рисовать диаграммы и так далее.
Это несложно, и сильно повышает производительность, есть замеры. До 70 % на шаблонных задачах. 50 в среднем экономии. Быстрое кросс-ревью. Ускорение *3 при неполной или отсутствующей документации: проект начинался, сделали как-то поговори об этом с разработчиками и узнай… Как оценивал эффективность? У него было несколько команд, в разных областях. Была оценка, плюс опыт аудита — для этого у него была моделька для оценки артефактов. И он оценивал изменения в работе команды до и после.
В конце Байкин добавил кейс. Нужно было разобраться с HR. Попросил ИИ написать типовые процессы, детализировать, придумать KPI. Послал, HR-директор оценил: о, какие хорошие!
И в ответ Алишер добавил использование: прослушай встречу 2 часа, расскажи что важное. Потом спросить про пояснения. Провалидируй требования.
Что нужно для этого? Главное — надо уметь ставить техническую задачу, чтобы понял ИИ. Он не домысливает, вернее, часто домысливает неверно. Очевидная вещь в SQL — синтаксис, ограничения, что хотите. Русский язык технически сложен, сложнее английского или испанского, там много ловушек неоднозначности — надо разжевывать, писать структурно. Это полезно не только для ИИ.
Риски ИИ известны: невалидированные результаты, неправильная постановка задачи, ограниченность данных обучения (ChatGPT знает состояние 21 года).
Зачем это надо? Аналитик может стать core-участникам команды.
Во всех вакансиях пишут полотенца текста, по которым аналитик должен понимать вообще все. Почему работодатель требует все это? Потому что часто источник требований — имеющаяся система. Посмотреть на базу данных, посмотреть на формы, код и так далее. И это надо уметь. Можно с помощью ИИ — и он реально поможет.
А вот умение говорить со всеми интересантами — это пока самому, отдельная компетенция.
Как делать, чтобы не утекало? Сбер и ВТБ — стали делать свои модельки. Еще можно обезличивать — как датасеты, ТЗ тоже можно обезличивать. И можно обезличивать код, если его надо прочитать. Еще можно договориться, что поднимаем в своем контуре.
Из комментариев.
- Phil Delgyado. Хмм. В известном чате сисаналитиков есть свой чатбот. И я регулярно смотрел на вопросы и ответы. И 70 процентов ответов (в моей компетенции) содержат критические ошибки — пропущены важные тезисы, придуманы несуществующие возможности, просто куча воды и так далее. Опытный специалист в теме — да, может использовать ответы как источник 'воды' или проверку 'не забыл ли что'. Неопытному ответы от текущего AI скорее вредны. Ну и если в компании внедрение chatgpt дает большую прибавку к производительности, значит значительная часть артефактов просто не нужна и надо бы процессы починить)
- mtsepkov. Ну, там были конкретные примеры: опиши api по тексту формально для swagger, нарисуй по тексту диаграмму и т. п. Там понятная экономия времени и польза. Речь про «расскажи чего не знаю», в основном, не шла. То есть это — не средство повысить квалификацию, а средство быстрее сделать полутехническую часть работы.
- Phil Delgyado. Вот все эти примеры, на мой взгляд, про вредное. Не должно быть таких задач вообще.
- mtsepkov Это не отдельные задачи, а кусочки. То есть нет задачи «сделать описание для swagger по тексту», есть задача «спроектировать api», результат — в формате swagger. Её человек может делать сам, а может — давая текстовые описания ИИ с просьбой выдать результат. Второй способ быстрее. С диаграммами — аналогично. И так далее.
Дмитрий Безуглый. Трансформация отдела Анализа: Пути к Усилению роли и ценности в условиях интенсивной цифровизации
У Димы, как часто бывает, получился доклад из ряда не слишком связанных, на мой взгляд, тезисов. Но каждый из них — отдельно интересен.
Зачем презентация? Мы пришли в ИТ чтобы сделать мир лучше. И мечтаем о том, чтобы компания принимали стратегические и локальные решения разумно, с учетом последствий, чтобы продуктами можно было гордиться. Он в эту сторону работает уже много лет, а ощущения — как лягушка толкает бегемота.
Информатизация — этап, когда ИТ использовалось чтобы улучшить процессы в компаниях. Enterprise unify process — апофеоз. Позиционирование. БА — гуру, которые помогают бизнесу принимать решения. СА — гуру в области реализации. Но этот этап — прошел. А новый этап — цифровизация. И твердый факт: ИТ и отделы проектирования не возглавили цифровизацию. И вообще прошла мимо CIO.
Почему? Потому что аналитики могут быть интересны бизнесу как партнеры, А для этого они должны уметь анализировать рынок, конкурентов, unit-экономику, прогнозировать. А они — не про это, они бодаются о том, писать use case или user story, а от бизнеса ждут постановки задачи. И бизнес теряет интерес, и не видит, о чем разговаривать.
Впрочем, у бизнеса тоже бывают странные представления про аналитиков. В Авито был период, когда велели всем аналитикам обучиться BABOK. B они пытались натянуть эту теорию на свою практику.
Взаимодействие бизнеса и ИТ бывает печально: из 100 заявок, реализуется 2, при этом ломается в 10 местах, идут критические баги. А дальше — стокгольмский синдром, бизнес от ИТ зависит, «давайте дружить мирно». Впрочем, я думаю, что Дима тут сильно утрирует ситуацию. И реакция зала говорит о том же. Реально ИТ дает ценность для бизнеса, и бизнес — понимает какую именно.
Цифровизация — история не про то, что берем существующий бизнес и пытаемся усилить ИТ, к 100 людям в операционке добавить 50 ИТ и взлететь. Это идея о том, чтобы заменить тех людей. Не ходить к прачке с вопросом, как сделать автоматическую стиральную машину. Кредитный конвейер — не то, чтобы поддержать работу 10к андерайтеров. Они про то, чтобы работал автомат, который поддерживают 20 человек и 200 человек разбирали не типовые частные случаи. То есть ИТ должно перестроить бизнес.
С моей точки зрения, тут и правда и неправда. Потому что информатизация — тоже про это, и задачи такого изменения кредитного конвейера я слышал еще в конце 90-х, и не просто слышал, банки так и делали. Конечно, бывает и то отношение, о котором говорил Дима, и когда-то был этап, когда автоматизация преимущественно поддерживала бизнес, но это было давно. Еще в 2017, рассказывая про эволюцию ИТ-проектов на SECR я говорил о сращивании ИТ и бизнес-частей проекта, смотри 7 слайд презентации https://mtsepkov.org/BA-methods-SECR-2017
При этом Дима тут же делает вывод о том, что от проектов надо переходить к продуктам. Но рассказанная история про кредитный конвейер не создает никаких новых продуктов, нет там никакого продуктового мышления. Продуктовое мышление — про другое. Про что именно продуктовое мышление, на мой взгляд, Дима так и не сказал.
Но вот то, что классическая проектная организация, особенно с выделением ИТ-проекта — тупиковая ветвь развития — в целом правильно, тут я согласен.
Дальше был спорный тезис о том, что даже когда бизнес не слишком готов к цифровизации, аналитик должен наносить пользу и должен делать бизнес все более цифровым, насколько это возможно. На мой взгляд, чаще всего в результате такого подхода будет не польза, а вред, за который аналитик будет огребать, а потом жаловаться, что бизнес его не так понял.
А вот что верно, это схема современного изменения в управлении, которая зафиксировала ряд переходов.
- Задачи -> Цели
- Люди -> Команды
- Мотивация -> Ценность
- Процессы -> Продукты
- Структура (иерархия) -> Сеть
Отсюда метастратегия: от оптимизации к трансформации. Задача анализа: двигаться от проектов в создание и развитие продуктов; быть источником данных для data driven decision. При этом работа с данными часто чистое поле, которое легко отдают. Дальше задача — научиться извлекать из data lake то, что будет наносить пользу бизнесу. Не ждать от бизнеса задачи, а самому порождать идеи.
И в конце была очень интересная схема как стать частью решения, с конкретными областями. На ней Product lab — песочница, в ней весело. Stars Fab — новые растущие продукты, здесь офигенно. А начинаем с Data Lab.
К моему конспекту был комментарий Димы: «С моих слов записано не верно))) Спасибо за конспект». В общем, да, я всегда интерпретирую в конспекте и в результате смысл может отличаться от замысла автора. Это относится ко всем конспектам.
Наталья Семенова. Концептуальное мышление — драйвер развития и преодоления непреодолимого
Видео доклада
Для меня загадка этого доклада — ссылка на первоисточник концепции концептуального мышления как подхода к мышлению. Быстро находится Conceptual Thinking, но это вроде что-то другое. Из доклада я бы сформулировал, что концептуальное мышление — просто мышление с помощью концепций. Для которого выделено 7 уровней, начиная с 0:
- 0 — не пользуется
- 1 — пользуется базовыми правилами
- 2 — распознает модели
- 3 — применяет сложные концепции
- 4 — упрощает сложность
- 5 — создает новые концепции
- 6 — создает новые концепции по сложным вопросам
- 7 создает новые модели
Это я записал со слайда, можно подробнее посмотреть на телеграм-канале Наташи https://t.me/SmartSpeaker_public/48
Дальше в докладе было много историй, как различные концепции помогали ей решать разные ситуации в жизни. Как иллюстрация самого подхода.
Смена взгляда inside — inside out — outside in помогла разобраться в ситуации, когда она не видела развития и ушла из аналитиков выращивать чеснок. Мы часто видим сферу, в которой находимся. И не знаем, что за ней. И потому не знаем куда идти — внутри все известно, а снаружи — неизвестность и муть. Надо выйти в inside out и далее outside in.
Лалу в открывая организации будущего дал схемы развития мышления: импульсивная, конформисткая, достиженческая, плюралистическая, эволюционная парадигмы.
IGOE framework (inputs guides outputs enablers) помог выбрать направления развития.
Цикл Колба, который начинается с ошибки: опыт — анализ — теория — практика. Его применил руководитель, спровоцировав ее развитие, а концепт она узнала через пару лет.
Окно Джохари: мне/другим известно/неизвестно. 4 зоны, и есть зона неизвестного. И многие консультанты дают модели, известные им, но неизвестные вам. Вы приходите к семейному консультанта, он говорит: «у вас разные языки любви» или «вы в треугольнике Карпмана». Модель описывает частично, вы понимаете — и снова к психологу. Но если бы знали самостоятельно — могли бы применять. И учитывать сложность. Но там есть область неизвестного ни вам ни другим, что в ней делать?
У нее был доклад про делегирование, который реально был про лидерство. В какой-то момент поняла, что от нее ждут лидерства, принятия решений, и начала это делать, и учиться этому. Но пошел конфликт с руководителем. Разобраться помогла модель Адизеса: она и руководитель были предприниматели, а модель объясняет, что они всегда будут конфликтовать. Ситуацию объяснили. Модель помогает и решить ситуацию, и строить команды — чтобы были нужные факторы.
Модель холакратии — выстраивание автономных зон ответственности и принятия решений.
Как только узнал про модель — можно применить. И это экономит время. Ты идешь наверх — всегда упираешься во что-нибудь.
Читала про VUCA — BANI — не заходило. Хотя антихрупкость зашла — а она про BANI. Но последние 2 года перешла из западной компании в российскую. Многое перестало работать. Почему? И нашла концепт SHIVA — он дал объяснение: зарождается новый мир, а не просто разрушается старый. И она поставила вопрос: как надо изменить парадигму мышления чтобы в SHIVA-мире жить, не изменяя ценностям. И она выписала: что нельзя делать, и что другое нужно делать. Согласовала мышление с миром.
И выводы. Что делать для развития концептуального мышления
- Менять взгляд inside-out — outside-in
- Изучать существующие концепции, не переизобретайте велосипеды
- Переводите в диаграммы — об этом не было, но это очень полезно, и все модели были визуальными. А это перенастраивает мозг
- Идите туда, где нет готовых решений
Только помните: концепции упрощают, поэтому важно знать много и смотреть с разных сторон.
Евгений Скориков. Модели автоматизации бизнес-процессов вместо функциональных требований
Очень интересный доклад о том, как реально происходит проектирование систем. Не теоретически обоснованным одним спуском по уровням, пусть даже замкнутым в итерационный цикл, а с многочисленными возвратами. И какие мыслительные операции выполняются на каждом шаге. И поскольку он это делает не осознанно, то у него боль от несоответствия идеальному процессу, описанному в учебниках, а еще он может пропускать важные, но не очевидные шаги. В презентации было много схем, а у меня будет линейный конспект.
Уровни — есть:
- Бизнес в целом — вписка в рынок
- бизнес-процессы
- модель автоматизации БП
- Функциональный дизайн ИТ-систем
- Конструктивный дизайн ИТ-систем
Но в динамике по ним разворачивается сложный путь.
Рассказ был на конкретном примере, что позволяло почувствовать, что лежит за словами: фотостудия для интернет-магазина, в которую привозят образцы товаров для фото и публикации, а сами образцы возвращают на склад. И на входе процесс был организован вручную.
Вводная: ручной процесс трудоемок и дает ошибки при привязке фото к товарам, давайте попробуем это улучшить с помощью автоматизации. Типичная вводная от бизнеса.
Первый шаг — модель процесса. Бизнес ее не принес. Тут она проста: заказать, привезти, снять и две ветви: привязать к товару и отобразить, а товар вернуть на склад.
2. Идея автоматизаци -: новая конструкция взаимодействия людей и софта, которая решил проблемы. Помечаем проблемные точки: заказать товары для съемки; правильно привязать фотки. Для каждой — идея решения.
Заказ решается быстро, делаем отчет, сравнивая товары на складе с наличием фотографий товаров.
С привязкой — сложнее. Тут решение НЕ очевидно. Товар определяется своим штрих-кодом. И можно взять умный фотоаппарат и запрограммировать, снимать им сначала ШК, потом товары, и чтобы он делал привязку каждой фотки. А можно брать обычный фотоаппарат и пусть фотограф снимает сначала ШК, потом товары, а дальше умная загрузка пойдет по последовательности фоток.
У решений выписываем плюсы и минусы — по качеству решения, трудоемкости, надежности. Дальше делаем выбор. Важно, что выбор делает бизнес, а не аналитик — он видит больше аспектов. Типичная проблема, когда аналитики сделали выбор сами, из своего понимания, и какие-то аспекты не учли. Но задача аналитика — подготовить варианты. Для выбора нужна какая -то оценка трудоемкости. Не точная — она должна быть достаточна для разделения вариантов. Кроме трудоемкости могут быть смежные аспекты, например, потенциал развития. А еще проблема, когда аналитики берут первое попавшееся решение, вообще не смотрят варианты.
Дальше решение детализируется по разным бизнес-процессам.
- Детализировать модель — по шагам
- Детализировать контекст. Съемка одежды и съемка конструктора — разное: одеть куртку на манекен или собрать из конструктора что-то — разное время. А декоративная сетка — вообще нельзя в студии.
- Детализация бизнес-процесса. Своя фотостудия или чужая — тогда билинг и так далее, ценообразование с выбором фотостудии.
- Контроль качества
- Управление процессом
- Обеспечение деятельности — расходники и так далее.
- Фискальный аспект
- Последовательность, организация, информация.
Для шагов есть типовые задачи, например, заказ со склада — там надо использовать, не придумывать. А есть — не типовые, их надо уметь конструировать через типовые. И нужен опыт оценки трудоемкости, чтобы удерживать стоимость.
Это все — проработка на бизнес уровне.
3. Прямая проекция на функциональные требования. Мы решили, что будет последовательность фоток: ШК и снимки товара. Где брать ШК? На товаре или на накладной? На накладной — увеличивает ошибки, на товаре — может быть сложно снять. А при загрузке: надо уметь отличить ШК от фоток товара.
Когда мы поделили на задачи — потерялась связь между ними. Печать ШК на накладной — это основной способ их получить, или это workaround когда нет ШК на товаре, и на первом шаге можно без него? При этом печать накладной, скорее всего, уже есть, то есть нам надо доработать стандартную фичу, и, наверное, вставить эту задачу соответствующей команде — поэтмоу важно понимать критичность.
Еще делаем проекцию на структуры данных. ШК — может ли один быть у нескольких товаров и так далее.
При проекции не создается новых знаний или принятие решений. Просто преобразование.
4. Возврат на проектирование — при проекции появились серые зоны, надо проработать бизнес-уровень. Например, может ли быть один ШК к нескольким товарам? Если может быть, то как разбираться? На уровне процесса. Могут быть дополнительные атрибуты и выбор при привязке фоток на загрузке, а может быть оклейка уникальными ШК, чтобы избежать дублирования.
Обработка исключений. Фотограф забыл сделать фото ШК, или система не может ШК распознать — как исправляется ситуация? Например, поскольку на товаре ШК может быть плохой, печать на накладной дублирует возможность сделать фото.
При возврате к уровень бизнес-процессов они могут меняться, и, возможно, потребуются доработка автоматизации.
4. Функциональный дизайн. Например, нужно контролировать количество ракурсов. При этом у разного вида товаров — разное количество. Например, у обуви 7, у одежды — 8. Вопрос: что сделать в ИТ-системе, чтобы был контроль? Hard code, настройка — в атрибутах товаров или сбоку через наборы условий и так далее. Из вариантов надо сделать выбор. Если мы выбрали таблицу правил, то дальше вопрос: какой язык записи правил, какие атрибуты. И появляется новый процесс заполнения таблицы.
5. Есть модель автоматизации — делаем дизайн. А потом идет возврат от дизайна к модели. Аналитики часто делают дизайн в рамках конкретного типового набора. А в конкретных случаях может быть нужен выход за типовые рамки. И от дизайна — идет возврат на уровень конструкции системы и бизнес-процессов с учетом дизайна.
6. Конструкция. Типовые деления, виды приложений, которые мы используем.
7. Исполнение конкретных функций. Например, фотограф сделал фото и как грузит? В локальную папку и указывает? Или в сетевую, откуда система сама автоматом забирает?
8. Возвратное проектирование. Фото 10мб, 10 фото на товар, 100к товаров — получили объемы, они дают технические решения. И тут могут появиться проблемы.
9. Проработка аспектов качества — было на ЛАФ. Там аспекты, которые меряют потери против расходов на обеспечение качества. Например, чтобы формочки открывались быстро. А тут на форме 10 фото, и будет открываться 16 секунд — очень долго. Разные тактики, например, авторесайз загруженных фоток, чтобы отображать уменьшенные. И тут возвратным ходом может быть решение хранить картинки не в БД, а на медиасервере, потому что он автоматом делает авторесайз.
Аспекты качества — на разных уровнях. Верхний — качество бизнес-процессов, а автоматизация — одна из тактик. Хотя качество автоматизации тоже играет.
Источник идей автоматизации не обязательно прилетает сверху, от бизнеса. Он может быть снизу — от новых технологий, от идей команд.
В завершении — комплексная картинка. С перемещением по уровням вниз-вверх, с возвратами, проработкой вариантов и выбором.
А где функциональные требования? Они возникали во всех операциях в двух случаях.
- При декомпозиции они являются способом отбросить лишнее, при этом может оказаться, что выполнение сложно — и надо вернуться. А для этого надо фиксировать варианты и основания выбора. Это не делают — и нельзя проверить ТЗ.
- Модель взаимосвязи разных моделей.
Есть мыслительные операции, когда вообще не использовали ФТ. Конструкция -> дизайн — работа с моделью. Проекция моделей — тоже без ФТ.
Итого, аналитик не просто обеспечивает согласованность решений стейкхолдеров, он делает оптимальное решение. Первое решение далеко не всегда оптимально.
- Мы создаем модели вариантов конструкции и дизайна с помощью типовых конструкций и конструирования из них.
- Решения по выбору принимает менеджер.
- Все это делаем используя некоторое количество мыслительных операций, они перечислены.
- Между уровнями — всегда конструкция. Внутри уровня может быть проекция.
И есть боль. В постановках очень часто пишут, что надо изменить. И в результате разобраться, как система работает в окружении очень сложно — надо инкрементально проработать все постановки. Нужно быть представление, чтобы работать сейчас.
Борис Вольфсон. Ландшафт стратегий в большой компании
Сфокусированный и минималистичный рассказ про то, как делать стратегию с конкретными фреймворками и материалами. Иллюстрирвоанный примером Сбермаркета и еще нескольких. Сбермаркет — динамично развивающийся стартап, с с 2016, 2019 — 1.9, 2020 — 20.7, 2021 — 62.6, 2022—102.8, в конкурентной среде: Озон фреш, Вкусвилл, Wildberries и т. д. Когда пришел, были явные признаки проблем со стратегией: постоянные пожары и хаотичное планирование — план на квартал-год с непонятными целями. Вообще типичная ситуация — каждое подразделение бежит в свою сторону, и менять курс, перефокусироватсья — сложно. Есть успешный пример Netflix, который рассылал DVD и смог переключиться на стриминг. А его конкурент блокбастер — не смог.
В России идет активный выход, но есть большие бренды, у которых нет интернет-продаж, и у них могут начаться проблемы. И надо уметь фокусироваться в одном направлении и в идеале — как единое целое. Сейчас интенсивный рост у Самоката и Яндекс-лавке. Чем они отличаются? У них — узкий ассортимент, 2-3к, в отличие от Магнита 5-6к или супермаркета на 10-15к. Зато сделали фокус на скорость доставки. То есть фокус — это еще и отказ от каких-то направлений.
Фокусировку важно согласовывать вплоть до слова, расхождения во мнениях топов вызывает большие расхождения ниже — правило маятника. Прибыльные и неубыточные — о разном. Стратегическое видение — 1-2 страницы текста, и проходят несколько раз, добиваясь понимания.
Стратегию надо не только принять, надо еще и действовать в соответствии с ней. Типичная ситуация, когда операционка и мелкие проекты забирают львиную долю времени, а на большие стратегические проекты его не остается. Правильно — наоборот. Об этом была известная иллюстрация про заполнение банки камнями: начинать надо с крупных проектов с ключевыми ставками, а мелочь должна заполнять промежутки, а не наоборот. стратегических проектов мало, на 6к человек — не более 10. Стратегия из 100 шагов никогда не будет сделана.
Пример фокусировки. В ecomerce 3 направления: быстрые и удобный сервис, широкий ассортимент и выгодные цены. Провели анализ в 2020 и сфокусировались на сервисе. В после начала СВО перефокусирвоались на выгодных ценах — стало более востребовано.
Что НЕ делаем — тоже есть в документе. В 2020 году было зафиксировано:
- Core — доставка grocery essentials из любимых магазинов.
- Не запускаем moms & pops формат — любимые магазины на районе
- Не делаем работаем с услугами, не делаем youdo и подобное
Ландшафт стратегий.
- Корпоративный: платформа на каждый день + устойчивый, прибыльный и публичный бизнес
- Вертикальные стратегии: клиенты, ритейлеры, сборщики и курьеры, бренды, новые вертикали и эксперименты
- функциональный уровень: продукт, разработка.
На функциональном уровне.
- Видение продукта, через 5 лет или через 1-2 года (зависит от стабильности). Целевой CJM в сбермаркете. Или в B2b телекоме — день сотрудника в контексте работы. Haven & help: текущая картинка для вашего или чужого продукта с болями, и идеал
- 5-7 ключевых инициатив. Метрики и ответственные за них.
Фреймворк PlayToWin — для вертикальных стратегий. Делал Procter & Gamble, доступны шаблоны
- Цели inspirations — большая вдохновленная цель, супер-OKR. Как у Форда: машин должно стать больше лошадей.
- Where to play — рыночные сегменты где играем и где НЕ играем, точки атаки. HH когда начинался — только на белых воротничках, а только потом только пошел на синие.
- How will we win choosen markets Как мы победим на этом рынке
- Capabilities и management systems
Самое пробемное — выбор рынка и способа победы на них. Канвасы value proposition, в книге Blue ocean strategy
6-страничник — основной формат для создания и обсуждения стратегии. Не презентация. Есть шаблон от Амазон. Черновик, разослать и попросить прокомментировать. И разбор, правка. Чтобы на выходе встречи был документ.
Книги:
- playing to win — фреймворк
- good strategy bad strategy — различия
- Blue ocean strategy — инструменты value канвас
- Working Backwards Colin Bryar and Bill Carr
- On strategy сборник Harvard business review — там конкретные кейсы
Как доносить до команд?
- 6-страничник обсуждается с продуктовыми директорами, и к концу обсуждения каждый понимает для своего подразделения
- Потом презентация продуктовым лидам. На каждый параграф текста рисуют 2-3 экрана — восприятие для визуалов. И эта презентация показывается всем, нужен overcommunication
- Цели — OKR. У каждой ключевой ставки есть метрики. И дальше идет вниз. Именно это обеспечивает исполнение.
Где именно определяются показатели — зависит от культуры компании, у него есть опыт и сверху и снизу. В любом случае это согласуется.
Каждый человек понимает, что такое быстрая доставка или хорошие цены. И как он может повлиять своей работой. Наприvер, на выгодные цены менеджер по работе с поставщиками влияет за счет договоренности об акциях и скидках, которые делают цены выгоднее, а доставщики — снижением себестоимости доставки, чтобы предложить лучшие условия доставки.
И в заключении — что делать.
- Прочтите материалы
- Попробуйте формат 6-страничника
- Попробуйте инструменты для отдельных элементов стратегии
- В рамках большой компании попробуйте сделать ландшафт стратегий
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.