Малолитражный менеджмент

Алексей Важнов

В предыдущих статьях цикла (см. PC Week/RE, № 49/97, с. 54, № 2/98, с. 49) мы уже рассмотрели ряд требований к проектированию корпоративной БД, предназначенной для реализации системы управленческого учета. С другой стороны, на семинаре, прошедшем на выставке “Бухгалтерский учет и аудит’98” (см. PC Week/RE, № 5/98, с. 56), управленческий учет, в результате общих усилий получивший даже вполне осмысленное определение, был рассмотрен во взаимосвязи с другими компонентами системы управления бизнесом. Казалось бы, пора перейти непосредственно к проектированию корпоративной БД. Однако не будем торопиться. Есть еще одна проблема, хорошо известная тем, кто эксплуатировал информационную систему в течение длительного времени. Это архивирование и грамотная подготовка данных к нему.

Последовательность действий распадается на три шага:

- выделение данных, детальность которых уже не представляет интереса;

- формирование на их основе агрегированных показателей для использования в системе статистической обработки;

- удаление этих данных из корпоративной БД, т. е. выполнение собственно процедуры архивирования.

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

Проблемы технические+

Почему необходимо рассматривать эту проблему сейчас? Казалось бы, она не влияет ни на интерфейсы системы, ни на реализацию процедур обработки, да и вообще проявится не скоро  -  не раньше, чем через полтора-два года после ввода системы в эксплуатацию. “Надо начать запуск системы, а за эти два года мы доработаем блок архивирования”  -  такие слова часто можно услышать от разработчиков.

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

Разработка подсистемы архивирования после запуска КИС в эксплуатацию может потребовать изменения не только структуры БД, но и алгоритмов обработки. Всякий, кто когда-либо был связан с промышленным программированием, знает, во что обходится внесение изменений в уже отлаженную и протестированную программу, которая к тому же сдана в эксплуатацию.    

+и не только

Кроме технических, есть и другие причины к тому, чтобы заблаговременно уделить серьезное внимание вопросу утилизации данных. Электронное представление информации (которое зачастую не дублируется на бумаге) используется все более широко, и в полный рост встает вопрос: как грамотно распространить на него юридические нормы и, главное, обеспечить неукоснительное следование им (см. статью “Законы распространяются и на электронную почту”, PC Week/RE, № 4/98, с. 47)?

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

Проблема архивирования более глубока, чем кажется на первый взгляд. Если вернуться к рассмотрению жизненного цикла сделки (см. PC Week/RE, № 49/97, с. 54), то завершением ее с точки зрения оперативного управления считается передача в архив. На самом деле это не конечная вершина графа переходов  -  за ней следует еще преобразование информации в статистическую и реальное удаление данных из системы.

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

Без организационной поддержки не обойтись

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

Одним из первых мероприятий подобного рода является проведение в жизнь “политики чистого стола”. Все документы, имеющие отношение к учету, в конце рабочего дня должны быть проведены по информационной системе и с необходимыми отметками (например, с распечаткой протокола ввода) подшиты в соответствующие папки. Эта процедура должна быть обязательной, и под нее резервируется время. В результате появляется уверенность в том, что, во-первых, все данные попали в информационную систему и, во-вторых, нет потерявшихся бумаг.

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

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

Сколько же времени нужно хранить документ?

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

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

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

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

Как точно узнать, когда внедрение закончилось

Подсистема утилизации информации является своеобразным индикатором, свидетельствующим, что внедрение информационной системы завершено. Как только начнется удаление из базы данных документов по всем цепочкам бизнес-процессов, ее объем должен зафиксироваться и в дальнейшем расти только пропорционально увеличению количества документов, обрабатываемых за период. Это очень точный показатель. На него не влияет развитие системы  -  ведь новые подзадачи используют другие отношения (таблицы) в БД, рост объемов которых может быть показан отдельно.

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

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

Вывод: корпоративная база данных не может быть построена без проектирования схемы ее эксплуатации в установившемся режиме.

К Алексею Важнову, исполнительному директору компании ICS, можно обратиться по адресу: vazhnov@postman.ru.