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

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

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

Допустим, в простейшем примере, мы (пользователь А) являемся инициатором задачи и отправляем ее на выполнение, согласование, утверждение (пользователю Б). Все замечательно — задача приходит. Уведомление отправлено. Пользователь Б — выполняет задачу и все замечательно. Но все это великолепие хорошо — только если в компании работает человек 10-20 и все друг друга знают визуально да еще и поименно. Но если же в компании на балансе околачивается сотрудников эдак 900, а то пара тысяч?.. И я понятия не имею как кого зовут, но зато как любой боец офисного фронта, на интуитивно офисном уровне, прекрасно понимаю какие есть логические должности и кто находится выше и ниже меня. Особенно если сотрудник заболел, уволился, умер или просто отчалил в страны с более заманчивыми климатическими условиями. Поэтому я не обязан знать имен, мне достаточно подшлемным пространством — только предсттавлять какие есть должности. Это несравнимо проще и удобнее.

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

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

2. Второй подводный камень — это отсутствие в Sharepoint какой либо внятной системы построения маршрута процесса в конкретном моменте какими то простейшими, понятными любому пользователю средствами. Само собой Sharepoint Designer и Visual Studio — это незыблимая твердыня с помощью которой можно все. Но мы то говорим о простых эксплуатантах системы… Поэтому остается либо вариант с предустановленной настройкой маршрутов процессов, либо сторонние конструкторы проде Nintex (может буквально все, разве что только картошку не чистит, но стоит безбожно, к тому же требует серьезных навыков построения ), либо использование совсем уж простых маршрутов, что то вроде из пункта А в пункт Б. Ну в общем не суть.

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

То есть функционально — работает совершенно просто:

Стартовав процесс утверждения документа, сотрудник указывает срок утверждения, а также выбирает один из предварительно спроектированных маршрутов утверждения документа.

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

Далее — выставляеv все требуемые шаги и запускает процесс.

Полный размер здесь

И все — процесс побежал! Просто и красиво:) Если маршрут один из постоянных — можно его не набивать каждый раз, а просто сохранить. А если требуется что то новенькое — то указываем динамически с изменениями.

Автор: anigillator

Источник