Журнал о системах электронного документооборота (СЭД)

Последние комментарии :

Юрий Зерин 21 марта 2017 г. 20:28  

Уважаемый Сергей.

Спасибо, что откликнулись и высказали свое  мнение.

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

   Я не такой компетентный знаток в данной области, но сталкивался с работами математиков, которые на прямую подвергают глубокому сомнению достоверность имеющиеся на сегодняшний день методик  построения алгоритмов шифрования. Не буду делать конкретных ссылок и вступать в теоретические дискуссии. Хотя на практике я столкнулся с реальным взломом и с тех пор отношусь с уважением к любому мнению полезному для моей деятельности.

   Меня больше интересуют аспекты практического применения простой электронной подписи в рамках системы документооборота. Именно в приведенной выше статье, по моему мнению, автор упустил довольно широкий круг возможно использования ПЭП. Этот круг обусловлен применением мессенджеров таких как Skype и WhatsApp.  Именно они способствуют оперативному обмену информацией и составляют необходимую базовую основу  использования простой электронной подписи. У меня есть практические наработки в данном направлении и я не прочь оценить их и услышать любые мнения специалистов. Относительная простота ПЭП и отсутствие явной финансовой составляющей могут быть весьма полезны для ее широкого использования. Не каждый день мы решаем задачи содержащие важную  тайну и не всегда понимаем  методы ее сокрытия при помощи средств дискретной математики.

    Так что, чем проще и доступней, тем быстрей и эффективней.

 

 

Сергей Бушмелев 21 марта 2017 г. 09:31  
Однако не надо забывать, что и квалифицированная электронная подпись, предлагаемая различными УЦ, не являет собой конечную истину на современном этапе развития криптографии.

ИМХО, такие сильные заявления нужно как-то аргументировать :)

Не являюсь специалистом про защите информации, поэтому просто наскреб информацию в Википедии: 

Криптостойкость цифровой подписи опирается на две компоненты — на стойкость хэш-функции и на стойкость самого алгоритма шифрования.[1]

Вероятность взлома хэш-функции по ГОСТ 34.11-94 составляет  при подборе коллизии на фиксированное сообщение и  при подборе любой коллизии.[1] Стойкость алгоритма шифрования основывается на проблеме дискретного логарифмирования в группе точек эллиптической кривой. На данный момент нет метода решения данной проблемы хотя бы с субэкспоненциальной сложностью.[2]

Юрий Зерин 18 марта 2017 г. 19:18  

   Недавно столкнулся с ситуацией использования простой электронной подписи (ПЭП). Как было сказано выше.

"А собственно электронная подпись:,

- информация в электронной форме, которая присоединена к другой информации в электронной форме (подписываемой информации) или иным образом связана с такой информацией и которая используется для определения лица, подписывающего информацию."

Подробнее: http://ecm-journal.ru/post/Prostaja-ehlektronnaja-podpis-uspekhi-i-praktika.aspx 

Следовательно, присоединяемая информация может быть представлена в виде текста, набора чисел, а так же графическим изображением и даже цветовым кодом. Её смысловая нагрузка - определить лицо подписывающее документ. Хорошо когда такая информация представлена : ФИО с серией и номером паспорта, номером телефона, номером СНИЛС, номером ИНН . В этом случае проверка прямым путем вполне возможна. Но трудоемкость затрат оставляет желать лучшего. С этой целью и была создана система удостоверяющих центров (УЦ). Обращение в эти центры хлопотно и накладно. Есть ли другой путь?

Обратимся к понятию простой электронной подписи (ПЭП).

«Простой электронной подписью является электронная подпись, которая посредством использования кодов, паролей или иных средств подтверждает факт формирования электронной подписи определенным лицом».
Подробнее: http://ecm-journal.ru/post/Prostaja-ehlektronnaja-podpis-uspekhi-i-praktika.aspx 

    Смысл, как мне кажется, кроется в том, чтобы при помощи кодов и паролей обратиться в удостоверяющий центр для подтверждения личности подписанта и получить своего рода "квитанцию". Причем такой центр уже имел подлинники документов, провел их проверку, и предоставил доступ к личному кабинету. Таким удостоверяющим центром может даже являться сайт Государственных услуг. Квитанцией подтверждения - скан с данных личного кабинета в формате PDF. ПЭП ссылка на квитанцию с содержанием СНИЛС.

    В качестве таких удостоверяющих центров могут являться банки, компании сотовых операторов связи и т.д., где есть доступ по логинам и паролям.

   Естественно, что такой подход имеет много слабых мест в плане достоверности и юридической грамотности. Однако не надо забывать, что и квалифицированная электронная подпись, предлагаемая различными УЦ, не являет собой конечную истину на современном этапе развития криптографии.

     

Дмитрий Бушмелев 27 марта 2017 г. 09:18  
Демонстрируя стандартный функционал, мы показываем возможности системы. А ложатся ли процессы Заказчика под этот функционал можно выяснить, только на этапе исследования, на котором экономить нельзя

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

Впрочем, не стоит забывать, что важно адаптировать процессы сохранив их прозрачность для пользователей, без чрезмерного усложнения.

 

