Русский
Русский
English
Статистика
Реклама

Электронная документация

Доверенная третья сторона как с ее появлением меняется электронная подпись

24.12.2020 18:19:54 | Автор: admin


За последние 10 лет принципиальным образом так и не решились вопросы удобного и долговременного (или еще архивного) хранения документов c электронной подписью (ЭП) и их обмена со взаимным доверием. Да, есть специальные архивные разновидности расширенных форматов ЭП (CAdES-A и XAdES-A), которые содержат несколько меток времени, списки отозванных сертификатов и цепочки удостоверяющих центров (УЦ) на момент формирования ЭП. Есть варианты решений с переподписанием документов с ЭП или созданием доверенной среды для их хранения. Однако все это не добавляет юзабилити. Появились и новые проблемы: отсутствие единой политики применения квалифицированных сертификатов в коммерческих информационных системах (особенно на торговых площадках), из-за чего в сертификаты начали добавлять узкоспециализированные OID; отсутствие единого реестра выданных сертификатов при значительном увеличении их числа; большое количество УЦ и их текучка; попытки мошенничества с недвижимостью и налоговыми декларациями при помощи квалифицированных сертификатов с ЭП, полученных мошенническим образом.

Принятые 27 декабря 2019 г. изменения в Федеральный закон Об электронной подписи нацелены на то, чтобы, наконец-то, устранить большинство этих проблем, узаконить облачную ЭП, а также фактически перестроить рынок удостоверяющих центров. Закон также вводит новый институт доверенную третью сторону (ДТС). Нормы о ДТС должны вступить в силу с 1 января 2021 года. Несмотря на это, почти все, что связано с ДТС, еще в ожидании разъяснений и регламентации со стороны регуляторов. Попробую описать подробно, что нас ждет.


Какие неочевидные проблемы краткосрочности обычной электронной подписи существуют сегодня?


Я работаю в подразделении, которое занимается прикладной интеграцией. Так сложилось, что нам не приходилось внедрять штатную ЭП для документооборота из коробки или внедрять готовые клиентские приложения для работы с ЭП. Почти всегда задачи внедрения сводились к встраиванию ЭП (включая разного рода автоматизации по обслуживанию жизненного цикла сертификатов, ключей и их носителей) в существующие и совсем не коробочные документообороты или в информационные системы, в том числе с длительным хранением документов. На первых этапах проектирования процесс формирования ЭП больших сложностей обычно ни у кого не вызывал. Казалось бы, ну что тут? Сформировать хеш на документ и подписать его закрытым ключом с использованием базовых форматов электронной подписи, например, CAdES-BES или XAdES-BES. А вот потребность в дальнейшем среднесрочном и долговременном хранение документов с ЭП, проверка ЭП в документообороте (в том числе автоматизированная) всегда в конечном итоге влияли на архитектуру решения. Усложнялись форматы ЭП, начиная от CAdES-T и XAdES-T (с метками времени) и заканчивая их расширенными и специальными A-версиями (Archival). А дальше всё по кругу возвращалось к процессу формирования ЭП, чтобы обеспечить необходимым контекстом выбранный для нее формат.

Так как осуществить проверку ЭП документа, хотя бы лет так через 10-15? (Опустим такую подробность, что, скорее всего, спустя столько лет не будет сертифицированных средств криптографической защиты информации (СКЗИ), поддерживающих нужные криптографические алгоритмы и нужные форматы, а необходимые средства просмотра электронных документов не будут запускаться на текущих ОС.)

Обратимся к закону об ЭП (от 06.04.2011 63-ФЗ). Какие условия признания (проверки) квалифицированной ЭП содержатся в статье 11 Признание квалифицированной электронной подписи (приведу только пункт 2 статьи, потому что именно он влияет на проверку документов с ЭП во времени):
Квалифицированная электронная подпись признается действительной [] при одновременном соблюдении следующих условий:

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

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

Законодатель не предложил и даже не намекнул на способы подтверждения достоверности информации о моменте подписания электронного документа. Впрочем, это нормально. Требования к процедуре должны раскрывать ответственные регуляторы. И спустя 9 лет, после того, как в конце 2019 года вышли изменения к закону об ЭП, Минцифры России и ФСБ России (в части работы с меткой времени, но об этом дальше), наконец-то, разработали проекты приказов. Пока же бремя доказывания достоверности момента подписания все еще лежит на плечах разработчиков СКЗИ и на владельцах информационных систем. Например, полагаясь на открытые международные спецификации и стандарты, они вынуждены сами выбирать форматы ЭП, в том числе с меткой времени, и ждать, подтвердит или скорректирует их подход судебная практика.

Какие решения для обхода краткосрочности базовой ЭП обычно используют?


