В этой статье речь пойдет не про разработку комплексной ERP-системы для автоматизации всех бизнес-процессов организации, а о разработке локального решения, программного продукта, решающего конкретную бизнес-задачу.
Программа для решения задачи
Такие программы чаще всего заказывают организации, которые уже используют другие (как правило стандартные) шаблонные системы. Приведем пример — у организации несколько шаблонных систем: стандартная CRM, СКУД для учета рабочего времени сотрудников, номенклатура ведется в 1С. Однако имеется проблема, например файлы чертежей для производства хранятся просто в общей папке и для их поиска используется 2 системы — сначала по списку номенклатуры, потом поиск по папкам или именам файлов в сетевой папке. Или на производстве автоматизировано множество процессов, однако в них не автоматизированы процессы ОТК.
По причине того, что уже используемые системы являются шаблонными, они не поддаются изменениям или эти изменения очень трудоемкие, выбирается вариант заказать информационную систему для решения локальной задачи или конкретного бизнес-процесса.
Бутылочное горлышко
Если организация приходит к пониманию, что отсутствие автоматизации конкретного процесса является “бутылочным горлышком” в основном бизнес-процессе, то это очень хорошо потому, что это начало пути к решению проблемы. При этом локальное программное решение для конкретной задачи — если эта задача является узким местом — является максимально эффективным с точки зрения окупаемости информационной системы.
Первый шаг
Кроме того, локальный программный продукт (если он имеет правильную архитектуру) может являться первым модулем в рамках построения единой большой системы, автоматизирующей множество бизнес-процессов и в итоге всю организацию.
Пробный камень
Заказ локальной программы, информационной системы решающей конкретную задачу является хорошим решением в том числе потому, что это может быть пробным шагом к построению взаимоотношений с компанией-разработчиком. Так сказать, возможность присмотреться к компании, понять как осуществляется взаимодействие, получается ли выстроить взаимопонимание. Это снижает один из основных рисков при заказе разработки программного обеспечения — шанс наткнуться на недобросовестного разработчика.
Начало пути
Исходя из опыта можем сказать, что около 50% заказов локального программного решения для автоматизации конкретной задачи впоследствии перерастает в разработку более крупной системы, ведь аппетит приходит во время еды. Построение крупной системы выполняется путем итераций, на каждой из которых к системе формируются новые требования, как к корректировке и улучшению уже разработанного функционала, так и к добавлению новых модулей.
Также при уже сформированных требованиях по разработке крупной системы часто разработка может начинаться с отдельного модуля. Таким образом крупная разработка делится на этапы, включающие готовые решения, которые можно внедрять по мере завершения этапа разработки. Этот подход является гибким и современным и позволяет получать пользу от разработки не через условные полгода, а уже через полтора месяца.
Наша рекомендация
Мы сами рекомендуем такой подход, при котором сначала делается небольшая система или модуль, который дальше дополняется новым функционалом. Такой подход позволяет постепенно привести систему к максимальной эффективности и удобству. Но у данного подхода есть и обратная сторона медали — при таком подходе можно объективно оценить только сам этот модуль. Без полноценного проектирования всей системы невозможно определить её стоимость и сроки, а часто это базовое требование заказчика. Поэтому соотношение решений разрабатывать систему постепенно или проектировать и делать всю большую систему целиком, делится примерно 50 на 50.
Итог
Заказывать разработку программного обеспечения, решающего отдельную бизнес задачу является хорошим выбором по следующим причинам:
- Снижение рисков бизнеса за счет небольшого размера проекта, а заказ разработки программного обеспечения несет много рисков.
- Максимальная эффективность и уровень окупаемости программного решения за счет решения проблемы “бутылочного горлышка”.
- Возможность расширять программное решение в будущем до полноценной системы автоматизации большого количества бизнес-процессов.