Электронный документ более простой по своей структуре (файлы, реквизиты, подписи), а значит и более универсальный. Такую структуру может понять любая автоматизированная система, а значит документ может быть экспортирован из ISIDA BPM, преобразован к иному формату хранения, отправлен по некоторой системе доставки во внешнее окружение и т.п. Чтобы экспортировать структурированный объект, с каждой системой предстоит отдельно согласовывать его структуру. Поэтому при взаимодействии с большим числом внешних систем проще использовать документ.

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

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

Электронные документы обладают большей консервативностью. Их реквизиты как правило описывают содержимое, поэтому вторичны. Если задача предполагает, что данные должны легко модифицироваться в ходе процесса и всегда быть актуальными, лучше использовать объект.

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

Процесс, связанный с документом, как правило, ограничивается жизненным циклом самого документа, т.е. он обычно короче, чем процесс у объекта. Например, естественными фазами документального процесса является его согласование, рассмотрение, исполнение. Если прикладная задача решается несколькими документами, то большой процесс разобьется на отдельные процессы по каждому документу, в то время как при работе с объектом можно построить один сквозной процесс. Можно сказать, что процессы для объектов более полные, непрерывные, охватывающие все стадии обработки и больше соответствуют духу BPM-систем.

В тех случаях, когда у объекта появляются поля с типом «большой текст», это повод задуматься о применении электронного документа. Текст привычнее и удобнее писать внутри документа. Проблема не в том, что большие фрагменты текста хранить в базе данных нелогично, современные СУБД легко справляются с этой задачей. Гораздо сложнее предоставить адекватный интерфейс для написания и чтения такого текста. Написать пару абзацев можно в любом поле объекта, а написать и прочитать текст на несколько страниц гораздо удобнее в файле формата Microsoft Word. Конечно, можно допустить прикрепление к объекту произвольных файлов и весь текст будет там. Однако к произвольным файлам невозможно выдвинуть требования по их оформлению, содержанию, как правило, это слабо структурированные, часто хаотичные материалы. Документ в этом отношении строже, на него действуют нормы внешнего вида, законодательные требования и в конце концов шаблоны и образцы. Поэтому при работе с текстом лучше использовать электронный документ.