Гузель Клабукова 24 марта 2017 г. 17:44  

 

После презентации Генерал скажет: «Мне нравится. Внедряем стандартный функционал системы. Это же лучшие практики многих компаний». Сразу возникают вопросы - как эти лучшие практики будут сочетаться с уже существующими процессами в компании? Если внедренец говорит об этом способе, значит он подходит и все будет хорошо? Можно влегкую применить этот способ или есть противопоказания?

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

Фатхуллин Равильевич 21 марта 2017 г. 13:45  

1. Это как закон сохранения, если где-то прибывает, то значит где-то убывает. Если вы хотите сэкономить на внедрении значит над этим надо работать. Если хотите понять подходит ли типовое решение, то выделите ресурсы и время и проведите тестовую эксплуатацию на типовом решении. Если все гуд, то следующим этапом переходите к запуску в опытную. Это конечно на СМБ применимо. Например для делопроизводства это совсем не сложно сделать.

2. Если у вас барадак с процессом и хотите лучших практик, то приглашайте Исполнителя с опытом. Как гарантия наличие технологий по внедрению и готовых типовых документов - проектных решений, инструкций и т.д.

Главное понять что быстро и с наскоку скорее всего не получишь экономии - максимум скидочку выбьешь.

Евгений Кочуров 21 марта 2017 г. 11:25  

Задаюсь вопросом – как на этапе заключения договора определить какие способы экономии мне можно применить?

Вот, например, рекомендация - отказ от глобальных модификаций с ориентацией на стандартный функционал системы.

После презентации Генерал скажет: «Мне нравится. Внедряем стандартный функционал системы. Это же лучшие практики многих компаний».

Сразу возникают вопросы - как эти лучшие практики будут сочетаться с уже существующими процессами в компании? Если внедренец говорит об этом способе, значит он подходит и все будет хорошо? Можно влегкую применить этот способ или есть противопоказания?

Фатхуллин Равильевич 20 марта 2017 г. 16:06  

Из опыта на больших проектов:

1. Если есть возможность разделить запуск процессов по этапам или подключение всех пользователей по этапам - надо делить.

2. Детальная инструкция по сильно функциональной системе - это не рабочие инструкции. Чем проще и понятней инструкция тем лучше.

3. Самообучение - обязательно, например краткие видеоролики. Обязательно проверка знаний (можно просто перечень вопросов на бумажке,  чем качественнее тем лучше (совместно с приказом очень стимулирует)).

4. Хотите экономить на оплате Исполнителю выделите сотрудников под 100% загрузку и сделайте систему премирования (подсчитаете затраты там видно будет есть ли экономия).

5. Советов может быть много - выбирайте команду которая может внедрить (либо есть опыт и либо такое желание и уверенность, что можно и договориться о деньгах). Не работайте с тем кто за хлеб трудиться - им терять нечего.

Тимур Шайхутдинов 20 марта 2017 г. 13:25  

Евгений, полностью от обучения конечно отказываться не стоит.

Но если обучать всех 5000 пользователей, то это примерно 250(!) проведенных семинаров. Как вы сами понимаете, это достаточно трудоемкий и дорогой процесс, к тому же долгосрочный.

Можно предложить решения:

1.      Сделать упор на самообучение. Нужно подготовить подробные инструкции или шпаргалки по работе в системе. Например, в формате коротких видео роликов с комментариями.  Опыт подсказывает, что время "компьютерной безграмотности" среди офисных сотрудников уже прошло, поэтому разобраться в функционале не составит труда.

2.      Обучить только выделенных от подразделений специалистов. Они в свою очередь уже смогут подсказать своим коллегам в сложных вопросах. 

3.      В процессе опытной эксплуатации запланировать проведение семинаров для тех, кто не до конца уверен в своих знаниях. В этом случае можно заодно разобрать реальные кейсы, которые возникают у пользователей.

 

Евгений Кочуров 20 марта 2017 г. 07:49  

Интересная статья от опытного специалиста. Поделитесь еще живым опытом внедрения.

А можно ли по каким-либо конкретным значениям характеристик компании Заказчика сразу сказать где и как можно экономить, а где это будет связано с неоправданными рисками и экономить не стоит?

Например, если заказчик планирует подключить к системе 5000 пользователей, то отказываться от обучения пользователей при внедрении противопоказано.

 

Юрий Зерин 20 марта 2017 г. 18:38  

Поживем увидим. Однако есть банковская политика и у каждого банка она своя. У ЕСИА совершенно другое направление практического использования. Думаю, что в рамках банковских услуг по  страховой деятельности, проведения  биллинговых операций, выхода на некоторые биржевые площадки, предоставления информационных услуг это еще допустимо. Но там где касается кредитно-расчетных отношений  звена "Банк-Клиент" это большой вопрос.

Сергей Бушмелев 15 марта 2017 г. 22:47  
Ну и интеграцию учетка-сервис придется делать М:М (или сервис/шину какую-то объединяющую вводить)

