Сейчас внедряю документооборот в крупном производственном холдинге. На этапе анализа требований выяснились 2 вещи.

1) Мы не доросли до BPMS типа Unify - в Киеве ОЧЕНЬ большой дефицит спецов по Java вообще, и вообще нет спецов по Unify или хотя-бы по JBPM в-частности. А раз так - высшее руководство решило не рисковать с самостоятельным внедрением.
2) Мы переросли "классический" документооборот типа DocsVision - в нем напрямую нельзя производить экономические расчеты и вести накопление табличных данных (например, надо сделать контроль бюджетов, проверить остатки, накопить данные о продажах или закупках), а раз так, то львиную долю согласовательных функций для документов типа "Требование на оплату", "Дополнение к договору", "План производства", "Отчет о выполнении плана продаж" и пр. нужно будет делать где-то сбоку, к примеру, в учетной системе, где это сделано через Ж№"%.

Как ни странно, нам больше подошел MS CRM 4, возможности которого покрыли наши потребности в документообороте на 86% (по сравнению с 65% для DocsVision). Сейчас идет пилотный проект, в середине мая - сдача, отчитаюсь обязательно.

GGestrizh не понимаю при чем тут СЭД и MS CRM 4????
Вот у нас документооборот и делается на базе CRM 4. А че - технологическая платформа позволяет. Вот кусочек ТЗ, все выложить не могу :(

Собс-но, картинка :)

Да шо ж такое :( Обедать пора :)

>Просто интересен метод подсчета процентов.

По рабоче-крестьянски. Расписали перечень пунктов (участков, действий), по которым нам надо документооборот. Получилось 28 - на 3 странички. Проранжировали их по значимости, экспертами выступили совладелец бизнеса и его брат. Обсудили с вендорами обеих систем возможности по каждому пункту, добавили свой и чужой опыт - получили оценки применимости систем по каждому пункту. Ну и средневзвешенная.

Промежуточный отчет по внедрению MS CRM 4 как платформы для финансового документооборота.

Достоинства.
1) Платформа мне нравится все больше и больше - пока субъективное мнение, но тем не менее. В ней предусмотрено очень много вещей. Тебе что-то надо - оп - а оно там есть :)
2) Поставщик оказался ОЧЕНЬ вменяемым, хоть и медленноватым - из-за относительно раздутого размера конторы

Недостатки.
1) Затяжка сроков из-за новизны платформы для поставщика (все-таки четверка была представлена совсем недавно) - финальную презентацию отложили на месяц.
2) Необходимость модернизации на всех рабочих местах Internet Explorer - до 7 версии. На 6-й - местами криво, но работает.
3) Утилита миграции данных - кривая :) Пришлось помучиться. Убили лишнюю неделю.

Сейчас идет активное тестирование соответствия функционала техзаданию, настройка юзеров и доделка-переделка отчетов.

Еще 1 промежуточный отчет.

Негатив.

1) Встроенный инструмент построения отчетов - слишком простой. В итоге - пришлось строить больше половины отчетов с помощью MS VS, а потом публиковать их.
2) Встроенный механизм обработки событий в формах - слишком простой. Пришлось код нескольких модулей (уже 10) писать на C#, а потом публиковать их.

При этом, вот так "слева" опубликованные вещи доступны из основного web-интерфейса юзерам, но не видны администратору из режима "Параметры"-"Настройка объектов" (ну и для отчетов аналогично). И ему приходится о них помнить. Это совсем не добавляет "прозрачности" и "сопровождаемости" системе.

3) Сделанные на C# модули исполняются от имени администратора системы и не учитывают защиту на уровне ролей юзеров. Хотя, может я не вкурил, как правильно это "готовить". Соответственно, напоролись на ситуевину, когда юзер, чего-то делая со своими данными и вызывая событие для обновления связанных таблиц, обновлял чужие записи, которые ему как-бы и не должны быть видны по роли.

4) Любое изменение макета отчета вызывает удаление прав на него всех юзеров, кроме админа. Блин - приходится опять назначать.

5) Маркетинговые мероприятия типа "Встреча" не ставятся в общий календарь. А если просто зайти в календарь и создать встречу - то всем участникам ставится. Да и вообще. Такое впечатление, что почти все функции работы с календарями MS оставила "на хлеб" внедренцам. Что за хрень ?

6) Нельзя управлять длиной поля типа "picklist" (список значений) - это всегда varchar(255) - слишком много в контексте пункта 7. Хотя есть и внутренний id для него - поле типа byte. Классический пример - месяц. Автоматически сравнение-сортировка идет по id, а вывод - как строки. Но вот ведь, зараза, при подстановке в средство "Поиск повторяющихся данных" - подставляются строки !

7) "Поиск повторяющихся данных" - это средство тут вместо уникальных индексов. Хрень в том, что максимальная длина уникального индекса - всего 450 байт, а если в ключ надо чтобы входило больше 1 поля типа "picklist" - то ... И системе никак не скажешь, что в этом случае надо брать из picklist не строку, а id.

Позитив.

1) Очень быстро, "на лету" выполняем поднастройку юзерам.

2) Юзеры молодые и сравнительно молодые, поэтому с энтузиазмом воспринимают WEB-интерфейс.

Workflow для MS CRM - это MS WF. Т.е., в контексте VS 2008, ставим туда расширения MS CRM, а потом создаем проект WF, в котором будут доступны объекты из MS CRM. Пока реальный проект не пробовал создать, только увидел наличие - нужные заголовки в студии. Надеюсь, если понадобится - будет работать :)

Деня, по обеим твоим вопросам. Надо запускать системный циклический БП, который будет заниматься отбором просроченных задач или наступающих Дней рождения и посылать письма.

А по сабжу топика.
Мой проект, описанный чуть выше, похоронен из-за финансового кризиса. Т.е. мы успешно устранили все недоработки по интеграции с клиент-банком, выверили процесс, обучили кучу юзеров и службу поддержки, сделали все нужные отчеты, оповещения и пр., провели презентацию гендиректору... Он сказал: "Супер, запускаемся !" И тут грянул кризис. И оказалось, что система планирования распределения денег, которых нет, никому не нужна, а рядовые юзеры поставлены перед фактом -30% от зарплаты и с угрозой увольнения с 1 января :(

Надо быть оптимистом ...