Технологические проекты

Рассчитайте стоимость и сроки работ прямо сейчас.

Это просто. Мы ответим в течение дня.

Об услуге
Технология работы
Разработка загрузчика
Данные для переноса
Перенос бизнес-процессов
Сроки работ
Преимущества для заказчика

Зачем и кому нужна загрузка исторических данных?

В организациях, которые уже ведут свою деятельность к моменту внедрения "1С:Документооборот", накапливаются какие-то документы. Они хранятся в бумажном виде, либо в виде каких-то файлов на дисках, либо в другой системе электронного документооборота. И когда компания начинает работать в новой системе - в СЭД "1С:Документооборот", эти документы нужно в новую систему перенести – в этом и состоит суть загрузки исторических данных.

Технология работы

Сама технология работы загрузки исторических данных зависит от того, в каком виде и где эти данные находятся у клиента.

Данные находятся в другой системе.

В этом случае необходимо данные выгрузить в промежуточный файл и загрузить в "1С:Документооборот". Либо подключиться к старой системе и забрать данные, если эта система позволяет это сделать.

Данные находятся в файлах на диске.

Нужно сделать загрузчик, который всю эту структуру файлов загрузит в "1С:Документооборот" в ту структуру , которая там уже к моменту внедрения подготовлена.

Документы находятся в бумажном виде.

Нужно документы из бумажного вида перевести в электронный. Для этого мы рекомендуем использовать потоковое сканирование и штрихкодирование. Необходимо создать в "1С:Документооборот" карточки документов, распечатать штрихкоды, наклеить на бумажные документы и потоковым сканированием все отсканировать.

Разработка загрузчика

Основные трудозатраты при загрузке исторических данных – это разработка загрузчика, который эти данные загрузит. Если объем данных большой, имеется большое количество документов, то может потребоваться большое количество времени, чтобы все эти данные загрузить. Если мы загружаем данные автоматически, то, во-первых, на большом объеме выигрываем во времени, потому что загрузка большого объема документов даже с разработкой с нуля загрузчика – это быстрее, чем ручной ввод. Плюс ручной ввод сопровождается ошибками пользователей. А загрузчик, если он заработал, отлажен, оттестирован, уже не ошибается.

Какие данные переносятся в новую систему?

В СЭД может переноситься разный состав данных. Архив документов, который накоплен у клиента, может содержать много видов документов и не все они могут понадобиться. Например, в компании есть архив входящих-исходящих документов и договоров. С договорами в организации часто работают: у них много действующих договоров, которые были созданы в предыдущие годы – они их внесут. А входящие и исходящие они могут не переносить в новую систему - просто начнут новые входящие и исходящие регистрировать в новой системе - "1С:Документооборот".

Перенос бизнес-процессов – насколько оправданно?

Некоторые заказчики хотят, переходя с одной системы электронного документооборота на "1С:Документооборот", перенести не только карточки документов и прикрепленные файлы, но еще и бизнес-процессы. То есть, если в старой системе запущено было согласование, они хотят запустить процесс согласования в новой системе и с того же места его продолжить в новой системе. Обычно это связано с большими трудозатратами на разработку загрузчика. И здесь уже надо смотреть, насколько это целесообразно. Мы рекомендуем все-таки старые процессы завершить в старой системе, а в новой системе уже по новым документам запускать процессы и новые процессы.

Сроки работ

Сроки работ по загрузке исторических данных в "1С:Документооборот" в среднем составляют от двух недель до 1 месяца.

Сроки зависят от того, в каком виде исторические документы; какая структура документов – сколько видов документов. Разный вид документов может иметь разный реквизитный состав. Часто бывает, что под каждый вид документа нужно писать определенный загрузчик, либо алгоритм загрузки разных видов документов различается. Если разношерстные исходные исторические данные, то это более трудозатратно. И на сам процесс загрузки влияет количество документов: к примеру, на непосредственно загрузку 100 тысяч документов уйдет несколько дней.

Преимущества автоматической загрузки исторических данных

Руками не всегда можно осилить загрузку скопившихся объемов документов
При загрузке исторических данных исключается риск возникновения ошибок (человеческий фактор)
Скорость автоматической загрузки в разы превышает скорость ввода документов руками
Экономия рабочего времени сотрудников, которые должны были бы выполнить эту механическую работу

