Последствия и цена ошибочного выбора программного продукта на примере блока казначейства
Статья подготовлена партнером проекта Digital4food, компанией «Константа».
Выбор программного продукта для развития любой компании является важным шагом в автоматизации процессов. Однако, неверное решение может привести к серьезным последствиям и проблемам при внедрении. И дело здесь не в том, что продукт «плохой», а в том, что в своем базовом функционале он не рассчитан на закрытие поставленных задач в нужном объеме. Именно поэтому мы ведем речь не о качестве тех или иных продуктов, а о форматах их целевого применения.
Неправильно выбранный программный продукт может:
- не обладать необходимыми функциональными возможностями, что может привести к неэффективному управлению компанией;
- вызвать сложности в интеграции с существующими системами и базами данных, а также потребует привлечения дополнительных продуктов;
- быть слишком сложным и трудоемким в использовании из-за высокого уровня кастомизации. Кроме того, неправильно выбранный продукт может не позволять реализовать все специфические требования и бизнес-процессы, что также может привести к проблемам в работе;
- быть слишком дорогим и неэффективным с точки зрения затрат. Если система требует больших финансовых вложений на приобретение, настройку и обслуживание, не соответствуя при этом потребностям, это может означать лишние расходы и неприемлемые затраты. Кроме того, неправильно выбранный продукт может требовать частых обновлений и модернизаций, что также будет затратным.
В данной статье разберем конкретный кейс автоматизации блока казначейства на пищевом предприятии. Проанализируем ситуацию, когда программное решение не соответствовало ожиданиям заказчика, требуя значительных изменений и изучим последствия такого развития событий.
Казначейство играет важную роль в управлении финансовыми ресурсами и обеспечении эффективного расходования средств. Правильное функционирование этого блока имеет прямое влияние на финансовую устойчивость и успех организации в целом.
Как выбирали программный продукт?
Когда клиент обратился к нам, у него уже была внедрена 1С ERP для автоматизации управленческого учета. Успешно внедрив управленческий учет, у клиента возникла потребность автоматизации блока Казначейства. В ходе анализа было выявлено, что функционал системы не соответствует потребностям клиента, и для приведения блока Казначейства в соответствие с требованиями необходимо провести значительные доработки. Замена текущей системы на более подходящую программу (забегая вперед: это была 1С ERP УХ) не рассматривалась клиентом.
Функционал, который требовался клиенту
| № |
Функционал |
1С ERP | 1С ERP УХ |
| 1 |
Формирование заявок на оплату |
+ | + |
| 2 | Финансовый контроль расходов/ Установка лимитов с последующим распределением лимитов между статьями | Настройка лимита по подразделению, ЦФО в пределах месяца (если использовать простое лимитирование) |
Настраиваются более гибко, есть инструменты для изменения лимита внутри периода. Есть специальные документы, с помощью которых изменяется лимит, например между статьями, ЦФО, периодами. |
| 3 | Согласование заявок на расход ДС |
В заявках нет разбивки по управленческим аналитикам, т.е. возможно только поставить решение «Согласовано» в целом по документу, без каких-либо маршрутов. Полноценно работает в сочетании с «1С: Документооборот 8» (имеется бесшовная интеграция) |
Согласование заявок на платеж с маршрутом согласования встроен в сам 1С ERP УХ |
| 4 | Платежный календарь | + |
+ Расширенный функционал, дружелюбный интерфейс |
| 5 | Формирование заявок на поступление | Информационный документ для закрытия кассового разрыва |
Документ с хозяйственными операциями, контрагентом. Более глубокое планирование прихода ДС |
| 6 |
Управляемый реестр платежей (удаление/добавление заявок, согласование) |
Отчет | Документ, которым можно управлять и согласовывать в рамках ERP УХ по маршруту |
| 7 |
Интеграция с клиент-банком |
+ | + |
| 8 |
Кредитный портфель с привлечением оборотного капитала, с учетом фиксированной и плавающей ставки |
Функционал рассчитан только на фиксированные кредиты с фиксированными процентами ставками | + |
| 9 |
Инвестиционный портфель |
— | + |
Как видно из таблицы, более верным решением в такой ситуации было бы выбрать продукт 1С ERP УХ, а не 1С ERP. Чтобы достичь целей проекта, были проделаны следующие работы и доработки:
- Перераспределение бюджетных лимитов между различными статьями расходов, при этом сохраняя общую сумму бюджета, установленную на месяц.
- Бесшовная интеграция с 1С Документооборотом
- Изменение документа «Ожидаемое поступление ДС» — внесение хозяйственных операций, контрагентов, объектов расчета
- Создание управляемого реестра платежей с согласованием его через 1С Документооборот
- Создание функционала по кредитам: изменение договоров по кредитам и займам для учета кредитных линий и плавающих ставок, добавление функционала по групповым кредитам, учет лимитов кредитных линий, создание отчетов кредитного портфеля и отчета по кредитам с отображением общего долга, траншей и сроков погашения.
- Изменение вида Платежного календаря с учетом кредитных линий, вывода информации в разрезе Организаций.
- Была также проделана работа по облегчению труда пользователей Казначейства: создание групповой обработки заполнения Списаний на расход ДС (выписка из банка) одной заявкой, отключение группового создания платежных документов из реестра платежа, безакцептное списание и т.д.
Фактически, большинство доработок было выполнено с целью приближения функционала блока Казначейства 1С ERP к функционалу системы 1С ERP УХ.
Какие последствия несло решение о выборе 1С ERP вместо 1С ERP УХ на примере блока Казначейства:
- Затраты временных ресурсов – разработка функционала, отвечающего потребностям клиента, заняла значительное количество времени, кроме того, потребовалось провести тестирование и отладку.
- Запуск Казначейства произошел позже, чем мог бы состоятся — затраченное время на разработку могло быть использовано для обучения сотрудников типовому функционалу в системе 1С ERP УХ и запуска подсистемы Казначейства
- Финансовые затраты на доработки (существенно больше, чем потребовалось бы на внедрение 1С ERP УХ)
- Понесены дополнительные расходы на приобретение продукта 1С Документооборот
- Решение с доработками было завершено, закрыв существующий функционал клиента. Однако нельзя гарантировать, что это будет достаточно для него в будущем. Возможно, ему придется снова обратиться к разработчикам или изменить конфигурацию 1С, чтобы лучше соответствовать его требованиям. В этом случае клиент будет нести дополнительные затраты.
Поскольку продукт ERP полностью удовлетворял потребности клиента в основном функционале, дополнительные затраты были оправданы. Однако, если бы потребовалось настраивать другие модули учета, неправильный выбор программного обеспечения мог бы привести к серьезным финансовым и временным издержкам.
Подведем итог
Зачастую выбор программного продукта диктует необходимость его доработки, чтобы он полностью соответствовал требованиям заказчика. Иногда требуется лишь незначительное корректирование типового функционала. Однако если масштаб доработок существенный, прежде чем брать их в работу, стоит задать себе вопрос: а стоит ли оно того? Или более целесообразно выбрать другой программный продукт, более подходящий под задачу в своем базовом функционале?
Поэтому важно проводить достаточное исследование рынка программных продуктов, анализировать требования и потребности клиента и внимательно подбирать подходящий продукт 1С для достижения эффективной работы компании.
