Подход
Ручные процессы в компании: восемь вопросов до того, как строить систему
Софт, положенный на неразобранный процесс, не делает его лучше. Он делает его быстрее неправильным.
У большинства компаний не проблема с софтом, а проблема с передачей. Мы сначала снимаем процесс, убираем дублирование, приводим к одной модели — и только потом строим. Эта страница описывает, что именно проверяется в разборе.
Сначала понять процесс. Потом построить подходящую систему.
Обычный порядок обратный: компания описывает, что её сотрудники делают сегодня, и получает софт, повторяющий ровно это — вместе с двойным вводом, обходными путями и шагами, которые существуют лишь потому, что кто-то ввёл их годы назад.
Мы работаем наоборот. Сначала записывается реальный процесс, затем убираются дублирование и лишние операции, затем всё приводится к одной модели — и только после этого проектируется система.
Разница не теоретическая. В проекте с тремя заводами и торговой структурой, продававшей их продукцию, съём и унификация трёх по-разному выросших процессов были самой тяжёлой частью работы — и условием того, что одна платформа вообще могла работать для всех трёх площадок.
Поэтому на выходе получается не CRM, не ERP и не приложение, а операционная модель компании: данные появляются один раз и дальше идут по тем процессам, которые действительно есть.
Восемь вопросов, из которых состоит разбор
Это не вопросы для протокола. Каждый вскрывает класс ошибок, который потом стоит денег.
- 01
Кто принимает решение — и на каком основании?
Кто может принять заявку, утвердить цену, запустить заказ. И по чему: по правилу, по опыту или спросив в соседнем кабинете.
- 02
Откуда приходит информация?
Каждый канал отдельно: сайт, телефон, сообщение, бумага, устная просьба. Каналы, которые никто не называет, — это те, где потом пропадают заказы.
- 03
Где она теряется?
Точки передачи между людьми и программами. Дорогие сбои почти никогда не происходят внутри отдела — они происходят между двумя.
- 04
Что заводится дважды?
Одно и то же значение в таблице, в отраслевой программе и в бухгалтерии. Двойной ввод — это не только трудозатраты, это две версии правды.
- 05
Какие решения человек принимает вместо правила?
Кому достанется заказ, когда дозаказать, какой мастер поедет. Вот здесь и лежит то, что действительно автоматизируется.
- 06
Что держится на одном человеке?
Процесс, который встаёт, стоит кому-то уехать на два дня. Это не кадровый вопрос, а конструктивная ошибка процесса.
- 07
Где возникает ожидание?
Между обращением и ответом, между сделкой и счётом, между выполнением и подтверждением работ. Ожидание — самая заметная часть сломанного процесса.
- 08
Какие цифры нужны руководству — и когда оно их получает?
То, что становится известно в конце месяца, месяц было неуправляемым. Этот вопрос решает, что системе вообще надо записывать.
Частые вопросы
- Что на выходе?
- Письменный документ: где сегодня теряется информация, что стоит автоматизировать и в каком порядке, что должно остаться ручным и почему, и грубый диапазон цены на разработку.
- А если хватит готовой программы?
- Тогда так и написано в документе, и программа названа. Разбор, который всегда заканчивается разработкой, — это не разбор, а продажа.
- Нужно ли давать доступы к нашим системам?
- Нет. Мы не работаем в ваших рабочих системах и доступов к ним не запрашиваем. Мы читаем документы и экраны и говорим с теми, кто делает работу.
- Сколько это занимает?
- Разбор по разговору и документам заканчивается письменным документом в течение трёх рабочих дней после первого разговора. Если процесс так не читается — мы это скажем, тогда нужен день на площадке.
- Засчитывается ли оплата в проект?
- Да, полностью, если проект стартует в течение 45 дней. Если мы придём к выводу, что помочь не можем, — вернём деньги.
Разбор процесса — €350
Один разговор, ваши документы, письменный документ за три рабочих дня. Засчитывается в проект, возвращается, если помочь не сможем.