В данной статье рассмотрен кейс создания кастомного веб-ресурса с использованием Product Catalog, который был реализован на одном из проектов. Основное внимание будет уделено анализу бизнес-анализа (BA), архитектурным решениям и техническим особенностям, использованным для создания кастомного решения. Это пример того, как можно эффективно адаптировать CRM-систему под уникальные требования клиента, обходя ограничения стандартных инструментов.
А узнать больше про это решение можно в нашем видео:
Реквест клиента
Клиент запросил систему Product Catalog, где можно было бы выбирать продукты с различными характеристиками (Product Properties), которые бы влияли на цену и формирование предложения. Аналогом, который использовал клиент, была система Proposal App — небольшая CRM, где можно добавлять продукты, разделенные по категориям, и у каждого продукта есть свои свойства. Важной частью запроса была возможность калькулировать цену продукта на основе выбранных характеристик и их комбинаций, что требовало гибкого и удобного интерфейса.
Почему кастомное решение?
Хотя стандартный функционал Product Catalog уже существовал в системе, он не подходил из-за ряда причин. Во-первых, стандартный интерфейс и возможности системы не удовлетворяли требованиям клиента, особенно в части работы с большим количеством свойств продуктов. Стандартный функционал был слишком громоздким и требовал значительных усилий для настройки. К тому же клиент хотел иметь возможность вносить изменения в продукты и их свойства по мере изменения своих потребностей.
Клиент также был готов выделить дополнительные ресурсы на разработку, что позволило выбрать кастомный подход вместо попыток адаптировать стандартные инструменты CRM-системы. Основная цель заключалась в создании гибкого и удобного интерфейса, который бы отвечал всем текущим и будущим запросам клиента.
WBS
Разработка кастомного решения была разделена на несколько этапов, начиная с анализа требований и проектирования архитектуры решения. На этапе анализа был создан WBS (Work Breakdown Structure), который включал в себя несколько ключевых шагов:
Анализ требований и создание ERD (схемы сущностей и связей).
Создание кастомных сущностей и настройка существующих.
Разработка интерфейсов, включая формы и представления.
Настройка бизнес-логики для расчетов и автоматизации.
Создание функционала для генерации PDF-документов.
Все этапы были согласованы с клиентом, включая диаграмму ERD, которая была утверждена перед началом разработки.
ERD
ERD (Entity Relationship Diagram) была создана для отражения основных сущностей системы и их взаимосвязей. Основные сущности, использованные в системе, включали в себя:
Квоты – предложения, которые создаются для клиентов.
Квот-продукты – продукты, привязанные к конкретной квоте.
Продукты – список товаров и услуг.
Product Properties – свойства продуктов, которые влияют на цену.
Некоторые сущности, такие как Product Properties, были кастомизированы для поддержки уникальных требований клиента. Важной особенностью схемы было наличие лукапов (ссылок) между продуктами и их свойствами, что позволяло каждому продукту иметь неограниченное количество характеристик, влияющих на итоговую цену.
Web-ресурс
На основе разработанной ERD была создана веб-аппликация, где пользователи могли выбирать продукты, устанавливать для них нужные свойства, и все это отражалось в квоте. Интерфейс был создан так, чтобы быть максимально удобным для пользователя: продукты разделены по категориям, а каждый продукт имел динамические поля для ввода значений свойств. Ключевой особенностью стала валидация данных, которая не позволяла пользователю оставлять некорректные или неполные данные, что было критически важно для корректного расчета итоговой стоимости.
Дополнительные фишки
Одной из интересных технических особенностей было решение проблемы экспорта данных в PDF. Стандартное решение CRM-системы не позволяло извлекать и сортировать данные из нескольких связанных сущностей, что стало ограничением.
Вместо использования стандартного функционала, было решено формировать HTML-страницу с полным набором данных и затем вызывать команду печати, что позволяло сохранить документ в PDF. Хотя это решение не позволило автоматизировать сохранение в SharePoint или отправку по email, оно обеспечивало необходимую гибкость в отображении данных.
Дополнительно, была реализована возможность работы с ревизиями квот: при внесении изменений в активную квоту создается новая версия, сохраняя все предыдущие данные.
Заключение
Создание кастомного решения для работы с Product Catalog позволило адаптировать систему под уникальные требования клиента, обойдя ограничения стандартных инструментов. Важными элементами решения стали разработка гибкой архитектуры, создание кастомных сущностей и интерфейсов, а также использование нестандартных технических решений для вывода данных. Это решение продемонстрировало важность детального анализа требований и возможности кастомизации CRM-систем под задачи клиента.
Comments