Первая ступень до любой разработки: разбор того, как работа устроена сейчас. На выходе документ - карта процессов, места потерь с оценкой в деньгах и объём работ с ценой. Этап самодостаточный: после него можно ничего не разрабатывать или уйти с этим документом к любому подрядчику.
Когда нужен отдельный разбор
Обследование имеет смысл не всегда. Если задача узкая и понятная, дешевле сразу делать. Разбор окупается в других ситуациях.
Автоматизировать хочется, но неясно что
Проблем много, бюджет один. Без оценки потерь список задач сортируется по громкости жалоб, а не по деньгам.
Оценки подрядчиков расходятся в разы
Разные цены обычно означают разное понимание задачи. Сравнивать нечего, пока объём работ не описан одинаково для всех.
Процесс держится на одном человеке
Решение принимается по файлу, который ведёт он один. Пока файл не разобран, автоматизировать нечего: логика живёт в голове.
Программу купили, ей не пользуются
Система стоит, а работа идёт мимо неё в таблицах. Причина обычно в процессе, и новой разработкой она не лечится.
Что смотрим по фактам
Разбор идёт не по регламентам, а по тому, как люди работают на самом деле. Регламент показывает, как задумано, экран показывает, как получилось.
Кто что делает руками
Пооперационно: какие данные человек переносит, куда и сколько раз в день. Обычно ручного труда больше, чем ожидают в кабинете.
Где данные вводятся дважды
Одно и то же заводится в кабинет маркетплейса, в складскую программу и в отчёт. Каждый повтор это точка расхождения.
Где решает один файл
Закупка, цена или отгрузка зависят от таблицы одного сотрудника. Ищем правила, по которым он считает, и записываем их.
Где работа ждёт
Заявка лежит, пока кто-то не откроет почту. Простои видно по датам в системах, а не по ощущениям участников.
Что уже стоит и работает
Складской учёт, кабинеты маркетплейсов, бухгалтерия, мессенджеры. Часть задач закрывается настройкой того, что есть.
Во что это обходится
Часы людей, замороженный в товаре оборот, потери от ошибок и упущенные продажи. Каждое место потерь получает оценку.
Что на выходе
Один документ, четыре части. Он написан так, чтобы его читал владелец, а не только разработчик, и чтобы по нему можно было работать без меня.
Карта процессов как есть
Схема движения товара, денег и документов: участники, системы, точки передачи. Без слоя пожеланий, только текущее состояние.
Места потерь с оценкой
Список проблемных участков, отсортированный по деньгам в месяц. Рядом с каждым видно, откуда взялась цифра.
Объём работ с ценой
Что именно нужно сделать, с описанием экранов, данных и интеграций. По этому описанию цену назовёт любой подрядчик.
Порядок внедрения
Что запускается первым контуром, что вторым. Каждый шаг приносит пользу сам по себе, а не только вместе со следующими.
Как идёт работа
- Разговор с владельцем. Что болит, какие решения принимаются вслепую, где деньги теряются заметнее всего. Это гипотезы, дальше их проверяем.
- Наблюдение за работой. Разговоры с теми, кто делает работу руками, и просмотр их экранов. Здесь всплывают файлы и обходные пути, о которых наверху не знают.
- Цифры. Выгрузки из систем и подсчёт стоимости потерь по каждому участку. Без этого приоритет назначается по громкости, а не по деньгам.
- Документ и разбор выводов. Карта, потери, объём работ, порядок внедрения. Проходим по документу вместе, спорные места правим, дальше он ваш.
Иногда вывод в том, что разработка не нужна
Часть потерь снимается без кода: сменой порядка работы, перестановкой шагов между людьми или настройкой программы, которая уже куплена. Такой вывод попадает в документ наравне с остальными. Разработчику это невыгодно, зато честно, а работать с компанией потом всё равно проще.
Смотрю на процесс со стороны операций, а не только кода: до проектной практики я был операционным директором e-commerce компании с оборотом 4 млн долларов в месяц. Знаю, как выглядит склад в пиковый сезон и почему красивая схема разваливается на приёмке.
Как это выглядит в работе
Ниже системы, которые выросли из такого разбора. По каждой есть подробный кейс и кликабельное демо на вымышленных данных.
Частые вопросы
Чем бизнес-анализ отличается от разговора о задаче
Разговор опирается на то, как процесс описывают словами. Разбор опирается на факты: кто и в какой программе нажимает кнопки, какие файлы открывает, сколько раз одни и те же данные вводятся заново. На словах процесс почти всегда стройнее, чем на деле.
Что я получу на выходе
Документ из четырёх частей: карта процессов как есть, список мест потерь с оценкой в деньгах, объём работ с ценой и порядок внедрения по одному контуру. Это рабочий материал, а не презентация. По нему видно, с чего начинать и что можно не делать вовсе.
Можно ли уйти с этим документом к другому подрядчику
Да, документ ваш. В нём описан объём работ, а не привязка ко мне: любой подрядчик прочитает его и назовёт свою цену. Иначе обследование превращается в способ продать разработку, а это разные задачи.
Зачем считать стоимость потерь в деньгах
Без цифры нельзя расставить приоритеты: список проблем всегда длиннее бюджета. Оценка показывает, какой участок съедает больше всего и что окупится первым. Считаем по времени людей, по замороженному в товаре обороту и по ошибкам, которые находят задним числом.
А если окажется, что разработка не нужна
Такой вывод тоже попадает в документ. Часть потерь снимается сменой порядка работы или настройкой программы, которая уже куплена. Код ради кода стоит дороже и живёт хуже, чем поправленный процесс.
Что нужно с вашей стороны
Доступ к людям, которые делают работу руками, и к файлам с отчётами, которыми они пользуются каждый день. Плюс выгрузки из систем, которые уже стоят. Владельцу обычно хватает двух разговоров: в начале и на разборе выводов.
Если нужен взгляд со стороны на то, как устроен процесс, напишите пару строк о том, что болит: LinkedIn или Telegram. В ответ придут вопросы по делу, а не презентация.