Да, в этом случае какое-то интеграционное/маршрутизирующее решение понадобится. И как оно будет реализовано (путем доработки КИС, решение на базе ECM-системы, специализированное интеграционное решение или сервис) - это уже придется решать в каждом отдельном случае по-своему. Так как информационные "ландшафты" организаций, навыки персонала, объем ИТ-бюджета - все это определяет, какое решение будет оптимальным.

Еще один сценарий: клиент выгружает очень сырые данные, к тому же сгруппированные в один физический документ. Преобразование и "резка" идет на стороне оператора. В этом случае хранение сырых данных в  ECM-системе тоже может оказаться малоэффективным.

Или когда в ЮЗЭДО-сервис ежедневно выгружаются значительные объемы документов (тысячи, десятки тысяч и т.д.). Тут тоже стоит изучить вопросы - не станет ли ECM-система узким местом, какие преимущества даст "транзит" документов через ECM?

Опять же, в разных кейсах ответы будут разные.  

объемы документов - стоимость хранения документов в сервисе при их  значительном объеме.

 

обязательства оператора по сроку хранения документов - насколько мне известно сервисы пока услугу долгосрочного хранения не предлагают?

Не буду говорить за всех операторов, так как не изучал специально этот вопрос, но мне известны случаи, когда сервис предлагает бессрочное хранение, после окончания подписки документы будут доступны на выгрузку бесплатно.

Не исключено, что при изменении объемов базы операторов условия будут меняться. Операторский рынок в России ЮЗЭДО только формируется, сейчас трудно что-то предполагать и обещать. 

Еще один момент. Начну издалека...

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

Известны и обратные прецеденты - когда документ может сыграть свою роль и после окончания "срока годности". И когда разные требования разных регуляторов предполагают прямо противоположные действия. Наталья Храмцовская рассказывала и писала про такие казусы.

Так вот, все вышесказанное должно подвести под мысль, что хранение документов в облаках (специализированный оператор или ЮЗЭДО-оператор), равно как и хранение "у себя" не освобождает организацию от задачи управления документацией (Records Management). Делать это придется все равно. Опять же, для разных организаций разные сценарии (использование собственных, облачных, гибридных приложений и сервисов) будут оптимальными. Тут у ECM или облаков, на мой взгляд, нет каких-то универсальных (для всех клиентов) преимуществ и фатальных недостатков. 

Елена Истомина 15 марта 2017 г. 13:08  

"Ну, и ЮЗЭДО-сервисы  тоже развиваются, предлагая некую функциональность по хранению, согласованию документов, плюс могут быть интегрированы с сервисами предоставления документов в контролирующие органы"

Да, безусловно, сервисы развиваются и при отсутствии СЭД вполне способны задачи такие решать.

"Против" использования сервиса без СЭД могут играть следующие факторы:

  • использование  нескольких сервисов (я же изначально "на вход" обозначала несколько сервисов и учеток) - в этом случае поиск и выгрузку документов придется это делать последовательно из каждого используемого сервиса. Аналогично придется в разных местах документы подписывать, отправлять и обрабатывать ответы. Хорошо, если это делают разные люди, а если один? Ну и интеграцию учетка-сервис придется делать М:М (или сервис/шину какую-то объединяющую вводить)
  • отсутствие документов в "локальном доступе" - как ни крути, многие предприятия облаку пока не доверяют. А тут речь идет о финансовой информации, которую надо уметь предоставить в любой момент.
  • объемы документов - стоимость хранения документов в сервисе при их  значительном объеме. В целом использование облаков д.б. дешевле, но для операторов это на самая прямая обязанность, и "доп. опция" по расширенному хранилищу может оказаться дорогой (но не изучала вопрос)
  • обязательства оператора по сроку хранения документов - насколько мне известно сервисы пока услугу долгосрочного хранения не предлагают?

Еще из кейсов "неоправданного использования СЭД" могу добавить, что иногда встает вопрос: зачем СЭД "нагружать" такими объемами документов? Размер финансового архива может в разы превышать остальной документооборот и негативно влиять на скорость работы и обслуживания системы. Но тут можно пойти по пути выделения для архива отдельной базы/хранилища, в зависимости от того, какую архитектуру предлагает используемая ECM-система.
 

Сергей Бушмелев 15 марта 2017 г. 10:46  

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

Однако, если из ERP систем идет большой поток документов, не во всех случаях будет оптимальным пропускать этот поток еще и через ECM. Особенно это касается первичных документов. ERP может работать и напрямую с сервисом ЮЗЭДО, не говоря уже и про сервисы EDI. 

Ну, и ЮЗЭДО-сервисы  тоже развиваются, предлагая некую функциональность по хранению, согласованию документов, плюс могут быть интегрированы с сервисами предоставления документов в контролирующие органы.

Поэтому, если функциональности сервисов и интеграционных решений хватает, на практике можно обойтись без ЕСМ системы на шагах 1,2,3,4,5,6. Не считайте меня противником ECM, но ECM и СЭД - это инструменты, как все КИС и сервисы. И к снижению производительности труда может приводить как ниеспользование инструмента, так и его неоправданное использование.

Да, последнее высказывание получилось в стиле "капитан Очевидность"  :)