Единый стандарт для формата ЭП с меткой времени в процессе разработки. Самым очевидным, с точки зрения среднесрочного (5-10 лет) и долгосрочного хранения документов с ЭП, является реализация квалифицированной ЭП в одном из расширенных форматов (на усмотрение владельца ИС) как минимум:

  • с внедренной меткой времени для достоверного определения момента подписания электронного документа сроком до 15 лет (теоретический максимальный срок действия сертификата ключа проверки ЭП сервиса меток времени);
  • с информацией о факте проверки сертификата в виде приложенного ответа от OCSP-службы (службы онлайн-проверки статуса сертификата) или приложенного списка отозванных сертификатов (обеспечивающего подтверждение действительности квалифицированного сертификата на момент подписания), подкрепленных меткой времени.

К менее очевидным и менее распространенным решениям, обеспечивающим проверку ЭП документа через N-лет, относится создание доверенных сред хранения. В такую среду документ с ЭП помещается чаще всего еще во время действия выданного пользователю квалифицированного сертификата ЭП (например, сразу после подписания) с максимальным набором метаданных. При помещении документа с ЭП в доверенную среду проверяется ЭП, статус сертификата, формируются расширенные отчеты о фактах проверок. После этого целостность документа и всех связанных с ним метаданных обеспечивается доверенной средой. К таким решениям можно отнести, например, и внутренние/отраслевые реестры крупных организаций, в которых регистрируется максимально возможный набор метаданных документа с ЭП (как минимум, атрибуты документа и его хеш, ЭП, идентификатор сертификата и сам сертификат ЭП, факт проверки сертификата с меткой времени, отдельно метка времени на ЭП). При желании все это может быть подписано сверху технической подписью архивариуса. В целом это подходит для внутренних нужд крупных компаний и организаций, где документы с ЭП не отчуждаются из системы или сама ЭП первично реализовывалась без метки времени.

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

Как изменит ситуацию появление доверенной третьей стороны?


Мы добрались до самого главного. В дополнениях к 63-ФЗ Об электронной подписи от 27.12.2019 вместе с целым рядом изменений, в том числе юридическим признанием облачной ЭП, появляется институт доверенной третьей стороны (статья 18.1). Это новый вид организации, которая призвана обеспечить доверие при обмене электронными документами с ЭП.

Законом определяется перечень услуг, которые ДТС будут оказывать участникам электронного взаимодействия:

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

Иными словами, появляется аккредитованная организация (а не просто набор сервисов при аккредитованном УЦ), предоставляющая такой необходимый набор услуг:

  • проверка действительности ЭП и сертификатов на определенный момент времени;
  • проверка полномочий владельцев сертификатов ЭП;
  • выдача квитанций с результатами проверки квалифицированной ЭП;
  • ведение фактического реестра выполняемых (верифицируемых) операций.

По сути это все те задачи и соответствующие аккредитованные решения по проверке ЭП во времени, которые призваны обеспечить внешний доверенный электронный документооборот с ЭП и минимум среднесрочное хранение документов.

А что не так с меткой времени и когда она должна заработать?


Подчеркну, что, в первую очередь, меня интересует правовое закрепление использования метки времени и унификация формата ЭП с меткой времени, а не сами расширенные форматы ЭП (основанные на разных международных стандартах), в которых метка времени давно уже используется.

К сожалению, законодатель (до декабря 2019) и регуляторы (до сентября 2020) не раскрывали функционал метки времени. Отсюда пошли различные несовместимые между собой форматы ЭП. Они вроде бы и являлись усиленными квалифицированными и были выполнены на сертифицированных средствах, но обмен документами с такими ЭП с автоматическим доверием между разными информационными системами в обход системы межведомственного электронного взаимодействия (СМЭВ) был невозможен. В СМЭВ, конечно же, используется метка времени, выдаваемая внутренним сервисом для ЭП в формате XAdES-T, но решает она скорее транспортные задачи при передаче документов.

На сегодня с меткой времени больше ясности, но пока она так и не закреплена в нормативно-правовых актах.

Метка доверенного времени (именно так указано в законе об ЭП, но я везде пишу просто метка времени) добавлена изменениями к закону об ЭП от 27.12.2019 г. Правда этот термин упоминается однократно в ст. 2 Основные понятия, используемые в настоящем Федеральном законе, и больше нигде не используется. Норма о метке времени вступает в силу одновременно с нормой о ДТС (с 01.01.2021 года), поскольку они связаны между собой.

Закон определяет метку времени так:
Достоверная информация в электронной форме о дате и времени подписания электронного документа электронной подписью, создаваемая и проверяемая доверенной третьей стороной, удостоверяющим центром или оператором информационной системы [].

Таким образом, метка времени может создаваться и проверяться ДТС, УЦ и оператором ИС, если она получена:
[]в момент подписания электронного документа электронной подписью в установленном уполномоченным федеральным органом порядке с использованием программных и (или) аппаратных средств, прошедших процедуру подтверждения соответствия требованиям, установленным в соответствии с настоящим Федеральным законом.

Почти год спустя (14 сентября 2020 г.) после появления метки времени в законе об ЭП вышел приказ Минцифры России 472 Об утверждении Формата электронной подписи, обязательного для реализации всеми средствами электронной подписи. Он, наконец-то:

  • унифицировал формат ЭП,
  • ввел требование к наличию времени создания ЭП в составе ЭП ( без четкого указания на метку времени),
  • предусмотрел опциональную возможность включения списка отозванных сертификатов в состав электронной подписи.

Далее. В дополнение к приказу Минцифры России 472 (где, как я написал выше, нет ни определения метки времени, ни ссылки на нее, но есть требование к размещению в составе ЭП времени создания ЭП) появилось 2 проекта правовых актов:

  • приказа Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации Об утверждении порядка создания и проверки метки доверенного времени в версии от 09.10.2020. Здесь раскрывается порядок создания и проверки меток времени службой меток доверенного времени (новый термин), определяются протокол взаимодействия со службой штампов времени (еще один новый термин), а также формат и содержание метки времени;
  • приказа ФСБ России О внесении изменений в приложения 1 и 2 к приказу ФСБ России от 27 декабря 2011 г. 796 Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра. Он обязывает создавать средства, реализующие механизмы формирования меток доверенного времени и службы меток доверенного времени в составе УЦ.

Очевидно, что ДТС для фиксирования определенного момента времени также нужна метка времени или сертификат ЭП, срок действия которого еще не истек. Метка времени должна быть одновременно и доверенной, и правильной (ДТС должна ее понимать). И, скорее всего, идеальный алгоритм проверки электронных документов с ЭП, в которых реализована метка времени, в ДТС будет следующем:

  1. Создание электронного документа с ЭП, где ЭП реализована средствами и в формате с поддержкой метки времени (приказ Минцифры России 472).
  2. Получение метки времени в ДТС или где-то еще (в УЦ или у оператора ИС).
  3. Встраивание метки времени (выданной аккредитованным сервисом ДТС/УЦ/оператор ИС) в документ с ЭП.

И только если все эти этапы будут пройдены, ДТС сможет подтвердить действительность электронной подписи со всеми плюшками и расширенными отчетами. Что из этого следует? Все, кто пожелает использовать ДТС для проверки документов с ЭП после истечения срока действия сертификата ЭП, должны иметь:

  • ЭП расширенного формата (тот же приказ Минцифры России 472, в котором, повторюсь еще раз, метка времени не определена);
  • средства работы с ЭП (СКЗИ, прикладное ПО), которые поддерживают работу с метками времени (технически это может быть и отдельный файл с еще одной отсоединенной электронной подписью сервиса меток времени);
  • соблюдение алгоритма по получению метки времени и встраивания ее в документ с ЭП.

Формат метки времени
Проект приказа Минцифры России, о котором я писал выше, предлагает сделать rfc 3161 Time-Stamp Protocol (TSP) основой для формата метки времени и протокола взаимодействия со службой штампов времени. Кроме того, в документе предъявляются общие требования к алгоритму работы службы штампов времени. Вот некоторые из них:

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

Если пропустить параметры, касающиеся протокола взаимодействия вызывающей стороны со службой штампов времени, то сама метка времени TimeStampToken будет выглядеть так:

image

На ум приходит пока только пара производителей СКЗИ, которые уже выпускают средства (серверную часть, библиотеки и клиентскую часть) для работы с меткой времени по rfc3161.


Нормативно-правовые акты регуляторов еще не приняты, тем не менее пазл с меткой времен начинает сходиться:

  • есть требования к ЭП (приказ Минцифры России 472, который определяет необходимость учитывать время создания ЭП);
  • есть требования к службе и формату метки времени (проект приказа Минцифры, см. выше);
  • есть требования к СКЗИ, в которых должна поддерживаться метка времени (проект приказа ФСБ, см. выше);
  • есть требования к УЦ и ДТС, в составе которых должна быть реализована служба меток доверенного времени (тот же проект приказа ФСБ, см. выше).


Сложный функционал проверки полномочий в ДТС


Вернемся к ДТС и функционалу проверок правильности применения сертификатов ЭП и полномочий. В соответствии с изменениями в законе об ЭП от 27.12.2019 ДТС выступает в том числе в роли авторизационного центра, выполняющего:

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

При этом первый пункт также должен включать проверку правильности применения сертификата квалифицированной электронной подписи (КЭП):

  • ведомственной или организационной принадлежности УЦ, чей сертификат КЭП используется в конкретных электронных правоотношениях (правоотношения юридических лиц УЦ налоговой службы; правоотношения финансовых, кредитных организаций УЦ Центробанка; правоотношения лиц, представляющих органы государственной власти и органы местного самоуправления, УЦ Федерального казначейства; правоотношения физических лиц коммерческие аккредитованные УЦ);
  • типа сертификата квалицированной электронной подписи (физлицо, юрлицо, ИП) на правильность его применения в конкретном электронном правоотношении.

