|
АБКонечно хорошо, когда данные структурированы и лежат в БД в нормализованном виде: можно удобно и быстро извлекать, группировать, сравнивать. Чтобы делать это еще быстрее, поверх СУБД накрутили OLAP и гиперкубы, а чтобы не потеряться в лабиринте БД, которые каждая прикладная система городит под себя, придумали MDM.
Нет, MDM придумали, "чтобы ничего не переписывать". То есть, сначала нагородили, а потом, чтобы не переписывать, придумали этот, концептуально - абсолютно бессмысленный, класс систем.
АБНо не все и не всегда возможно структурировать, и в 90-е случилось еще одно просветление: есть данные, а есть контент - вордовые документы, экселевые таблички, а также сканы факсов, писем и заявлений.
Это тоже данные, причем структурированные. Если речь идет о типах, то просветление - частное понятие, и оно случается каждый день у кого-нибудь. Например, можно ввести тип "Габаритный размер" (a*b*c, где a, b, c - положительные числа) и отношения "Размещается в (без кантования)", "Размещается в (с кантованием)" и т.п., что позволит управлять данными (подбирать коробки для товаров, например), вероятно, эффективнее, чем в случае трех отдельных атрибутов Длина, Ширина, Высота. То же и с перечисленными типами.
АБДо определенного момента никто теорией особо не заморачивался - ну файлы и файлы. На заре цивилизации ПиСи обменивались файлами через "флопинет", потом юзеры познакомились с сетевыми дисками и "электронкой" и продемонстрировали, что нет такого диска и такого канала, который нельзя забить многомегабайтными пдф-ами и сканами. У сисадминов появился термин "файлопомойка" (грубый народ, что возьмешь), ИТ-директора предпочитают красивое название "корпоративный архив".
Никто - это сильно сказано. Ей и сейчас мало кто заморачивается. Разве, что теоретики.
АБТак или иначе, что с помойкой, что с архивом, но что-то надо было делать. Просто объявить файлы корпоративным контентом недостаточно - надо его хранить централизованно, а не как обычно - куча версий одного и того же документа на локальных дисках и в почтовых ящиках с правками, которые не понятно как сливать друг с другом. Надо обеспечивать аккуратное разграничение доступа и версионность - не в последнюю очередь для защиты юзера от него же самого, чтоб не потер невзначай. Надо уметь искать и по контенту, и по ключевым словам. Ну и доступ надо обеспечить, в идеале, откуда угодно - и из веб-портала, и из проводника Windows, и из iPad.
А к данным других типов не надо что ли???
АБНапрашивается идея выделить отдельный класс софта с перечисленным функционалом для обслуживания сущности под названием контент. Почему отдельный? Да потому что чем бы вы не занимались - регистрировали заказ в ERP, или выполняли задание в BPMS, или управляли проектом с помощью MS Project - вам везде потребуется контент и стандартный функционал для работы с ним.
А даты??? А числа??? Требую и для них класс софта, для справедливости.
АБСитуация в точности та же, что и с DBMS, и с BPMS: чем прикручивать этот функционал то там, то здесь, лучше один раз взяться и сделать как следует.
Уточню:
Ситуация в точности та же, что и с DBMS, и с BPMS, и с ERP, и с CRM, и с MDM (и т.д. по обстоятельствам): чем прикручивать этот функционал то там, то здесь, лучше один раз взяться и сделать как следует.
АБИтак, нам нужна инфраструктура уже как минимум из трех компонент: DBMS для структурированных данных, ECM для неструктурированного контента, BPMS для процессов.
Уточню:
Итак, нам нужна инфраструктура уже как минимум из трех компонент: DBMS для структурированных данных, DBMS для неструктурированного контента, DBMS для процессов.
Интересная мысль. Как плохо обстоит дело в сфере DBMS.
АБНо вот какая штука: не в интересах производителей софта замыкаться в своих рамках - все эти системы свою прямую работу, понятно, выполняют лучше всех, но при этом могут работать еще и за соседа. "Изя, чтобы ты делал, если бы стал королем? - Я бы жил лучше, чем король! - ? - Потому что я бы еще немножко шил."
В результате в СУБД можно "немножко" реализовать и процессы (через смену состояний объекта и/или возможные переходы), и хранение контента (через binary поля); BPMS норовят похранить в себе, как в черном ящике, и данные, и контент; ECM претендует и на хранение вообще всего, а не только неструктурированного контента, и на то, что в нем можно автоматизировать процессы. Все подобные проявления, конечно же, следует категорически исключить.
Вот! От объективной реальности в виде прослеживания причинно-следственных цепочек развития событий в области управления данными перешли к исключению проявлений объективной реальности:)
АБИ в частности, реализацию процессов в ECM, которую у нас называют документооборотом. (Есть еще слово workflow, но оно ругательное иностранное и поэтому широкими массами трудящихся заказчиков не воспринимается.) Документооборот в разумных пределах - вещь вполне осмысленная: в конце концов, в уважающей себя организации должны как-то учитываться официальные входящие и исходящие. Беда в том, что особо ретивые автоматизаторы на этом не останавливаются. Хотите автоматизировать прием на работу - не вопрос, это ведь движение документа "заявление о приеме на работу". Закупки? Тем более понятно, это ничто иное, как документ "Заявка на приобретение". Какие там структуры данных, какие схемы процессов? Все можно сделать с помощью вордового документа, его состояний и списка согласующих. Как известно, "с помощью маркера можно раскрасить все, кроме самого маркера. А с помощью двух маркеров можно раскрасить ВООБЩЕ ВСЕ!" (ц)
Один в один аргументы в пользу BPMS. Но они критикуются! Я, в общем-то, так и знал:)
АБИ люди на это ведутся!
Еще как. Что там люди, специалисты, как видите, ведутся:)
АБНе понимая, что без структурирования данных это будет не управление, а пародия на него: много суеты, много бумажек, мало толку. Сначала загнать цифры по объемам и ценам закупок в вордовый документ, чтобы потом, предпринимая героические усилия, их оттуда вытаскивать - ну не бред ли?
Загнать операцию разрешения выработки продукции в BPMS, чтобы потом, предпринимая героические усилия ее оттуда вытаскивать? Даже не знаю что сказать.
АБНе меньший бред - взгляд на процесс от документа. Типа есть бумажка - есть процесс, нет бумажки - нет процесса. Из непридуманного: "Мы хотим, чтобы система контролировала, что в пакете документов, который мы отправляем в министерство, запрашивая разрешение, присутствовали все необходимые документы. А если какого документа нет, пусть система нас предупредит." Какие документы, о чем предупредить?! О работе надо думать, причем думать надо было полгода назад, чтобы успеть провести исследование для этого документа! А документ - это всего лишь красиво оформленные данные, которые мы собрали. Или (второй вариант) сканированный документ, полученный извне. И все!
Хорошо. Но теперь уже куда не глянь - везде бред получается:(
АБВ общем, концепция документооборота - это вот что. Была организация, работавшая по старинке, управлявшаяся с помощью бумажек: приказов, распоряжений, служебок. Пришли автоматизаторы. Для начала стали бумажки делать с помощью текстовых редакторов и принтеров. В результате их стало на порядок больше - раньше машбюро хоть как-то ограничивало этот поток, а с вордом и лазерным принтером можно столько документов наплодить - ого-го! Чтобы справиться с этим потопом, автоматизаторы предложили бумажки хранить в компьютерах, в компьютерах же пересылать с одного рабочего места на другое и с помощью тех же компьютеров делать в них пометки, накладывать резолюции и т.п.
Я согласен, что концепция "документооборота" имеет так же мало объективных оснований, как и BPMS, в аспекте управления данными.
АБВместо того, чтобы спроектировать бизнес-процесс приема на работу, структурировать его данные, определить какие данные нужны на каком шаге и в конечном итоге показать пользователю экран с данными о соискателе, разложенным по полям экранной формы, давайте тупо зашлем ему вордовый документ - пусть наложит резолюцию, а после решит кому этот документ переправить. Я это называю "документонаоборот".
Уточню: вместо того, чтобы реализовать это так же формально и ясно, как и любую другую задачу в среде корпоративной информационной системы...
АБКороче: ECM также плохо умеет управлять бизнес-процессами, как BPMS хранить контент. Документооборот имеет смысл в ограниченной области канцелярской деятельности, но ее надо по возможности сокращать, как не добавляющую ценность, а не распространять на всю деятельность компании.
Разобрались с документооборотом:)
|
