Версия 13:33, 28 февраля 2024

В середине февраля, 16-18.02 прошел первый Winter Analitycal Weekend (WAW). Это была давняя мечта организаторов Летнего аналитического фестиваля (ЛАФ) — сделать аналогичное событие зимой, и вот она, наконец, осуществилась. Мероприятие было относительно камерным, примерно 150 участников, проходило, как и ЛАФ в загородном отеле, так что можно было не только послушать доклады. но и отдохнуть и позаниматься всякими спортивными активностями. А также - активно общаться не только в перерывах, но и вечером в фойе отеля. Качество докладов было высокое, кроме докладов было много интересных мастер-классов. Кроме того, в замысле организаторов было обсуждение о будущем специализации аналитиков, для этого были организованы обсуждения в группах, которые прошли довольно активно.

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

В частности, Денис Бесков организовал очень интересное обсуждение про аналитиков: их область ответственности, хорошие практики, критерии выбора подходящих людей, способы обучения. Я активно участвовал, а участвовать и конспектировать у меня не получается. А Денис ухитрялся вести протокол в Миро А от меня — ссылка на мои доклады про разделение ответственности в разработке https://mtsepkov.org/Roles, которую я обещал участникам. Их было довольно много, тема развивалась.

В начале отчета — о моем выступлении. Мне был запрос от организаторов — поразмышлять о развитии ИТ и специализации аналитика. Доклад так и называется Место ИТ и аналитиков в будущем мире: Как учит системный подход, всякую систему надо прежде всего рассматривать в контексте объемлющей надсистемы. А значит, рассказ о будущем ИТ невозможен без рассмотрения развития мира в целом. Поэтому начинался доклад именно со сценариев развития человеческого общества в целом. С одной стороны. события последних лет показывают. что краткосрочные прогнозы тут сомнительны. С другой стороны. долговременные тренды примерно понятны. Все это было в докладе, презентация была сразу опубликована на моем сайте, а видео ожидается примерно в течении месяца после конференции. По отзывам участников, рассказ оказался интересным и полезным.

А теперь — про остальные доклады.

Алишер Умаров. Аналитик 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-страничника
• Попробуйте инструменты для отдельных элементов стратегии
• В рамках большой компании попробуйте сделать ландшафт стратегий

Шаблон 6-страничника.