Створення системи управління документами і бізнес-процесами: технологічні аспекти, Книги та статті, Різне, статті


Сучасна система автоматизації управління документами і бізнес-процесами, інакше кажучи, система автоматизації документообігу, являє собою складний комплекс ПЗ, до якого пред’являється безліч специфічних вимог. На відміну від традиційних облікових систем, які, по суті, являють собою комплекси спеціалізованих за профілем основної діяльності АРМ, система документообігу поєднує в собі підходи, як властиві класичним додаткам, так і відносно нові – і часом вельми специфічні. Наприклад, для автоматизації робочого місця секретаря-діловода використовуються технології, цілком відповідають традиціям звичайного АРМ, але при цьому при автоматизації ділових процесів компанії повинні бути реалізовані основні принципи процесної автоматизації. Вельми специфічні вимоги висувають до системи автоматизації документообігу та стандарти зберігання юридично значущих документів (MoReq, DoD і т.п.), які, очевидно, найближчим часом почнуть застосовувати і в нашій батьківщині. Ціла група вимог, пов’язаних з інтеграцією додатків, пред’являється до системи автоматизації документообігу в силу того, що реальні процеси компанії, як правило, не обмежуються обробкою документів, а захоплюють різні додатки інформаційної системи. І нарешті, можна говорити про абсолютно новому наборі вимог до системи автоматизації документообігу, що виникають у зв’язку з використанням системи в режимі хостингу, за моделлю Software as a Service. Всі перераховані аспекти змушують розробників вдаватися до різних технологічних інновацій, які ми і розглянемо в даній статті на прикладі функціональності нової версії системи DocsVision.


Механізми реінжинірингу бізнес-процесів


На відміну від традиційного бізнес-додатки, в якому можна виділити формальні рівні: логічний (рівень даних), рівень бізнес-логіки і рівень клієнтського інтерфейсу, – процесні програми будуються за іншими принципами. В силу того, що спочатку процесне додаток орієнтоване на постійну, безперервну модифікацію, його можна розділити на відносно незалежні компоненти – набори бізнес-об’єктів (Документів або облікових карток), бізнес-процесів їх обробки і звітів, в яких консолідована інформація, що зберігається в різних бізнес-об’єктах. При цьому кожен з компонентів процесного програми повинен володіти двома якостями – наявністю інструментарію для простої, бажано візуальної, розробки і модифікації налаштувань і ізольованістю (можливістю змінювати його, не зачіпаючи інші компоненти системи). Крім цих компонентів в системі повинен бути присутнім модуль, що забезпечує навігацію, який реалізує пошукові механізми та ініціалізацію дій користувача, а також засоби для ведення довідників. Таким чином, в системі з необхідністю повинні бути присутніми три типи конструкторів – бізнес-об’єктів (карток, документів, довідників), процесів і звітів (групових уявлень), а також кошти конфігурування персонального оточення користувача. До даних інструментів пред’являються такі основні вимоги:



Коротко зупинимося на тому, яким чином реалізуються дані конструктори.


Засоби швидкого конструювання рішень


Почнемо з коштів конструювання бізнес-об’єктів. По суті для реалізації даного інструменту є три варіанти:



Кожен з цих способів має свої переваги: ​​у першого способу це технологічність і відносна доступність кваліфікованих кадрів, у другого – поєднання гнучкості і можливості розробки без програмування, у третього – максимальна ступінь гнучкості і кастомізіруемості. Зрозуміло, є і недоліки – відповідно обмежена функціональність, низька технологічність і складність реалізації рішень. Для детального порівняння варіантів реалізації конструкторів бізнес-об’єктів потрібна була б окрема стаття, а тут як приклад конкретної реалізації даного інструментарію наведемо засоби, що використовуються в системі DocsVision.


