Рабочие процессы в шарике для документооборота: стандартные и не очень

    Доброго времени суток, уважаемые хабровчане!

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

    В этой статье хочу кратко описать основные известные мне способы создания рабочих процессов в Sharepoint, и, в качестве дополнительной темы – то, как это можно сделать в одном из прикладных решений — EOS for Sharepoint. Тематика рабочих процессов – документооборот.

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

    1. Использование встроенного в Sharepoint бизнес-процесса утверждения (три этапа)
    2. Моделирование процесса в Sharepoint Designer
    3. Создание рабочего процесса в Visual Studio
    4. Создание рабочего процесса в решении EOS for Sharepoint

    Сознательно опущу здесь такие методы как написание Custom Activities + Sharepoint Designer, создания конструктора рабочих процессов в Visual Studio, использование логики в Infopath формах. Первый несущественно повышает логическую гибкость по сравнению с Sharepoint Designer, второй сложен в разработке, которая будет обоснована разве что при разработке собственных коробочных решений. Ну а формы InfoPath есть только в Enterprise-версии, желание покупать Enterprise есть не у всех.


    Рисунок 1 — Схема линейного согласования

    Очевидно, если автоматизируемый бизнес-процесс выглядит так, как на рисунке 1, то, с некоторыми оговорками, подойдет любой способ – дело только в целесообразности. Я бы использовал встроенный рабочий процесс + удобное оформление страниц и представлений списков.

    Но что делать, если процесс согласования выглядит так, как на рисунке 2? Здесь процесс согласования нелинейный, и маршрут зависит от нескольких условий.

    Рисунок 2 – Схема нелинейного согласования

    В отделе документационного обеспечения (2-й шаг), получив проект документа, могут решить, что в процесс требуется добавить дополнительных согласующих. Кроме того, на согласование к финансовому директору проект должен направляться только при условии, что сумма договора по проекту составляет более 900 000 рублей.

    По поводу возможных средств здесь ситуация выглядит иначе:
    1. Использование встроенного в Sharepoint бизнес-процесса утверждения

    Встроенный процесс не поддерживает ветвления, а значит для решения задачи не подойдет

    2. Моделирование процесса в Sharepoint Designer

    Если бы передо мной поставили условие смоделировать процесс в Sharepoint Designer, я бы, несколько ругаясь, написал что-то подобное тому, что изображено на рисунке 3.

    Рисунок 3 – Рабочий процесс в Sharepoint Designer

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

    Рисунок 4 – Настраиваемая задача в Sharepoint Designer

    Плюсы подхода:
    1. При некоторой подготовке, упорстве и наличии свободного времени, с этой задачей справится и грамотный менеджер или адекватный админ.
    2. Процесс можно перенастраивать.
    3. Возможность ограничения прав пользователя, создающего рабочий процесс.

    Минусы подхода:
    1. выглядит громоздко и непрозрачно.
    2. При большем количестве ветвлений придется рисовать схему рабочего процесса на листочке отдельно – по тому, как это выглядит в Sharepoint Designer, понять что-то сложно.
    3. В Sharepoint Designer 2010 циклы в рабочих процессах еще не придумали, поэтому перезапускать процесс в случае отказа не получится, по крайней мере очевидными методами.
    4. Большое количество дополнительных действий, которые не относятся к логике процесса.

    3. Создание рабочего процесса в Visual Studio

    Visual Studio позволяет создавать сколь угодно гибкие и сложные бизнес-процессы. Например, часть описанного выше процесса может выглядеть примерно так (Рисунок 5):

    Рисунок 5 – Фрагмент рабочего процесса Visual Studio

    Логикой можно управлять, используя циклы While, ветвления If-Else и ConditionalActivity (подробнее можно здесь http://msdn.microsoft.com/ru-ru/library/hh824675(v=office.14).aspx).

    Плюсы подхода:
    1. Высокая логическая гибкость
    2. Возможности .NET

    Минусы подхода:
    1. сложность реализации, внесения изменений.
    2. требуется программирование и права администратора фермы.
    3. Прозрачность только во время написания процесса и при серьезном документировании.

    4. EOS for Sharepoint

    Eos for Sharepoint – полноценная система электронного документооборота. Визуального редактора процессов здесь нет, но есть встроенный конструктор, который при ближайшем рассмотрении оказывается довольно мощным и простым в использовании. Так, процесс, описанный выше, состоит из последовательной настройки всех этапов (рисунки 6,7,8).

    Рисунок 6 – Выбор участников этапа


    Рисунок 7 – Условия запуска рабочего процесса

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

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

    Рисунок 8 – Настройка параметров рабочего процесса

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

    Вывод


    Выбор способа автоматизации бизнес-процессов Sharepoint зависит, по большей части, от его сложности. Если процесс очень простой – достаточно использовать стандартные средства. Если процесс сложный и разветвленный, реализация его логики в SPD или Visual Studio может оказаться длительной и сложной, в этом случае эффективнее будет применять сторонние средства, которые позволяют сосредоточиться на логике процесса, не вдаваясь в тонкости реализации.
    • –6
    • 17.1k
    • 5
    Электронные Офисные Системы
    49.30
    Company
    Share post

    Comments 5

      +3
      Когда вижу такие схемы в организации, мне становится интересно, когда же там успевают вообще что-то делать в перерывах между согласованиями и дополнительными согласованиями ?)
        0
        Да полно таких примеров, у большинства коммерческих структур схемы согласования договоров, слежебок, приказов, счетов могут быть супер извращёнными. В зависимости от суммы договора может идти то одному. то другому, и там уже решают, подписывать али нет. А по другому нельзя, это Вам не дизайнер ИП Сидоров. Без СЭДа в больших организациях полный швах делается, и договора теряются, и никто не согалсует их, никто не исполняет, или срывают сроки… вообщем бяда :)
          0
          Основная бяда с маркетингом СЭД компаний на хабре в нудности и заунывности статей. Дигдез вон вообще деактивировал свой аккаунт. Дамы и господа из eos_market сколько нужно получить минусов в статьи и карму, чтобы начать писать нормальные интересные для аудитории Хабра статьи? Выньте из глубин вашей компании нормального технаря, который напишет интересную вещь. Или последуйте за Дигдезом, просто стыдно за нашу отрасль. Гляньте, что пишут мобильные разработчики или геймеры, любо дорого читать.
        0
        спасибо, пишите еще.

        пара вопросов к рисунку 2:

        1. Как реализуется в ЭОС2SP при проектировании workflow задание условия, при котором проект должен направляется на согласование к финансовому директору либо нет?

        2. Как лучше формировать список сотрудников юр. отдела, которые могут согласовать: отдельная группа в AD или какой то список в SharePoint?

        доп. вопрос оффтопом:

        3. Можно ли сделать workflow, доступный для сотрудников всех подразделений, в котором на определенном этапе (например на 2) согласующим лицом будет непосредственный руководитель автора проекта (в зависимости от подразделения, изначально неизвестно кто), а дальше уже стандартно. Как это реализуется?
          0
          Привет! давай сам отвечу по системе:

          1. В настройках этапа есть возможность настройки логического условия (фильтра) по метаданным проекта. Если условие возвращает «ЛОЖЬ» — этап пропускается.

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

          3. Можно. В настройке типа участников этапа выбирается «роль из оргструктуры: подразделение», «сотрудник (поле документа)» – автор, «поле карточки подраздления» — начальник. В этом случае конкретный начальник в каждом случае вычисляется по оргструктуре в справочнике сотрудников и подразделений.

        Only users with full accounts can post comments. Log in, please.