Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Откуда есть пошли контент-менеджмент и документооборот

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

Конечно хорошо, когда данные структурированы и лежат в БД в нормализованном виде: можно удобно и быстро извлекать, группировать, сравнивать. Чтобы делать это еще быстрее, поверх СУБД накрутили 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-системы, имеет смысл в ограниченной области канцелярской деятельности, но эту канцелярскую работу надо по возможности сокращать, как не добавляющую ценность, а не распространять на всю деятельность компании.

04.12.12 | Статьи | ,    

Комментарии (6)

  1. Кирилл 04.12.12 18:42

    Анатолий, а что такое тогда docflow? я всегда считал, что ИС документооборота есть docflow, а workflow это что-то другое….так сказать недоBPMS?

  2. Anatoly Belychook 04.12.12 18:52

    Кирилл

    Так оно и есть. Просто docflow - еще более непроизносимое слово :)

  3. Касперович Юрий 05.12.12 08:26

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

  4. Дмитрий Бацюро 01.01.13 20:29

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

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

  5. Anatoly Belychook 02.01.13 14:31

    Дмитрий, спасибо за удачную метафору со счетами.

    Коллеги

    Наверное документы бывают разными. Бывают распорядительные - накладная на перемещение - они действительно похожи на транзакции. Бывают отчетные - ведомость инвентаризации. Бывают художественные - объяснительная по поводу прогула :)

    Любой процесс порождает документ? Не уверен. Например, как насчет процесса “прописки” нового сотрудника (employee onboarding)? При желании наверное можно придумать документ, который он порождает, но стоит ли?

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

  6. Дмитрий Бацюро 04.01.13 16:13

    Анатолий, я в своей фразе про связь документа и процесса имел в виду не документ, оформленный неким типографским или художественным образом, а именно набор взаимосвязанных данных, совокупность которых несет определенный смысл. Так что тут наше видение с вами совпадает. И именно с таким пониманием документа и надо читать мою фразу о том, что процесс и документ друг друга как рука руку моют. А уж как эту взаимосвязанную информацию красиво изложить на бумаге или в виде XML, XLS, PDF, как обеспечить ее подлинность, неизменяемость и неотрекаемость (при помощи ЭЦП) - вопрос второй.

А что вы думаете?

Captcha

Copyright © 2008-2016 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии