Зачем нужен анализ процессов перед началом ERP-проекта?

В демо ERP всё работает гладко; проблема в том, что компания из демо — не ваша. Анализ процессов — это работа, в ходе которой шаг за шагом выясняется, как на самом деле идут дела от заказа до получения оплаты, прежде чем переходить на какую-либо программу. Успех ERP-проекта во многом зависит от качества этой работы.

В этой статье мы рассказываем, почему анализ нельзя пропускать, что в нём выясняется и какие документы должны быть у вас на руках по его итогам. Подход мы разбираем на принципах YazSis ERP, которую строим как архитектуру, подстраиваемую под бизнес.

Что будет, если пропустить анализ?

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

• Границы проекта плывут: просьбы «давайте добавим и это» накапливаются посреди проекта, сроки растягиваются, и становится предметом споров, какая работа входит в первый этап.
• Начинаются двойные записи: работа, для которой в системе нет места, по-прежнему ведётся в Excel; две записи со временем расходятся, и непонятно, какая из них верна.
• Пользователи сопротивляются: вместо того чтобы облегчать работу, экран заставляет заполнять лишние поля. Тогда программа воспринимается как дополнительная нагрузка.
• Ответственность остаётся неопределённой: кто даёт согласование и кто решает исключения — об этом спорят уже после запуска, хотя решить это можно было в начале проекта.

Анализ процессов: пять шагов

1. Нарисуйте поток как есть. Запишите, от кого к кому и с помощью какого инструмента сегодня идут заказ, закупка и движение запасов. Важен не должный, а реальный поток.
2. Соберите исключения. Возврат, частичная отгрузка, разница в цене, срочный заказ — такие «нештатные» случаи могут составлять значительную часть ежедневной работы. Программе тяжелее всего именно с ними, поэтому для них нужен отдельный список.
3. Уточните согласования и полномочия. Кто согласует суммы выше определённого порога, кто может дать скидку, кто вправе исправлять остатки? Ответы должны привязываться не к человеку, а к роли.
4. Перечислите источники данных. Где хранятся список клиентов, карточка товара, прайс-лист? Какой из них актуален и кто его обновляет? Места, где одна и та же информация живёт в нескольких местах, — это те места, которые в системе сводятся к одной записи.
5. Решите, что вы будете измерять. Если заранее выбрать несколько показателей, которые руководство хочет видеть каждую неделю, экраны и отчёты будут построены под них; добавлять отчёты потом всегда сложнее.

Небольшой пример: согласование скидки

Клиент просит скидку. Менеджер по продажам пишет руководителю в WhatsApp, руководитель отвечает «хорошо», и менеджер готовит предложение. Никто не описывал это как процесс, но он работает каждый день. Если при переходе на ERP этот поток не записать, в системе либо вообще не будет шага согласования, либо будет шаг, которым никто не пользуется. Анализ переносит это невидимое правило на бумагу и делает его пригодным для встраивания в программу. Тот же метод работает и для других негласных правил — исправления остатков, выбора поставщика, приёма возвратов: сначала выясняется, кто и на каком основании принимает решение, затем это решение записывается в систему как шаг.

Процесс, который вы не смогли объяснить программе, в программе работать не будет.

Кто должен участвовать в анализе?

Лучше всего процесс знают те, кто занимается этой работой каждый день. Поэтому анализ не должен ограничиваться уровнем руководства и ИТ; в нём должны участвовать менеджер по продажам, кладовщик, специалист по закупкам и бухгалтер. Руководство рассказывает, как работа должна идти, а сотрудник — как она идёт. Разница между этим и есть настоящий рабочий список проекта. Иногда эта разница — не потребность в программе, а просто недостающее правило или лишний шаг согласования; увидеть это во время анализа гораздо меньше хлопот, чем обнаружить после запуска.

Что должно быть у вас на руках по итогам анализа?

Хороший анализ заканчивается не устными совещаниями, а конкретными документами. Эти документы становятся опорой и для внедрения ERP, и для последующих изменений; когда приходит новый сотрудник или новый руководитель, именно они объясняют, почему система устроена так:

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

Наш подход: ERP должна подстраиваться под бизнес

YazSis ERP мы строим по четырём принципам. Эти же принципы определяют, что будет решено по итогам анализа процессов:

• Сохранить действующую систему: работающую ERP не демонтируют; недостающие процессы достраиваются.
• Расширять отдельным модулем: процесс, который стандартный продукт не покрывает, разрабатывается под компанию.
• Объединять данные: общий поток информации строится через API и интеграции с базами данных.
• Измерять и улучшать: управленческие отчёты делают видимыми узкое место и результат.

Если вы хотите вместе составить карту ваших процессов и определить состав первого этапа, свяжитесь с нами через страницу YazSis ERP.