Разработка VS Автоматизация

Хочу поделиться историей двух проектов, очень похожих по задачам, но очень разным по применяемым подходам.

Подход с позиции разработки

Давным-давно, во времена, когда мониторы еще были большими, а флеши маленькими, заказали мне разработку программы. Инвестор купил себе новый бизнес, который занимался посуточной арендой квартир в Москве. Задач было две:

1) Сделать внутреннюю автоматизацию компании, обеспечить точный учет всех операций и денежных потоков. И, как сформулировал задачу новый собственник: «Хочу видеть, что у меня не воруют».

2) Обеспечить возможность бронирования квартиры онлайн. Соответственно на сайте нужна была актуальная информация по их занятости, стоимости и т. д.

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

Опыта выполнения подобных проектов у меня тогда еще не было. Фактически, это была одна из первых задач, когда я работал не в составе большой команды, а напрямую поставлял результаты заказчику. К делу я подошел как хороший разработчик. Спроектировал БД, сверстал страницы для сайта, разработал удобный интерфейс для бек-офиса, позаботился о производительности (хотя там нагрузка было до 3-5 человек одновременно), настроил разграничение прав, контроли, логирование и еще кучу всего. Даже сейчас, с позиции многолетнего опыта автоматизации, считаю, что техническое решение было очень хорошим.

На одной из встреч по сдаче системы между инвестором и пользователями возник спор о системе мотивации покупателей. Собственник настаивал, что будут только накопительные бонусы, чтоб был стимул обращаться к нам еще раз. Менеджеры утверждали, что бонусы, это конечно хорошо, но обязательно нужны скидки. Тот случай, когда заказчик сам с собой поспорил, и каждый остался при своем мнении. А я, как хороший программист, принял официальную позицию собственника (читай «сделал по ТЗ»). Скидки запретил, бонусы запилил. Все суммы считались автоматом, изменить их было вообще нельзя независимо от прав и ситуаций.

Все тесты прошли, проект перевели в пром, я занялся уже следующей задачей и периодически сапортил свою разработку поэтому знаю о ее дальнейшей судьбе. А судьба печальная. Практически все вопросы от пользователей по системе были «а как сделать скидку?». Я терпеливо объяснял, что скидки запрещены, что есть бонусы, что так договорились (так в ТЗ) и вообще. Меня слышали, соглашались, уходили, но через 1-2 опять возвращались с тем же вопросом. Какие-то данные в системе появлялись, заказы велись, расписание актуализировалось. Проверить полноту и качество данных у меня как-то мысль не возникла. Я же программист – мое дело чтоб работало.

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

Для меня это был шок. Все проверки показали, что система работает правильно, ошибок нет. Но пользователи меня уже слушать не хотели. Собственник, который у меня эту разработку заказывал, денег назад не попросил, но смотреть стал криво.

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

· Кто-то из клиентов к скидкам уже привык и без скидки приезжать отказывался.

· Где-то переход был с баннера со скидкой. Не предоставить скидку нельзя.

· Бывало, что квартира простаивает. Или заказ сорвался в последний момент, есть другой, но хочет дешевле. Дать скидку 10-20% или не заработать ничего? Решение очевидно.

Менеджеры были замотивированы на процент от заказов. Поэтому оформляли продажи в системе как могли. Кто-то оставлял сумму как посчитала система, а по факту продавал со скидкой. Кто-то ставил в системе 4 дня, а сдавал на 5. А некоторые вообще заказы заводить перестали. В системе было неактуально все: и расписание, и учет денег, и заказы.

В результате хорошо сделанная, но плохо внедренная система привела к неуспеху проекта.

Подход с позиции автоматизации

А это наши дни. Делали автоматизацию другой компании, которая оказывает услуги по рекламе. Бизнес конечно сильно сложнее, но тоже довольно хорошо стандартизирован. Стоимость услуги можно рассчитать с точностью до копеек. Вроде уже наличными взаиморасчетами никто не пользуется, но одно из основных опасений менеджмента было именно в части скидок и откатов. Иностранный собственник из России ушел вместе с ПО, пришлось экстренно импортозамещать. А раз уже все равно все переделывать, то почему бы сразу не оптимизировать процессы и не усилить контроли. И первой же идеей было – запретить скидки для всех.

Но теперь у меня за плечами 17 лет проектного опыта автоматизации всего и вся. Долго спорил с заказчиком, несколько встреч провели. И в широком составе, и в узком и тет-а-тет. К счастью, удалось уговорить на первом этапе вместо запрета сделать отчет по предоставленным скидкам.

Результаты получились куда как лучше.

1) Мы вообще смогли запуститься. А это не мало, не все проекты проходят этот рубеж.

2) Система в проме, отторжения у пользователей не вызывает. Учет ведут довольно аккуратно, особенно под присмотром опытных консультантов. А значит, в системе накапливаются очень любопытные данные для анализа!

3) А вот результат анализа стоит самого проекта. Сгруппировав скидки по менеджерам стало очень сильно заметно, кто дает скидки чаще и кто дает самые большие. Этот же отчет в разрезе клиентов показал кому дают скидки чаще всего и в каком размере. Выводы, а точнее вопросы, которые возникли у руководства, были очень интересные. Оказалось, что у клиентов с большим объемом заказов, скидки маленькие или их вообще нет. А вот у нескольких относительно небольших клиентов скидки большие. Дальше каждый сам додумать может…

4) Нам, кроме благодарности клиента, достался дополнительный контракт на развитие системы. Пока скидки не запрещаем, но дорабатываем гибкую систему согласования. При определенном объеме небольшие скидки можно предоставить без согласования, а вот значительные – только после утверждения руководства.

1
5 комментариев

Разработка VS АвтоматизацияВообще говоря, суть любого ПО - автоматизация. По содержанию примеров возможно у Вас и корректное противопоставление, но термины выбраны неудачно ;)

Ответить

В этом и состоит идея: разработать ПО не равно автоматизировать. Для меня автоматизация - более широкое и комплексное понятие, которое может включать, в том числе, и разработку.

Ответить