Отдельно разберемся со вторым пунктом проверкой полномочий. Кроме правильности применения типа сертификата выданного на физлицо, юрлицо или ИП, здесь должна выполняться проверка документа о полномочиях, который должен быть подписан КЭП уполномоченного в установленном порядке на принятие соответствующих решений должностного лица соответствующего государственного органа или органа местного самоуправления. Сами же полномочия должны быть определены на основании классификатора полномочий, который уполномоченный федеральный орган формирует, актуализирует. В соответствии со статьями 17.2 и 17.3 закона об ЭП необходимо также проверить наличие и содержимое электронной доверенности, поскольку именно она уполномочивает сторону на те или иные правоотношения. Таким образом, при проверке полномочий ДТС должна также проверять:

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

Выполнять данные проверки, конечно же, сможет прикладная система. Она понимает контекст электронных правоотношений, знает, какие полномочия и доверенности допустимы с сертификатами КЭП и с какими УЦ можно/нужно работать. Другой вопрос, как будет проводить такие проверки ДТС, ведь она не обладает информацией о контексте правоотношений.

Авторизационные операции при использовании сертификатов ЭП, с одной стороны, унифицировались. Специфицированные OID-ы в сертификатах ЭП теперь должны игнорироваться, а схемы авторизаций по принципу свой/чужой OID с 01.06.2020 вне закона. С другой стороны, разграничение полномочий и правила применения сертификатов ЭП трансформировались в более сложные процессы, которые еще должны быть отрегулированы к 01.01.2022.

Белые пятна в проверке полномочий
В проекте приказа ФСБ России Об утверждении Требований к средствам доверенной третьей стороны, включая требования к используемым доверенной третьей стороной средствам электронной подписи разъяснений по авторизационным функциям ДТС так и не последовало. Например, пункт 2.3 проекта требований гласит:

Компонент проверки полномочий должен осуществлять проверку полномочий должностного лица отправителя электронного документа, являющегося владельцем сертификата ключа проверки электронной подписи.


Не ясно, где, например, проверка полномочий физического лица, действующего на основании документа о полномочиях или действующего на основании электронной доверенности? И какие именно полномочия должностного лица тут будут проверяться? Будем надеяться, что требования к применению доверенностей и полномочий, которые вступают в силу только с 01.01.2022, еще будут уточнены.

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


Выводы: уже куда-то бежать или ждать?


Легализация хранения и дистанционного использования средствами УЦ облачной ЭП с 01.01.2021 должна запустить новый виток ее развития. Это касается увеличения количества внедряемых услуг на базе ЭП (особенно в наше ковидное время) и удобных сервисов работы с ЭП для мобильных клиентов и клиентов на рабочих местах, которые, в свою очередь, будут нуждаться во внешних обслуживающих сервисах проверки ЭП (на базе ДТС).

Скорее всего, либо под новый год, либо сразу же после праздников упомянутые мною приказы примут. Потом разработчикам СКЗИ потребуется еще месяца 3-4 для корректировки клиентского ПО и библиотек под новый формат ЭП с меткой времени и сервисы служб меток доверенного времени. К слову, последние у ключевых разработчиков СКЗИ уже реализованы и эксплуатируются как TSP-службы штампов времени.

Далее потребуется еще некоторое время на разработку функционала ДТС, явно не завязанного на какие-либо форматы, но необходимого по закону об ЭП:

  • создание квитанций с результатом проверки КЭП в электронном документе;
  • хранение данных, в том числе документирование выполняемых ДТС операций.

С учетом всех необходимых доработок ПО, а также организационных процедур на аккредитацию, ждать появления первых ДТС раньше лета 2021 года, думаю, не стоит. Может быть, ФНС и ключевой разработчик СКЗИ выпустят что-то раньше в качестве тестовой версии ДТС.

Услуги ДТС, очевидно, не будут бесплатными для всех, и все затраты прямо или косвенно лягут на участников электронного взаимодействия.

Появление на рынке ДТС должно в итоге способствовать появлению полезных сервисов (в первую очередь, в виде API для встраивания), которые смогут обеспечивать:

  • подтверждение действительности электронных подписей,
  • проверку полномочий участников электронного взаимодействия;
  • формирование отчуждаемых квитанций с результатом проверки КЭП электронных документов;
  • формирование меток времени, которые можно использовать не только для документов с ЭП, но и для электронной корреспонденции, для иных сервисов, требующих фиксации времени.

Эти сервисы можно будет встраивать в информационные системы, например:

  • для среднесрочного хранения документов,
  • для экспорта/отчуждения документов пользователям без опасения, что они станут непроверяемыми через год,
  • для автоматизированного принятия решений на основании результата проверок ЭП.

Сервисы найдут применение и в мобильных клиентах разных информационных систем, в том числе для работы с облачной ЭП. Второй вариант соответствует недавно озвученному предложению Максута Шадаева, министра цифрового развития, связи и массовых коммуникаций России:

Нам кажется, основной сценарий использование электронной подписи на смартфоне. Такое техническое решение мы с коллегами согласовали, такая возможность есть.


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

Итого: заявленные изменения в законе об ЭП и предложенный функционал ДТС действительно интересны, долгожданны и обязательно будут востребованы. Метка времени (которая вводится одновременно с ДТС с 01.01.2021) автоматически решит проблемы среднесрочного хранения документов. ДТС и унифицированный формат ЭП с меткой времени позволят осуществлять доверенный оборот документов с ЭП старше 1 года и проверять их после отчуждения из системы. Конечно, многое зависит от реализации, и в том числе от регламентов и приказов Минцифры России и приказов ФСБ России, которые в идеале должны привести к единому знаменателю технические решения по всем ДТС.

Вместо P.S. Будущее рынка УЦ и ДТС


И напоследок хотелось бы написать про возможное схлопывание рынка УЦ.

Этим же законом изменен срок аккредитации УЦ с 5 до 3 лет. Аналогичный срок 3 года определен для аккредитации ДТС. При этом значительно возросли требования к УЦ. Теперь необходимо:

  • минимум 1 млрд рублей собственных средств (капитала) или 500 млн рублей капитала, но при этом один либо несколько филиалов или представительств УЦ должно быть размещено не менее чем в 3/4 субъектов России (аналогичное требование к ДТС);
  • финансовое обеспечение ответственности за убытки, причиненные третьим лицам в размере не менее 100 млн рублей для УЦ (сейчас это 30 млн рублей). Для ДТС размер еще не определен.

По оценкам экспертов, увеличение требований к минимальному капиталу приведет к сокращению количества УЦ более чем в 10 раз уже в 2021 (примерно с 450 до 20-40). По аналогии не ожидается и появления значительного количества ДТС, которые, скорее всего, будут созданы при ключевых УЦ (Центробанке, налоговой службе, казначействе), чтобы обслуживать их внутренние потребности. Возможно, они появятся и при нескольких крупных выживших коммерческих аккредитованных УЦ.

Пользователям или разработчикам небольших прикладных систем (тех, кто хотел бы внедрить документооборот с облачной ЭП), конечно же, интереснее работать с независимыми от удостоверяющих центров ДТС, а также взаимодействовать со всеми или большинством крупных УЦ.

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

Пишите, если есть вопросы не для комментариев вот моя почта: SGontzov@croc.ru.
Подробнее..

Настоящий металл как сплавить команды в горниле совместной разработки

28.12.2020 16:18:38 | Автор: admin

У нас было 2 проектных менеджера, 72 эксперта от производства, 33 высококлассных спеца из двух IT-команд, несколько десятков систем управления производством по всей стране, а еще, разработчики КРОК и Группы НЛМК прежде не работали вместе.

Звучит как организационный ад, и это недалеко от истины. Но мы справились и теперь хотим поделиться опытом работы в объединенной команде НЛМК и КРОК в масштабном проекте по развитию информационных сервисов службы продаж.

На этот раз КРОК работал вместе с Группой НЛМК одной из самых крупных сталелитейных компаний с заводами в семи странах. Нашей объединенной команде предстояло масштабировать и усовершенствовать систему маркировки продукции так, чтобы, считав с этикетки QR-код, можно было получить исчерпывающую информацию о продукции через онлайн сервис.

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

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

Это не просто формальность. Сертификат качества в металлопродукции это как свидетельство о рождении и одновременно медицинская карта для человека. Без него сложно понять, например, подойдет ли арматура для строительства многоквартирного дома, выдержит ли она нагрузку.

Нашими стараниями, к бумажным сертификатам добавились QR-кодыНашими стараниями, к бумажным сертификатам добавились QR-коды

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

Другое дело цифровой сертификат. Можно заверить его электронной подписью, добавить исчерпывающие характеристики товара и напечатать на каждой этикетке или бирке QR-код с уникальной ссылкой на все эти данные. А для проверки электронно-цифровой подписи существуют специальные общедоступные сервисы. В частности, подлинность ЭЦП не сложно проверить на портале Госуслуги.

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

Работа в тандеме

Группа НЛМК сотни видов продукции и заводы, похожие на маленькие города. Каждый с многолетней историей и собственными вычислительными центрами. Мягко говоря сильно непростое хозяйство.

