Александр

Добрый день!
описанный процесс в той или иной мере описывает достаточно большую долю деятельности компании
но его надо моделировать именно в Документообороте чтобы ответить на вопрос а что именно в типовой конфигурации позволяет реализовать хотелки и есть ли функциональные разрывы для нивелирования которых надо будет делать доработки.

Лично я бы я бы рассматривал предлагаемый процесс как несколько процессов в программе а не один.
процессы и документы безусловно влияют друг на друга и могут быть основанием для последующих процессов.
процесс надо дробить на несколько (3-4) связанных друг с другом. про доступ и безопасность в Тз вообще ни слова но при реализации вероятно будут уточнения.

почему несколько ?
потому что большой процесс тяжелее отлаживать , искать в нем ошибку.
простые процессы более логичны понятны.
Вам эту систему поддерживать и сопровождать - это должно быть просто и понятно Для Вас.

по поводу ценообразования и количества часов - скорее всего это будет дороже 6 тыс долларов и дольше 3 месяцев работы опытного программиста / команды специализирующейся на ДО.

просто что бы провести нормальное предпроектное обследование - задать множество Вопросов Вам , Выявить потребности Бизнеса и наложить их на функциональные возможности типового Документооборота , те просто чтобы сформировать черновое и самое простое предложение это уже работа смело от 40 часов.

я про то что Выходя на рынок услуг с такими схемами надо иметь готовность платить, причем внедрение документроборота это львиная доля работы консультанта и методолога а их работу обычно склонны не дооценивать.

у меня например после работы Методолога всегда остается чувство того что это все мог сделать я сам просто чуть дольше разбирался бы , или например силами штатных специалистов отдела разработки "потихоньку этого слона мы бы съели по частям самостоятельно".

Могу порекомендовать несколько Московских команд.

Любич Александр.