Проекты, в ходе которых осуществлялась загрузка исторических данных: холдинг "Металлоинвест", золотодобывающая компания ПАО "Полюс".

Об услуге
Виды интеграций
Общий подход к интеграции
Список работ
Популярные запросы

Зачем нужна интеграция?

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

Какие мы делаем интеграции

Интеграция "1С:Документооборот" с другими системами "1С"
Интеграция "1С:Документооборот" с системами на других платформах

Общий подход к интеграции

В "1С" платформе в "1С:Документооборот" поддерживается несколько механизмов для интеграции: планы обмена, правила обмена и различный обмен через xml. Обмен через промежуточные файлы (сюда же можно отнести xml файлы) и через веб-сервисы. Еще есть такой механизм – http-запрос к платформе "1С". Это больше подходит для разных внешних систем на других платформах. И есть вызов с помощью COM-технологии – вызов на подключение к другой системе.

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

Если на другой стороне платформа "1С", то, соответственно, эти две платформы поддерживают одинаковые механизмы и тут уже можно либо разрабатывать какой-то интеграционный механизм с нуля, либо использовать готовые механизмы между конфигурациями "1С", которые встраивает в типовые конфигурации фирма "1С" при разработке.

Если мы пишем с нуля, то обычно используются планы обмена или правила обмена через xml-файлы, веб-сервисы. Если говорить о механизмах, которые встроены в типовые конфигурации, есть несколько планов обмена с другими учетными системами – "1С:ERP Управление предприятием 2", "1С:Бухгалтерия 3.0", "1С:Зарплата и управление персоналом 8". Есть веб-сервисы, которые встроены в "1С:Документооборот" – это веб-сервисы для бесшовной интеграции и для работы с файлами и документами из сторонних систем.

Список работ в общем виде

Нужно определиться, какие механизмы поддерживают сторонние системы, выбрать механизмы взаимодействия и договориться о формате взаимодействия. После этого приступить к разработке интеграционных механизмов и на стороне 1С:Документооборот, и на стороне сторонней системы, если их нет. Либо к модификации, если требуется. Либо к настройке, если типовые подходят. Протестировать их и запустить в работу.

Что такое РИБ?

РИБ – это распределенная информационная база. Логически это единая база данных, а физически это несколько баз данных, которые логически объединены в одну. Чаще всего она нужна для холдинговых структур и территориально-распределенных компаний, потому что у них часть людей (часть пользователей) также территориально распределены. Соответственно, у нас есть 2 схемы архитектуры – это либо единая база данных, либо распределенная база данных.

Преимущества РИБа

Распределенная информационная база позволяет сократить трафик внутри локальной сети между клиентом и сервером, поскольку трафик между клиентом и сервером идет к ближайшему серверу приложений и серверу баз данных. И если каналы связи у клиента не везде хорошие, то это один из способов оптимизировать нагрузку на сети канала связи.

Это способ оптимизировать нагрузку на сервер приложений "1С" и базу данных СУБД "1С" за счет перераспределения пользователей между узлами распределенной базы данных.

Распределенная база данных дает возможность создать для каждого юридического лица свой узел, свою базу данных, которая: 1) будет иметь определенную степень изоляции данных от других организаций или юридических лиц, 2) будет иметь возможность, например, отсоединиться. Если, например, юридическое лицо закрывается, то эти данные можно просто отсоединить и забыть о них. Либо наоборот: если, например, новое юридическое лицо добавляется, то можно создать новый узел по образу предыдущих и наполнять его данными. То есть это некая определенная степень свободы этого узла внутри холдинга.

Варианты реализации

В "коробке" есть типовой РИБ, который позволяет создать полный (или так называемый "зеркальный") РИБ. В этом случае все базы данных - узлы в рамках данного РИБа - будут являться полными копиями друг друга и все данные будут мигрировать во все узлы. Это делается быстро и нетрудозатратно – только параметрическими настройками.

Если же нужны какие-то другие модели миграции данных внутри вот этой распределенной сети, то это нужно программировать и на это нужен уже отдельный проект. Тогда можно организовать так называемый РИБ по организации – когда каждое юридическое лицо имеет свой узел и все документы мигрируют в соответствии с принадлежностью к юридическому лицу.

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

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

