(Продолжение. Начало тут.)
Конечно хорошо, когда данные структурированы и лежат в БД в нормализованном виде: можно удобно и быстро извлекать, группировать, сравнивать. Чтобы делать это еще быстрее, поверх СУБД накрутили OLAP и гиперкубы, а чтобы не потеряться в лабиринте баз данных, которые создает под себя каждая прикладная система, придумали MDM.
Но не все и не всегда возможно структурировать, и в 90-е случилось еще одно просветление: есть данные, а есть контент - вордовые документы, экселевые таблички, сканы факсов, писем и заявлений. До определенного момента никто теорией не заморачивался - ну файлы и файлы. На заре цивилизации ПиСи обменивались файлами через “флопинет”, потом юзеры познакомились с сетевыми дисками и “электронкой” и продемонстрировали, что нет такого диска и такого канала, который нельзя забить многомегабайтными пдф-ами и сканами. У сисадминов появился термин “файлопомойка” (грубый народ, что возьмешь), ИТ-директора стали употреблять красивый термин “корпоративный архив”.
Так или иначе, что с помойкой, что с архивом, но что-то делать было надо. Просто объявить файлы корпоративным контентом недостаточно. Для начала, надо его хранить централизованно, а не как обычно - куча версий одного и того же документа на локальных дисках и в почтовых ящиках юзеров, у каждого со своими правками, которые не понятно как сливать друг с другом. Надо обеспечить аккуратное разграничение доступа и версионность - не в последнюю очередь для защиты юзера от него же самого, чтоб не потер невзначай. Надо уметь искать по тексту и по ключевым словам. Ну и доступ надо обеспечить, в идеале, откуда угодно - и из веб-портала, и из проводника Windows, и из iPad.
Напрашивается идея выделить отдельный класс софта с перечисленным функционалом для обслуживания сущности под названием контент. Почему отдельный? Да потому что чем бы вы не занимались - регистрировали заказ в ERP, или выполняли задание в BPMS, или управляли проектом с помощью MS Project - вам везде потребуется контент и стандартный функционал для работы с ним. Ситуация в точности та же, что и с DBMS, и с BPMS: чем прикручивать этот функционал то там, то здесь, лучше один раз взяться и сделать как следует.
Итак, нам нужна инфраструктура уже как минимум из трех компонент: DBMS для структурированных данных, ECM для неструктурированного контента, BPMS для процессов. Но вот какая штука: не в интересах производителей софта замыкаться в своих рамках - все эти системы свою прямую работу, понятно, выполняют лучше всех, но при этом могут работать еще и за соседа. “Изя, чтобы ты делал, если бы стал королем? - Я бы жил лучше, чем король! - ? - Потому что я бы еще немножко шил.”
В результате в СУБД можно “немножко” реализовать и процессы (через смену состояний объекта и/или возможные переходы), и хранение контента (через binary поля); BPMS норовят похранить в себе, как в черном ящике, и данные, и контент; ECM претендует и на хранение вообще всего, а не только неструктурированного контента, и на то, что в нем можно автоматизировать процессы. Все подобные проявления, конечно же, следует категорически осудить.
И в частности, реализацию процессов в ECM, которую у нас называют документооборотом. (Есть еще слово workflow, но оно ругательное иностранное и поэтому широкими массами трудящихся заказчиков не воспринимается.) Документооборот в разумных пределах - вещь вполне осмысленная: в конце концов, в уважающей себя организации должны как-то учитываться официальные входящие и исходящие.
Беда в том, что особо ретивые автоматизаторы на этом не останавливаются. Хотите автоматизировать прием на работу - не вопрос, это ведь, в их трактовке, движение документа “заявление о приеме на работу”. Закупки? Тем более понятно, это ничто иное, как документ “Заявка на приобретение”. Какие еще структуры данных, какие схемы процессов? Все можно сделать с помощью вордового документа, его состояний и списка согласующих.
Достойно удивления и сожаления, что люди на это ведутся. Не понимая, что без структурирования данных это будет не управление, а пародия на него: много суеты, много бумажек, мало толку. Сначала загнать цифры по объемам и ценам закупок в вордовый документ, чтобы потом, предпринимая героические усилия, их оттуда вытаскивать - ну не бред ли?
Не меньший бред - взгляд на процесс от документа. Типа есть бумажка - есть процесс, нет бумажки - нет процесса. Из непридуманного: “Мы хотим, чтобы система контролировала, что в пакете документов, который мы отправляем в министерство, запрашивая разрешение, присутствовали все необходимые документы. А если какого документа нет, пусть система нас предупредит.” Какие документы, о чем предупредить?! О работе надо думать, причем думать надо было полгода назад, чтобы успеть провести исследование для этого документа! А документ - это всего лишь красиво оформленные данные, которые мы предварительно собрали. Или (второй вариант) отсканированная бумага с подписью. И все!
В общем, концепция документооборота это вот что:
- Была организация, работавшая по старинке и управлявшаяся с помощью бумажек: приказов, распоряжений, служебок.
- Пришли автоматизаторы, продали организации персоналки и MS Office, сотрудники стали бумажки делать с помощью текстовых редакторов и принтеров. В результате документов стало на порядок больше - раньше машбюро хоть как-то ограничивало этот поток, а с вордом и лазерным принтером можно столько бумажек наплодить - ого-го!
- Чтобы справиться с этим потопом, автоматизаторы предложили бумажки хранить в компьютерах, в компьютерах же пересылать с одного рабочего места на другое и с помощью тех же компьютеров делать в них пометки, накладывать резолюции и т.п.
Вот за это я и не люблю термин “автоматизация” - за ним зачастую скрывается стремление продолжать делать ровно то же самое, что делали раньше, только с помощью компьютера. Получается консервация отсталости.
Вместо того, чтобы честно спроектировать бизнес-процесс приема на работу, структурировать его данные, определить какие данные нужны на каком шаге и в конечном итоге показать экран с полями для ввода или отображения данных соискателя, давайте тупо зашлем юзеру вордовый документ - пусть наложит резолюцию, а после решит кому этот документ переправить. Инерция работы с документами мешает понять, что вместо того, чтобы создавать, например, вордовый шаблон запроса на получение офисных канцтоваров, намного технологичнее сделать экранную форму с обязательными полями “номенклатура” и “количество” и опциональным полем “комментарии”.
Резюмирую: ECM так же плохо подходит для управления бизнес-процессами, как BPMS - для хранения контента. Документооборот, как прикладное решение, разработанное поверх ECM-системы, имеет смысл в ограниченной области канцелярской деятельности, но эту канцелярскую работу надо по возможности сокращать, как не добавляющую ценность, а не распространять на всю деятельность компании.
Анатолий, а что такое тогда docflow? я всегда считал, что ИС документооборота есть docflow, а workflow это что-то другое….так сказать недоBPMS?
Кирилл
Так оно и есть. Просто docflow - еще более непроизносимое слово
“Не меньший бред - взгляд на процесс от документа” и ниже - не согласен.
Документ в первую очередь “бизнес-транзакция”, а уж во вторую “набор данных”.
Юрий, что означает ваша фраза “документ в первую очередь “бизнес-транзакция””? Документ - это набор определенных данных, неким образом структурированных (в большей или в меньшей степени - это уже отдельный вопрос). Транзакция - это изменение текущего состояния системы, т.е. информации в ней. Документ в ходе транзакции может изменяться - меняя свое состояние, приобретая дополнительно заполненные атрибуты или изменение прежних. Процессы с документами связаны таким образом: “не бывает процесса, не порождающего тот или иной документ; не бывает документа, не порожденного каким-либо процессом”. Поэтому утверждать, что документ эквивалентен транзакции (а транзакция - часть процесса) - не корректно.
Что из этого первично - документ или процесс - я бы не стал даже обсуждать, так как это спор про курицу и яйцо. Но вот что однозначно - и, я так понял, Анатолий именно этот смысл хотел передать - что при автоматизации часто пытаются не провести реинжениринг процесса с учетом новых возможностей, а тупо исполнить ранее существовавшие методы работы новыми средствами. Получается примерно как если бы вместо калькулятора или электронной таблицы на экране компьютера отображались бы счеты с косточками, которые можно было бы прикосновениями к тач-скрину перемещать, исполняя простейшие математические операции, как это делали продавщицы в советских сельпо. Глупо, неуклюже, не эффективно.
Дмитрий, спасибо за удачную метафору со счетами.
Коллеги
Наверное документы бывают разными. Бывают распорядительные - накладная на перемещение - они действительно похожи на транзакции. Бывают отчетные - ведомость инвентаризации. Бывают художественные - объяснительная по поводу прогула
Любой процесс порождает документ? Не уверен. Например, как насчет процесса “прописки” нового сотрудника (employee onboarding)? При желании наверное можно придумать документ, который он порождает, но стоит ли?
Можно распечатать документ и подшить его в папку. Можно подготовить документ в формате PDF и записать его в определенную папку ECM-системы. А можно ограничиться “идеей документа” (почти по Канту) в виде связанного набора данных в корпоративной системе. Кстати, XML-документ (опционально - подписанный электронной подписью) - это документ или набор данных? С одной стороны, вроде бы и документ. А с другой - вроде бы и нет: ни шрифтов, ни абзацев, ни интерлиньяжа, извините за выражение.
Анатолий, я в своей фразе про связь документа и процесса имел в виду не документ, оформленный неким типографским или художественным образом, а именно набор взаимосвязанных данных, совокупность которых несет определенный смысл. Так что тут наше видение с вами совпадает. И именно с таким пониманием документа и надо читать мою фразу о том, что процесс и документ друг друга как рука руку моют. А уж как эту взаимосвязанную информацию красиво изложить на бумаге или в виде XML, XLS, PDF, как обеспечить ее подлинность, неизменяемость и неотрекаемость (при помощи ЭЦП) - вопрос второй.