В НЛМК сложный IT-ландшафт на каждом заводе, в каждом цехе свой парк оборудования и связанные с ним MES (manufacturing execution system) системамы планирования и управления производством. Это десятки цеховых систем управления, которые работают в разных часовых поясах, предоставляют данные в разное время и в разных форматах, а также системы корпоративного класса (ERP, CRM и пр.)

Чтобы реализовать QR-кодирование продукции, нам нужно было найти общий язык с системами на четырех российских площадках Группы НЛМК: Новолипецком комбинате, НЛМК-Урал, НЛМК-метиз и НЛМК-Калуга.

Катанка, моталка, прокатка, бунт, швеллер и подмотка лишь некоторые термины и слова, которые вошли в мой словарь за время работы с НЛМК, Марина Зиновьева, аналитик проекта, КРОК.

В подобных случаях необходимы и большой опыт системной интеграции в промышленности, и знание конкретного производства. Так что, обычный аутсорсинг здесь мало применим. Группа НЛМК предпочитает интегрированный подход над проектом работает объединенная команда разработчиков.

Распределение зон ответственности в рамках проектаРаспределение зон ответственности в рамках проекта

В нашем случае часть команды со стороны Группы НЛМК отвечала за общее видение системы, архитектуру и архитектурный контроль, инфраструктуру. Они предоставили экспертизу по MES. DevOps, проектирование, планирование работы и собственно разработка были на стороне КРОК.

Для разработчиков КРОК это был первый масштабный проект в такой тесной связке с командой НЛМК. И что могло пойти не так?

Старт проекта

Разработчики Группы НЛМК провели большую подготовительную работу, связались с ключевыми клиентами и выяснили их потребности, изучили процедуру выпуска сертификатов, продумали архитектуру будущей цифровой платформы.

Они ожидали от партнера такой же погруженности. Поэтому для команды КРОК проект стартовал будто с места в карьер. Через несколько часов после окончания конкурса раздался звонок:

Добрый день! Присылайте план проекта.

Здравствуйте, приятно познакомиться, сейчас пришлем.

Не спали ночь, но прислали.

Первые три недели команда КРОК планировала пустить на изучение текущих наработок и IT-ландшафта предприятия, но оказалось, что нужно показать первые результаты разработки уже через две недели после старта проекта. Это было жестко.

Для НЛМК проект оказался так важен, что они провели собеседования с каждым членом нашей команды, Ярослав Репной, менеджер проекта, КРОК.

Команда КРОК боялась, что за первые две три недели ничего не успеет. Напряжение росло, но на выручку пришел бизнес-заказчик. Он выделил задачи, которые помогли быстро выработать общие подходы к работе и видение проекта.

Пара коротких спринтов на практике доказала, что разработчики КРОК и Группы НЛМК могут продуктивно работать вместе. Появилось время, чтобы познакомиться с новыми коллегами и вникнуть в нюансы задачи.

Важно подчеркнуть, что разработка велась на базе Единой Цифровой Платформы (ЕЦП), которая развернута в НЛМК как целевая экосистема для внедрения новых цифровых продуктов. В основе подходов к созданию ЕЦП лежит гибридная IT-архитектура, задачей которой является сочетание коробочных IT-компонентов и открытой платформы. Платформа обеспечивает унифицированные технические компоненты и данные для построения сквозных сценариев, создания цифровых продуктов и приложений.

Не у каждой IT-компании есть аналогичные решения. Как правило, приходится внедрять такие решения у заказчика самим. Это сильно ускорило нашу работу в ЕЦП все спроектировано, задумано и внедрено удобно. Спорить с НЛМК в части ЕЦП не приходилось вообще OpenShift, Kafka, S3 всё на месте, всё как мы любим.

Учитывая, что и другие продукты уже начинали запускаться параллельно с нами, ЕЦП в НЛМК можно называть зрелой экосистемой. Ни одной значимой технической проблемы в проекте не было. Вместо этого, нас ждали организационные вызовы.

Аджайл VS реальность

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

Проект состоит из семи этапов, так что мы разбили работу на параллельные потоки:

  1. тираж QR-кодирования сертификатов качества и готовой продукции на трех производственных площадках;

  2. разработка сервиса для утверждения сертификатов качества электронной подписью;

  3. разработка стартовых веб-страниц для экспортной продукции группы НЛМК;

  4. разработка мобильного приложения для фотографирования транспортных средств и готовой продукции;

  5. API для интеграции сервиса с информационными системами покупателей;

  6. разработка тартовой страницы для предоставления информации по продукции, маркируемой DataMatrix-кодами;

  7. разработка сервиса для автоматизации работы с несоответствиями готовой продукции (подача претензий по QR-кодам).

Фактически ребята ведут семь 7 потоков параллельно. Одну задачу разрабатывают, другую проектируют, третью выводят на демо, а по четвертой ждут результаты от зависимых систем, Ангелина Панарина, руководитель проекта, НЛМК-ИТ.