Платформа DocsVision підтримує всі три описані можливості. Для створення бізнес-об’єктів системи можна використовувати готові редактори форм – Microsoft InfoPath, якщо в якості об’єктів використовуються XML-документи, або засоби розробки Microsoft Visual Studio for Application для обробки офісних документів. У системі є власний дизайнер форм для швидкої розробки форм об’єктів (рис. 1), якщо потрібно швидко сконструювати складні об’єкти, що використовують специфічні компоненти системи. І нарешті, в DocsVision реалізовані засоби моделювання бізнес-об’єктів (менеджер карток) і набір програмних компонентів для створення більш складних програм шляхом компіляції.


У новій (розробляється в даний момент) версії DoscVision 5.0 планується реалізувати нове середовище розробки бізнес-об’єктів, що сполучає в собі властивості перерахованих вище способів реалізації даної підсистеми. Новий дизайнер форм, з одного боку, дозволить без програмування описувати довільну структуру даних оброблюваного об’єкта, задавати його дизайн, описувати стану і граф переходів об’єкта між станами і рольову структуру прав доступу, а з іншого – дозволить програмно розширювати обробку будь-яких подій і використовувати додаткові програмні компоненти. На відміну від звичайного дизайнера форм, який по суті оперує наперед заданої схемою даних, що розробляється інструмент дозволить прив’язувати структуру форми до довільної наперед заданої моделі даних облікової картки документа.


Наступний рівень конструювання рішень на базі системи документообігу – дизайнер бізнес-процесів, або, як його прийнято називати, дизайнер WorkFlow. Практика реалізації такого інструментарію відрізняється великою різноманітністю підходів. Відсутність стандартів опису бізнес-процесів, а також відмінність підходів до структур моделювання базових бізнес-об’єктів призводять до того, що в кожній системі по суті існує власний підхід до реалізації цього дизайнера. Практично спільного між ними – лише сам факт наявності графічного дизайнера топології бізнес-процесу і підтримка двох загальних типів активностей (Функцій, елементів бізнес-процесів) відповідно до вимог WorkFlow Management Coalition (WfMC): функції ручної обробки (етап участі людини в бізнес-процесі) і серверних активностей (реалізованих за допомогою програмного коду). Інші компоненти Workflow, такі як типи спеціалізованих активностей, засоби опису змінних оточення процесу, нотація опису процесу, способи реалізації обробки подій, передачі інформації між етапами бізнес-процесу, опис засобів декомпозиції та взаємодії процесів, засоби передачі і отримання зовнішніх даних, реалізуються досить довільно.


В системі DocsVision використовується два інструментарію для опису структури бізнес-процесу (рис. 2). Перший – це дизайнер власної розробки, що включає розширюваний набір з півтора десятків спеціалізованих функцій, який максимально пристосований для обробки бізнес-об’єктів системи DocsVision і дозволяє реалізувати більшу кількість процесів обробки інформації без програмування, за допомогою візуального конструювання. При необхідності програмного розширення бізнес-процесів можна скористатися функцією Script, яка реалізує в рамках бізнес-процесу довільну програму, написану мовою C # або VB.NET. Дана програма буде виконуватися в контексті бізнес-процесу і мати доступ до його змінним і оточенню.


Другий інструмент – дизайнер, орієнтований на розробку бізнес-процесів на базі нотації і з використанням активностей Windows WorkFlow Foundation. Цей програмний протокол з’явився в складі. NET Framework 3.0 і по суті справи став стандартом для створення систем Workflow на базі Windows. Про підтримку даного стандарту заявили багато виробників промислових систем WorkFlow, і більшість розробників програмних комплексів мають намір в найближчому майбутньому випустити набори функцій для реалізації доступу до даних і функцій своїх додатків з процесів на базі протоколу Windows WF. Однак у сьогоднішній реалізації нотація і засоби розробки WF-процесів орієнтовані швидше на розробників, ніж на системних аналітиків та інженерів-внедренцев, що робить широке використання цього модуля кілька проблематичним.


