ПО на заказ VS «коробочное» решение: помогаем бизнесу сделать правильный выбор

Автоматизация процессов особенно нужна в условиях роста бизнеса и увеличения рутинных задач: HR-процессы, сбор финансовой отчетности, прочие задачи, которые сотрудники выполняют «руками». Всё это необходимо автоматизировать, снизить риск человеческой ошибки и освободить сотрудников от рутины. Потому что в конечном счёте так мы снизим расходы на выполнение стандартных процессов.

О том, в каких случаях и каким компаниям может подойти готовое коробочное решение, а когда лучше обратиться за разработкой ПО на заказ, расскажу я, Алёна Болдырихина, лид бизнес-анализа IT-компании Red Collar.

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

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

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

Итак, давайте разберемся, когда же все-таки можно использовать более дешёвое «коробочное» решение, а когда лучше вложиться в кастомный продукт и в перспективе получить от этого гораздо больше выгоды.

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

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

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

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

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

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

А теперь рассмотрим в каких случаях кастомное ПО лучше всего подойдёт бизнесу.

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

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

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

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

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

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

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

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

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

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

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