Документ как он есть
Документ как он есть
С точки зрения различных стандартов, законов и положений документ определяется примерно одинаково. Так или иначе, это информация на материальном носителе с реквизитами, позволяющими ее зафиксировать и идентифицировать, а также использовать в деловой практике. С точки зрения бумажного документа — достаточно, с точки зрения электронного — вроде бы тоже (но споры неизбежны), но вот с точки зрения логической программной схемы документа, позволяющей наиболее эффективно использовать его при хранении и обработке в электронных архивах, в СЭД, в других информационных системах, при передаче из одной точки в другую по каналам связи, единого взгляда нет.
Наиболее важный фактор, который определяет логическую программную схему документа — это задачи, которые будут решаться относительно документа. Будет ли это хранение, будет ли это активная обработка документа, нужно ли системе работать с содержимым документа, будет ли схема документа служить задаче обмена документами. Отсюда вытекают потребности: каким образом решать задачу сочетания тела и метаданных документа, как типизировать и классифицировать документы, каким образом строить версионность (и строить ли вообще). Есть ли необходимость вводить понятие жизненного цикла документа, нужно ли обеспечивать многоформатность документов, надо ли создавать сложные агрегации документов. Всплывают сотни факторов, включая многоязычность, аудит и связь электронного документа и его бумажного аналога.
Обычно ECM-система оказывается в роли этакого "крайнего" в данном вопросе, принимая на себя задачу создания такого "контейнера" для тела (тел) документа, чтобы обеспечить разрешение самых разнообразных ситуаций. В отличие от ECM-систем системам других классов приходится значительно легче, ведь они решают лишь подмножество задач: архивы (даже если это подмножество ECM-системы) — хранение единственно верного варианта документа, ERP — работа с структурированным телом, системы обмена и EDI-системы — маршрутизация документов и гарантия неизменности их значимой информации.
Даже стандарты не стремятся — и, на мой взгляд, это правильно — дать единственно верный путь для программной модели документа. Например, MoReq определяет документ больше с позиции его учета, CMIS — с позиции гарантированного доступа к разным репозиториям (ограничиваясь довольно упрощенной схемой доступа и допуская неслабую вариативность реализации). Стандарт, разработанный Гильдией Управляющих документацией, определяет модель сообщения, которая оперирует ограниченной моделью документа. Всё определяется задачами и ситуациями использования и реализуется в соответствии с принципом "лучше меньше да лучше".
Отсюда я делаю один довольно очевидный вывод. Со временем мы перейдем к электронным документам (т.е. в преобладающем большинстве случаев будем оперировать именно таким понятием в наших транзакциях). При этом останутся разные наследники текущих форматов с сотнями вариаций модели документов. Документ будет вынужденно преобразовываться, мигрируя от одной системы или организации к другой, проецируясь на разные программные схемы документов. Набор байтов, составляющих документ в одном месте и в одно время, будет гарантированно отличаться от набора байтов, составляющих тот же документ в другом месте и в другое время. Речь, оговорюсь, не только и не столько о формате документа, сколько о способе его восприятия информационной системой и доступности сведений о нем (истории, версий, различных метаданных, включая подписи) конечному пользователю.
Комментарии 14
Концепция ECM - это в определенной степени попытка вывернуть бизнес-логику "наизнанку". В "предметных" системах, которые заняты решением "более конкретных" задач, главной "ценностью" являются более определенные (и менее универсальные) сущности (транзакции, клиенты, финансовые потоки), а документы играют "вспомогательную", прикладную роль. Не больше и не меньше. Подход ECM в этом смысле прямо противоположен - в режиме стоп-кадра из бизнес-процессов выдирается контент, который ставится в центр системы. А поскольку бизнес-процессы и документы, участвующие в них, сильно разнятся в отдельных задачах и информационных системах, их решающих, то "общего", что все эти документы связывает, я бы сказал "квинтэссенции документа" оказывается настолько мало, что трудно определить. Прямо родственник "сферического коня в вакууме". Я уже не говорю о том, чтобы стандартизировать понятие "документ".
Так что, на мой взгляд, возможен и иной сценарий эволюции документа - он, как понятие, просто "растворится" в информационном потоке, и мы будем оперировать более понятными, осязаемыми, и менее концептуальными, чем документ сущностями.
А казалось бы документ, самая что ни есть осязаемая сущность (в головах большинства людей). Так что вряд ли в ближайшее время мы не будем опрерировать этим понятием. По крайне мере нам придется делать это для общения с большинством людей.
Первый аспект.
С точки зрения документа, его реализация, бумажная, электронная, вербальная или любая другая, не имеет существенного значения.
Форма (вид) документа не имеет значения и с точки зрения пользователя. Количество органов чувств у человека ограничено, например, слух, зрение, тактильное чувство. Поэтому отличить электронный документ, например, от бумажного перечисленными органами чуств почти не возможно (с некоторыми оговорками).
Отсюда можно сделать вывод, что проблема электронизации документов надумана. Проблема находится в области электронных сигналов, а не документов. Мы пока не научились эти сигналы достоверно обрабатывать. Перечисленные в статье стандарты из области обработки сигналов, а не документов.
Второй аспект.
Что есть, собственно, документ? Документ есть средство управления, "есть осязаемая сущность (в головах большинства людей)".
Поэтому он ни как не может "просто "растворится" в информационном потоке".
> Перечисленные в статье стандарты из области обработки сигналов, а не документов.
Жаль, авторы не в курсе :) Ладно, долой иронию. К сигналам можно свести вообще всё, но я вообще-то о другом. В посте я хотел поразмышлять на тему моделей для документа: моделей, которые позволят описать как поведение систем, обрабатывающих документы, так и зафиксировать представление людей о документе (в системах или отрыве от них). И вывод (один из, на самом деле) был таков, что один и тот же документ в разных системах (в неэлектронных в т.ч.) логически будет представлен по-разному.
Ну про сигналы, конечно чуток загнул :)
А размышления на тему моделей систем и документов нужно начать с простого.
Поставить главный вопрос ребром, о чем собственно речь? О «системе», о «документе» или о чем-то другом. Что такое «система» - инструмент. Что такое «документ» - инструмент. Мы что хотим говорить об инструментах? Давайте поговорим об инструменте под названием - топор. Что можно сделать топором: рубить, тесать, колоть, мерзлую землю ковырять и кучу других трудных работ, а можно делать приятные вещи, например, варить кашу из топора.
Какой вывод? Если изучать инструмент, то все многообразие его применения описать нет возможности. Поэтому, как только выходит очередной стандарт, относящийся к документообороту, сразу находятся «умники» (в хорошем смысле этого слова), которые заявляют об отсутствии полноты раскрытия темы.
Что делать? Нужно применить старый сыщиковский метод – найти того, кто в этом безобразии заинтересован и разобраться с ним.
В системах документооборота (и в других) изучают кого или что угодно но, только не субъекта деятельности. А, именно субъект ведет деятельность, используя инструменты в своих интересах. Размерность описания системы деятельности субъекта существенно меньше и проще, нежели описание возможностей инструмента (см. про топор), за счет того, что речь идет только о необходимом и достаточном, а не о возможном не имеющем границ.
Проще говоря, задачи, решаемые инструментом, первичны. Кто бы спорил... Но если тот же топор не заточить, не продумать его форму, не учесть опыт его применения для рубки леса и варки каши, то нормально -- быстро и с хорошей отдачей -- задачи не решишь.
Это верно. Однако.
Сложилась традиция создания автоматизированных систем, где люди используются в качестве обеспечения, наравне с программным, техническим и другими. Т.е. техноцентрический подход. Примеры можно наблюдать в «Системный проект формирования в Российской Федерации инфраструктуры Электронного правительства», Рисунок. 6.1. Ключевые компоненты инфраструктуры электронного правительства в составе федерального и регионального сегментов. И др.
Хотелось бы акцентировать внимание что, в этом же документе дается определение электронному правительству как способу ОРГАНИЗАЦИИ ДЕЯТЕЛЬНОСТИ органов власти ПО ГОСУДАРСТВЕННОМУ УПРАВЛЕНИЮ на основе удаленного взаимодействия. Коряво получилось, это моя трансляция текста из введения. Можно еще отжать и получится: Правительство – это способ организации деятельности по государственному управлению.
Так вот, ключевыми словами тут являются: управление деятельностью. Отсюда, нужна система автоматизации управления деятельностью, а не система управления запасами, документами, персоналом и т.п. Казалось бы, а в чем разница? А, в том, что в центре системы становится человек (субъект) и все остальное крутится вокруг него. Получается антропоцентрический подход или точнее деятельностный подход к моделированию систем.
Основные положения метода ранее представлялись на конференциях, последний раз апрель в Гильдии Управляющих Документацией.
Плясать можно и от человека, его деятельности. Только если сильно увлечься таким подходом, можно прийти к тому, чтобы автоматизировать отдельно каждый вид деятельности или каждую роль. Практически в каждом бизнес-процессе, связанном с управлением, участвуют документы (не важно, бумажные или электронные). Если рассматривать документы только как внутренние объекты, подчиненную бизнес-процессу, то может стать, что один реальный документ будет представлен несколькими сущностями. Если процессы не взаимосвязаны, и не требуется их синхронизация (скажем, в зависимости от статуса документа), то большой беды в этом нет. Но на практике один и тот же документ может участвовать в нескольких бизнес-процессах одновременно. Таким образом, возникает необходимость вводить "сквозной" объект - документ. Отсюда и "документоцентричность" современных ECM-систем. Как видите, не от хорошей жизни :)
Вы правы, счастья в жизни нет!
Я не очень понял про увлечение подходом. Объем автоматизации определяется желанием заказчика, с одной стороны, и возможностями поставщика с другой, методический подход, наверное, не при чем.
Если сравнивать подходы процессный и деятельностный, то в самом простом представлении различие состоит в том, что процесс – это набор действий, а деятельность – это набор результатов действий.
Моделирование в категориях результатов позволяет достаточно просто оперировать с одноуровневым и многоуровневым представлениями о деятельности.
А, относительно многострадального «сквозного документа» с точки зрения деятельностной модели проблем просто в принципе нет.
Про модели для документов.
Анализ. Современный средний документ представляет собой удивительный сплав противоречий внутри себя и с другими документами, существующими давно или которые появятся завтра, а также недосказанных мыслей. Документ не предназначен для обработки электронными методами. Подобными свойствами обладает не только отдельно взятый документ, но и система документации, а также система деятельности, которая организуется и реализуется с помощью документов, как говорится одного поля ягодки.
Сейчас актуальна тема электронного обмена документами, предлагаемое решение – карточка документа + файл с документом произвольной структуры. Так решают задачу сокращения времени и бумаги на передачу. Но технология формирования, принятия решения или исполнения не изменилась, она осталась на уровне бумажного документа. Получилось бумажно-ориентированное применение электронных документов.
Вывод - идем эволюционным путем, т.е. пока гром не грянет... Количество обрабатываемых электронных документов к 15 году возрастет на порядки. Средний срок исполнения документа сократится незначительно. Основные затраты времени находятся в области обработки документа. Нужно понять, что традиционные способы исполнения документа, как-то: совещания, телефонные переговоры, служебные записки и прочее не отменены. Таким образом, использование только электронного обмена документами принципиально ничего нового не дает по сравнению с бумажным обменом. Проявятся положительные эффекты в будущем: персонал поймет неизбежность электронизации и возьмется за ум, будет сформировано недостающее звено «обмен» и вслед за этим возникнет понимание, что существующие разработки автоматизированной регламентации и прочее, которые кусочно автоматизируют управленческие процессы, очень затратны и неэффективны из-за их разрывности. Возникнет понимание о необходимости формирования единой системы управления видами деятельности, в которой должны использоваться древовидные по структуре документы, логически связанные меду собой. Интересная особенность: ввести в существующую систему документов противоречивый документ будет очень трудно или почти невозможно.
Верно, что «нужен обмен отдельными, хорошо структурированными и связанными сообщениями с фиксацией их как документов».
Иными словами просто необходимы: структура отдельного документа, в том числе структура описательной части и структура связей отдельных документов. Откуда берутся структуры – из всяческих видов классификаторов и справочников: номенклатура, план счетов, штатное расписание и т.д. и т.п. Насколько более полно проклассифицирована деятельность, ровно настолько можно проклассифицировать документы.
Как есть. Классификаторы и документы живут, как правило, отдельно. Только во время обработки документы встречаются с классификаторами и получают от них наборы признаков и других служебных меток.
А какие тут проблемы? Проблема одна, синхронизация, но их две. Как синхронизировать отдельные документы и как синхронизировать документы и классификаторы?
Зададимся вопросом, а почему у нас все документы отдельные? Жизнь одна, история одна, а документы отдельные и почему классификаторы находятся как-то сбоку, сами по себе. В учетных системах уже давно сообразили делать записи в одну цепочку. Иными словами в учетной системе один документ, который начинается с первой записи и завершается текущим моментом.
Как надо. Давайте попробуем сделать вместо множества отдельных документов – один документ - «bada»документ, причем структурой этого большого документа должен стать классификатор деятельности, для описания которой будет предназначен большой документ. Тогда все «отдельные» документы будут представлять собой выписки или дописки из/в большой документ. Наличие структуры (классификаций) в большом документе позволит вписать или добавить в него только структурированные малые документы. При необходимости структура классификаций развивается эволюционно путем добавления новых свойств.
Александр, а работать с таким мега-документом удобно будет? Сейчас отдельные, пусть и логически связанные документы могут находиться в разных стадиях жизненного цикла, да просто в разных географических точках. Я уже не говорю про существование копий документов. Можно ли без потери функциональности перейти к одному мега-документу?
А где потеря функциональности? Речь идет о том, чтобы повысить функциональность - созать предпосылки и обеспечить возможность электронной обработки структурированных документов. Сейчас в государственном масштабе решается вопрос только об обмене документами в электронном виде. Речь об электронизации остальных видов обработки документов пока не идет. Умельцы почему-то предлагают ставить на экране монитора электронную подпись в виде росчерка пера и электронную печать в виде оттиска печати. Происходит увлечение внешними свойствами документа и попытка приведения электронного документа в вид подобный бумажному. Это тупик.
На самом деле, мегадок уже существует. Миллионы документов имеют различные связи между собой и классификаторами в существующих БД. В лучшем случае документы минимально структурированы, имеются карточка и метаданные, в худшем имеется карточка и электронная картинка. В одной разработке поле с метаданными назвали "мусор", потому что не понятно что, зачем, а главное кто будет заполнять это поле.
Современные системы управления не отслеживают непротиворечивость документов. Например, недавно сравнивал два постановления на одну тему вышедшие с интервалом 10 дней. Первое отменяет документ и вводит новый регламент, а второе вносит изменения в отмененый документ и неучитывает новый регламент. При этом в разработке этих документов участвовали десятки специалистов. А Вы говорите разные фазы и точки, да копии.
Основное назначение мегадока - обеспечение непротиворечивости деятельности через поддержание непротиворечивости документов, находящихся в разных точках, фазах и копиях. Точнее это не мегадок, а система управления деятельностью с помощью структурированных документов. И функциональность у системы очень высокая.