У новій версії DoscVision 5.0 планується суттєво розширити використання протоколу Windows WF. Базовий дизайнер бізнес-процесу планується також перевести на цю платформу і забезпечити його повну сумісність з нотацією BPMN, поступово де-факто займає місце стандарту моделювання бізнес-процесів на базі Workflow. Для цього планується використовувати можливості розширення базового компонента дизайнера, що входить до складу бібліотек. NET.







Впроваджуйте СЕД DocsVision з меншими витратами! Компанія “Інтерфейс” спільно з DocsVision пропонує спеціальні умови по впровадженню системи електронного документообігу (СЕД) DocsVision. Детальніше “


Рольова і контекстна безпека


Інший дуже важливий аспект, що виникає при розробці реальних процесних систем, полягає в тому, що традиційних засобів управління правами доступу і безпекою в подібного роду системах виявляється зовсім недостатньо. Традиційний підхід до визначення прав доступу до об’єкта зводиться до розмежування доступу до окремих прикладних АРМ, причому доступ до тих чи інших об’єктів визначається бізнес-логікою, реалізованої в коді програми. Настроювальні механізми зводяться до двох сценаріїв – дискредитаційної (декларативним визначення обмежень прав доступу до об’єктів для користувачів і груп користувачів) і рідше мандатної (виділення рівнів доступу користувачів і об’єктів та надання відповідних прав згідно з політиками співвіднесення рівнів доступу).


Дані механізми управління безпекою не враховують динамічної природи об’єкта в його життєвому циклі. При створенні процесного додатки, якщо мати на увазі особливості його розробки та модифікації, розглянуті в попередньому розділі, необхідна можливість динамічного або контекстного управління правами доступу до об’єкта. При цьому найчастіше права доступу до об’єкта залежать від таких параметрів, як його зміст (наприклад, значення поля “виконавець” облікової картки завдання визначає, чи можна дати тому чи іншому користувачеві доступ до даного завдання), стан об’єкта (переклад документа в стан “Передано в архів” забороняє всі зміни його змісту всім користувачам), характеристики оточення (наприклад, робоче це чи неробочий час – для заборони доступу до інформації користувачам у неробочий час). Права доступу також можуть залежати від тієї чи іншої довідкової інформації, наприклад, від наявності ознаки “у відпустці” в довіднику співробітників компанії – для запобігання конфліктів при редагуванні документа співробітником і його заступником. Прикладів подібного роду завдань, при яких права доступу формуються не на підставі статично закріплених правил, а поточним контекстом його використання, при створення процесних додатків виникає безліч.


В DocsVision є спеціальний механізм настройки контекстної безпеки, який служить для розробки додатків (зокрема, він використовується в продукті “Адміністративне діловодство” на базі DocsVision). Даний механізм дозволяє при впровадженні системи визначити доступність або недоступність тих чи інших операцій обробки об’єктів для користувачів системи. Дані правила можуть бути закріплені як статично, на рівні довідника співробітників, так і динамічно, залежно від поточного контексту об’єкта (рис. 3). Правила визначення контексту формуються на підставі опису XML-запиту до вмісту об’єкта і значень параметрів оточення (часу, поточного користувача і т.п.)


У версії DoscVision 5.0 даний механізм буде істотно розширений, і права доступу, що визначаються контекстом, будуть застосовуватися не тільки до операцій, але і до даних об’єктів. Крім того, в поняття контексту буде включено поточний стан об’єкта. Дані поліпшення в платформі дозволять внедренцем реалізувати складніші сценарії, витрачаючи на це набагато менше зусиль, що істотно підвищить гнучкість використання системи.


Інтеграція процесів