Вскоре стало ясно, что при таком количестве задач двухнедельных спринтов не хватает, чтобы довести макеты до релиза. Пришлось удлинить спринты до 3 недель.

Еще мы поняли, что не можем заранее утвердить проектную реализацию и сделать фиксированные спринты.

По одной из новых схем интеграций у нас не было готовых стандартов. Мы сделали предложения по интеграции, а через неделю поняли, что хотим все изменить. Ребята из КРОК отнеслись к этому лояльно, и все сделали. Зачастую, подрядчики отказываются делать внеплановые доработки, но в этом проекте мы находим компромиссы, потому что все ориентируются на результат, Михаил Скрипник, специалист направления производственных решений, НЛМК-ИТ.

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

Распределенная команда

Со стороны КРОК в проекте участвовало 11 человек. Ядро команды Группы НЛМК состояло из 24 IT специалистов. Получилась гибкая и разносторонняя команда, но постепенно в проект оказалось вовлечено больше 100 сотрудников из других подразделений НЛМК: эксперты от производства, интеграторы MES, инженеры, специалисты и руководители по продажам и начальники цехов.

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

Ачивмент: встать в шесть утра, чтобы зарядить разработчиков из Иркутска.

У техподдержки, например, на Урале свои: задачи, сроки и проблемы. Им приходилось одновременно участвовать в нескольких крупных проектах, решать текущие вопросы и поддерживать системы. Они оказались очень загружены.

Вы мне про аджайл, а мне оборудование настраивать надо, инженер Группы НЛМК, пожелавший остаться неизвестным.

Конечно, можно было форсировать работу через начальство, но так не добиться заинтересованности в результате, да и можно помешать другим проектам Группы НЛМК.

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

Пришлось смириться, что инженеры и сотрудники производства работают в другом ритме, за рамками спринта. Мы завели для них отдельный реестр поручений, регулярно обзванивали их, обновляли статусы задач и напоминали о сроках. Кстати, реестр показался бизнес-заказчику таким удобным, что он заглядывал туда чаще, чем в Jira.

Сложности коммуникации

Участники объединенной команды были разбросаны от Минска до Иркутска. Даже не будь пандемии, собраться вместе мы бы не смогли. Так что в начале проекта Skype-конференции стали основным каналом связи. Календарь состоял из непрерывных встреч и обсуждений. Времени на разработку не оставалось.

Когда собирается больше десяти человек из разных отделов (например, разработчики, управление сопровождения продаж, производство и контроль качества продукции), совещание затягивается и без дополнительных коллов уже не обойтись.

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

Теперь в коллах постоянно участвуют только менеджеры, техмены, аналитики и ведущие разработчики. Они передают задачи дальше, а остальные подключаются по мере необходимости. Благодаря этому большинство встреч не выходит за рамки регламента.

Итоги встреч мы фиксируем в письменном виде. Такие протоколы много раз выручали, когда информация забывалась или искажалась при передаче.

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

Вместо заключения

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

Для нас КРОК близкие друзья, мы учимся у них гибкости и неформальному подходу к решению задач, Ангелина Панарина, руководитель проекта, НЛМК-ИТ.

На старте мы бы и сами в это не поверили, но первый этап проекта, тираж QR-кодирования сертификатов качества и готовой продукции, был готов за четыре месяца. Мы запустили QR-кодирование на трех производственных площадках Группы НЛМК и заполнили стартовые страницы по огромному ассортименту продукции. Это позволило сократить расходы на обмен бумажными сертификатами, но основная цель этого проекта повышение качества клиентского сервиса.

Одни клиенты НЛМК уже пользуются сервисом и оценили его преимущества, другие пока знакомятся и разбираются, как наше решение упрощает их бизнес-процессы. Одним из следующих этапов развития QR-кодов будет полная интеграция с личным кабинетом клиента в онлайне, а также интеграция со складскими и учетными системами клиентов, Иван Говорухин, менеджер бизнес-решений, Группа НЛМК.

В ближайшем будущем клиенты Группы НЛМК на базе Единой Цифровой Платформы смогут мгновенно получать сертификаты качества, отслеживать поставки товаров, автоматически учитывать их при поступлении на склад при помощи API и быстро сообщать о дефектах продукции через личный кабинет на портале НЛМК.

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

Это был непростой проект, но благодаря ему мы многое поняли. Если возьметесь за совместную разработку:

1. Выделите время на плавный старт

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

2. Убедитесь, что все одинаково хорошо понимают цели и задачи проекта

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

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

Главное создать vision of future, когда все понимают, осязаемо понимают, что мы собираемся делать, Игорь Кораблев, энтерпрайз-архитектор, НЛМК.

3. Изучите команду

Пока вы не знаете, кто за что отвечает и что умеет, решение даже самых простых вопросов будет похоже на скучный, утомительный квест.

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

