Как сделать свою систему ведения контрактов и не сойти с ума — реальные кейсы, применимые в любом бизнесе

В применении коробочных решений для автоматизации бизнес-процессов есть ряд проблем.

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

Внедрение какого-либо решения — не гарантия того, что у компании вырастет эффективность, повысятся продажи. Команда может пренебрегать инструкциями, если решение не удобно использовать и бизнес-процесс «натянут» на него.

За коробочные решения нужно платить. Бесплатной версии практически всегда недостаточно. И чем больше сотрудников, тем дороже стоит решение.

Расходы на оплату коробочных решений растут ежегодно и их сложно запланировать. Это происходит из-за повышения тарифов или изменения условий. Так Google Диск раньше хранил на платной подписке 1 ТБ, а теперь 500 Мб, потому что изменились условия.

У коробочных решений есть интеграции, но они не могут учесть все потребности бизнеса.

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

Мы разработали индивидуальное программное решение для Investmann. Эта компания помогает получить банковскую гарантию организациям, участвующим в закупке.

Как выглядит процесс получения банковской гарантии для клиентов Investmann:

Это сложный процесс, в котором одновременно участвует несколько человек. Они должны координироваться между собой, быстро получать информацию от заказчика и передавать ее банку. Получение гарантии может занять несколько месяцев, но заказчик ограничен сроком в несколько дней.

Investmann использовали связку из трех коробочных решений:

Какие это порождало проблемы:

В итоге Investmann решили разработать свой программный продукт, который будет заточен под процессы компании и они обратились к нам.

Разработка уже стартовала и, спустя месяц, Monday сообщил, что прекращает работу с РФ и оставляет месяц на перенос всех данных.

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

Подробнее об этом случае мы рассказали здесь.

Проектирование ПО — это прежде всего сбор и анализ требований.

В ходе проектирования можно более точно оценить сроки разработки. Понять, что какую-то фичу в продукте стоит реализовать, но ее разработка займет несколько месяцев и для MVP она не нужна. Ее можно отложить и выпустить рабочую версию в более короткие сроки.

Или понять, что какая-то фича не нужна вовсе и отказаться от нее, сэкономив время и ресурсы.

Если вы приносите подрядчику свое ТЗ, то лишаетесь возможности проверить, что он все правильно понял. Лучше принести черновик, набросок. Тогда подрядчик должен будет понять, что именно нужно и объяснить это вам.

Если вы в ТЗ прописываете как все должно работать, то подрядчик разработает продукт, который будет ему соответствовать. Но он уже не несет ответственность за то, чтобы ПО было полезным.

В рамках проекта Investmann мы собрали 2512 требований. В них входят:

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

А еще позволяет видеть, что какая-то фича добавляет к ТЗ еще 10 000 требований и, возможно, ее стоит отложить или вообще не делать.

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

С этим подходом мы получаем гибкий программный продукт, в который на этапе разработки заложены различные интеграции.

Большое количество требований позволяет подробно описать бизнес-процесс и то, как он должен работать:

Разработка своей системы работы с контрактами дало Investmann:

Заинтересовало решение? Напишите нам в Телеграм или заполните форму на сайте. А еще мы можем усилить вашу команду специалистами. Узнать подробности можно здесь.