Intranet и CMS для НПК «Контакт», Новосибирск

Старейшая компьютерная компания Западно-Сибирского региона, основана в 1988 году, системный интегратор. Офисы НПК «Контакт» расположены в Новосибирске, новосибирском Академгородке и в Барнауле.
Релиз: 2003

На сайте заказчика не было каталога товаров. Раз в неделю (иногда чаще, если цены штормило) на сайт выкладывался прайс-лист в формате Excel. То есть основной задачей проекта было появление на сайте динамичного каталога, а все остальное — либо сопутствующие задачи, либо эволюционные.

Постановка задач в общем виде:

  • Транслировать на сайт каталог товаров из внутренней учетной системы (не 1С).
  • Обеспечить регулярное, раз в период, автоматическое обновление каталога.
  • Разработать систему управления (CMS).
  • Разработать внутренний корпоративный портал (Intranet) в соответствии с функциональными требованиями.
  • Обновить интерфейс и структуру действующего сайта.
  • Разработать проектную документацию.
Boromir
«Нельзя просто так взять и показать каталог на сайте», говорил Боромир.
И быстро выяснилось, что он таки прав: отображать каталог один-в-один — плохая идея.

И не потому, что с ним что-то не так. Просто у этих продуктов (учетной системы и сайта) разные пользователи, с разным опытом и разными задачами.
Нужно искать общий знаменатель.

Структура каталога может и удобна для менеджеров, но непригодна для показа конечному пользователю. Во-первых, она слишком подробна и ветвиста, а во-вторых, основана на других принципах. Например: Периферийные устройства > Мониторы > Sony > ЭЛТ > 17" (и вот тут уже будут конкретные модели). Но увидеть на одной странице все семнашки ЭЛТ любых производителей пользователь не сможет.
Значит необходим инструментарий для переопределения структуры.

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

Понятно, что такие позиции сложно идентифицировать и невозможно сравнивать.
А значит нужен интерфейс для переименования товаров.

Дополнительные поля товаров отсутствуют в принципе. Как поля характеристик, так и информационные (например, бренд, изображение, ссылка на сайт произоводителя, описание и так далее). То есть товары невозможно фильтровать. А карточка товара не имеет смысла.
Значит нужны интерфейсы для определения полей характеристик и для их заполнения.

(Из любознательности заглянули в Битрикс, как, мол, другие решают такие задачи. Тупо и тотально решают: предлагается создать все возможные поля характеристик, а заполнять только те из них, которые имеют значение для конкретной товарной позиции. Хм.)

Концептуально разработанная система выглядит следующим образом. Есть 3 сайта (интранет, тестовый сайт и боевой) и две базы данных (рабочая и боевая). Тестовый сайт отображает данные из рабочей БД, клиентский — из боевой.

Особняком стоит адаптер. Его разработка была вынесена в отдельный проект. Основная задача адаптера — все со всем синхронизировать. Обновления происходят по заданному расписанию, а также в ручном режиме — по командам операторов интранета. Адаптер получает данные из учетной системы (через API) и обновляет рабочую БД, а потом, со сдвижкой в 30 минут, обновлят БД клиентского сайта. При этом адаптер проверяет данные, сигнализирует о коллизиях, если таковые возникают, и пишет логи обновлений. Логи, кстати, используются не только для просмотра и разбора полетов, но и для построения отчетов для клиентского сайта: снято с продаж, новые позиции, изменения цен.

Структурная схема разработанной ИС

Схема информационной системы

Основные функциональные модули Intranet'a

  • Управление Адаптером (просмотр отчетов, запуск в ручном режиме, генерация прайс-листов в xls-формате).
  • Интерфейсы для переопределения структуры каталога.
  • Интерфейсы для определения полей характеристик.
  • CMS (заполнение полей характеристик, а также управление прочими разделами сайта: новости, вакансии, статьи и так далее).
  • Корпоративные сервисы.

Проект, напомним, 2003 года, но скриншот сделан несколько позже, более ранних не нашлось:

Адаптер

Ниже более подробно о функциональных возможностях разработанной системы.

Управление адаптером и CMS

Здесь важно отметить такой момент. Тестовый сайт, как было сказано выше, отображает данные из рабочей БД. С ней же работает Intranet. При этом данные каталога товаров обновляются в автоматическом режиме (с возможностью запуска по запросу), а прочие данные — только в ручном. Это позволяет операторам CMS готовить новые материалы столько, сколько нужно, отслеживать результаты на тестовом сайте, а потом, по готовности, одной кнопкой обновить клиентский сайт. Причем, к данным этого типа относятся не только статьи, новости и прочее, но и настроечные параметры каталога товаров: структура, заполненные характеристики товаров и сами поля характеристик.

Иными словами, ассортимент обновляется в фоне, а все, что требует внимания оператора, обновляется по мере готовности.

Переопределение структуры каталога

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

Кстати, можно было не только переопределить родительскую группу, но и создать новую, отсутствующую в исходном каталоге. Чем операторы активно пользовались.

Определение полей характеристик

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

Например, для самого верхнего уровня каталога были заданы два поля: бренд и ссылка на сайт производителя. А чем ниже мы спускаемся по каталогу, тем более специфичные поля задаются для каждой группы. В результате мы получаем, например, такую картину: у принтера и монитора есть какой-то общий набор характеристик и есть набор специфичных характеритик, заданных только для этой категории и ее наследников. Пример: у всех товаров группы «Мониторы» (и только у них) есть поле «Диагональ экрана», а у товаров подгруппы «Мониторы TFT» есть дополнительно поле «Тип матрицы», которое, в свою очередь, наследуется дочерними подгруппами.

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

Корпоративные сервисы

На интранете был также реализован набор сервисов для внутреннего пользования сотрудниками компании.

  • Разграничение прав доступа в двух аспектах: группы пользователей и структурные подразделения.
  • Файловый архив с возможностью динамичного, через интерфейс, создания директорий, описаний, загрузкой файлов и указанием прав доступа. Сервис использовался отделами для хранения внутренней документации.
  • Адресная книга
  • Рассылка почтовых сообщений с визуальным выбором адресатов (по структурным подразделениям и группам пользователей).
  • Структурированное хранение корпоративных документов: правила, регламенты, инструкции.

Можно утверждать, что по совокупности возможностей на тот момент (2003 год) ничего подобного на рынке не было. По крайней мере, среди коробочных продуктов, включая MS SharePoint. Любой специальный инструмент лучше универсального. Уже тем, что дешевле и заточен только под востребованные функции.

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

Другие работы в разделе Портфолио