Комментарии 22
Вы пишите
А какие технологии использует ТЭЗИС?
избегайте устаревших технологий, находящихся на последних стадиях жизненного цикла – дефицит специалистов может оказаться критическим фактором
А какие технологии использует ТЭЗИС?
ТЕЗИС построен на платформе CUBA, которая в свою очередь использует Java стек:
www.cuba-platform.com/ru/technologies
www.cuba-platform.com/ru/technologies
Стандартов собственно на ECM/СЭД в России нет.
Наталья Храмцовская наверняка оспорила бы это высказывание.
В целом — спасибо за статью. Продукты, которые я продаю, полностью подходят под все ваши рекомендации.
А как же MoReq. Если не ошибаюсь, то данный стандарт подразделяет ECM системы на 2 типа: EDM (electronic document management — управление документами — системы документооборота) и ERM (Enterprise records management — управление записями — системы электронных архивов). Официально стандартом MoReq не признается, но де-факто оон таким является. На его основе созданы как зарубежные системы типа Documentum, так и российские, например STOR-M.
Данный стандарт четко разделяет понятия document и record, но в русскоязычной ECM среде широкого распространения термин «record»- «запись» почему-то не получил.
Document — любой документ находящийся в стадии написния, обсуждения, согласования. Может изменяться любое количество раз и не представляет бизнес-значимости для компании.
Record — согласованный, утвержденный и подписанный бизнес-значимый документ. Он уже никогда не изменится, сам факт его наличия важен для компании, к нему обращаются сотрудники в процессе работы. При этом это может быть не только документ в прямом смысле слова, но и, например, видеозапись встречи, диктофонная запись совещания.
В общем-то автор прав, что в России стандарта нет, но тем не менее они используются. Призываю в этот топик staskin1, он обладает значительно большими знаниями в этой области.
Данный стандарт четко разделяет понятия document и record, но в русскоязычной ECM среде широкого распространения термин «record»- «запись» почему-то не получил.
Document — любой документ находящийся в стадии написния, обсуждения, согласования. Может изменяться любое количество раз и не представляет бизнес-значимости для компании.
Record — согласованный, утвержденный и подписанный бизнес-значимый документ. Он уже никогда не изменится, сам факт его наличия важен для компании, к нему обращаются сотрудники в процессе работы. При этом это может быть не только документ в прямом смысле слова, но и, например, видеозапись встречи, диктофонная запись совещания.
В общем-то автор прав, что в России стандарта нет, но тем не менее они используются. Призываю в этот топик staskin1, он обладает значительно большими знаниями в этой области.
Приятно видеть, что MoReq не забыт:)
Но хотел бы поправить: Documentum не был сделан на основе MoReq. Хотя бы потому, что он появился раньше MoReq.
Но это не главное — Moreq определяет довольно узкую часть функциональности, именно records management, тогда как scope любой ECM-платформы значительно шире.
Также не стоит проводить жесткую демаркационную линию между document и record. В ECM-системах обычно есть операция «declare document as record» — аналогично нашему понятию «регистрация документа».
Record — это с одной стороны документы, которые требуются по закону (комплаенс) — накладные, счета-фактуры и проч.
С другой — все документы, которые как-то могут обосновать вашу позицию перед различными компетентными органами или перед партнерами. Например, обычное письмо по e-mail, где менеджер контрагента обещал вам скидку.
Для вас это record, ибо если человек уволится и потрет свою почту, как вы эту скидку получите?
Но хотел бы поправить: Documentum не был сделан на основе MoReq. Хотя бы потому, что он появился раньше MoReq.
Но это не главное — Moreq определяет довольно узкую часть функциональности, именно records management, тогда как scope любой ECM-платформы значительно шире.
Также не стоит проводить жесткую демаркационную линию между document и record. В ECM-системах обычно есть операция «declare document as record» — аналогично нашему понятию «регистрация документа».
Record — это с одной стороны документы, которые требуются по закону (комплаенс) — накладные, счета-фактуры и проч.
С другой — все документы, которые как-то могут обосновать вашу позицию перед различными компетентными органами или перед партнерами. Например, обычное письмо по e-mail, где менеджер контрагента обещал вам скидку.
Для вас это record, ибо если человек уволится и потрет свою почту, как вы эту скидку получите?
Э, не надо путать стандарты на предметную область (документооборот) и на технические системы. На СЭД таки стандартов нет.
И да — это не пособие по выбору конкретного продукта))
И да — это не пособие по выбору конкретного продукта))
Было бы замечательно, если бы заказчики использовали данные рекомендации при выборе софта. Но, если эти рекомендации не донести до широкого круга заказчиков-пользователей, то они так и останутся известными лишь специалистам по ECM и должной пользы не принесут.
Спасибо, очень правильная статья.
Согласен, если выбор идет из TOP-10 СЭД (ниже 10-ки высока вероятность, что в СЭД не окажется какой-нибудь полезной функции, которую забыли учесть при выборе), то в основе должны лежать уже, именно, не функциональные требования.
Единственное, немного дополню список не функциональных требований на основе своего опыта:
— Развитая партнерская сеть. Под «развитая» имеется ввиду не тысячи франчайзи, а сертифицированные вендором партнеры (и важно, чтобы реально сертифицированные, т.е. прошедшие обучение, сдавшие экзамены, имеющие опыт внедрения и т.д.). От того, кто внедряет СЭД, очень сильно зависит успех проекта.
— Отраслевые решения. Высокая компетенция вендора и его партнеров в той или иной отрасли, чтобы при внедрении СЭД говорить с заказчиком на одном языке.
детальное сравнение возможностей продуктов может оказаться бесполезным
Согласен, если выбор идет из TOP-10 СЭД (ниже 10-ки высока вероятность, что в СЭД не окажется какой-нибудь полезной функции, которую забыли учесть при выборе), то в основе должны лежать уже, именно, не функциональные требования.
Единственное, немного дополню список не функциональных требований на основе своего опыта:
— Развитая партнерская сеть. Под «развитая» имеется ввиду не тысячи франчайзи, а сертифицированные вендором партнеры (и важно, чтобы реально сертифицированные, т.е. прошедшие обучение, сдавшие экзамены, имеющие опыт внедрения и т.д.). От того, кто внедряет СЭД, очень сильно зависит успех проекта.
— Отраслевые решения. Высокая компетенция вендора и его партнеров в той или иной отрасли, чтобы при внедрении СЭД говорить с заказчиком на одном языке.
Развитая партнерская сеть. Под «развитая» имеется ввиду не тысячи франчайзи, а сертифицированные вендором партнеры (и важно, чтобы реально сертифицированные, т.е. прошедшие обучение, сдавшие экзамены, имеющие опыт внедрения и т.д.). От того, кто внедряет СЭД, очень сильно зависит успех проекта.
В целом верное замечание, но я бы развила дальше — необходимо рассматривать не только систему, но и бизнес-модель вендора. Кто-то из вендоров внедряет самостоятельно, кто-то через партнерскую сеть, другие используют смешанный вариант. Соответственно, чем больше возможностей выбора у заказчика, тем больше гарантий успеха внедрения. Идеально, если технологии системы и компания-разработчик позволяют заказчику выбирать — внедрять ли самостоятельно, с помощью вендора или партнера-интегратора.
Да, выбор это всегда хорошо, но данном случае, на мой взгляд, есть все-таки одна идеальная схема:
1. Партнер внедряет СЭД. Плюсы: территориальная близость к заказчику (нет командировочных расходов); конкурентная стоимость ч/ч (ставки в регионах отличают от Москвы); проектный опыт в схожей сфере (как правило интеграторы специализируются на какой-то одной отрасли).
2. Вендор помогает партнеру и контролирует внедрение СЭД. Плюсы: в сложные моменты вендор может дать партнеру ценный совет; помочь правильно спроектировать решение; для заказчика это гарантия качества + стоимость такого привлечения значительно ниже, чем заказывать у вендора проект внедрения.
3. Специалисты заказчика сопровождают СЭД. Плюсы: оперативное решение любого вопроса; свои специалисты лучше разбираются в созданном на платформе решении и как правильно лучше понимают специфику своей компании; стоимость как правило ниже. А партнер и вендор привлекаются только в случае развития СЭД или перехода на новую версию.
1. Партнер внедряет СЭД. Плюсы: территориальная близость к заказчику (нет командировочных расходов); конкурентная стоимость ч/ч (ставки в регионах отличают от Москвы); проектный опыт в схожей сфере (как правило интеграторы специализируются на какой-то одной отрасли).
2. Вендор помогает партнеру и контролирует внедрение СЭД. Плюсы: в сложные моменты вендор может дать партнеру ценный совет; помочь правильно спроектировать решение; для заказчика это гарантия качества + стоимость такого привлечения значительно ниже, чем заказывать у вендора проект внедрения.
3. Специалисты заказчика сопровождают СЭД. Плюсы: оперативное решение любого вопроса; свои специалисты лучше разбираются в созданном на платформе решении и как правильно лучше понимают специфику своей компании; стоимость как правило ниже. А партнер и вендор привлекаются только в случае развития СЭД или перехода на новую версию.
Единственная идеальная схема? Мне кажется это слишком мало для рынка. В одном случае эта схема работает, в других случаях заказчики ориентированы сразу на другие варианты взаимодействия. Например, по опыту, крупные заказчики сразу настаивают на прямой работе с вендором, т.к. никто не знает систему лучше самого вендора. А кому-то нужна независимость и предпочитают полностью самостоятельное развитие системы, такие примеры тоже есть. В общем, в многообразии предложения кроется рост качества услуг для конечного потребителя.
Людмила, здравствуйте.
Нам как инициаторам создания хаба ECM/СЭД* очень приятно, что ряды расширяются и ваша компания также сочла Хабру достойным местом для размещения публикаций по ECM. Пожалуйста, не перепечатывайте статьи чужих авторов особенно корреспондентов российских онлайн СМИ, тогда не придется оправдываться за чужие глупости. Это я про отсутствие в России стандартов на ECM. Автор или чего-то не знает или не разбирается в стандартизации. Можно не признавать MoReq и утверждать, что он приемлем только для Европы, но те же ISO — международные стандарты и ISO 15489 в двух частях, работает и даже переведен и принят в качестве национального.
Нам как инициаторам создания хаба ECM/СЭД* очень приятно, что ряды расширяются и ваша компания также сочла Хабру достойным местом для размещения публикаций по ECM. Пожалуйста, не перепечатывайте статьи чужих авторов особенно корреспондентов российских онлайн СМИ, тогда не придется оправдываться за чужие глупости. Это я про отсутствие в России стандартов на ECM. Автор или чего-то не знает или не разбирается в стандартизации. Можно не признавать MoReq и утверждать, что он приемлем только для Европы, но те же ISO — международные стандарты и ISO 15489 в двух частях, работает и даже переведен и принят в качестве национального.
Автор достаточно разбирается в стандартизации, посвятив области СЭД более 20 лет.
Тем более что автор делал первый перевод MoReq на русский язык по договору с Европейской Комиссией.
Автор также проводил ряд работ по оценке отечественных систем на соответствие требованиям MoReq, так что имеет далеко те только теоретические познания в этом вопросе.
Касательно ГОСТ ИСО 15489-2007. Это фреймворк для предметной области — Управление документами. Отнюдь не для технических решений для управления документами. Таковым стандартом мы планировали сделать MoReq, но, к сожалению пока не получилось.
ГОСТ ИСО 15489 не содержит функциональных и иных требований непосредственно к информационным системам.
Станислав Макаров, автор.
Тем более что автор делал первый перевод MoReq на русский язык по договору с Европейской Комиссией.
Автор также проводил ряд работ по оценке отечественных систем на соответствие требованиям MoReq, так что имеет далеко те только теоретические познания в этом вопросе.
Касательно ГОСТ ИСО 15489-2007. Это фреймворк для предметной области — Управление документами. Отнюдь не для технических решений для управления документами. Таковым стандартом мы планировали сделать MoReq, но, к сожалению пока не получилось.
ГОСТ ИСО 15489 не содержит функциональных и иных требований непосредственно к информационным системам.
Станислав Макаров, автор.
Станислав, здравствуйте,
Спасибо, что присоединились к беседе. Немного странно, что вы пишите о себе в третьем лице :)
С вашим вариантом перевода стандарта MoReq и в частности вышепомянутой связки: document/record, где «информационный документ = document, официальный документ = record» я хорошо знаком и даю его в купе с оригинальным текстом на английском и переводом от Натальи Храмцовской слушателям на занятиях по ECM.
Переводить стандарты еще не значит разбираться в стандартизации в данном случае не только отраслевой, но и международной. Я говорю о статусе стандартов, их действии на территории той или иной страны, применимости для целей бизнеса, легитимности и отношении официальных органов в том числе и судов в случае различных споров. Как вы, например, ответите на такой вопрос: имею ли я право на территории РФ использовать стандарт ISO 15489-1:2001 Information and documentation — Records management — Part 1: General, если существует национальный ГОСТ Р ИСО 15489-1-2007. «Система стандартов по информации, библиотечному и издательскому делу. Управление документами. Общие требования»?
Не согласен с вами, в данном стандарте содержатся и функциональные и нефункциональные требования к информационным системам, другой вопрос, что их детализация (один абзац на одно требование) категорически не достаточно для проектирования и разработки информационной системы. Потому и появился MoReq и последующие его версии, чтобы эту ситуацию исправить.
Станислав, а почему вы не опубликовали данную стстаью на Хабре от своего имени? Или на Хабре вы представляете интересы компании Haulmont, которая вас пригласила? Тем более надо поститься от своего имени :)
Автор достаточно разбирается в стандартизации...
Спасибо, что присоединились к беседе. Немного странно, что вы пишите о себе в третьем лице :)
С вашим вариантом перевода стандарта MoReq и в частности вышепомянутой связки: document/record, где «информационный документ = document, официальный документ = record» я хорошо знаком и даю его в купе с оригинальным текстом на английском и переводом от Натальи Храмцовской слушателям на занятиях по ECM.
Переводить стандарты еще не значит разбираться в стандартизации в данном случае не только отраслевой, но и международной. Я говорю о статусе стандартов, их действии на территории той или иной страны, применимости для целей бизнеса, легитимности и отношении официальных органов в том числе и судов в случае различных споров. Как вы, например, ответите на такой вопрос: имею ли я право на территории РФ использовать стандарт ISO 15489-1:2001 Information and documentation — Records management — Part 1: General, если существует национальный ГОСТ Р ИСО 15489-1-2007. «Система стандартов по информации, библиотечному и издательскому делу. Управление документами. Общие требования»?
ГОСТ ИСО 15489 не содержит функциональных и иных требований непосредственно к информационным системам.
Не согласен с вами, в данном стандарте содержатся и функциональные и нефункциональные требования к информационным системам, другой вопрос, что их детализация (один абзац на одно требование) категорически не достаточно для проектирования и разработки информационной системы. Потому и появился MoReq и последующие его версии, чтобы эту ситуацию исправить.
Станислав, а почему вы не опубликовали данную стстаью на Хабре от своего имени? Или на Хабре вы представляете интересы компании Haulmont, которая вас пригласила? Тем более надо поститься от своего имени :)
Прежде всего, прошу вас держаться в рамках профессиональной дискуссии. Именовать мнение, отличное от своего «глупостью» явно плохая идея. Непонятно ваше пренебрежительное отношение к журналистам «особенно корреспондентов российских онлайн СМИ». Считать все журналистов недотепами, не разбирающимися в предмете также, простите, банально, как считать всех чиновников жуликами.
Также не надо передергивать: в моем тексте нет утверждения что MoReq чем-то не подходит для России. Тем более что я всегда утверждал обратное — посмотрите мои публикации и презентации за последние лет десять.
Ответ на свой риторический вопрос про стандарты вы найдете в законе 184-ФЗ «О техническом регулировании». Как известно, стандарты у нас — дело добровольное, ГОСТ носит рекомендательный характер. То есть нечто вроде best practice — хотите следуйте, хотите — нет. С этой точки зрения и MoReq, и стандарт 15489 являются практически полезными, но отнюдь не обязательными.
Проверить любую СЭД на соответствие MoReq просто — большинство требований подразумевает простой ответ, выполняется оно в системе или нет. В ИСО15489 определяются политики управления документами, а не функции системы. Странно, что это надо разъяснять. но не суть важно — к теме статьи это мало относится. Ибо какой-либо общепризнанной системы сертификации СЭД у нас не существует (полагаю, с этим вы не будете спорить), а заявления вендоров о соответствии любым стандартам могут оказаться лишь декларацией, поэтому я к ним отношусь скептически и вам советую.
Данная статья — это типичный white paper, написанный мной специально для компании Haulmont и они вольны распоряжаться ей по своему усмотрению, в то числе публиковать. Это обычная практика сотрудничества вендоров и консультантов. Моя профессиональная деятельность журналистикой не ограничивается.
Также не надо передергивать: в моем тексте нет утверждения что MoReq чем-то не подходит для России. Тем более что я всегда утверждал обратное — посмотрите мои публикации и презентации за последние лет десять.
Ответ на свой риторический вопрос про стандарты вы найдете в законе 184-ФЗ «О техническом регулировании». Как известно, стандарты у нас — дело добровольное, ГОСТ носит рекомендательный характер. То есть нечто вроде best practice — хотите следуйте, хотите — нет. С этой точки зрения и MoReq, и стандарт 15489 являются практически полезными, но отнюдь не обязательными.
Проверить любую СЭД на соответствие MoReq просто — большинство требований подразумевает простой ответ, выполняется оно в системе или нет. В ИСО15489 определяются политики управления документами, а не функции системы. Странно, что это надо разъяснять. но не суть важно — к теме статьи это мало относится. Ибо какой-либо общепризнанной системы сертификации СЭД у нас не существует (полагаю, с этим вы не будете спорить), а заявления вендоров о соответствии любым стандартам могут оказаться лишь декларацией, поэтому я к ним отношусь скептически и вам советую.
Данная статья — это типичный white paper, написанный мной специально для компании Haulmont и они вольны распоряжаться ей по своему усмотрению, в то числе публиковать. Это обычная практика сотрудничества вендоров и консультантов. Моя профессиональная деятельность журналистикой не ограничивается.
Станислав, если мои слова вас оскорбили или задели, я прошу прощения, не хотел. Однако настаиваю на том, что, в вашем случае особенно, зная как обстоят дела со стандартизацией, писать «в России стандартов по ECM/СЭД нет» является глупостью или написано умышленно, правда для каких целей мне не понятно.
Про внешних авторов похоже тоже придется прокомментировать и в первую очередь специалистам компания Haulmont. Создавая корпоративный блог на Хабре, вы скорее всего преследуете определенные PR и маркетинговые цели. Учитывая, что Хабра — достаточно продвинутая UGC система, то что проходит на ура на многих известных площадках с заказным контентом и на сайтах собственных компаний тут мало кому интересно. Вы отлично начали, с удовольствием прочитал ваши статьи про платформу и внешние фрейморки. Продолжайте в том же духе.
По поводу соответствия каких-либо российских или зарубежных систем стандартам. Как мне видится ситуация на сегодняшний день, не так важна сертификация программного продукта, как научить заказчика писать требования и уже на основании этих требований искать разработчика и поставщика. Ценность стандарта MoReq именно в том, что он помогает сформулировать функциональные и нефункциональные требования и рассказывает как это делать правильно. Например в стандарте написано, что нельзя показывать не только метаданные документа, но даже намекать на наличие документа в поисковой выдаче, если на сам документ у пользователя нет прав. При задании такого вопроса пользователи с ходу говорят обратное: «да, документ не открываем, но карточку и в поиске показать можем, не страшно».
Про внешних авторов похоже тоже придется прокомментировать и в первую очередь специалистам компания Haulmont. Создавая корпоративный блог на Хабре, вы скорее всего преследуете определенные PR и маркетинговые цели. Учитывая, что Хабра — достаточно продвинутая UGC система, то что проходит на ура на многих известных площадках с заказным контентом и на сайтах собственных компаний тут мало кому интересно. Вы отлично начали, с удовольствием прочитал ваши статьи про платформу и внешние фрейморки. Продолжайте в том же духе.
По поводу соответствия каких-либо российских или зарубежных систем стандартам. Как мне видится ситуация на сегодняшний день, не так важна сертификация программного продукта, как научить заказчика писать требования и уже на основании этих требований искать разработчика и поставщика. Ценность стандарта MoReq именно в том, что он помогает сформулировать функциональные и нефункциональные требования и рассказывает как это делать правильно. Например в стандарте написано, что нельзя показывать не только метаданные документа, но даже намекать на наличие документа в поисковой выдаче, если на сам документ у пользователя нет прав. При задании такого вопроса пользователи с ходу говорят обратное: «да, документ не открываем, но карточку и в поиске показать можем, не страшно».
Станислав, здравствуйте!
По поводу публикаций в блоге. Вы безусловно правы, мы преследуем определенные PR и маркетинговые цели. Как и 100% зарегистрированных здесь компаний. Спасибо за теплые слова про предыдущие статьи, но на мой взгляд данная публикация также вполне соответствует правилам и принципам Хабра.
Это не копипаст — статья публикуется впервые. Да, она написана не нашими сотрудниками, что честно указано в начале статьи. Мы хотели, чтобы статья получилась достаточно интересной широкому кругу читателей, и действительно полезной тем, кто стоит перед выбором системы — поэтому и обратились к Станиславу, обладающему и широчайшим опытом в данной области, и литературным талантом. Я считаю, что это было правильное решение и не вижу здесь ничего предосудительного.
Это не реклама (хотя обратите внимание — формально она разрешена в корпоративном блоге!) — статья достаточно объективна и никаким образом не выделяет какой-то продукт, надеюсь вы не будете это отрицать. Да, взгляд Станислава на стандарты или другие моменты может не совпадать с вашим (и кстати, с нашим) — но ведь это нормально, в споре рождается истина, не так ли?
В связи с этим мне непонятна ваша сентенция про «то что проходит на ура на многих известных площадках с заказным контентом и на сайтах собственных компаний тут мало кому интересно». Впрочем, для этого есть объективный показатель — отзывы пользователей Хабра.
По поводу публикаций в блоге. Вы безусловно правы, мы преследуем определенные PR и маркетинговые цели. Как и 100% зарегистрированных здесь компаний. Спасибо за теплые слова про предыдущие статьи, но на мой взгляд данная публикация также вполне соответствует правилам и принципам Хабра.
Это не копипаст — статья публикуется впервые. Да, она написана не нашими сотрудниками, что честно указано в начале статьи. Мы хотели, чтобы статья получилась достаточно интересной широкому кругу читателей, и действительно полезной тем, кто стоит перед выбором системы — поэтому и обратились к Станиславу, обладающему и широчайшим опытом в данной области, и литературным талантом. Я считаю, что это было правильное решение и не вижу здесь ничего предосудительного.
Это не реклама (хотя обратите внимание — формально она разрешена в корпоративном блоге!) — статья достаточно объективна и никаким образом не выделяет какой-то продукт, надеюсь вы не будете это отрицать. Да, взгляд Станислава на стандарты или другие моменты может не совпадать с вашим (и кстати, с нашим) — но ведь это нормально, в споре рождается истина, не так ли?
В связи с этим мне непонятна ваша сентенция про «то что проходит на ура на многих известных площадках с заказным контентом и на сайтах собственных компаний тут мало кому интересно». Впрочем, для этого есть объективный показатель — отзывы пользователей Хабра.
Вы не только оскорбили, да еще продолжаете это делать. Удивлен.
Если вы не видите разницы между стандартами на процессы и на системы, то не могу ничем помочь.
И кстати: вы практически дословно цитируете мои статьи десятилетней давности про MoReq. Да, все верно — это хороший фундамент для написания хорошего ТЗ на СЭД, занятую делопроизводством и архивом. Да, не надо в поисковой выдаче показывать даже карточку, если у человек нет прав. Более того: не надо даже учитывать в количестве найденных документов в итогах поиска, чтобы сотрудник, не имеющий доступ к документам не мог даже косвенным образом провести исследование, что хранится в базе. Я именно так и рассказывал в своих презентациях. Честно говоря, не врубаюсь — о чем вы пытаетесь со мной спорить? Кстати, не надо ли вашу систему проверить на соответствие MoReq?
И про ГОСТ 15489 я довольно много писал — погуглите, прежде чем кидаться в бой.
Но оставьте уже MoReq в покое. ECM, а нынче уже EIM — enterprise information management — понятия более широкие, чем records management. MoReq даже в версии 2010 этот домен не покрывает. Пора двигаться дальше, а не зацикливаться частном вопросе. Стандарты всегда будут отставать от технического прогресса, и это нормально. Сейчас задача автоматизации канцелярии и архива является вполне рутинной и на мой взгляд не требует обсуждения на этой площадке.
Гораздо интереснее посмотреть на новые применения ECM, на процессы digital transformation, которые и у нас уже проявляются в полный рост. А вы все про СЭД…
Если вы не видите разницы между стандартами на процессы и на системы, то не могу ничем помочь.
И кстати: вы практически дословно цитируете мои статьи десятилетней давности про MoReq. Да, все верно — это хороший фундамент для написания хорошего ТЗ на СЭД, занятую делопроизводством и архивом. Да, не надо в поисковой выдаче показывать даже карточку, если у человек нет прав. Более того: не надо даже учитывать в количестве найденных документов в итогах поиска, чтобы сотрудник, не имеющий доступ к документам не мог даже косвенным образом провести исследование, что хранится в базе. Я именно так и рассказывал в своих презентациях. Честно говоря, не врубаюсь — о чем вы пытаетесь со мной спорить? Кстати, не надо ли вашу систему проверить на соответствие MoReq?
И про ГОСТ 15489 я довольно много писал — погуглите, прежде чем кидаться в бой.
Но оставьте уже MoReq в покое. ECM, а нынче уже EIM — enterprise information management — понятия более широкие, чем records management. MoReq даже в версии 2010 этот домен не покрывает. Пора двигаться дальше, а не зацикливаться частном вопросе. Стандарты всегда будут отставать от технического прогресса, и это нормально. Сейчас задача автоматизации канцелярии и архива является вполне рутинной и на мой взгляд не требует обсуждения на этой площадке.
Гораздо интереснее посмотреть на новые применения ECM, на процессы digital transformation, которые и у нас уже проявляются в полный рост. А вы все про СЭД…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Электронный документооборот: как выбрать систему и не упустить важное