Процесне додаток має ту особливість, що воно не автоматизує окремий етап робочого процесу, як більшість традиційних додатків, а орієнтоване на автоматизацію послідовності етапів в рамках зв’язкового бізнес-процесу компанії. При цьому, як показує реальний досвід автоматизації, процес звичайно не тільки охоплює дані різних додатків в рамках компанії, але і може зажадати виконання окремих операцій безпосередньо у відповідних додатках. Характерна риса бізнес-процесу – його вихід за межі інформаційної системи, що вимагає від засобів автоматизації інтеграції з електронною поштою та засобами обробки різних форм технологічного обміну. Типовий сценарій інтеграції процесів – переклад інформації в паперовий формат і назад, з паперу в електронний вигляд. Для гнучкої автоматизації подібного роду сценаріїв в системі документообігу повинні бути реалізовані ті чи інші механізми, які спростили б створення додатків, що автоматизують такого роду інтеграційні сценарії. При цьому завдання розробника системи документообігу зводиться до забезпечення інструментарію, який мінімізує програмування при їх розробці; більшість типових сценаріїв обробки інформації повинно реалізуватися шляхом інтерактивного налаштування шаблонів процесів. Нижче наведено приклади типових сценаріїв, які повинні підтримуватися подібного роду підсистемою:



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


В системі DocsVision є набір програмних шлюзів, що реалізують перераховані вище функції, які можуть бути включені в різні бізнес-процеси практично без програмування, для наступних додатків: “1С: Підприємство 8.0”, Microsoft Office SharePoint Server 2007, Microsoft Dynamics CRM, Microsoft Dynamics AX, Microsoft Exchange Server, файлова система Windows.


Найближчим часом планується випуск нового компонента системи, який дозволить включати в процеси обмін даними з довільним додатком, що використовують в якості сховища Microsoft SQL Server.


Організація хостингу додатків


Ще одна з сучасних тенденцій у створенні систем автоматизації документів і бізнес-процесів пов’язана з можливістю їх використання в режимі оренди на базі публічного хостинг-провайдера. Така модель використання ПЗ називається Software as a Service (SaaS). Незважаючи на обмежене її поширення в Росії, в цілому в світі подібний спосіб використання ПЗ стає все більш популярним, зокрема, і для бізнес-додатків, до яких відноситься розглянутий нами клас програмних продуктів. Свідченням тому є титанічні зусилля компанії Microsoft по висновку на ринок проекту Azure – програмної платформи для хостингу додатків в мережі. Очевидно, найближчим часом ця тенденція стане більш поширеною і в нашій країні, так як подібний спосіб використання ПЗ обіцяє величезні вигоди в плані скорочення вартості володіння системою в цілому.


Щоб систему управління документами і бізнес-процесами можна було використовувати в моделі SaaS, вона повинна відповідати таким основним вимогам:



Система DocsVision спочатку створювалася з орієнтацією на такий режим роботи. Сервер системи являє собою Web-сервер, що взаємодіє з клієнтом по протоколу SOAP / HTTP. Клієнтське робоче місце і всі додатки, що розробляються на базі платформи, є виконують у середовищі Microsoft Internet Explorer автоматично інсталюються програмні компоненти. Підтримується робота як в середовищі VPN, так і з публічного каналу доступу з використанням шифрування трафіку по протоколу HTTPS. Наявність розвинутої системи розмежування прав на всі модулі і компоненти системи дозволяє ізолювати окремі групи користувачів і реалізувати повноцінний режим MultiTenancy. Приклад реалізації програми в режимі SaaS можна подивитися на сайті live.docsvision.com.


У розробляється в даний момент версії DoscVision 5.0 планується реалізувати повнофункціональний крос-платформну легкий клієнт, що забезпечить додаткову гнучкість використання додатків на базі DocsVision в режимі хостингу.


Висновок


Ми розглянули лише окремі технічні аспекти реалізації сучасної системи управління документами і бізнес-процесами, хоча можна обговорити і інші завдання. Такі системи відносяться до одного з найбільш бурхливо розвиваються в даний час класів ПЗ, і очевидно, що в найближчому майбутньому нас чекають нові технічні ідеї в даній області.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*