Проекты

В холдинге "Металлоинвест" задачи и документы мигрируют вслед за местонахождением пользователей.

В золотодобывающей компании ПАО "Полюс" реализована сложная схема. Документы мигрируют в местонахождение пользователя. Мигрируют вместе со всеми связями и с другими документами. Сложнонастраиваемые правила.

В группе компаний "Эйнком" система построена на базе решения "1С:Документооборот КОРП" и состоит из двух информационных баз: в Москве и Сургуте. Между ними настроен полный обмен данными через ftp-сервер.

Об услуге
Этапы работ
Итоги
Для кого
Сроки

Нагрузочное тестирование - это

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

Этапы нагрузочного тестирования

1. Анализ деятельности предприятия с целью выявления, какое количество и каких данных необходимо будет создать в ходе нагрузочного тестирования.

Например:

У заказчика есть сервер и он планирует (условно), что на нем будет работать 100 пользователей одновременно, и что они будут выполнять определенные действия: создавать документы каждые пять минут, запускать 2 процесса каждую минуту и выполнять задачи каждые 10 минут. Нагрузочное тестирование позволит промоделировать то, что запланировано, и посмотреть, как будет вести себя система: будет ли она справляться и какое будет время отклика системы.

2. Наполнение данными.

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

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

Наполнение данными – сложный этап: нужно заполнить много данных, на что уходит много времени.

Например:

Когда мы делали нагрузочное тестирование для одного из действующих наших клиентов, автоматической обработкой было создано несколько миллионов документов. На создание каждого объекта тратится примерно 1 секунда, но, когда речь идет о миллионах, то счет идет на недели. Как решалась эта задача: параллельно запускались обработки, т.е. параллельно происходило создание данных в одной и той же базе, но в несколько сеансов И второй момент, что было сложно – это пересчет прав. Мы сделали специальные обработки, которые выполняли пересчет в параллельном режиме. Мы запускали 24 сеанса, соответственно, в 24 раза быстрее рассчитали права, чем если бы они рассчитывались типовым образом.

3. Написание тестового сценария.

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

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

На одном из наших проектов мы на 1 пользовательской машине запускали 10 клиентов.

4. Дополнение стандартных ключевых операций – при необходимости.

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

5. Разворачивание инфраструктуры.

6. Запуск тестирования.

Один рабочий день – этого более чем достаточно для проведения тестирования. Даже за час вполне понятно, что будет происходить.

7. Замер производительности.

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

8. Анализ, внесение изменений, повторное тестирование.

Необходимо изучить результаты, т.е. данные по ключевым операциям. Есть система APDEX, которая усредняет значения: она отбрасывает самые экстримальные значения, берет только более реальные. Еще в системе APDEX устанавливает целевое время, т.е. время, которое заказчик считает приемлемым на каждую операцию. И потом в конце мы смотрим, насколько мы уложились вот в эти числа – в эти желаемые длительности ключевых операций. Метод APDEX показывает, насколько близки мы к нужным нам значениям.

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

Итоги

Нагрузочное тестирование признано успешным в том случае, когда достигнуты целевые показатели, которые всех устраивают.

Кому нужно?

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

Заказчик иногда сам настаивает, чтобы было произведено нагрузочное тестирование. Он понимает, что без предварительного нагрузочного тестирования нельзя быть ни в чем уверенным. Либо мы рекомендуем заказчику это сделать, если проект серьезный, большой и много пользователей одновременных, то требования производительности у заказчиков есть завышенные (чтобы все работало хорошо и быстро), то ему говорят, как мы можем это обеспечить: давайте нагрузочное тестирование проводить. Может даже сам клиент это сделать при большом желании.

Сроки нагрузочного тестирования

Сроки зависят от каждого конкретного проекта: сколько пользователей одновременных, какой объем данных нужно будет наполнить в базе, сколько ролей различных предусматривается в этой системе, соответственно, сколько сценариев нам писать. Какие именно сценарии, какая у них будет сложность: если обычно человек заходит, документ создает, записывает – то это одно дело; если он там какие-то вещи делает: процессы стартует, что-то еще делает – то уже сложнее. Кол-во пользователей – от этого тоже зависит трудоемкость. Сколько надо будет задействовать клиентских машин. Сколько придется на них ботов запускать.