44567

Создание инфосистем на основе системы автоматизации деловых процессов

Доклад

Информатика, кибернетика и программирование

Из зарубежных систем это в первую очередь ction Workflow фирмы ction Techologies и продукт фирмы Stffwre Inc. Работа workflowсистем как правило основывается на том что большая часть деловых процессов представляет собой периодически повторяемую отрегулированную последовательность действий выполнение заданий которая может быть легко формализована. Таким образом без всякого программирования можно за считанные минуты получить реально работающее workflowприложение. В некоторых workflowсистемах создание информационных моделей деловых...

Русский

2013-11-12

36 KB

0 чел.

16 Создание инфосистем на основе системы автоматизации деловых процессов

Сегодня существует целый ряд систем автоматизации деловых процессов (САДП), заслуживающих самого пристального внимания потребителя, который собрался проводить комплексную автоматизацию. Из зарубежных систем это, в первую очередь, Action Workflow фирмы Action Techologies и продукт фирмы Staffware Inc., который так и называется Staffware; из отечественных — ничуть не уступающая зарубежным конкурентам система WorkRoute компании ВЕСТЬ АО, получившая признание на западном рынке.

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

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

Карта делового процесса создается, а обычно просто рисуется мышью с использованием нескольких графических примитивов и затем может быть легко изменена. Таким образом, без всякого программирования можно за считанные минуты получить реально работающее workflow-приложение. В некоторых workflow-системах создание информационных моделей деловых процессов возможно только с помощью программирования, что представляет собой довольно кропотливый процесс, требующий к тому же специальных знаний. Так, в Action Workflow программирование используется для разработки электронных форм, которые являются неотъемлемой частью бизнес-модели, обеспечивая взаимодействие системы с пользователем на этапах делового процесса.

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

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

Следует помнить, что значения переменных, в идеале, должны считываться не только из базы данных workflow-системы, но и из баз данных прикладных программ, поддерживающих наиболее распространенные промышленные стандарты СУБД. Это позволяет интегрировать систему автоматизации деловых процессов с внешними приложениями в разрезе совместного использования данных. Что же касается встроенного языка программирования, о котором выше уже шла речь, то к нему, вполне очевидно, предъявляются такие требования, как простота (например, он должен быть семантически совместим с каким-либо распространенным языком — на сегодняшний день предпочтительнее всего VBA), эффективность, наличие широких возможностей по управлению деловыми процессами и связанными с ними данными. Крайне желательно, чтобы скрипт мог работать с OLE-серверами, запускать внешние программы, взаимодействовать с MAPI-совместимыми почтовыми системами. Кроме того, учитывая, что workflow-система рассматривается нами как основа КИС, для получения полной интеграции с другими программами и облегчения этого процесса, скорее всего, потребуется наличие открытого программного интерфейса API, который бы позволил управлять системой из внешних программ.

Международной организацией, курирующей разработку стандартов и спецификаций на системы класса workflow, является Workflow Management Coalition (WfMC). Теперь, после небольшого отступления, вернемся к проблеме построения КИС на базе системы автоматизации деловых процессов.


 

А также другие работы, которые могут Вас заинтересовать

31128. Процесс руководства проектом и планирование проектных задач 17.3 KB
  Анализ риска. Исследование области неопределенности анализ ее влияние на проект. Первыми выполняемыми задачами являются системный анализ и анализ требований. Системный анализ проводится с целью: 1 выяснения потребностей заказчика; 2 оценки выполнимости системы; 3 выполнения экономического и технического анализа; 4 распределения функций по элементам компьютерной системы аппаратуре программам людям базам данных и т.
31129. Модели качества процесса конструирования. Архитектура программных систем 41.02 KB
  Архитектура программной системы ПС это набор внутренних структур ПС которые видны с различных точек зрения и состоят из компонентов их связей и возможных взаимодействий между компонентами а также доступных извне свойств этих компонентов. Вид с точки зрения прецедентов Use cse view охватывает прецеденты которые описывают поведение системы наблюдаемое конечными пользователями аналитиками и тестировщиками. Вид с точки зрения проектирования Design view охватывает классы интерфейсы и кооперации формирующие словарь задачи и ее...
31130. Базис языка UML 249.01 KB
  Словарь UML образуют 3 разновидности строительных блоков это предметы отношения и диаграммы. Предметы это абстракции основные элементы в модели отношения связывают предметы а диаграммы группируют коллекции предметов. Структурные предметы это существительные в UML моделях статические части. Предметы поведения Предметы поведения это динамические части глаголы модели поведение объектов во времени.
31131. Унифицированный процесс разработки программных систем 45.19 KB
  Прецеденты должны быть основным артефактом на основании которого устанавливается желаемое поведение системы проверяется и подтверждается правильность выбранной системной архитектуры производится тестирование. Системная архитектура является решающим фактором при разработке концепций конструировании управлении и развитии создаваемой системы. Итеративным называется процесс который предполагает управление потоком исполняемых версий системы. Разработка стабильной базовой архитектуры продукта которая позволяет решать поставленные перед...
31132. Основы объектно-ориентированного представления программных систем 169.01 KB
  Сцепление модулей. Сцепление это мера взаимозависимости модулей по данным внешняя характеристика модуля которую желательно уменьшить. Измеряется сцепление степенью сцепления. Выделяют 6 видов степени сцепления: Сцепление по данным; Сцепление по образцу; Сцепление по управлению; Сцепление по внешним ссылкам; Сцепление по общей области; Сцепление по содержанию.
31133. Статические модели объектно-ориентированного представления программных систем 142.29 KB
  Диаграмма классов это набор классов и связей между ними. Диаграммы классов используются: в ходе анализа для указания ролей и обязанностей сущностей которые обеспечивают поведение системы; в ходе проектирования для фиксации структуры классов которые формируют системную архитектуру. Отношения в диаграммах класса. Ассоциации отображают структурные отношения между экземплярами классов.
31134. Динамические модели объектно-ориентированного представления программных систем: автоматы 336.98 KB
  Динамические модели обеспечивают представление поведения системы путем отображения изменения состояний в процессе работы системы в зависимости от времени. Автомат описывает поведение в терминах последовательности состояний через которые проходит объект в течение своей жизни. Диаграмма схем состояний отображает конечный автомат выделяя поток управления от состояния к состоянию. Конечный автомат поведение определяющее последовательность состояний в ходе существования объекта.
31135. Динамические модели объектно-ориентированных программных систем: диаграммы взаимодействия Use Case 14.52 KB
  Диаграмма сотрудничества это диаграмма взаимодействия выделяющая структурную организацию объектов посылающих и принимающих сообщения. Иначе диаграмму сотрудничества называют диаграмма кооперации. Диаграмма последовательности это диаграмма взаимодействия отображающая сценарий поведения в системе и обеспечивающая более наглядное представление порядка передачи сообщений. Графически диаграмма последовательности это разновидность таблицы которая показывает объекты размешенные вдоль оси икс и сообщения упорядоченные во времени вдоль оси...
31136. Модели реализации объектно-ориентированных программных систем 34.82 KB
  Модели реализации обеспечивают представление системы в физическом мире рассматривая вопросы упаковки логических элементов в компоненты и размещения компонентов в аппаратных узлах. Рисунок 1 обозначение компонента Сходные характеристики: наличие имени; реализация набора интерфейсов; участие в отношения зависимости; возможность быть вложенными; наличие экземпляров экземпляры у компонентов только у диаграмм размещения № Описание различий 1 Классы логические абстракции компоненты физические предметы. 2 Компоненты являются...