4. Вовлекайте в совместную работу

Иногда в начале работы для участников объединенной команды неочевидна польза тесного сотрудничества. Ведь после окончания проекта они могут никогда не встретиться. Административным давлением эту проблему не решить. Приглашайте невовлеченных людей на совещания, зовите на демо, в главное общайтесь лично и открыто.

5. Доверяйте друг другу

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

Если это не касается каких-то внутренних ограничений информационной среды, нужно давать подрядчику творить так, как он считает нужным, Олег Богданов, куратор проекта, бизнес-заказчик, НЛМК.

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

6. Держите руку на пульсе

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

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

7. Обучайте и обучайтесь

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

Мы научились ставить задачи друг другу и работать, как единое целое. Я вижу взаимный профессиональный рост разработчиков КРОК и НЛМК, Дмитрий Лаптев, технический менеджер, КРОК.

8. Создайте единое информационное пространство

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

Команде нужно общее пространство для асинхронного общения, где все видят сообщения, и не приходится повторять одно и то же по многу раз. Для нас таким хабом стал Confluence, выполняющий роль как хранилища проектных решений, так и мессенджера.

9. Не пытайтесь решить проблемы на 100%

Привычные подходы могут плохо работать в объединенной команде, но нет такого способа спланировать спринт, чтобы работа всегда шла гладко. Какую бы практику вы ни внедрили, она не даст 100% результат и не избавит разом от всех проблем.

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

P.S. Если у вас остались вопросы, можете написать на ipopkov@croc.ru.

Кстати, а вы работали в объединенных командах? Пожалуйста, поделитесь своим опытом в комментариях.

Подробнее..

Деятельность, документы и семантика

07.07.2020 16:22:26 | Автор: admin
На данный момент современные информационные системы моделирующие деятельность и системы документооборота, юридически обеспечивающие деятельность, разнесены по разным архитектурным уровням, взаимодействующим только по линии контроля и учета. Электронный документооборот с использованием ЭП не не решает проблему разрыва между двумя этими уровнями, обеспечивая лишь скорость и защищенность обмена документами.

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

При решении задачи мы имеем дело с несколькими сущностями

  1. деятельность, состоящая из частично упорядоченной последовательности действий,
  2. документ, представляющий собой множество фактов, юридически обеспечивающих действия,
  3. актор, имеющий право и выполняющий действия, согласно фактам, прописанным в документе,
  4. цифровая модель деятельности, предписывающая и фиксирующая действия актора.

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

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

Наиболее целесообразным решением проблемы технологического разрыва можно считать использование единого, как для описания документов, так и для моделирования деятельности, языка семантической разметки данных. В такой идеологии факт, зафиксированный в документе в виде утверждения на этом языке, должен интерпретироваться в цифровой модели как команда выполнения предписанного этим фактом действия. В идеальном исполнении этого подхода, каждый документ, по сути, должен трактоваться как фрагмент модели деятельности. Предельно важно, чтобы язык семантического описания деятельности и документов был универсальным, то есть независимым от предметной области, а также человеко-читаемым вне и до конкретных цифровых моделей деятельности. Основой такого языка может стать стек спецификаций для представления данных семантического веба (RDF/OWL и др.).

Однако помимо технологического барьера существует еще проблема доверия, то есть подтверждения юридической значимости, как документа, так и действий актора, в качестве которого в модели деятельности наравне с человеком может выступать и программный агент (контроллер, исполняющий команды, записанные на языке семантической разметки). Проблема доверия распадается на две задачи: (1) подтверждение юридической значимости документа (всех его фактов) и (2) доказательство не фальсифицированности действия, выполненного актором, согласно документу.

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

Задача признания юридической значимости результата действия, выполненного по модели, включающей в себя документ, сводится к двум подзадачам: (1) проверка права актора человека или программного агента совершить действие, подписываемое его приватным ключом, (2) исключение случайной или умышленной фальсификации результата действия. Первая задача сводится к автоматической проверке актуальности подписей соответствующих документов в системе. Проблема валидности результата на данный момент может быть решена только достижением консенсуса множества независимых исполнителей модели деятельности, являющихся узлами одноранговой сети.

Итак, идейную основу предложенного решения составляет представление о необходимости совмещения в одной цифровой модели деятельности: (1) алгоритма действий, (2) документа, определяющего юридическую обусловленность этих действий, (3) актора действий, и (4) самой деятельности, которая, по сути, полностью переходит в цифровое пространство.

Технологический базис решения составляют стандартные на сегодняшний день технологии:

  1. криптографические методы шифрования и подписи документов,
  2. системы управления ключами,
  3. одноранговые сети с консенсусной валидацией транзакций,
  4. языки семантической разметки данных.

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

См. еще Семантика и деятельность
Подробнее..

Категории

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

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru