Pull to refresh

Comments 5

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

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

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

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

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

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

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

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

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

Sign up to leave a comment.