Проектирование системы управления компанией до разработки

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

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

Когда это нужно

• Компания выросла, а управление осталось ручным. Раньше все решалось в одном кабинете, теперь три площадки и сто человек, а координация по-прежнему держится на совещаниях и мессенджере.
• Систем уже несколько, а картины нет. Есть 1С, есть CRM, есть таблицы. Каждая отвечает на свой вопрос, и ни одна — на вопрос «как у нас дела».
• Собираются заказывать разработку. Без проекта подрядчик либо посчитает с большим запасом, либо согласится на нереальный срок, а потом будет объяснять, почему не уложился.
• Предыдущий проект провалился. Систему написали, но ей не пользуются. Почти всегда причина не в коде, а в том, что не разобрались с процессами.
• Меняется собственник или руководство. Нужно понять, как компания устроена на самом деле, а не по схеме из презентации.

Что мы делаем

1. Смотрим, как работа идет сейчас. Не по регламентам, а по факту: интервью с теми, кто делает работу руками, и разбор реальных документов и таблиц. Расхождение между регламентом и практикой — обычно самое интересное в проекте.
2. Строим карту процессов. Кто инициирует, кто выполняет, где ждет, где переделывается, сколько занимает. С цифрами там, где их можно посчитать, и с честной пометкой там, где нельзя.
3. Находим потери. Двойной ввод, согласования без смысла, ожидание решения, работа по памяти. Каждая потеря измеряется хотя бы порядком величины, иначе про нее не о чем говорить.
4. Проектируем целевую схему. Как должно быть: какие контуры нужны, что автоматизируется, а что остается человеку, где проходят границы ответственности.
5. Проектируем данные. Какие сущности есть в компании, как они связаны, что считается источником правды для каждой. Это фундамент: ошибка здесь стоит дороже любой ошибки в интерфейсе.
6. Собираем план по этапам. С какого контура начинать, что во вторую очередь, что не делать вовсе. С оценкой сроков и стоимости по каждому этапу.

Что расходится чаще всего

Что вы получаете на выходе

Где здесь искусственный интеллект

Проектирование — работа головой, и подменить ее моделью нельзя. Но часть ее ускоряется заметно.

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

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

Сроки и стоимость

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

Что именно мы смотрим

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

• Где данные вводятся дважды. Самый частый и самый дорогой вид потерь. Один и тот же факт человек заносит в таблицу, потом в 1С, потом пересылает в письме.
• Где решение ждет человека. Согласования, у которых нет срока и нет замены на время отпуска. Здесь обычно и живет большая часть календарного времени процесса.
• Где работа держится на памяти. «Иван знает, как считать эту надбавку». Пока Иван на месте, все хорошо. Это не автоматизация, это риск.
• Откуда берутся цифры в отчетах. Часто выясняется, что одна и та же цифра в двух отчетах считается по-разному, и обе версии считаются правильными.
• Что происходит при отклонении. Процессы обычно описаны для нормального хода. Вся сложность — в отменах, возвратах, доплатах и исключениях, и именно они съедают время.
• Кто что видит. Права доступа почти всегда либо отсутствуют, либо настроены так, что их обходят. И то и другое — предмет проектирования, а не настройки после запуска.

Как проходит работа по времени

1. Стартовый созвон, 1 час. Определяем границы: какие процессы смотрим, каких не касаемся, с кем нужно поговорить. Сразу договариваемся, какой результат считаем успехом.
2. Сбор материалов, 2–4 дня. Ваши текущие таблицы, формы документов, регламенты, выгрузки из существующих систем. Смотрим их до интервью, чтобы не тратить время людей на очевидное.
3. Интервью, 4–8 разговоров. Отдельно с исполнителями и отдельно с теми, кто принимает решения. По 40–60 минут и обязательно порознь: в группе люди повторяют за руководителем.
4. Сборка схемы, 3–7 дней. Карта процессов, модель данных, список потерь. Здесь же появляются вопросы, которых не было в начале, — их закрываем короткими уточнениями.
5. Прототипы и план, 3–7 дней. Ключевые экраны и разбивка на этапы с оценкой. Прототипы показываем тем же людям, с кем говорили: это последняя дешевая точка для правок.
6. Защита результата, 1,5 часа. Разбираем проект вместе с вашей командой, фиксируем решения и согласовываем первый этап.

Где это работает

• Производство. Самый частый запрос — понять реальную себестоимость и загрузку. Почти всегда упирается не в отсутствие системы, а в то, что факт не фиксируется в цехе.
• Оптовая торговля и дистрибуция. Управляемость теряется на стыке закупок, запасов и продаж: три службы оптимизируют свое и вместе получают замороженный склад.
• Сервис и обслуживание. Заявки, выездные бригады, запчасти, договоры. Проектируется в первую очередь маршрут заявки и то, как в него встраиваются люди в поле.
• Строительство. Много участников и подрядчиков, учет идет по объектам и этапам. Основная потеря — в согласованиях и в материалах, которые уехали и не вернулись в учет.
• Группы компаний. Несколько юрлиц и площадок с разными учетными системами. Первая задача — не единая система, а общий язык: одинаковые справочники и одинаково считаемые показатели.

Чем это отличается от консалтинга

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

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

Частые ошибки

• Проектируют по регламентам. Документ описывает, как должно быть, а не как есть. Автоматизация желаемого дает систему, в которую никто не вносит данные.
• Спрашивают только руководителей. Руководитель знает, как задумано. Как получается, знает тот, кто оформляет заявку каждый день.
• Стараются описать все. Толстый документ никто не читает, и он устаревает раньше, чем закончен. Проектируется то, что войдет в ближайшие этапы.
• Откладывают модель данных. «Сначала интерфейсы, структуру потом» — самая дорогая экономия в проекте.
• Не назначают владельца. Если со стороны компании нет человека, который принимает решения, проект встает на первом спорном вопросе.

Что бывает дальше

Проектирование не обязывает заказывать разработку у нас. Дальше возможны три пути, и все три нормальны.

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

Дальше по теме