учета с бухгалтерской системой («1С: Бухгалтерия»), нам, как правило, нужно время от времени передавать в бухгалтерскую базу информацию о совершенных хозяйственных операциях – и только. Оперативность передачи данных из одной системы в другую не играет особой роли, в фискальном учете время измеряется кварталами, и любой документ может задержаться на несколько дней и даже недель.
Совсем другое дело, когда от элементов интегрированной информационной системы требуется постоянное и оперативное взаимодействие. Простой пример: интеграция системы управления торгово- закупочной деятельностью («1С: Управление торговлей») с конфигурациями, в которых реализованы функции складской логистики, управления взаимоотношениями с клиентами, управления цепочками поставок и т. д. В этом случае от всех функциональных блоков требуется полная синхронность действий; информация, внесенная или модифицированная в одной подсистеме, должна сразу же становиться доступной во всех остальных, а иногда и порождать в других подсистемах соответствующие события. Единственное решение такой задачи – объединение всех необходимых конфигураций (обычно – двух, но бывает, что и большего количества) в единую и неделимую информационную базу.
Сам процесс объединения конфигураций и его многочисленные технологические нюансы (правильное сопоставление объектов, настройка правил поддержки, выявление и разрешение конфликтов между объектами разных конфигураций и т. д.) – тема для отдельного методического пособия. В рамках статьи мы рассмотрим возможные сценарии действий поставщиков прикладных решений с точки зрения конечного пользователя, т. е. – дальнейшей поддержки интегрированной информационной базы. Основных сценариев два: «вертикальная поддержка» и «горизонтальная поддержка».
В самом простом варианте этот сценарий предполагает наличие «базовой» тиражной конфигурации от поставщика «А» и существование поставщика «Б», который вносит в базовую конфигурацию «А» какие-либо доработки. Сценарий действий поставщиков и пользователя строится следующим образом:
• Поставщик «А» формирует и выпускает поставку тиражной конфигурации «А».
• Поставщик «Б» создает на базе конфигурации «А» новую конфигурацию, ставит ее на поддержку в режиме «поддержка с возможностью изменения» и вносит необходимые доработки. Причем доработкой может стать и объединение конфигурации «А» с собственной тиражной конфигурацией поставщика «Б». В результате получается конфигурация «Б».
• Поставщик «Б» формирует поставку конфигурации «Б» и передает конечному пользователю.
• Конечный пользователь разворачивает на основе конфигурации «Б» информационную базу и ставит конфигурацию на поддержку.
• Поставщик «А» формирует и выпускает обновление конфигурации «А».
• Поставщик «Б» получает обновление от поставщика «А», обновляет свою конфигурацию, формирует обновление конфигурации «Б» и передает конечному пользователю.
• Конечный пользователь обновляет свою информационную базу в режиме «Полная поддержка».
Сценарий «вертикальной поддержки» применяется, как правило, в двух случаях:
• При разработке тиражных отраслевых конфигураций, построенных на базе типовых конфигураций «1С». В роли поставщика «А» выступает фирма «1С», а поставщика «Б» – партнер-разработчик.
• При доработке тиражной конфигурации под нужды конкретного предприятия в рамках проекта внедрения. В роли поставщика «А» выступает разработчик тиражного решения (фирма «1С» или партнер- разработчик), а поставщика «Б» – партнер-внедренец и (или) внутренний отдел ИТ предприятия- пользователя.
Преимущество сценария «вертикальной поддержки» для конечного пользователя заключается в технологической простоте: все сложные операции объединения конфигураций выполняют поставщики типа «Б» (их, как мы увидим, может быть несколько), конфигурация информационной базы стоит на полной поддержке и обновляется полностью в автоматическом режиме.
Но у сценария есть и недостаток, который является прямым следствием из преимущества. Представим такую ситуацию: партнер-разработчик («Б-1») создал свое тиражное решение на базе типовой конфигурации «1С», партнер-внедренец («Б-2») на базе этого же решения разработал конфигурацию для конечного пользователя. Далее фирма «1С» выпускает обновление своей типовой конфигурации. Тогда передача обновлений происходит по «вертикали», т. е. последовательно. Партнер «Б-1» должен обновить свою конфигурацию и выпустить свое обновление. Партнер «Б-2» должен дождаться этого обновления и проделать аналогичную операцию со своей конфигурацией, и только потом обновление дойдет до конечного пользователя. И чем значительнее изменения, внесенные в исходные конфигурации обоими поставщиками (заметим, что поставщиков в такой схеме может быть и больше двух), тем больше времени займет передача обновлений по всей цепочке. Фактор времени может оказаться важным и даже критичным для конечного пользователя, например, когда обновление исходной типовой конфигурации содержит поддержку изменений в законодательстве и (или) исправление серьезных ошибок.
Этот сценарий базируется на технической возможности платформы «1С: Предприятие 8»: механизм поддержки конфигураций позволяет в рамках одной информационной базы иметь несколько конфигураций разных поставщиков и обновлять их независимо друг от друга.
Сценарий действий поставщиков и пользователя строится следующим образом:
• Поставщик «А» формирует и выпускает поставку тиражной конфигурации «А».
• Поставщик «Б» создает на базе конфигурации «А» новую конфигурацию, ставит ее на поддержку в режиме «поддержка с возможностью изменения» и вносит необходимые доработки. Важный нюанс: в сценарии «горизонтальной поддержки» доработкой также может стать объединение конфигурации «А» с любой другой тиражной конфигурацией. Предположим, с конфигурацией «В» поставщика «В». Но в этом сценарии конфигурация «В» будет использована в «чистом» виде и в последующих шагах. В результате внесения доработок получается конфигурация «Б».
• На стороне конечного пользователя (либо его собственными силами, либо с помощью специалистов поставщика «Б») разворачивается информационная база на основе конфигурации «А». Далее, в этой информационной базе включается режим «поддержка с возможностью изменения» и производится последовательное объединение с конфигурациями «В» (если она использовалась на предыдущем шаге) и «Б». В процессе объединения каждая из конфигураций ставится на поддержку своего поставщика.
• Любой из поставщиков («А», «Б» или «В») в любое время может сформировать и выпустить обновление своей конфигурации. Конечный пользователь получает обновление от любого из поставщиков и тут же устанавливает его на свою информационную базу.
Что касается технологии, сценарий «горизонтальной» поддержки намного сложнее сценария «вертикальной поддержки». Любое обновление требует выполнения на стороне конечного пользователя операции сравнения-объединения конфигураций, которая не столь обычна и требует привлечения специалиста определенной квалификации. Но зато ценой технологического усложнения достигается оперативный режим внесения изменений в информационную базу – не нужно никого ждать, можно устанавливать обновления любого из поставщиков сразу, как только они получены.
Какой сценарий поддержки предпочтительнее? Определенного ответа на этот вопрос нет и быть не может. Рекомендации можно дать только в конкретных случаях: очень многое зависит от того, какие именно используются тиражные конфигурации, насколько часто выходят обновления, какие именно доработки планируется в них вносить, специалисты какой квалификации имеются в распоряжении и т. д.
