Содержание к диссертации
Введение
1. Введение 4
1.1. Постановка задачи 4
1.2. Содержание диссертации 5
1.3. Актуальность и новизна 6
1.4. Методы исследования 7
2. Теоретическая работа 9
2.1. Обзор 9
2.2. Классификация взаимосвязей между схемами баз данных
2.2.1. Примеры взаимосвязей 12
2.2.2. Классификация взаимосвязей между доменами 15
2.2.3. Классификация взаимосвязей схем данных 22
2.3. Способы сопоставления записей 29
2.3.1. Алгоритм Смита-Ватермана Psw 34
2.3.2. Оптимизированный алгоритм Pswo 36
2.3.3. Обобщенный алгоритм Pswg 38
2.4. Способы устранения дубликатов 39
2.4.1. Полное устранение дублирования 39
2.4.2. Устранение дубликатов с сохранением истории 40
2.4.3. Пометка дубликатов в БД 41
2.4.4. Хранение информации о дублировании в НСИ 43
2.5. Организационные вопросы 44
2.5.1. Разрешение организационных конфликтов 44
3. Экспериментальная работа 46
3.1. Пример 1: Задача учета ЮЛ и ФЛ.. 46
3.1.1. Описание предметной области и проекта 46
3.1.2. Интеграция банковской и контрольной систем 47
3.1.3. Интеграция регистрирующей и контрольной систем з
3.1.4. Устранение дублирования 84
3.2. Пример 2: Задача централизованных закупок 106
3.2.1. Описание предметной области и проекта 106
3.2.2. Анализ процесса планирования закупок 110
3.2.3. Формирование справочника-прейскуранта 114
3.2.4. Бизнес-процесс формирования плана закупок 119
3.2.5. Задача расчета цен 125
4. Заключение 131
4.1. Планируемое продолжение работы 132
5. Литература
Введение к работе
Актуальность проблемы
Во многих как государственных, так и коммерческих организациях сегодня накоплены большие массивы информации, организованные в виде самых разнообразных структур и программных средств. С расширением интеллектуальных возможностей компьютеров и компьютерных систем все более актуальными становятся задачи, как в науке, так и в бизнесе, которые требуют для своего решения совместного использования и консолидации распределенной по разным системам информации. При этом типичной является ситуация, когда отдельные системы работают на разных программных платформах и используют разные локальные справочники, никак не связанные между собой, что значительно усложняет информационный обмен между компьютерными системами.
Стандартным и весьма популярным в последние годы подходом к решению данной проблемы является внедрение единой интеграционной шины, позволяющей унифицировать форматы сообщений, способы настройки интеграционных интерфейсов и конверторов данных, осуществлять централизованный мониторинг интеграционных процессов. Данный подход эффективно решает многие «технические» задачи: гарантирует доставку сообщений и правильную конвертацию форматов данных, корректно обрабатывает временную недоступность некоторых систем, отслеживает изменение адресов, решает задачу совместного доступа к информационным ресурсам и т.д.
Однако этот подход мало помогает в решении более высокоуровневых задач. Например, он не может гарантировать, что любой состав данных, сформированный в одной системе и переданный в другую через интеграционную шину, будет сохранен во второй системе без ошибок. Не
может он также гарантировать отсутствие дубликатов информационных объектов в разных системах и корректное связывание данных в них.
Одним из подходов, позволяющих решить высокоуровневые задачи информационного обмена, является создание централизованной системы ведения справочников, стандартизирующей и унифицирующей справочную информацию. Обобщенно класс таких систем называют Master Data Management (MDM-системы) или более распространенным в России термином - системы Нормативно Справочной Информации (НСИ). Основной проблемой при использовании данного подхода является то, что создание централизованной надстройки над всеми системами должно, с одной стороны, производиться на основе единых архитектурных решений, а с другой стороны, требует учета особенностей предметных областей всех интегрируемых систем. В настоящее время данную проблему нельзя считать решенной. Требуются предметно-независимые методы и алгоритмы позволяющие формализовать процесс интеграции баз данных и знаний, стандартизировать процессы проектирования и анализа взаимосвязей в схемах данных, а также оценивать качество интеграционных программных систем.
Цель работы
Целью данной работы является построение предметно-независимой классификации взаимосвязей между структурами данных, позволяющей однозначно определять возможности интеграции заданных структур и устанавливать необходимые и достаточные условия решения типовых интеграционных задач, а также разработка «интеллектуальных» методов и алгоритмов интеграции данных.
Для достижения поставленной цели в работе предполагалось решить следующие задачи, определившие логику диссертационного исследования и его структуру:
Построить классификацию взаимосвязей между доменами отдельных атрибутов в различных схемах данных.
Построить классификацию взаимосвязей между переменными-отношениями в различных схемах данных.
Построить алгоритм сопоставления текстовых строк учитывающий «веса» замены одного символа на другой, а также возможность перестановки слов в строке.
Разработать методы и алгоритмы классификации интеграционных взаимосвязей структур данных и применить их в программной реализации интеграционных интерфейсов в различных проектах. Объектом исследования являются совокупности баз данных и знаний,
распределенные по разным системам.
Предметом исследования являются модели, методы и алгоритмы интеграции данных, хранящихся в различных базах данных и знаний.
Диссертационная работа выполнена в рамках паспорта научных специальностей ВАК 05.13.11 «Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей», п. 3. -Организация баз данных и знаний, построение систем управления базами данных и знаний.
Методы исследования. Теоретико-методологической основой диссертации явились труды ведущих отечественных и зарубежных исследователей, работающих в области интеграции данных и извлечения знаний.
Для решения поставленных задач использован математический аппарат теории реляционных баз данных.
Инструментальными средствами разработки программных модулей явились современные объектно-ориентированные средства быстрой разработки программ.
Основные положения диссертации, выносимые на защиту:
Построение классификации взаимосвязей между доменами отдельных атрибутов в различных схемах данных. Рассмотрены следующие классы взаимосвязей между доменами: смысловая взаимосвязь доменов, конвертирующее отображение из X в 7, обобщающее отображение из X в 7, обобщающее отображение X на 7, изоморфизм доменов. Доказана корректность построенной классификации, а также некоторые свойства определяющие пересечения этих классов.
Построение классификации взаимосвязей между переменными-отношениями в различных схемах данных. Выделены следующие классы: соответствие кортежей, возможность по кортежу в переменной-отношении А определить кортеж в переменной-отношении В, возможность по кортежу в А однозначно определить кортеж в В, возможность синхронизации переменных-отношений. Доказаны необходимые и достаточные условия для определения класса взаимосвязей между переменными отношениями. Исследованы свойства, определяющие практическую значимость выделенных классов взаимосвязей, приведены соответствующие примеры.
Построение алгоритма сопоставления текстовых строк, учитывающего «веса» замены одного символа на другой, а также возможность перестановки слов в строке.
Два примера выполненных проектов, использующих технологию интеграции данных, основанную на построенной классификации. Проекты относятся к различным предметным областям: в первом примере рассматривается задача интеграции данных о физических и юридических лицах, во втором примере рассматривается задача интеграции данных о материально-технических ресурсах.
Научная новизна работы
В диссертации предложена оригинальная предметно-независимая классификация взаимосвязей между структурами данных, отличающаяся тем, что в ней применяется математический аппарат теории реляционных баз данных к взаимосвязям в структурах данных, реализуемым современными программными средствами, предназначенными для интеграции данных. Идея заключается в том, чтобы сначала классифицировать взаимосвязи между доменами отдельных атрибутов, а затем изучить каким классам взаимосвязей между доменами принадлежат наборы атрибутов, являющихся потенциальными ключами, и какие интеграционные задачи при этом можно решать.
Также в данной работе разработан новый алгоритм сопоставления строк, учитывающий возможность изменения порядка слов в строке, возможность пропуска слов и различные «веса» замены символов.
Практическая значимость
Приведенная в данной работе классификация взаимосвязей в схемах данных может применяться в широком спектре проектов по интеграции информационных систем, на этапе анализа предметной области и формирования проектных решений. В соответствии с технологией, описанной в данной работе, разработчикам совместно со специалистами в предметной области необходимо определить взаимосвязи между отдельными атрибутами в интегрируемых системах и наборы атрибутов, которые являются потенциальными ключами. В данной работе приводятся строгие доказательства возможности или не возможности применения определенных операций над данными в зависимости от указанных взаимосвязей. Использование такой классификации позволяет переложить часть высокоуровневых интеграционных задач на шину данных, автоматизировав
верификацию корректности интеграционных интерфейсов и конвертеров, реализуемых в шине данных.
Апробация работы и публикации
Основные результаты диссертации были доложены на научных конференциях [4, 5] и опубликованы в рецензируемых журналах [1, 2, 3], в том числе одна публикация в издании из списка рекомендованных ВАК. Основные результаты диссертационной работы были использованы в практических проектах по интеграции данных [2, 3].
Структура и объем работы
Содержание диссертации
Задача интеграции баз данных включает две проблемы: сопоставление схем данных и сопоставление записей (поиск/устранение дубликатов).
Сопоставление схем данных проводится разработчиками совместно с экспертами в предметной области. На сегодняшний день есть средства, которые автоматически предлагают соответствия между схемами на основе их синтаксического анализа [Rahra, Bernstein, 2001] либо на основе семантических данных, задаваемых экспертами [Roth at al., 2006]. Подобные средства позволяют получать конверторы между схемами данных на различных языках: SQL, XQuery, XSLT. Однако применение этих средств не дает ответа на вопрос о гарантированной возможности решения той или иной задачи интеграции данных. В случае определения соответствий на основе семантических данных, от экспертов обычно требуется абстрактное высокоуровневое проектирование: детальное описание объектной модели предметной области [Bernstein, Melnik, 2007] либо определение формальной онтологии разрешения конфликтов [Ram, Park, 2004]. Подход, описанный в данной работе, напротив, не требует от экспертов ничего кроме указания конкретных взаимосвязей между атрибутами в интегрируемых базах данных.
Подобные подходы применяются в некоторых специфичных предметных областях. Например, в статье [Ram et al., 1999] описываются и классифицируются конфликты, возникающие при сопоставлении схем географических баз данных. Все конфликты в этой статье укрупнено делятся на структурные конфликты (schema-level) и конфликты в данных (data-level). Структурные конфликты представляют собой различия логической структуры или неполноту метаданных в описании одной сущности в различных базах данных. Двумя основными причинами таких конфликтов являются (1) использование разных структур (таблиц и полей) для одной и той же информации, и (2) использование разных спецификаций (т.е. имен, типов данных и констрейнтов) для одной и той же структуры. Далее, данная статья подразделяет структурные конфликты на шесть типов: конфликты имен (синонимы в названиях записей и атрибутов), конфликты кодирования, конфликты изоморфизма схем, конфликты обобщения, конфликты агрегации (включая конфликты географической агрегации), и несовместимость схем. Конфликты данных так же могут быть разделены на шесть типов: конфликты значений, конфликты представления данных, конфликты единиц измерения, конфликты точности данных (включая степень детализации и конфликты географических масштабов), конфликты достоверности известных данных, и конфликты различия доменов. Такая классификация не всегда подходит для интеграции схем данных из других предметных областей. Приведенная в настоящей работе классификация рассматривает более общий случай, и использует обратный подход: классифицируются не конфликты, а взаимосвязи в схемах данных.
Ранее проводились некоторые исследования по автоматическому сопоставлению схем баз данных, на основе хранящейся в этих базах данных информации [Kim et ah, 1993; Madhavaram et al., 1996; Song et al., 1996]. Основная идея этих работ заключается в том, что если найти несколько полей в таблице А одной базы данных, попарно совпадающие с несколькими полями таблицы Б другой базы данных, то можно сделать вывод о том, что таблицы А и Б описывают одну и ту же сущность.
Проблема сопоставления записей, а также поиска и устранения дубликатов в базах данных исследовалась гораздо подробнее. Например, с 1950-ого года вышло более 100 публикаций на тему поиска дубликатов записей о пациентах в различных медицинских базах данных для эпидемиологических исследований [Newcombe, 1988]. Большой интерес к проблеме устранения дубликатов есть в банках (например, для отслеживания кредитной истории) и в налоговых органах. Одна из первых публикаций на эту тему принадлежит Ямпольскому и Горбоносову [Ямпольский, 1973].
Большинство работ по устранению дублирования предлагают алгоритмы специфичные для определенной предметной области. Например, есть алгоритмы для поиска записей о людях, и совсем другие алгоритмы для поиска записей о химических веществах. Есть, так же алгоритмы, в которых не заложена изначально предметная область, но которые предполагают, что информация о предметной области будет предоставлена пользователем, перед запуском алгоритма [Hernandez and Stolfo, 1995].
Одной из важных подзадач при интеграции баз данных и устранении дубликатов является проблема сопоставления текстовых строк или поиска похожих строк. Эта проблема была исследована еще подробнее, чем проблема сопоставления записей [Galil and Giancarlo, 1988; Chang and Lampe, 1992; Du and Chang, 1994]. Общий подход к решению данной проблемы основывается на дистанции Левенштейна [Левенштейн, 1966] (или дистанции редактирования). Дистанцией Левенштейна называется минимальное число операций над символами (замен, добавлений и удалений) необходимых, чтобы преобразовать одну строку символов в другую.
Методы исследования
Даны две строки. Алгоритм Смита-Ватермана с помощью динамического программирования находит наименьший «вес» серии изменений, которые переводят одну строку в другую, то есть наименьшую дистанцию редактирования с учетом весов отдельных операций: изменение символа (мутация), добавление символа, удаление символа. Веса операций являются параметрами алгоритма. Данный алгоритм широко применяется в приложениях проверяющих орфографию и других текстовых приложениях.
Мы будем использовать алгоритм Сита-Ватермана для сопоставления текстовых атрибутов в базах данных. Для определенности определим алфавит, с которым работает алгоритм, из букв в верхнем и нижнем регистрах, десяти цифр и трех знаков препинания: пробела, запятой и точки. Все остальные символы удаляются перед применением алгоритма.
Алгоритм Смита-Ватермана принимает на вход три параметра: m, s и с. Если задан алфавит А, то m это матрица размера \А\ X \А\, в которой указаны веса соответствия для каждой пары символов алфавита Е. В матрице m мы будем задавать вес для точного совпадения символов, для возможного совпадения и для точного несовпадения символов. Изначально в алгоритме Смита-Ватермана эта матрица моделировала вероятность мутаций происходящих в цепочках ДНК в природе. В нашей работе мы будем использовать эту матрицу для того чтобы учесть типичные орфографические ошибки и опечатки, которые могут возникать при ручном вводе записей в базу данных.
Основное преимущество алгоритма Смита-Ватермана перед аналогичными алгоритмами состоит в возможности вставлять зазоры в строки. Зазор это последовательность символов в строке, которые не участвуют в сопоставлении. В следующем примере зазоры указаны символом дефиса:
Скалярный параметр s - это стоимость начала зазора, параметр с - это стоимость продолжения зазора. Значения этих параметров существенно влияют на поведение алгоритма. Например, если значения параметров таковы, что относительно дешево продолжать зазор (c s), то алгоритм Смита-Ватермана будет стараться найти один длинный зазор вместо нескольких коротких. Поскольку алгоритм Смита-Ватермана позволяет учитывать зазоры из несоответствующих символов, интуитивно понятно, что он должен хорошо работать с аббревиатурами. Так же он должен хорошо работать когда строки имеют незначительные синтаксические отличия или когда в них пропущены короткие подстроки.
В ходе работы алгоритм Смита-Ватермана вычисляет матрицу весов Е. Одна из строк помещается по горизонтальной оси матрицы, а вторая строка помещается по вертикальной оси. Элемент E(i,j) матрицы - это лучший вес сопоставления подстрок $і(1. .) первой строки и s2 второй строки. Когда подстроки (или строки целиком) полностью совпадают, оптимальный путь проходит в матрице Е по главной диагонали. При приблизительном соответствии строк оптимальный путь проходит на небольшом расстоянии от главной диагонали. Формально значение E(i,j) вычисляется следующим образом: (i-1,7 - l)+m(5l(і), s2(/))
Во всех примерах, приводимых в экспериментальной работе (см. раздел 3), для алгоритма Смита-Ватермана используется один и тот же набор параметров. Эти параметры были выбраны экспериментально и показали хорошие результаты. Для совпадающих символов не зависимо от регистра элементы в матрице m заполняются значением 5. Для близких по звучанию или написанию символов элементы в матрице m заполняются значение 3. Все остальные элементы матрицы m заполняются значением -3. Веса начала и продолжения зазора равняются 5 и 1 соответственно.
Эксперименты показывают, что вес начала зазора должен примерно равняться в абсолютном выражении весу совпадения двух символов. Вес продолжения зазора должен быть меньше чем вес близких символов. Если эти условия соблюдаются, то алгоритм Смита-Ватермана работает достаточно эффективно, не зависимо от точных значений параметров. В ходе экспериментов варьировался вес начала зазора. При этом рассматривались значения больше и меньше чем вес точного совпадения символов. Аналогично, рассматривались различные положительные значения для веса продолжения зазора.
Функцию соответствия текстовых строк, использующую алгоритм Смита-Ватермана, мы будем обозначать Psw.
Алгоритм Смита-Ватермана имеет квадратичную сложность относительно длины сравниваемых строк. В ходе работы алгоритма необходимо полностью вычислить матрицу Е имеющую размер IsjJ х s2. В отличие от расстояния Левенштейна, тут нельзя применить динамическое программирование. Как известно, для применения динамического программирования необходимо, чтобы задачу можно было разбить на подзадачи и использовать решения подзадач при решении задачи. Для алгоритма Смита-Ватермана это условие не выполняется. Если мы вычислим вес соответствия двух подстрок Psiv(s1[l..i](S2[l..y]), а затем будем вычислять Psw(si[l..i + l],s2[l..j +1]), то расположение зазоров в st [1.. і] и s2 [1-І] может измениться.
Тем не менее, этот алгоритм можно оптимизировать. Мы знаем, что если строки совпадают, то наименьший вес соответствия строк будет лежать на главной диагонали. Если строки отличаются незначительно, то наименьший вес будет расположен на небольшом удалении от главной диагонали. Поэтому достаточно вычислять элементы матрицы Е только в небольшой окрестности главной диагонали. Для строк длинной в 50 символов эксперименты показывают, что если вычислять элементы на главной диагонали плюс минус 15 символов, то точность алгоритма Смита-Ватермана практически не изменяется. Интуитивно понятно, что разница в 15 символов допускает до двух пропущенных слов или двух аббревиатур в сравниваемых строках. Причем если отсутствующие слова есть в обоих строках, то они компенсируют друг друга и наименьший вес остается в окрестности главной диагонали. Если строки отличаются больше, то можно считать, что это разные строки.
Такое ограничение делает теоретическую сложность алгоритма линейной, в то время как фактическое время работы алгоритма сокращается более чем на 50%. Функцию соответствия текстовых строк, использующую оптимизированный алгоритм Смита-Ватермана, мы будем обозначать Pswo. Ее имеет смысл применять при сравнении большого числа записей.
Способы сопоставления записей
Сохранить назначение и поведение общих пунктов контекстного меню по аналогии с одноименными пунктами в других списках КС. При экспорте списка в MS Excel не учитывать ограничение по количеству отображаемых в списке записей.
Сортировать список по ФИО (в алфавитном порядке), дате рождения (по возрастанию) и дате пожертвования (по возрастанию) при первом открытии списка или если сортировка не задана, а так же при нажатии на заголовок колонки «№».
При выборе любого из пунктов подменю «Установить признак «К загрузке» выполнить с каждой из записей списка (соответствующей выбранному пункту контекстного меню) все действия, предусмотренные при выходе из редактора «Данные PC» с сохранением изменений. Если при этом необходимо установить фокус ввода в поле редактора, открыть редактор «Данные PC». После закрытия редактора перейти к обработке следующей записи, соответствующей выбранному пункту контекстного меню. При выборе любого из пунктов подменю «Установить признак «К загрузке» (кроме пункта «для выбранной записи» отображать процесс установки значения поля «Запись обработана» с помощью прогресс-бара и таймера, отсчитывающего время с начала процесса установки значения поля «Запись обработана» в формате «часы:мгшуты:секунды» (каждое значение выводится двумя цифрами).
Запускать функцию «Импорт сведений из PC» при выборе пункта «Импорт файла» контекстного меню списка «Данные из PC», исключив запуск данной функции из главного меню. Сохранить форму ввода параметров функции (переименовав для этого заголовок окна «Загрузка сведений PC»). Исключить из формы ввода параметров группу полей «Документ о результатах проверки». Разместить на форме ввода параметров функции объектную ссылку «Документ о результатах проверки» с возможностью создания, выбора и редактирования записи списка входящих документов.
Запускать функцию «Загрузка сведений из PC» автоматически при открытии списка «Данные из PC», если без учета установленных критериев фильтрации список не содержит записей. При нажатии кнопки «Загрузить» на форме ввода параметров функции проверить корректность формата полученного с помощью PC текстового файла (данный функционал сохраняется без изменений).
Для каждой строки полученного с помощью PC текстового файла, содержащей данные в требуемом формате: 1) создать в списке «Данные из PC» новую запись; 2) проверить идентификатор ФЛ из файла по таблице дубликатов: если данный идентификатор соответствует лицу-дубликату, то перенести в запись списка «Данные из PC» идентификатор основного лица, указанный в таблице дубликатов, иначе — идентификатор ФЛ из файла; 3) перенести в запись списка «Данные из PC» значение полей «Результат поиска в PC», «Дата пожертвования» и реквизиты ФЛ из соответствующей строки файла (удаляя при этом начальные и конечные пробелы и символы табуляции), а также реквизиты входящего документа, заданные на форме ввода параметров функции. Для всех вновь созданных записей списка «Данные из PC»: 1) вычислить значение поля «Результат поиска в КС» (по алгоритму, приведенному в технических решениях по реализации пункта 2.1.6.6.3 ТЗ); 2) если значение поля «Результат поиска в КС» отлично от «ФЛ удалено в КС», «ФЛ не найдено в КС», «Пожертвование удалено», «Пожертвование не найдено», то вычислить значения поля «Название партии, РО, ИЗСП» (по алгоритму, приведенному в описании списка «Данные из PC»), а также полей, соответствующих флагам «Считать расхождением» для каждого из реквизитов ФЛ (по алгоритму, приведенному в технических решениях по реализации пунктов 2.1.6.6.4 - 2.1.6.6.6 ТЗ), для остальных вновь созданных записей оставить поле «Название партии, РО, ИЗСП» пустым, а поля, соответствующие флагам «Считать расхождением» редактора «Данные PC» установить в значение «Нет»; 3) вычислить значение поля «Действие» (по алгоритму, приведенному в технических решениях по реализации пунктов 2.1.6.6.4 - 2.1.6.6.6 ТЗ), с учетом следующего: для группы записей списка, у которых значение поля «Результат поиска в PC» равно «5 — найдено более 1 ФЛ», относящихся к одному физическому лицу и имеющих одну дату пожертвования, значение поля «Действие», отличное от «Не обрабатывать результат проверки данных в PC», установить для записи, имеющей наименьшее количество расхождений с данными из пожертвования (если таких записей несколько -для записи, созданной раньше), для остальных вновь созданных записей указанной группы установить значение «Не обрабатывать результат проверки данных в PC»; 4) вычислить значение поля «Дата начала действия сведений о ФЛ»: если значение поля «Результат поиска в КС» равно «Актуальный результат проверки не подтвержден входящим документом» или «Актуальный результат проверки совпадает с данными из PC и подтвержден входящим документом», то установить значение поля равным значению поля «Дата начала действия сведений о физическом лице» найденного результата проверки ФЛ; для остальных вновь созданных записей установить значение поля равным дате пожертвования, указанной в полученном с помощью PC текстовом файле; 5) установить поля «Реквизиты документа недостоверны», «Адресные реквизиты недостоверны», «Умер(ла) , «Данные PC редактировались пользователем» в значение «Нет»; 6) поле «Примечание» оставить пустым; 7) если значение поля «Результат поиска в PC» равно «20 — ФЛ не найдено», установить значение поля «Персональные данные не обнаружены в PC» равным «Да», для остальных вновь созданных записей - равным «Нет»; 8) вычислить значение поля «Запись обработана»: для записей, у которых значение поля «Результат поиска в PC» равно «10-найдено единственное ФЛ» и значения всех полей «Считать расхождением» равны «Нет», а также для записей, у которых значение поля «Результат поиска в КС» равно «ФЛ удалено в КС», «ФЛ не найдено в КС», «Пожертвование удалено» или «Пожертвование не найдено» установить значение «К загрузке»; для остальных вновь созданных записей установить значение «Не обработана».
Описать такое поведение системы в эксплуатационной документации. Если в процессе импорта файла возникали ошибки, отобразить реализованный в системе отчет о загрузке сведений о физических лицах из PC, переименовав его в «Отчет об ошибках, выявленных при импорте файла с результатом проверки в PC сведений о физических лицах жертвователях» и заменив слова «Статус PC» словами «Результат поиска в PC». Данные, включаемые в отчет, в БД не сохраняются. Возможность вызова отчета из интерфейса КС не предусматривается. Сохранить возможность экспорта отчета в MS Excel. Если импорт файла произведен без ошибок, выдать предупредительное сообщение, содержащее текст «Импорт успешно завершен» и кнопку «Закрыть».
При нажатии кнопки «Закрыть» или перед выводом отчета об ошибках, выявленных при импорте файла с результатом проверки в PC сведений о физических лицах-жертвователях, закрыть форму ввода параметров функции, вернуться в список «Данные из PC», сбросить настройки фильтра в значения по умолчанию, реквизит фильтра «Входящий документ» установить в значение, соответствующее выбранному на форме ввода параметров функции входящему документу, и обновить список «Данные из PC».
Устранение дублирования
В отсутствии централизованного корпоративного справочника товаров специалисты по закупкам постоянно сталкивались с проблемами дублирования товаров, затягиванием сроков выполнения заявок, "замораживанием" складских запасов. Кроме этого, реализуя намеченную стратегию развития, высшее руководство холдинга поставило перед снабженцами задачу не только годового, но и трехлетнего перспективного планирования закупок. Однако уже при годовом планировании организация закупок требовала от персонала больших усилий. С вводом же трехлетнего плана объем работы увеличивался, а штат сотрудников Торгового дома оставался прежним. Холдинг развивается, строит в разных регионах страны новые крупные объекты, а это тоже прибавляет снабженцам работы.
Все перечисленные проблемы требовали радикального совершенствования управления закупками. Для этого был выбран очевидный и проверенный на практике путь — автоматизация соответствующих бизнес-процессов с использованием подходящего ИТ-решения. В Торговом доме холдинга было выработано свое понимание того, каким должно быть оптимизированное материально-техническое обеспечение. На основе этого понимания была подготовлен новый регламент централизованного материального обеспечения Дочерних обществ, в котором была задокументирована общая идеальная модель бизнес-процессов снабжения в холдинге.
В 2004 году руководство холдинга запланировало завершить заявочную компанию на закупки 2005 года к концу октября 2004 года и провести компанию уже с использованием работающей системы. Это означало, что Торговый дом как заказчик системы должен был уложиться с ее внедрением в весьма сжатые сроки. Предстояло за август и сентябрь 2004 года сдать в штатную эксплуатацию функционал системы, обеспечивающий составление заявок, включая подготовку всех необходимых для этого данных (ранее копившихся в формате MS Office Excel). По этой причине выбор решения ограничивался классом "небольших" ERP-систем с "быстрым" внедрением.
После предварительного анализа рынка заказчик остановился на системе Navision, которая помимо своих основных характеристик расположила к себе также дружественным интерфейсом, во многом напоминающем интерфейс операционной системы Windows.
Сложности реализации проекта в Торговом доме холдинга в первую очередь были связаны с отсутствием у заказчика централизованного справочника товаров. До внедрения системы вся заявочная компания проводилась на основе обмена файлами MS Office Excel, в которых дочерние компании формировали свои заявки, и которые имели произвольную форму, а потому требовали ручной обработки и к тому же не всегда корректно описывали товар. Начинать нужно было с импорта файлов MS Office Excel в систему Navision. На базе импортированных данных предстояло сформировать справочник-прейскурант и провести его очистку от дублирующих записей. В сжатые сроки эта работа была выполнена, и в конце октября согласование заявочной компании проводилось уже по отчетам, полученным из работающей системы. Таким образом, в октябре 2004 года планирование закупок было полностью перенесено в систему. Сегодня система уже поддерживает работу над проведением конкурсов закупок на основе данных этапа их планирования.
К особенностям, усложнившим проект, следует также отнести, что система Navision рассчитана на работу с "толстым" клиентом в локальных сетях. В рамках же проекта к системе пришлось подключать и удаленные "дочки", не охваченные локальной сетью. Для этого были разработаны две схемы. По одной из них для компаний, не имеющих постоянного канала связи, создается набор файлов в формате MS Office Access, содержащие данные общекорпоративных справочников. На стороне "дочек" был предусмотрен ввод данных в эти файлы с последующим импортом данных в систему. В другой схеме использовался терминальный доступ в систему на базе технологии Citrix. Это позволило задействовать в терминальном режиме каналы с низкой пропускной способностью (от 25 Кбит).
Торговый дом по своему формальному статусу не имеет административных средств влияния на другие дочерние структуры холдинга. Это усложняло его задачу, как заказчика проекта, заключающуюся в том, чтобы система была принята остальными коллективными пользователями -"дочками" холдинга. Встреча с представителями дочерних компаний и их акционерами, состоявшаяся в конце прошлого года, подтвердила, что эта задача выполнена: система устроила и головную, и дочерние структуры холдинга. Более того, собрание подтвердило правильный выбор архитектуры решения, которая позволит развить его в нужном для пользователей направлении. Уже за короткое время эксплуатации стало понятно, что от системы потребуется в ближайшем будущем. Это оказалось возможным в результате взвешенного подхода к автоматизации бизнес-процессов, что по помогло быстро почувствовать преимущества выбранного решения и осознать возможные перспективы развития.
Отправной точкой для анализа процесса планирования стало изучение регламента централизованного материального обеспечения, форм отчетов используемых у заказчика, должностных инструкций и другой документации, описывающей работу Торгового дома. Этот этап позволил аналитикам получить представление о предметной области и подготовиться к первым встречам с ключевыми пользователями. Такая тщательная подготовка обеспечила позитивное отношение представителей заказчика к сторонним консультантам и позволила эффективно построить работу проектной команды на начальной стадии проекта.
