(Продолжение. Начало тут.)

Конечно хорошо, когда данные структурированы и лежат в БД в нормализованном виде: можно удобно и быстро извлекать, группировать, сравнивать. Чтобы делать это еще быстрее, поверх СУБД накрутили OLAP и гиперкубы, а чтобы не потеряться в лабиринте баз данных, которые создает под себя каждая прикладная система, придумали MDM.

Но не все и не всегда возможно структурировать, и в 90-е случилось еще одно просветление: есть данные, а есть контент - вордовые документы, экселевые таблички, сканы факсов, писем и заявлений. До определенного момента никто теорией не заморачивался - ну файлы и файлы. На заре цивилизации ПиСи обменивались файлами через “флопинет”, потом юзеры познакомились с сетевыми дисками и “электронкой” и продемонстрировали, что нет такого диска и такого канала, который нельзя забить многомегабайтными пдф-ами и сканами. У сисадминов появился термин “файлопомойка” (грубый народ, что возьмешь), ИТ-директора стали употреблять красивый термин “корпоративный архив”.

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

Напрашивается идея выделить отдельный класс софта с перечисленным функционалом для обслуживания сущности под названием контент. Почему отдельный? Да потому что чем бы вы не занимались - регистрировали заказ в ERP, или выполняли задание в BPMS, или управляли проектом с помощью MS Project - вам везде потребуется контент и стандартный функционал для работы с ним. Ситуация в точности та же, что и с DBMS, и с BPMS: чем прикручивать этот функционал то там, то здесь, лучше один раз взяться и сделать как следует.

Итак, нам нужна инфраструктура уже как минимум из трех компонент: DBMS для структурированных данных, ECM для неструктурированного контента, BPMS для процессов. Но вот какая штука: не в интересах производителей софта замыкаться в своих рамках - все эти системы свою прямую работу, понятно, выполняют лучше всех, но при этом могут работать еще и за соседа. “Изя, чтобы ты делал, если бы стал королем? - Я бы жил лучше, чем король! - ? - Потому что я бы еще немножко шил.”

В результате в СУБД можно “немножко” реализовать и процессы (через смену состояний объекта и/или возможные переходы), и хранение контента (через binary поля); BPMS норовят похранить в себе, как в черном ящике, и данные, и контент; ECM претендует и на хранение вообще всего, а не только неструктурированного контента, и на то, что в нем можно автоматизировать процессы. Все подобные проявления, конечно же, следует категорически осудить.

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

Беда в том, что особо ретивые автоматизаторы на этом не останавливаются. Хотите автоматизировать прием на работу - не вопрос, это ведь, в их трактовке, движение документа “заявление о приеме на работу”. Закупки? Тем более понятно, это ничто иное, как документ “Заявка на приобретение”. Какие еще структуры данных, какие схемы процессов? Все можно сделать с помощью вордового документа, его состояний и списка согласующих.

Достойно удивления и сожаления, что люди на это ведутся. Не понимая, что без структурирования данных это будет не управление, а пародия на него: много суеты, много бумажек, мало толку. Сначала загнать цифры по объемам и ценам закупок в вордовый документ, чтобы потом, предпринимая героические усилия, их оттуда вытаскивать - ну не бред ли?

Не меньший бред - взгляд на процесс от документа. Типа есть бумажка - есть процесс, нет бумажки - нет процесса. Из непридуманного: “Мы хотим, чтобы система контролировала, что в пакете документов, который мы отправляем в министерство, запрашивая разрешение, присутствовали все необходимые документы. А если какого документа нет, пусть система нас предупредит.” Какие документы, о чем предупредить?! О работе надо думать, причем думать надо было полгода назад, чтобы успеть провести исследование для этого документа! А документ - это всего лишь красиво оформленные данные, которые мы предварительно собрали. Или (второй вариант) отсканированная бумага с подписью. И все!

В общем, концепция документооборота это вот что:

1. Была организация, работавшая по старинке и управлявшаяся с помощью бумажек: приказов, распоряжений, служебок.
2. Пришли автоматизаторы, продали организации персоналки и MS Office, сотрудники стали бумажки делать с помощью текстовых редакторов и принтеров. В результате документов стало на порядок больше - раньше машбюро хоть как-то ограничивало этот поток, а с вордом и лазерным принтером можно столько бумажек наплодить - ого-го!
3. Чтобы справиться с этим потопом, автоматизаторы предложили бумажки хранить в компьютерах, в компьютерах же пересылать с одного рабочего места на другое и с помощью тех же компьютеров делать в них пометки, накладывать резолюции и т.п.

Вот за это я и не люблю термин “автоматизация” - за ним зачастую скрывается стремление продолжать делать ровно то же самое, что делали раньше, только с помощью компьютера. Получается консервация отсталости.

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

Резюмирую: ECM так же плохо подходит для управления бизнес-процессами, как BPMS - для хранения контента. Документооборот, как прикладное решение, разработанное поверх ECM-системы, имеет смысл в ограниченной области канцелярской деятельности, но эту канцелярскую работу надо по возможности сокращать, как не добавляющую ценность, а не распространять на всю деятельность компании.