Методология построения композитных системдокументооборота.
1. Введение
На сегодняшний день компьютерные технологии столь глубокоинтегрированы в производственные процессы, что чисто бумажные технологиипрактически перестали существовать. Сегодня во всех процессах документооборотана той или иной стадии используется компьютер. Как результат, влияниеинформационных технологий, которое изначально было крайне мало, возрастает иуже начинает претендовать на определяющее. Под влиянием первоначально вторичныхинформационных технологий документооборот непрерывно изменяется, своей новойсущностью заполняет новые ниши, возникающие в человеческой деятельности.
Таким образом, современные решения документооборота надорассматривать на пересечении электронных и бумажных технологий. Композитнаясущность этого представления предопределяет противоречивый характер, двеисходные составляющие влияют друг на друга в поиске эффективного решения [1]. Удельное влияние составляющих частей коррелируетсяуровнем развития технологии и устойчивостью традиций предметадокументооборота. Системы документооборота могут успешно функционировать приусловии, что будут преодолены противоречия между представлениями о системезаказчика и разработчика, а также будет найден баланс применения бумажных иэлектронных документов. Помимо этого, наиболее естественным являетсяэволюционный путь создания. Именно данное обстоятельство определяет композитныйподход к реализации систем документооборота, где сосуществуют как чистоэлектронные, так и чисто бумажные документы, а также множество композитныхгибридов. Такой подход полностью соответствует принципу смешанного экстремума [1], обеспечивающему, с одной стороны, гармонизацию системы,а, с другой стороны, являющемуся одним из механизмов, определяющих обратнуюсвязь эволюционного развития системы.
Понятие «электронный документооборот» (ЭД) является широко используемым и нечетко понимаемым.Большинство специалистов по информационным технологиям считает его определенными устоявшимся. Тем не менее определения, которые использовались при зарождении понятия ЭД, равно как и современные определения, являютсяочень общими и детерминированы лишь для высокого уровня абстракций. Например,под определение «документ інформація в якому зафіксована увигляді електроних даних, включаючи обов’язкові реквізити документа» [2] могут бытьподведены любые, даже самые догматично бумажные документы.
Расплывчатость формулировок есть лишь частью целогокомплекса проблем индустрии по созданию систем, которые принято называтьсистемами документооборота. Причем интересен тот факт, что принадлежность кэтим системам определяется скорее названием, данным автором, чем фактомудовлетворения необходимого списка функциональных потребностей.2. Постановка проблемы
Жизнь не стоит на месте. Современное общество постоянноизменяется, ставит перед собой и решает новые, все более сложные задачи.Прогресс в технологиях информационного взаимодействия идет темпами,оцениваемыми близко к экспоненциальным [3], что приводит кинформационному взрыву.
Процесс становления систем электронного документооборота(СЭД) в современном обществе не только начался и установился, а идет постояннонарастающим потоком. На базе промышленных, полупромышленных и просто«доморощенных» разработок выпускается много систем, которые обеспечиваютдвижение огромного количества документов. Эти документы накапливаютсянеструктурированной кучей [5], что предопределяетсерьезные проблемы на будущее. На данный момент специалистами так и недостигнуто однозначного соглашениея, что делать со старыми бумажнымидокументами, каким образом организовать использование старых данных, чтобы неутратить специфических свойств оригинальных документов.
Сегодня, в основном, пользователи и создатели СЭД действуютинтуитивно, создавая системы различной степени эффективности и устойчивости, непредусматривающие приемственности. В результате старые постсоветские канонынаходятся под сильным влиянием прозападных традиций, что порождает на светгибриды, отталкивающие потенциальных пользователей этих систем и устрашающие ихсоздателей.
Целью данной статьи является создание единой методологииреализации систем документооборота, использование которой позволило бы унифицироватьпроцесс разработки и увеличить эффективность создаваемых СЭД. Приведеннаяметодология является лишь рамочным описанием теориетической и практическойработы, основывается на апробированых подходах и может быть использована припроэктировании, создании и эксплуатации современных СЭД.3. Методология
Основу предлагаемой методологии составляют:принципы автоматизации систем организационного управления [4], принципы обьектно- ориентированного проектирования [5] и принципы управления проектами [6].
В современном понимании под автоматизациейподразумевается не столько замена людей автоматами, выполняющими их функции, а,в основном, усиление возможностей людей возможностями автоматов. Такаятрактовка очень важна, так как одной из основных проблем успешного внедренияновых информационных систем является сопротивление персонала. Люди боятся, тогочто они станут ненужными или что им прийдется работать более интенсивно.Поскольку подобные соображения обычно не высказывают открыто, то сопротивлениевыражается в скрытых формах. Принятие же трактовки усиления [7] позволяетутверждать, что внедрение системы будет означать не сокращение потребности вперсонале, а возможность выполнения людьми работы на другом качественномуровне.
Одна из основых идей сформулирована впринципе автоматизации документооборота [4]. Суть этого принципа в том, что СЭДдолжна проектироваться не только как носитель, а какактивный элемент процессов. В обьектно- ориентированной парадигме это принятоназывать инкапсуляцией [5]. Не будут успешными реализации, основанные накорректных технических решениях, но не учитывающие сущестовующей практикииспользования автоматизируемого обьекта.
СЭД должна являться не просто посредником,собирающим и обрабатывающим документы, а быть определяющим элементом, безкоторого использование документооборота не будет возможным. Иными словами, рядфункций должен быть реализован таким образом, что не будет существовать ихреализации вне электронной системы.
Этот принцип важен, так как следование емуделает СЭД неотьемлимой составной частью работы организации, что предопределяетпривыкание персонала к системе. В любой сложной системе, какой является и СЭД,персонал есть самым слабым, труднопредсказыемым и плохоуправляемым звеном.Поэтому важно закладывать такие решения, которые дадут дополнительные рычагимотивации персонала к работе с системой.
Создание СЭД, как любой процесс созидания,имеет творческое начало. Одна и таже система может бытьпредставлена множеством реализаций, даже если ее проектирует один и тот жечеловек. В то же время, современные техноологии программирования требуютстрогой формализации для реализации поставленных задач в заданные сроки и сзаданным показателем качества. Аппробированные методы достижения посталвенныхцелей требуют четкого предварительного декларирования задач, допускающегопоследующую достаточно точную декомпозицию и детализацию.
Для построения современных СЭД необходимодостижение баланса между неконтролируемой спонтанностью творческого начала иформализованной четкостью производственного процесса. При этом нельзяограничивать креативность, которая позволяет интуитивно находить решения,близкие к оптимальным. В то же время надо обеспечивать устойчивуюконтролируемость и управляемость процессов разработки. Для решения этой противоречивойзадачи принято отдельно выделять ее решения на уровне макро- и микропроцессов.
Макропроцессы определяют общие направленияразвития организации, выходя за пределы СЭД и сферы ее влияния. Будучидостаточно общими они слабо подвержены формализации, что придает имнеопределенный декларативный характер. Микропроцессы формализуемы,контролируемы и исполняемы.
Это соответствует принципу единства дальнихи ближних целей В.М. Глушкова. Данный принцип определяет совместноерассмотрение задач стратегии и тактики с целью получения максимальных успехов внастоящее время с учетом перспектив развития. Дальние и ближние цели отличаютсяне только временем до их реализации, но и принципом постановки. Ближняя цельдолжна быть видима и достижима. Ее триггер должен быть достаточно ясным, чтобыконстатация достижения была бесспорной, а дальняя цель — достаточно удаленной иуказывать скорее направление, чем конкретный путь реализации задач.
С одной стороны, ближние цели являеютсярезультатом декомпозиции дальних и являются составными частями будущегорезультата. В то же время, полная совокупность ближних целей не определяетполностью дальних. Надо сказать, что проблема неполноты составных частей поотношению к общему не является только частной проблемой СЭД, а есть общейметодолгической проблемой.
Эта ситуация отвечает принципукомплексности задач В.М. Глушкова. Суть его состоит в том, что большинствозадач являются комплексными и, поэтому, не могут быть сведены к простойарифметической сумме мелких задач. Поэтому и решать совокупностьдекомпозированных задач следует имея ввиду первоначальное целое. Иными словами,между задачами должно происходить постоянное взаимодействие, что превращает ихв комплекс, то есть в систему. Помимо этого, на передний план выдвигаютсяпроблемы системного подхода и анализа.3.1. Макропроцесс
СЭД, как и любая сложная программнаясистема, во многом обладает свойством живых организмов эволюционировать.Практика разработки и внедрения программных систем выявила феноменнепредусмотренного их использования. Пользователи, как правило, используютсистему не совсем так, как первоначально планировалось разработчики.
Казалось бы, проблема этого эффекта состоитв некорректной постановке задачи на стадиях анализа и проектирования.Разработчики, как правило перекладывают вину на пользователей, считая, что онинепониманиют основ построения сложных систем. Пользователи, в свою очередь,обвиняют в этом разработчиков, утверждая, что они взялись за постановку задачибез достаточной экспертизы и знаний в данной предметной области.
Таким образом, можно утверждать, что врезультате внедрения и эксплуатации система приспосабливается к пользователям,так же, как и пользователи приспосабливаются к системе. Невозможно сделатьсистему, которая была бы сразу полностью адаптирована к требованиямпользователей.
В этой связи можно привести следующийжитейский пример: нельзя сделать сразу разношенную обувь. Даже если сделатьобувь индивидуально и из самых мягких материалов, тем не менее какое то, пустьи короткое время, обувь при ходьбе будет вызывать некоторый дискомфорт. Онабудет разнашиваться до тех пор, пока нога к ней не привыкнет, а обувь, в своюочередь, примет удобную для ноги форму.
Пример с изготовлением индивидульной обувихорош, однако надо учитывать тот факт, что современному индустриальномуобществу характерны масштабные промышленные решения. Большинство обуви делаетсяна конвейере по стандартным размерам и стандартным моделям. Этот подходпозволяет уменьшить потребительскую цену, но делает обувь мене присобленной ккаждому конкретному потребителю, укладывая наши ноги в прокрустово ложестандартных размеров.
Опыт современных СЭД показывает, чтосистемы предпочтительно строить базируясь на промышленных решениях. Причинэтому много, но основная состоит в том, что для того, чтобы решения стали болееили менее пригодными, им надо пройти долгое тестирование многими миллионамипользователей. Этому требованию могут удовлетворять только те системы, которыевсемирно распостранены и имеют массовое использование.
Пострение СЭД на основе промышленныхрешений предопределяет использование разработчиком ограниченного наборафункциональных возможностей. Полученные путем компоновки решения неудовлетворяют потребностям конкретного пользователя, а являются лишьапроксимацией к ним. Система модернизируется неоднократно, каждый разприближаясь к индивидуальным требованиям. Для этого она должна быть достаточнооткрыта к последующей модернизации. Через несколько итераций адаптации ктребованиям пользователя наступает не только привыкание персонала к системе, нои более полное удовлетворение конкретных функциоанльных потребностей. Этосостояние характеризуется тем, что разработчики считают, что удовлетворили всезапросы пользователей, а пользователи думают, что, наконец-то, разработчики сделалито, о чем их изначально просили.
Описанная выше адаптация является не толькорезультатом переработки системы, но и результатом изменения обьектаавтоматизации и декларируемых им задач. В.М. Глушков называет это принципомновых задач. Создание информационных систем является инновационным процессом,внедрением новых технологий. Именно использование новых технологий во многомпредопределяет возникновение новых задач, которых не существовало прииспользовании старых технологий. Системы должны проектироваться с учетомвозникновения новых задач, которые возникают исходя как из сущности новыхтехнологий, так и расширения выполняемых функций.
Макропроцесс, в основном, обьединяетпроцессы в рекурсивном цикле и реализует общий эволюционный цикл доводкисистемы. Критерии выхода из этой рекурсии индивидуальны для каждого проекта и восновном определяются условиями договора между заказчиком и исполнителем.3.2. Микропроцесс
Описание микропроцесса опирается на понятие“жизненный цикл” СЭД, которое служит для определения начала разработки и концавнедрения СЭД. Наиболее удобным способом представления процессов реализацииСЭД есть представление совокупности процессов в виде проекта, как этоопределяется в стандарте PMBOK [6].
Жизненный цикл СЭД разделяют на следующиестадии: анализ, проектирование, реализация, внедрение и эволюция. В каждую изстадий входит значительное число процессов, которые обьединяются по принципуобщности отношений в СЭД. При этом под процессом понимается набор действий,приносящих результат.
Каждый из процессов может как одноразовым,так и многоразовым за время реализации жизненного цикла СЭД. Это свойствоопределяется рекурсивной природой создания сложных систем. При этом основныепроцессы отличаются от дополнительных тем, что они происходят как минимум быодин раз за время жизненного цикла.
Процессы взимодействуют между собой каклогичически, так и информационно. Логическое взаимодействие определяетпоследовательность происходящих событий, формирует устойчивую сетьвзаимосвязей. Информационное взаимодействие определяет информацию,циркулирующую в системе. Можно также говорить, что процессы связаныинформацией, которую они производят, так как результат или выход одногоявляется входом для другого.
Процессы являются не детерменированными последовательнымисобытиями, а чаще параллельными с пересекающимися активностями переменнойинтенсивности. Начало процессов обуславливается срабатыванием соответствующихтриггеров других процессов, находящихся в логической взаимосвязи с ними.Длительность процессов может быть достаточно длительной, что приводит к ихпрекращению вне зависимости от достижения цели, а по факту завершения проекта.3.2.1 Анализ
Основная задача анализа – установитьосновные функцмиональные требования к создаваемой системе, которые можновыявить на первичном этапе. В последствии, на основании выявленных требованийбудут строится первичные сценарии поведения, то есть воспроизводитсяпредполагаемая реакция системы на внешние раздражители.
Функциональные требования к системевырабатывются путем совместного рассмотрения требований ключевых участниковпроекта (stakeholders).
Как показала практика, успешность большого проекта восновном определяется мнением об этом факте достаточно узкого круга лиц. Можноопределить, что ключевые участники – это лица или организации активнововлеченные в проект, чьи интересы могут критично повлиять на успешностьпроекта. Они также могут быть не активно вовлеченными, ноосуществлять надзор и оказывать критичное влияние. Работу по выявлению ключевыхучастников важно начинать как можно раньше. Многие из участников долгое времяоставаются в тени, появляясь лишь тогда, когда по их мнению дела идут не в томнаправлении, как они себе представляли.
Требования, формируемые путем опросаключевых участников обычно являются противоречивыми. Конфликт интересов естьестественным состоянием любой организации при появлениинового элемента управления [7]. Наибольшую опасность представляют те ключевыеучастники, влияние которых недостаточно для принятия их мнения во внимание, но достаточнодля торможения, а то и блокирования проекта. Нахождение копромиссного решения иопределение балансов влияний есть слабоформализуемое и очень критичное звенопроекта по созданию СЭД.
Разрешение этой проблемы В.М. Глушковсформулировал в [4] как принцип первого лица: система должна заказываться,разрабатываться и внедряться под непосредственным контролем первогоруководителя предприятия. Практика проектов показывает, что всякая попыткапередоверить решение задачи второстепенным лицам приводит к тому, что созданнаясистема решает лишь второстепенные задачи организации. Такой результат являетсяочевидным, так как система создается на основании анализа требованийвторостепенных руководителей, которые видят перед собой соответственновторостепенные цели.
В качестве первичного продукта анализаможет служить созданный прототип будущей системы. Прототипы служат для раннегообнаружения “тонких мест” и неудачных решений, закладываемых в базиссоздаваемой системы. Гараздо лучше обнаружить это и закладываемые риски в самомначале, чем потом исправлять их в уже эксплуатирующейся системе.
При этом различают два основных видапрототипов систем – пилотного и модельного типов. Эти прототипы имеют разноепредназначение и поэтому отличаются способом и целью их реализации.
Пилотный прототип является точнымвоспроизведением одной из функциональных частей системы. В нем используютсяпромышленные решения, которые будут использованы в рабочей системе. Цельюпилотного проекта является показать или проверить какие-то техническиерешения, которые являются ключевыми и в корректности реализации которых имеютсясомнения.
Модельный прототип является уменьшеннойкопией системы или ее части. При реализации модели могут использоватьсятехнологии, отличные от планируемых. Целью модели является получение общегопредставления о функционировании будушей системы и выработка понимания сутипроекта у ключевых участников.
Несмотря на важность прототипа дляуспешности выполнения проекта в целом, очень важно, чтобы прототип не былэволюционирован в промышленную систему. К сожалению, использование прототипов вкачестве промышленного решения очень распространено. Это связано с тем, чторуководители, увидев прототип и в целом оценив его полезность, часто принимаютрешение о внедрении прототипа и прекращении дальнейшего доростоящего процессаразработки. Тем не менее, надо понимать, что прототип хоть и является наглядным(что собственно и является его основной задачей), строился совершенно не дляэксплуатации. В результате, будучи успешным и экономным решением в начале, он,в большинстве случаев, потребует дальнейшей дорогостоящей модернизации, что витоге значительно превысит первоначальную планируемыю стоимость системы. Приэтом становиться реальностью поговорка “скупой платит дважды” и остановка разработкискорее всего приведет как к утрате первоначальных целей, так и к потереинвестированных средств.
Вторая задача анализа – дать описаниесистемы, причем такое, чтобы оно было насколько возможно полным,непротиворечивым, пригодным для восприятия и модификации, измеряемым иуправляемым.
На стадии анализа анализируется выбраннаясистема из реального мира, для которой будет построена формальная модель.Анализ в основном сосредоточен на изучении поведения реальной системы, инымисловами, уделяется основное внимание тому, что делает система, а не тому какона это делает.
Поведение системы можно описать с помощьюсценариев, которые характеризуются точками ее устойчивых состояний. Точкиобозначают хорошо видимые извне и поддающиеся проверке и измерению элементыповедения системы.
Такие точки, выявленные на стадии анализа,будем называть функциональными точками системы. В этих точках задачи наиболеепросто формализуются, их синтезирование не представляет значительных трудностейс точки зрения применяемых технологий.
С точки зрения пользователя функциональнаяточка представляет некоторое простейшее действие системы в ответ на некоторыйпростейший “раздражитель”. В простейшем виде можно считать, что функциональнаяточка представляет отдельную бизнес- функцию конечного пользователя.
С точки зрения аналитика функциональныеточки представляют собой кванты поведения системы. Таким образом,функциональные точки являются мерой сложности системы и чем их больше, темповедение системы более сложное.
Семантика поведения системы, то естьсемантика функциональных точек, задается сценариями. Каждый сценарийпредставляет одну функциональную точку. Первичные сценарии используются дляиллюстрации ключевого поведения, вторичные – для описания поведения висключительных ситуациях.
Если воспринимать моделируемую систему и еевнешние раздражители как совокупность сложноорганизованных обьектов, описаниевзаимодействия которых дает в качестве результата формальнуюмодель, то такое восприятие отвечает системному анализу обьекта и системы управленияим, названное В.М. Глушковым принципом комлексного (системного) подхода [4].
На стадии анализа целесообразно выделяють участки, наиболее пригодные для автоматизации. Начинатьследует с наиболее простых участков, так как удачное начало проекта во многомпредопределяет дальнейшее удачное продолжение и завершение. Такие участкихарактеризуются прежде всего высоким уровнем готовности персонала, подходящимтехническим оснащением и заинтересованностью руководства в работе данногоучастка.
Считается полезным также привлекать службукачества организации (предприятия) для работы по разработке сценариев. По сутиименно сравнение сценариев с реальным поведением системы определяет качествополученной модели, то есть ее адекватность системе из реального мира.
Полученные в результате анализа данныеобьединяются в один формальный документ, который формулирует требования ксистеме, полученные в результате анализа — Техническим Задание на СЭД.3.2.2. Проектирование
Основная задача проектирования – созданиеархитектуры будущей системы и разработка плана достаточного для последующей еереализации и внедрения. Процесс проектирования целесообразно начинаеть сразупосле построения некоторой приемлимой формальной модели.
На стадии проектирования описанные функциональныеточки обследуются не только аналитиком, но уже и архитектороми технологом. Совместная работа этих специалистов дает архитектуру системы,описанную в проектных решениях.
При этом не следует начинать проектированиецентральных узлов до окончания этапа анализа, в тоже время нельзя затягиватьначало проектирования в ожидании завершении этапа анализа. Построение модели,будучи процессом итеративным, может последовательно уточнять модель поведениясистемы, пытаясь получить в определенном смысле идеальную, а, следовательно, вбольшинстве случаев недостижимую модель. Такая ситуация классифицируетсяпрактиками как паралич анализа.
При проектировании полезно закладыватьвозможность реализации максимального количества функциональных потребностей,выявленных при анализе. При этом целесообразно иметь несколько разных решенийдля одной и той же задачи. Такой подход назван В.М. Глушковым принципомфункциональной избыточности [4].
Пользователи часто используютсистему не совсем так, как это предусматривали разработчики. Поэтому важно,чтобы проектируемая архитектура содержала достаточные возможности адаптации.Жестко определенные функциональные возможности потенциально предопределяютпоследующие конфликты во время внедрения и эволюции системы. Желательно, чтобысистема имела функциональный модуль, либо модули, которые прозволяютпроизводить изменение конфигураций функционирования. Таким образом,пользователь может получить некий каркас, “обшитый” устойчивыми решениями и впоследующем произвести адаптацию исходя из реалий эксплутации. Этосоответствует тому, что В.М. Глушков формулирует как принцип гибкости системы[4].
Другой стороной описанной адаптивнойспециализации является типизация. Современное программное обеспеченияизготавливается в крайне сжатые сроки с учетом ограниченных требованийпостановщиков. Ушли в прошлое времена, когда система годами отлаживалась дозапуска в промышленную эксплуатацию. В тоже время безответственным иавантюристичным является построение серьезных и сложных систем, опираясь лишьна надежду и необоснованную уверенность в том, что они будут работать.
В рамках АСУ В.М.Глушков описал решениеданной проблемы как принцип разумной типизации. Выходом является построениеиндивидуальных систем из модулей хорошо отлаженных промышленных систем. Этосоответствует использованию крупноблочной сборки, где крупные блоки самиявляются системами, либо подсистемами, используемыми в промышленнойэксплуатации миллионами пользователей. Применение в качестве каркаса“доморощенной” системы приводит к получению закрытогосложноадаптируемого решения, что, в итоге, делает решение краткосрочным, что, всвою очередь, приводит к потере инвестированных в него ресурсов.
Рациональное отношение к потребляемымресурсам требует также использования совместимых решений. Под совместимымирешениями понимается возможность взаимодействия различных уровней системы длядвижения информации.
На эту проблему обратил внимание В.М.Глушков в [4] и определил это как принцип единства информационной базы.Информация, которая образуется на разных уровнях системы, используется поразному для решения разных задачи. Для этого необходимо использовать интерфейсыв том смысле, как это понимается в обьектно- ориентированном проектировании.Использование множественных интерфейсов для обработки единого информационногомассива позволяет удовлетворять множественные запросы пользователя и в тожевремя сохранить целостность данных. Таким образом, в нашей технологии принципВ.М.Глушкова дополнен полиморфизмом представления данных, что позволяет решатьсовременные задачи, характеризующиеся большими обьемами и слабойдетерминированностью.
Одна из основных задач – создание“правильной” архитектуры будущей системы, которая обеспечит ее концептуальнуюцелостность. Стратегическое направление обеспечивается целенаправленнымтактическим движением. Архитектура должна обеспечивать баланс междустратегическим и тактическими решениями.
Идеальная архитектура в основномнедостижима, но можно достаточно четко описать свойства, присущие сильнойархитектуре:
- Архитектура представляет собой многоуровневуюсистему абстракций. На каждом уровне абстракции взаимодействуют между собой поформализованным протоколам. Абстракции имеют четкие интерфейсы для внешнегомира и основываются на хорошо продуманной реализации.
- Система абстракций имеет слабое зацепление,функциональную связность, достаточность, полноту и предельную примитивность.
- На каждом уровне интерфейс абстракций строгоограничен от реализации. Реализация может быть изменена, при это интерфейсдолжен остаться неизменным. Таким образом, изменяясь внутренне абстракциипродолжают соответствовать внешним ожиданиям, то есть своему протоколу.
- Архитектура проста в понимании, прозрачна иприспособлена к масштабированию.
Вторая задач проектирования – разработка исогласование детального плана реализации и внедрения. В современных условияхзадачи всегда реализуются в ограниченные сроки и при ограниченных ресурсах. Этосвязано с тем, что пользователю не нужно решение, которое займет большевремени, чем у него отведено и не нужно решение, которое потребует ресурсовбольше, чем он может выделить.
Разработка плана – это процесс созданияцелостного и непротиворечивого документа, который может быть использован дляисполнения и контроля. Фактически в плане описываются с большей или меньшейстепенью детализации действия и мероприятия, которые будут реализованы настадии реализации и внедрения.
Процесс разработки плана имеет итеративнуюприроду и движется от первоначального черновика, содержащего грубые оценки посрокам и ресурсам, к конечному списку работ с определенными стоимостями исроками. В процессе разработки плана получается упорядоченный список работ,который называют Иерархической Структурой Работ — ИСР (WBS – Work BreakdownStructure) [5].
Каждый элемент ИСР ставится в соответствие свойствам иресурсам, необходимым для выполнения данного элемента. В частности, элементусоответствуют сроки, стоимость и квалификация персонала.
Поскольку ИСР является результатомдекомпозиции конечного результата с точки зрения достижения цели, то списокработ является конечным и полным. По сути выполнение всех работ,предусмотренных в плане означает достижение цели проекта, то есть создание СЭД.
3.2.3. Реализация
На стадии реализации на основании проектаизготавливается конкретная программная реализация. Таким образом, из общейформальной модели получается конкретная формальная модель. Конкретная модельявляется функционально подобной системе реального мира, то есть реализовываетсценарии ее поведения.
По сути реализация является лишьисполнением плана, разработанного на стадии проектирования. Именно на стадиюреализации приходится большая часть времени от общего времени проекта. Большаячасть ресурсов затрачивается, как правило, тоже на стадии реализации.
Исполнение плана – это координацияперсонала и управление потреблением ресурсов с целью достижения поставленнойцели. Персонал проекта включает в себя персонал заказчика и сотрудниковзаказчика, которые при этом не только консультируют, но и обучаются.
Исполнение необходимо постоянно сравниватьс планом, выявляя отклонения. Как правило, все планы выполняются сотклонениями. Создание идеального плана невозможно, следовательно,возникновение отклонений неизбежно. Если даже удалось создать план, которыйобеспечит нужный результат, то все равно за время разработки, как правило,происходит изменение первоначальных требований клиента, что приводит кизменению плана.
Отклонения анализируются с точки зрения ихпозитивного или негативного влияния на вероятность достижения цели. Изменения,реализация которых будет иметь позитивное влияние называются возможностями,негативное – угрозами. Управление рисками в реализации сводится к мониторингупроцесса с целью уменьшения угроз и увеличения возможности. Основнымихарактеристиками рисков является вероятность и степень их влияния в случаевозникновения.
Реализация есть итеративный процесс, накаждой итерации которой возникает некоторое приближение – модель, поведениекоторой все больше и больше соответствует описанным сценариям. Степеньреализованности сценариев определяет адекватность модели. Промежуточные моделипринято называть релизами или версиями. Важно обеспечивать приемственныйхарактер измененений, так как более успешным всегда являлся эволюционныйподход, а не революционный. Необходимо помнить, что процесс устранения ошибокесть процесс внесения новых ошибок и каждая модернизация системы, кромеположительных последствий, обязательно будет иметь и негативные.
Имеет смысл некоторые участки реализациизапускать в пробную эксплуатацию еще на стадии разработки. Это позволяетвыявить несовместимые решения, принятые на этапе проектирования и изменитьпроект и его реализацию до стадии внедрения, тем самым избежав значительныхфинансовых, временных и людских затрат.3.2.4. Внедрение
На стадии внедрения происходит установка изапуск изготоволенной программной модели в промышленную эксплуатацию. Этастадия, как отмечалось выше, характеризуется сильным сопротивлением персонала.Люди, в своем большинстве, опасаются внедрения систем автоматизации, подозреваягрядущее увеличение обьема работа и возможное их увольнение.
На этой стадии важно продемонстироватьперсоналу, что система является их помощником, а незаменой. Для это полезно совмещать электронные и неэлектронные части рабочихпроцессов на одних и тех же исполнителях. То есть документ в своем физическом ивиртуальном движении обрабатывается одним и тем же участником. В.М. Глушковназывает это принципом совмещения подготовки документов [4]. В современныхсистемах документооборота редко встречается бумажная форма не имеющая электронногосоответствия и наборот. Поэтому имеет смысл во всех точках, где создаютсябумажные документы, предусмотреть возможность инициации в системе ихэлектронного аналога.
При внедрении всегда встает вопрос оначальном наполнении системы. Редко встречаются случаи, когда СЭД создается всамом начале деятельности организации и ее использование не требуетзадействования накопленных больших обьемов бумажных документов. Чаще всего привнедрении рассматривается вопрос поэтапного ввода в систему документов, преобразуемыхк новым электронным форматам. Причем часто вырабатывается решение в котором вСЭД используется только электронный каталог, содержащий ссылка на местохранения бумажных документов.
Сложность этого вопроса определяется темфактом, что самые большие проблемы информационных систем возникают в звеневзаимодействия человека и компьютера. Представления человеческое и машинноесильно отличаются друг от друга и процесс преобразования от одного вида кдругому технически сложный и неоднозначный. В.М. Глушков называет это принципомминимизации ввода- вывода. Это обьясняется тем, что, именно, на процессахввода- вывода возникает наибольшее число ошибок и происходят самые невероятныесбои.
Внедрение должно быть реализовано такимобразом, чтобы возможности вернуться к старой системе уже не существовало. 3.2.5. Эволюция
Системы электронного документооборота ипредмет их автоматизации, как уже отмечалось выше, обладают некоторымисвойствами живых организмов, в частности эволюционировать. За время разработкиСЭД его предмет значительно изменяется, при этом часто менются декларируемыецели и поставленные задачи. Во время внедрения система становится непохожей нату модель, которую разрабатывали при проектировании.
Эволюция – одна из самых длительных иопределяющих стадий создания СЭД. Можно определить стадию эволюции, как периодс момента начала внедрения и до окончания использования системы хотя бы однимучастником. За это время система до неузнаваемости меняет свои интерфейсы иреализацию, и, зачастую, о приемственности можно догадаться только по названию.
Именно на стадии эволюции появляетсяпродукт, который отвечает реальным интересам пользователя. Это связанно с тем,что, в промышленной эксплуатации пользователь определяет какие функции нужноразвить, а какими — пренебречь. Поэтому важно, чтобы система была открытой,простой к пониманию и модернизации.
Это формулируется принципом постоянногоразвития, который состоит в том, что и программная и реальная системы находятсяв постоянном развитии, поэтому необходимо обеспечить синхронность этихпроцессов. СЭД должна развиватся вместе с организацией, чтобы инкапсулированнаяна этапе внедрения система стала естественной и неотьемлимой частьюорганизации.
4. Выводы
В статье предложена интегрированная методология реализациикомпозитных систем документооборота, которая обьединяет в себе, обогатив ихновым содержанием, три базовых подхода: принципы проектирования АСУ В.М.Глушкова, обьектно- ориентированный подход при реализации программных продуктови принципы управления проектами PMBOK
В соответствии с принципом смешанного экстремума [1] целесообразно композитное сочетание электронного ибумажного документооборота, что делает практическое использование системы болееэффективным и уменьшает сопротивление персонала при ее внедрении.
Изложенный подход к улучшению функционирования системдокументооборота соответствует, так называмому, стратегическому подходу Р.Беллмана [8]. Когда вместо того, чтобы строитьоптимальную последовательность решений от фиксированного состояния системы,определяется оптимальное решение любого состояния системы. Такой подходприводит к апроксимациям в пространстве стратегий в том смысле, что каждоепоследующее приближение улучшения функционирования системы, улучшает результатпреидующего.
Принятый достаточно высокий уровень абстракции делаетметодологию справедливой для широкого круга задач. В то же времясформулированные в статье принципы служат каркасом, который позволяет принаращивании сохранить целостность предложенной модели.
Разработка теоретических основ композитного документооборотаявляется крайне актуальной для современного управления тематикой и открываетперспективы для дальнейшего теоретического развития и практического внедренияполученных результатов.
Данная методология может быть использована в качестве базисадля разработки нормативной базы СЭД отраслей и предприятий.
5. Список литературы
1. Теслер Г.С. Принцип смешанногоэкстремума как основа эволюции вычислительных средств. Математические машины исистемы. 2002. №1. С.3-13.
2. Закон України про електронні документи таелектронний документообіг. Опублікований Відомості Верховної Ради (ВВР), 2003,№36, ст. 275
3. Engelbart, D.C. «A Conceptual Framework for theAugmentation of Man's Intellect.» London: VI Spartan Books, 1963.
4. Глушков В.М. Введение в АСУ. К: Техніка,1972. – 312 с.
5. Booch Grady.Object- Oriented Analysis and Design with Applications. Third Edition.Addison-Wesley. 1993.
6. Project Management Institute. A guide tothe Project Management Body of Knowledge. 2000.
7. Engelbart D.C.Toward Augmenting the Human Intellect and Boosting our Collective IQ.,Communications of the ACM, 38: 8 (August 1995), pp. 30-33
8. Беллман Р. Теория регулирования // Сб.Математика в современном мире. – М: 1967. – 173с.
Краткие сведения об авторе:
Круковский Максим Юрьевич, в 1994 году окончил кафедрусистем автоматизированного проектирования факультета электронной техникиКиевского Политехнического Института в 1994г по специальности инженер-системотехник.
С 1994 по 2003 работал в организациях над созданием системподдержки производственных процессов, в частности, систем электронногодокументооборота. В 2003 перешел на работу в ИПММС для реализации своегонаучного потенциала.
Область научных интересов: системы электронногодокументооборота, системы групповой работы, создание теоретической основы ипрактических решений для развития отечественных решений групповой работы.
АННОТАЦИЯ
В статье рассмотрена существующая отечественная и зарубежнаяпрактика по созданию систем электронного документооборота (СЭД). Задачадекомпозирована на совокупность активностей в виде описанных процессов,образующих систему взаимодействующих элементов. Для улучшения управляемостивзаимодействие разделено на макро- и микроуровень.Теоретической основойметодологии являются принципы создания АСУ В.М. Глушкова, принципы обьектно-ориентированного проектирования Г. Буча, принципы управления проектами PMBOK и принцип смешанного экстремума Г. Теслера. Данныепринципы обьеденены в гармоничную общность, обогатив друг друга новымсодержанием. Научная ценность статьи состоит в практическом примененииметодологии к решению задач современного управления. Полученная методология можетбыть использована как для создания систем, так и при разработке стандартовСЭД.
В статті розглянута існуюча вітчизяна таіноземна практика щодо створення систем електроного документообігу (СЕД).Задача декомпозована на сукупність активностей у вигляді описаних процесів, щостворює систему взаємодіючих елементів.
The article observes existent domestic andforeign expertise in developing and usage of system electronic documentflow.Methodology as a solution was presented by complex of activities with strictdefined processes that forms a system of interactive elements. To achieveappropriate control level interactions were separated to macro- and micro-level. Theoretical basis of the methodology is formed by principles of ACMsystems of V.M. Glushkov, principles of object oriented design of G. Buch,principles of project management from PMBOK and principle of mixed extremum G.Tesler. All that principled were consolidated value added as a harmonicalliance. Scientific value of this article is in practical solution provided tomodern management problems. This methodology can be used as a practical guidein creating documentflow systems as well as in developing and implementingdocumentflow regulations.