Из опыта разработки отраслевого стандарта электронного обмена информацией
Стандарты и информационные технологии в мире
Современная эпоха характеризуется бурным развитием информационных технологий, и в это революционное время особое значение приобретают процессы выработки стандартов. Сегодня осознание этого факта является без преувеличения одним из ключевых условий успешного ведения бизнеса.
Действительно, вспомним, что любая корпоративная система - это по существу воплощение неких бизнес-требований, описанных в соответствии с конкретной спецификацией. За спецификацией же стоит тот или иной орган стандартизации, возглавляемый ведущими поставщиками программного обеспечения. Поэтому, отдавая предпочтение какому-либо ПО, надо понимать, что при этом выбирается не только продукт с требуемыми функциональными возможностями, но и определенный стандарт. А значит, следует отчетливо представлять, что это за стандарт и какая организация его разрабатывала.
Актуальность темы стандартизации подтверждает и то, что в настоящий момент на ниве стандартизации трудится целый ряд международных организаций. Об этом и многом другом шла речь в статье Камерона Стардеванта "Обретение стандарта" (см. PC Week/RE, N 8/2003, с. 45).
Отметим, что необходимость выработки стандартов во всем мире была понята уже давно, и причин тому немало. Это и сознательность западного общества в целом: традиция регламентировать все стороны жизни, тем более те, что непосредственно влияют на развитие бизнеса. Это и зрелось рынка ПО, проявляющаяся в том, что и разработчики софта, и их клиенты понимают значимость спецификаций и активно участвуют в общем для всех деле. Наконец, нельзя забывать о том, что проекты по разработке стандартов в значительной степени поддерживаются (в том числе и материально) их потенциальными потребителями. Последний мотив по существу представляет собой своеобразную квинтэссенцию двух первых: сознательный западный пользователь прекрасно понимает, насколько ему выгодно наличие единых стандартов, особенно если при их написании доминирующими являются именно его пожелания, - отсюда и его желание быть максимально причастным к этому процессу.
Стандарты и XML-технологии
Особое место в практике стандартизации занимают вопросы разработки XML-спецификаций. Сегодня вряд ли кто-нибудь станет оспаривать значение XML-технологий. Благодаря языку расширяемой разметки стало возможным развитие электронной коммерции по схеме "бизнес - бизнес" (B2B). Что, как не XML, ключевой особенностью которого является независимость от платформы, может обеспечить взаимодействие программных и аппаратных средств различных поставщиков? По мнению специалистов аналитической компании IDC, для электронного бизнеса XML уже стал стандартом де-факто.
Кроме того, XML стал базисом для развития многих других языков, предназначенных для решения прикладных задач (например, XLink *1, XPointer *2, XSLT *3) и отраслевых диалектов XML (FpML *4, OFX/IFX *5, FinXML *6, ebXML *7, MathML *8, XBRL *9), используемых в различных сегментах экономики или направлениях бизнеса.
_____
*1 XMLLinkingLanguage
*2 XML Pointer Language
*3 Extensible Stylesheet Language (XSL) Transformations
*4 Financial Products Markup Language
*5 Open Financial Exchange
*6 Financial XML
*7 e-Business XML
*8 Mathematical Markup Language
*9 Extensible Business Reporting Language
Наконец, столь популярные ныне, ставшие буквально притчей во языцех Web-сервисы просто немыслимы без XML. Будучи универсальным механизмом обмена, XML создает все предпосылки для создания независимой от платформы модели Web-сервисов.
Таким образом, неоспоримо важной оказывается роль организаций, занимающихся стандартизацией самого языка XML, его диалектов и XML-технологий. Ни в коем случае не пытаясь умалить достоинства других органов стандартизации, как тех, о которых шла речь в упомянутом выше обзоре, так и тех, что в него не попали, выделим две, на наш взгляд, ключевые фигуры в области разработки стандартов XML-технологий - это международные консорциумы W3C *1 (www.w3c.org) и OASIS *2 (www.oasis-open.org). Общую информацию об этих организациях: о целях и задачах, которые они перед собой ставят, условиях членства, чем они знамениты - можно узнать, обратившись к упомянутой выше статье. Мы же добавим, что членами этих сообществ являются ведущие игроки на рынке информационных технологий: IBM, Intel, Microsoft, Oracle, SAP и др., - что лишний раз свидетельствует о серьезности спецификаций, утверждаемых в этих консорциумах.
_____
*1 World Wide Web Consortium
*2 Organization for the Advancement of Structured Information Standards
Как отмечалось в статье Камерона Стардеванта, "...процессы стандартизации в различных организациях могут несколько различаться", но в целом прослеживается определенная общность подходов. Автор выделяет основные этапы стандартизации и приводит краткую характеристику каждого из них в таблице "Пути стандартизации". Значимость нормативных документов, регламентирующих порядок принятия стандартов, трудно переоценить - действительно, успешное завершение работ над стандартом во многом зависит от продуманности методики разработки стандартов. Несомненно, знакомство с любым опытом по этому вопросу, тем более мировым, может оказаться весьма полезным. Поэтому рассмотрим, как осуществляется разработка стандартов в вышеупомянутых организациях, а затем попытаемся установить общие точки и имеющиеся различия.
Консорциум W3C: от Рабочего проекта до Рекомендации
Этап формирования "Идеи" (см. таблицу в PC Week/RE, N 8/2003, с. 45) в международной организации W3C начинается с выдвижения предложения об инициализации нового направления деятельности (Activity). К такому предложению штатные сотрудники консорциума (W3C Team) могут прийти в ходе осуществления своей деятельности: проведения конференций и семинаров, отслеживания тенденций в области Web-технологий и т. п. В этом случае Директор (Director) направляет соответствующую заявку в Консультативный комитет (Advisory Committee). В течение периода рассмотрения Консультативный комитет высказывает свои соображения и замечания по обсуждаемому вопросу, после чего Директор информирует комитет об отношении членов консорциума к этому предложению. При наличии консенсуса, т. е. если эта идея получает всеобщую поддержку, создается новое направление.
Организационно все работы в консорциуме строятся вокруг таких направлений. Цели и задачи каждого направления излагаются в Декларации направления (Activity Statement), в котором приводится список задействованных Рабочих групп (Working Group). Именно в этих группах выполняется львиная доля работы консорциума; результатом их деятельности являются технические отчеты, программные средства с открытым кодом и другие услуги.
Необходимо уточнить, что технический отчет, который публикует рабочая группа, по сути является одной из возможных версий разрабатываемого стандарта, а именно Рабочей версией (Working Draft), Последней редакцией Рабочей версии или Рабочей версией в статусе "крайнего срока" (Last Call Working Draft), Кандидатом к рекомендации (Candidate Recommendation), Предложенной рекомендацией (Proposed Recommendation) или Рекомендацией (Recommendation).
Рабочая версия
Рабочая версия - это первая ступень в продвижении технического отчета к самому высокому статусу, который может получить спецификация, - Рекомендации. Формально для опубликования Рабочей версии необходимо согласие Директора, хотя факт обнародования документа не является свидетельством наличия консенсуса или одобрения со стороны W3C. При этом Рабочая группа вправе запросить издание Рабочей версии, даже если ее текст не окончательный и не соответствует всем требованиям группы.
После выхода Рабочей версии группа продолжает принимать комментарии и замечания к данному документу как от членов W3C, так и от разработчиков и пользователей, не входящих в состав консорциума.
Последняя редакция Рабочей версии
Последняя редакция рабочей версии - это особый случай Рабочей версии. Этот документ является результатом ее уточнения на предмет соответствия требованиям Рабочей группы, а также формального разрешения всех вопросов, возникших в процессе ее изучения как самими авторами, так и другими Рабочими группами и представителями общественности. Выпуская спецификацию в этом статусе, Рабочая группа рассылает запрос на участие в рассмотрении документа, фактически ожидая получить подтверждение отсутствия значительных возражений. При этом Рабочая группа должна установить период приема комментариев.
На этом этапе к работе над спецификацией подключается Консультативный комитет, который всячески содействует обсуждению данного документа - для того, чтобы выявить все проблемы и вопросы, прежде чем спецификация перейдет в статус Кандидата к рекомендации.
По завершении окончательного срока Рабочая группа может обратиться к Директору с просьбой предоставить спецификации статус Кандидата к рекомендации или Предложенной рекомендации. В случае отказа Директор обязан "понизить" документ до Рабочей версии, поставив об этом в известность все группы W3C.
Кандидат к рекомендации
Для получения статуса Кандидата к рекомендации Рабочая группа должна выполнить все требования, предъявляемые к Последней редакции Рабочей версии, т. е. формально ответить по всем претензиям, возникшим во время периода крайнего срока, а также согласовать все вопросы, которые относятся к ведению других групп.
При переводе Последней редакции Рабочей версии в Кандидаты к рекомендации Директор направляет в Консультативный комитет запрос на реализацию данной спецификации. Фактически переход спецификации в рассматриваемый статус означает, что Рабочая группа ожидает, что предложенный ею документ найдет практическое применение (два не связанных между собой примера реализации не являются обязательным требованием для получения данного статуса, однако их наличие или указание о потенциально возможных реализациях всячески приветствуется).
Как и в случае с Последней редакцией рабочей версии, по окончании "кандидатского" периода Рабочая группа может обратиться к Директору с просьбой предоставить спецификации статус Предложенной рекомендации. В случае отказа Директор обязан "понизить" документ до Рабочей версии, поставив об этом в известность Консультационный комитет.
Предложенная рекомендация
Для получения статуса Предложенной рекомендации Рабочая группа должна выполнить все требования предыдущего этапа, а также добиться реализации каждой функциональности, представленной в спецификации. Желательно, чтобы на каждую функциональность имелось хотя бы два не связанных между собой случая ее реализации. Тем не менее, если Директор считает, что незамедлительное изучение спецификации членами Консультативного комитета является необходимым условием успешного завершения разработки стандарта, он может предоставить спецификации статус Предложенной рекомендации, даже если она не получила необходимого апробирования.
Директор может обязать Рабочую группу разрешить все вопросы, поднятые членами Консультативного комитета при ее рассмотрении, а также формально ответить на замечания, полученные от других рабочих групп и представителей общественности.
По окончании данного этапа Директор имеет право предоставить спецификации статус Рекомендации, в противном случае он обязан "понизить" документ до Кандидата к рекомендации или Рабочей версии.
Пожалуй, лишь пребывание документа в этом статусе выбивается из общей канвы, очерченной в статье "Обретение стандарта", хотя было бы неправильно трактовать это несовпадение как принципиальное различие - это, скорее всего, лишь специфика методики работы консорциума W3C.
Рекомендация
Чтобы Предложенная рекомендация превратилась в Рекомендацию, Директор должен быть уверен, что данный документ пользуется ощутимой поддержкой со стороны Консультативного комитета, членов консорциума, рабочих групп W3C и общественности. Решение о придании документу статуса Рекомендации (стандарта) является решением W3C.
Основные этапы разработки стандартов
некоммерческого партнерства
"Стандарты электронного обмена информацией"
Предполагается, что при переходе спецификации в статус Рекомендации члены консорциума оказывают новой Рекомендации всяческую поддержку (отслеживают опечатки, предоставляют испытательные программные средства и т. д.) и способствуют широкому распространению этого стандарта.
Разумеется, W3C может публиковать и исправленные версии Рекомендации, в которых указывается, что было исправлено.
Перейдем теперь к рассмотрению практики разработки стандартов в международной организации OASIS.
От спецификации технических комитетов до открытого стандарта OASIS
Первый шаг на пути становления стандарта OASIS - формирование на Web-сайте организации так называемого списка обсуждения (Discussion List), цель которого - обоснование необходимости создания технического комитета и обсуждение его задач, устава и т. п. Для этого не менее трех членов консорциума направляют в Правление технических комитетов OASIS (OASIS TC Administration) соответствующую просьбу, указав потенциальные задачи будущего комитета, название этого списка обсуждения, имена лиц, участвующих в его формировании, контактную информацию, а также имя руководителя данного проекта.
По получении указанной просьбы Правление технических комитетов OASIS публикует эти материалы, призвав членов организации к участию в обсуждении. Указанный список обсуждения представляет собой реестр электронных адресов, который находится на сайте консорциума.
Следующий шаг - обращение в Правление технических комитетов OASIS с предложением об образовании Технического комитета. Такая заявка включает следующую информацию: название будущего Технического комитета, декларацию его задач, перечень выходных документов комитета, планируемые сроки завершения работ. Примечательно, что в этом документе также указывается язык проекта: работа в комитете может осуществляться на любом языке, хотя итоговый отчет о его деятельности, представляемый членам OASIS на утверждение, должен быть написан на английском языке.
По получении предложения Правление технических комитетов OASIS публикует данную информацию, обращаясь к членам организации с призывом к участию в работе вновь создаваемого комитета. Правление также может отклонить заявку, указав причину отказа. В случае положительного решения Правление формирует общедоступный и закрытый списки рассылки, предназначенные для комитета.
Призыв к участию в работе нового комитета - это фактически предложение присоединиться к комитету; для этого необходимо направить на имя председателя комитета соответствующее письмо, а также подписаться на общедоступный список рассылки.
Известно, что в консорциуме OASIS разрабатываются и принимаются два вида технических материалов: Спецификации комитетов (Committee Specification) и Стандарт OASIS (OASIS Standard).
Спецификация комитета
Спецификация комитета - это окончательная и утвержденная членами комитета версия документа. Наличие этого статуса является достаточным условием для того, чтобы организации могли начать использовать данную спецификацию, хотя переход спецификации на следующий уровень - Стандарт OASIS - придает ей дополнительный вес. Необходимо иметь в виду, что Технический комитет вправе не выдвигать свою спецификацию на получение статуса Стандарта.
Как и в случае других решений, принимаемых комитетом, данное постановление заносится в протокол и публикуется на Web-странице и в списке рассылки. Кроме того, чтобы спецификация появилась на Web-странице, на которой перечислены Спецификации комитетов, председатель комитета ставит в известность о постановлении комитета Управляющего техническими комитетами (TC Administrator).
Стандарт OASIS
Стандарт OASIS - это Спецификация комитета, которая после представления членам консорциума на рассмотрение была одобрена в ходе проведенного голосования.
Прежде чем внести Спецификацию на утверждение, ее передают на суд общественности. Цель этого шага - гарантировать, что документ достоин выдвижения на статус Стандарта (при этом комитет может провести несколько циклов рассмотрения с последующим голосованием на предмет окончательного утверждения документа в качестве Спецификации комитета). По завершении данного этапа Технический комитет принимает решение путем голосования о том, направлять ли данную Спецификацию на соискание статуса Стандарта. В случае положительного результата председатель комитета направляет Управляющему технических комитетов Спецификацию и сопутствующую документацию, а также Сертификат, подтверждающий, что по крайней мере три организации - члена OASIS успешно используют данную Спецификацию.
По получении указанных документов Управляющий технических комитетов проверяет заявку на предмет ее соответствия требованиям Регламента технических комитетов, после чего передает членам OASIS на рассмотрение. В период рассмотрения члены консорциума знакомятся со Спецификацией комитета; на данном этапе выдвижение комментариев не приветствуется, поскольку считается, что Спецификация уже прошла этап изучения и приема замечаний. Таким образом, до конца этого этапа члены OASIS обязаны проголосовать за или против предлагаемого Стандарта. Правом голоса обладают только корпоративные члены организации. Примечательно, что голосование является открытым и проводится посредством отправки электронных сообщений.
Еще одна интересная особенность заключается в том, что для получения статуса Стандарта OASIS за Спецификацию комитета должно проголосовать не менее 10% членов консорциума, однако в свою очередь и число проголосовавших против должно быть не более 10%. По словам представителей OASIS, указанное правило, с одной стороны, позволяет утвердить стандарт, если он действительно имеет поддержку, а с другой стороны, так же легко отклонить в случае его несостоятельности. Однако если спецификация не получила одобрения, Технический комитет вправе повторить ее представление на статус Стандарта.
При положительном результате объявление о выходе нового Стандарта и сам Стандарт публикуются на сайте OASIS.
Методики принятия стандартов W3C и OASIS: общность подходов
Приведенное выше описание технологий разработки стандартов, принятых в W3C и OASIS, позволяет сделать следующие выводы. Несмотря на кажущуюся на первый взгляд несхожесть методик - многоступенчатый процесс принятия рекомендаций W3C и наличие стандартов двух типов у OASIS, - они представляют суть одного подхода. Так, существование нескольких этапов пересмотра/ревизии в W3C нисколько не выбивается из общей схемы; а между спецификацией комитета OASIS и Кандидатом к рекомендации W3C можно условно поставить знак равенства: и та и другой достаточно проработаны, чтобы найти практическое применение, более того, это можно считать их задачей.
К менее очевидному различию, пожалуй, можно отнести тот факт, что если в W3C отправной точкой при начале работ над стандартом является формулирование идеи - создание нового направления с последующим выделением ресурсов (технических групп), то в OASIS все как раз строится вокруг формирования целевого комитета. Что это - принципиальное отличие или же незначительная организационная вариация? Скорее всего, второе: известно, что комитеты OASIS обладают весьма высокой степенью автономности, в то время как W3C - весьма централизованная организация. То есть отмеченное различие вряд ли можно считать коренным.
Таким образом, напрашивается следующий вывод: схемы стандартизации в этих двух организациях примерно одинаковы и, следовательно, могут быть использованы как универсальный рецепт или образец разработки стандартов.
Место России в процессе стандартизации
Проблемы стандартизации не обошли стороной и Россию - в нашей стране все более острым становится вопрос стандартизации процессов представления информации и обмена данными, все более актуальна задача обеспечения совместимости систем и сервисов. Во всем мире этим проблемам уделяется очень большое внимание - как на государственном уровне, так и в среде технологических компаний. Поэтому Россия также пытается идти в ногу со временем - так, в федеральной целевой программе "Электронная Россия" особо подчеркивается необходимость привлечения отечественных специалистов к участию в международных программах развития и стандартизации в сфере ИТ.
Однако надо отметить специфичность ситуации в России - изначально непростая задача разработки стандарта у нас приобретает дополнительные сложности. Объясняется это рядом причин. Во-первых, незрелостью рынка высоких технологий. И хотя ряд российских компаний предлагает программные продукты, которые могут составить конкуренцию своим зарубежным аналогам, а отдельные поставщики даже активно экспортируют свое ПО, все же в целом ситуация по отрасли далеко не радужная. Очевидно, корни этого отставания от Запада в том, что рынок информационных технологий в России начал складываться относительно недавно и еще не сформировалась особая культура, свойственная западным поставщикам и их клиентам.
С идеей "культуры" перекликается понятие "сознательности конечного пользователя" - в отличие от своих западных коллег российские потребители в массе своей, к сожалению, пока не понимают важность стандартизации и не уделяют ей достаточного - если уделяют вообще - внимания.
Наконец, стоит заметить, что многие информационные технологии носят новаторский, революционный характер и для их освоения и применения требуется довольно высокий уровень готовности всей компьютерной отрасли, чего, как отмечалось выше, мы пока не наблюдаем.
Некоммерческое партнерство "Стандарты электронного обмена информацией", цели и задачи
С целью решения обозначенных выше задач в январе 2002 г. было создано некоммерческое партнерство "Стандарты электронного обмена информацией" (далее - Партнерство), в состав которого вошли представители ведущих отечественных производителей ПО и финансовых организаций: "1С: Акционерное общество", "Банковские информационные системы", московское представительство Microsoft, представительство фирмы Intel, "Парус", Intersoft Lab, Центр финансовых технологий, "Эр-Стайл Софтлаб", "Диасофт", Акционерный коммерческий Сберегательный банк Российской Федерации, Ассоциация российских банков, Российская национальная ассоциация членов SWIFT.
Необходимо подчеркнуть, что среди заявленных задач данное сообщество также поставило себе целью продемонстрировать зрелость российских поставщиков ПО, их готовность разрабатывать стандарты мирового уровня, а также привлечь внимание конечного пользователя - потребителя стандартов - к этой важной проблеме.
Рассмотрим процедуру разработки стандартов, принятую в Партнерстве, сопоставив ее с подходами, реализованными в методиках, описанных выше. Для большей наглядности изложения в качестве практической иллюстрации воспользуемся опытом создания "Стандарта публикации финансовой отчетности коммерческих банков".
Основные этапы разработки "Стандарта публикации финансовой отчетности коммерческих банков"
Как и в большинстве международных органов стандартизации, основным инструментом при выработке стандартов Партнерства являются профильные комитеты по различным рынкам, отраслям или сегментам экономики. Состав комитетов формируется Советом директоров Партнерства из членов Партнерства и третьих лиц, участие которых способствует эффективной деятельности комитета.
Если провести параллель с международной организацией OASIS, то нетрудно заметить много общего - как и в случае OASIS, создание профильного комитета (подкомитета) Партнерства начинается с написания Положения (устава в терминах OASIS) - документа, определяющего его основные цели и задачи, сферу интересов, порядок формирования и деятельности.
Так, Подкомитет по финансовой отчетности занимается разработкой стандартов электронного обмена информацией, а также справочников, систем классификации и кодирования в области подготовки, публикации и обмена финансовой отчетностью между банками, их клиентами, а также иными организациями и ведомствами, при общей координации этой деятельности Комитетом по банковской деятельности Партнерства. Кроме того, работа Подкомитета предусматривает тесное взаимодействие с международными организациями по стандартизации финансовой отчетности, ЦБР и государственными органами.
Оговоримся сразу, что поскольку первый стандарт Партнерства был подготовлен Подкомитетом по финансовой отчетности, то в дальнейшем при изложении будет фигурировать уровень подкомитета. Определение уровня организационной единицы, в которой будет формироваться стандарт, зависит от рамок последнего - комитет (подкомитет) может заниматься разработкой только тех видов стандартов, которые указаны в положении о данном комитете (подкомитете).
В определенной степени учреждение профильного комитета Партнерства - это этап формулирования идеи, а точнее, исходная точка этого этапа, поскольку формально первым шагом по созданию стандарта Партнерства является утверждение Определения стандарта.
При внесении на рассмотрение подкомитета базового либо детального предложения по разработке стандарта создается документ (Определение стандарта), в котором указывается предлагаемое наименование разрабатываемого стандарта, обоснование необходимости его выпуска, описание рынков (отраслей), где будет применяться данный стандарт, предполагаемые пользователи, примерный перечень электронных документов, подлежащих стандартизации. В случае детального предложения данный документ также включает сведения о языке описания формата, начальном стандарте.
В упомянутом Определении стандарта также указывается Разработчик стандарта и Ответственный за разработку.
Основанием для любого Определения стандарта (или формирования "Идеи") являются наличие существующих потребностей в определенном сегменте рынка и общая декларация (описание) потенциального решения. Поэтому написанию этого документа, как правило, предшествует большая исследовательская работа. Так, в случае "Стандарта публикации финансовой отчетности коммерческих банков" было выявлено, что в настоящий момент как клиенты, так и контрагенты финансовых учреждений банковского сектора испытывают сложности с получением достоверной и удобной для анализа и принятия решений финансовой информации. Многообразие информационных источников и отсутствие стандартов представления различных видов отчетов определило необходимость разработки единого стандарта публикации финансовой отчетности.
Одновременно были установлены потенциальные пользователи стандарта и их ожидания. Условно были выделены три категории предполагаемых пользователей: поставщики финансовой информации (банки и другие финансовые учреждения), потребители финансовой информации (клиенты банков и сами банки), разработчики ПО (автоматизированных банковских систем и систем автоматизации предприятий). Первые смогут публиковать отчетность для автоматической обработки, обеспечивая естественную трансформацию финансовой отчетности в различные формы представления. У представителей второй группы появится возможность собирать, загружать и анализировать финансовую отчетность любого банка при помощи стандартных программных средств. Наконец, поставщики программных продуктов смогут встроить в свои системы стандартные модули представления и приема финансовой отчетности, предлагая своим клиентам более легкий и удобный, а при желании и полностью автоматический способ презентации и получения финансовой информации.
Таким образом, сделалась очевидной и область применения разрабатываемого стандарта - банковский сектор, а именно та его часть, которая связана с публикацией финансовой отчетности и ее обменом между банками, их клиентами, а также иными организациями и ведомствами.
Следующим шагом стало определение рамок применения стандарта - в качестве исходных документов стандартизации было решено остановиться на двух основных формах отчетности: так называемых 101-й и 102-й формах ("Оборотной ведомости по счетам бухгалтерского учета" и "Отчету о прибылях и убытках" соответственно). Основной критерий выбора данных документов - прагматизм: эти формы отчетности относятся к наиболее востребованным и позволяют наглядно продемонстрировать возможности и достоинства стандарта.
Наконец, потребовалось проанализировать существующие языки описания структуры и форматов данных, а также действующие стандарты с целью выявления наиболее подходящих для решения данной задачи. Важность этого этапа, пожалуй, трудно преувеличить: очередное изобретение колеса может скомпрометировать любые благие начинания.
Определение XML в качестве языка описания формата вряд ли нуждается в комментариях; что касается начального стандарта - спецификации XBRL 2.0, то данный выбор требует некоторого пояснения.
Эта спецификация определяет элементы и атрибуты XML, которые могут применяться для представления информации, используемой при обмене бизнес-данными, при их создании и анализе. XBRL состоит из базового языка элементов и XML-атрибутов электронных документов. Сегодня наблюдается настоящий бум языка XBRL - он позволяет на порядок упростить процесс обмена данными финансовой отчетности, их подготовки и анализа. В настоящий момент Правление комитета по международным стандартам финансовой отчетности (International Accounting Standards Committee Foundation) и XBRL International опубликовали таксономию "Основные финансовые отчеты" (Primary Financial Statements, PFS), которая фактически является XBRL-версией Международных стандартов финансовой отчетности.
Однако будет нелишним добавить еще один довод в пользу XBRL. Несмотря на наличие весьма представительного семейства финансовых XML-стандартов (FpML, OFX/IFX, FinXML, ebXML), XBRL имеет очень важную особенность - он задумывался как диалект языка XML, предназначенный исключительно для области финансовой отчетности. Другими словами, если еще раз посмотреть на названия разработанного "Стандарта публикации финансовой отчетности коммерческих банков" и самого подкомитета по финансовой отчетности, то нельзя не заметить 100-процентного попадания с точки зрения области применения!
Таким образом, ориентированность на финансовую отчетность вкупе с отличной технологической базой - достаточное основание для выбора Рекомендации XBRL в качестве начального стандарта.
Утверждение Определения стандарта профильным подкомитетом фактически является решением о начале разработки стандарта и подразумевает завершение этапа формирования "Идеи".
Следующий этап - "Регламент" - подразумевает представление разработанного стандарта, точнее, его проекта в соответствии с требованиями нормативных документов, принятых в Партнерстве. Поясним, что под этими требованиями понимается оформление двух документов - "Логическая модель электронного обмена информацией" и "Представление на языке разметки" - и формирование файлов XML-схем для электронных документов, подлежащих стандартизации. Логическая модель - это описание структуры и содержания электронных документов, порядка их использования. Второй документ устанавливает, как из логической модели получается конечный документ (XML-схема).
Касаясь "Стандарта публикации финансовой отчетности коммерческих банков", отметим, что поскольку для данного стандарта в качестве начального применялась Рекомендация XBRL, помимо XML-схем электронных документов также были разработаны базы связей (linkbase), которые вместе с XML-схемами образуют таксономии документов финансовой отчетности.
Оформленный таким образом проект стандарта выносится на рассмотрение членов подкомитета, при этом возможно многократное проведение процедур согласования.
Отметим, что, как и в международной организации OASIS, проведение согласования и обсуждения стандарта осуществляется путем отправки электронных писем, а также опубликования замечаний в специальном форуме, поддерживаемом на сайте Партнерства (www.stp.ru).
По завершении этапа согласования проект выносится на окончательное рассмотрение подкомитета, и подкомитет принимает решение об утверждении стандарта. Решения подкомитета вступают в силу после проведения очередного заседания Совета директоров. Затем Исполнительная дирекция публикует утвержденный стандарт на официальном сайте Партнерства.
Подводя итог, можно констатировать, что рассмотренная методика во многом перекликается с порядком разработки стандартов, принятым в международной организации OASIS.
В завершение добавим, что в настоящий момент проект "Стандарта публикации финансовой отчетности коммерческих банков" находится на рассмотрении членов подкомитета по финансовой отчетности - по нему активно ведется переписка и принимаются замечания и предложения.
Заключение
Злободневность темы стандартизации - вовсе не выдумка досужих умов. Российские разработчики обладают опытом, знаниями и умениями, необходимыми для создания стандартов мирового качества. Они полностью компетентны в этом вопросе. Наступил переломный момент, когда конечный пользователь должен осознать важность стандартизации и принять самое активное участие в этом процессе.
С автором статьи Александром Кудиновым - руководителем подкомитета по финансовой отчетности некоммерческого партнерства "Стандарты электронного обмена информацией" (www.stp.ru), ответственным за продвижение XML-стандартов компании Intersoft Lab (www.iso.ru), - можно связаться по e-mail: kudinov@iso.ru.
