Последствия и цена ошибочного выбора программного продукта на примере блока казначейства

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

Неправильно выбранный программный продукт может:

1. не обладать необходимыми функциональными возможностями, что может привести к неэффективному управлению компанией;
2. вызвать сложности в интеграции с существующими системами и базами данных, а также потребует привлечения дополнительных продуктов;
3. быть слишком сложным и трудоемким в использовании из-за высокого уровня кастомизации. Кроме того, неправильно выбранный продукт может не позволять реализовать все специфические требования и бизнес-процессы, что также может привести к проблемам в работе;
4. быть слишком дорогим и неэффективным с точки зрения затрат. Если система требует больших финансовых вложений на приобретение, настройку и обслуживание, не соответствуя при этом потребностям, это может означать лишние расходы и неприемлемые затраты. Кроме того, неправильно выбранный продукт может требовать частых обновлений и модернизаций, что также будет затратным.

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

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

Как видно из таблицы, более верным решением в такой ситуации было бы выбрать продукт 1С ERP УХ, а не 1С ERP. Чтобы достичь целей проекта, были проделаны следующие работы и доработки:

1. Перераспределение бюджетных лимитов между различными статьями расходов, при этом сохраняя общую сумму бюджета, установленную на месяц.
2. Бесшовная интеграция с 1С Документооборотом
3. Изменение документа «Ожидаемое поступление ДС» - внесение хозяйственных операций, контрагентов, объектов расчета
4. Создание управляемого реестра платежей с согласованием его через 1С Документооборот
5. Создание функционала по кредитам: изменение договоров по кредитам и займам для учета кредитных линий и плавающих ставок, добавление функционала по групповым кредитам, учет лимитов кредитных линий, создание отчетов кредитного портфеля и отчета по кредитам с отображением общего долга, траншей и сроков погашения.
6. Изменение вида Платежного календаря с учетом кредитных линий, вывода информации в разрезе Организаций.
7. Была также проделана работа по облегчению труда пользователей Казначейства: создание групповой обработки заполнения Списаний на расход ДС (выписка из банка) одной заявкой, отключение группового создания платежных документов из реестра платежа, безакцептное списание и т.д.

Фактически, большинство доработок было выполнено с целью приближения функционала блока Казначейства 1С ERP к функционалу системы 1С ERP УХ.

• Затраты временных ресурсов – разработка функционала, отвечающего потребностям клиента, заняла значительное количество времени, кроме того, потребовалось провести тестирование и отладку.
• Запуск Казначейства произошел позже, чем мог бы состоятся - затраченное время на разработку могло быть использовано для обучения сотрудников типовому функционалу в системе 1С ERP УХ и запуска подсистемы Казначейства
• Финансовые затраты на доработки (существенно больше, чем потребовалось бы на внедрение 1С ERP УХ)
• Понесены дополнительные расходы на приобретение продукта 1С Документооборот
• Решение с доработками было завершено, закрыв существующий функционал клиента. Однако нельзя гарантировать, что это будет достаточно для него в будущем. Возможно, ему придется снова обратиться к разработчикам или изменить конфигурацию 1С, чтобы лучше соответствовать его требованиям. В этом случае клиент будет нести дополнительные затраты.

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

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

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

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