- 2003
Россия: необходимость обретения стандарта. Из опыта разработки отраслевого стандарта электронного обмена информацией
Особое место в практике стандартизации электронного обмена данными занимают вопросы разработки XML-спецификаций. По мнению аналитиков, для электронного бизнеса XML уже стал стандартом де-факто.
Стандарты и информационные технологии в мире
Современная эпоха характеризуется бурным развитием информационных технологий, и в этом революционном процессе особое значение приобретают процессы выработки стандартов. Сегодня осознание этого факта является без преувеличения одним из ключевых условий успешного ведения бизнеса.
Действительно, вспомним, что любая корпоративная система - это по существу воплощение неких бизнес-требований, описанных в соответствии с конкретной спецификацией. За спецификацией же стоит тот или иной орган стандартизации, возглавляемый ведущими поставщиками программного обеспечения. Поэтому, отдавая предпочтение какому-либо программному обеспечению, необходимо понимать, что при этом выбирается не только продукт с требуемыми функциональными возможностями, но и определенный стандарт. То есть, следует отчетливо представлять, что это за стандарт и какая организация его разрабатывала.Актуальности темы стандартизации подтверждает и то, что в настоящий момент "на ниве стандартизации трудится" целый ряд международных органов стандартизации. Об этом и многом другом шла речь в статье Камерона Стардеванта "Обретение стандарта" (PCWEEK/RE, 2003, № 8 (374)).
Отметим, что необходимость выработки стандартов во всем мире была понята уже давно, и причин тому немало. Это и сознательность западного общества в целом: традиция регламентировать все стороны жизни, тем более те, что непосредственно влияют на развитие бизнеса. Это и зрелось рынка программного обеспечения, проявляющаяся в том, что и разработчики "софта", и их клиенты понимают значимость спецификаций и активно участвуют в "общем для всех деле". Наконец, нельзя забывать о том, что проекты по разработке стандартов в значительной степени поддерживаются - в том числе и материально - потенциальными потребителями стандарта. Последний мотив является, по существу, своеобразной квинтэссенцией двух первых: сознательный западный пользователь прекрасно понимает, насколько ему выгодно наличие единых стандартов, особенно если при их написании доминирующими являются именно его пожелания - отсюда и его желание быть максимально причастным к этому процессу.Стандарты и XML-технологии
Особое место в практике стандартизации занимают вопросы разработки XML-спецификаций. Сегодня вряд ли кто-нибудь станет оспаривать значение XML-технологий. Благодаря языку расширяемой разметки стало возможным развитие электронной коммерции по схеме "бизнес-бизнес" (B2B). Что не как XML, ключевой особенностью которого является независимость от платформы, может обеспечить возможность взаимодействия программных и аппаратных средств различных поставщиков? По мнению специалистов аналитический компании IDC, для электронного бизнеса XML уже стал стандартом де-факто.
Кроме того, XML стал базисом для развития многих других языков, предназначенных для решения прикладных задач (например, XLink , XPointer , XSLT ), и отраслевых диалектов XML (FpML , OFX/IFX , FinXML , ebXML , MathML , XBRL ), используемых в различных сегментах экономики или направлениях бизнеса.Наконец, столь популярные ныне, ставшие буквально притчей во языцех, Web-сервисы просто немыслимы без XML. Будучи универсальным механизмом обмена, XML создает все предпосылки для создания независящей от платформы модели Web-сервисов.
Таким образом, неоспоримо важной оказывается роль организаций, занимающихся стандартизацией самого языка XML, его диалектов и XML-технологий. Ни в коем случае не пытаясь умалить достоинства других органов стандартизации: как тех, о которых шла речь в упомянутом выше обзоре, так и тех, что в него не попали, выделим две, на наш взгляд, ключевые фигуры в области разработки стандартов XML-технологий: международные консорциумы W3C и OASIS . Общую информацию об этих организациях: о целях и задачах, которые они перед собой ставят, условиях членства, чем они "знамениты" - можно узнать, обратившись к упомянутой выше статье. Мы же добавим, что членами этих сообществ являются ведущие "игроки" на рынке информационных технологий: IBM, Intel, Microsoft, Oracle, SAP и другие - что лишний раз свидетельствует о серьезности спецификаций, утверждаемых в этих консорциумах.Как отмечалось в статье Камерона Стардеванта, "процессы стандартизации в различных организациях могут несколько отличаться", но в целом прослеживается определенная общность подходов. Автор выделяет основные этапы стандартизации и приводит краткую характеристику каждого из них в таблице "Пути стандартизации". Значимость нормативных документов, регламентирующих порядок принятия стандартов трудно переоценить - действительно, успешное завершение работ над стандартом во многом зависит от продуманности методики разработки стандартов. Несомненно, знакомство с любым опытом по этому вопросу, тем более "мировым", может оказаться весьма полезным. Поэтому рассмотрим, как осуществляется разработка стандартов в вышеупомянутых организациях, а затем попытаемся установить "общие точки" и имеющиеся различия.
Консорциум W3C: от Рабочего проекта до Рекомендации
Этап формирования "Идеи" (см. таблицу "Пути стандартизации") в международной организации 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 может публиковать и исправленные версии Рекомендации, в которых указывается, что было исправлено и какие редакторские правки были внесены.
Таким образом, как следует из проведенного нами анализа, процедура принятия стандартов 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", ЗАО "Центр финансовых технологий", ЗАО "Эр-Стайл Софтлаб", ЗАО "Диасофт", Акционерный коммерческий Сберегательный Банк Российской Федерации, Ассоциация российских банков, Российская Национальная ассоциация Членов СВИФТ.Необходимо подчеркнуть, что среди заявленных задач, данное сообщество также поставило себе целью продемонстрировать зрелость российский поставщиков программного обеспечения, их готовность разрабатывать стандарты мирового качества, а также привлечь внимание конечного пользователя - потребителя стандартов - к этой важной проблеме.
Рассмотрим процедуру разработки стандартов, принятую в Партнерстве, сопоставив ее с подходами, реализованными в методиках, описанных выше. Для большей наглядности изложения воспользуемся опытом создания "Стандарта публикации финансовой отчетности коммерческих банков" в качестве практической иллюстрации.Основные этапы разработки "Стандарта публикации финансовой отчетности коммерческих банков"
Как и в большинстве международных органов стандартизации, основным инструментом при выработке стандартов Партнёрства являются профильные комитеты по различным рынкам, отраслям или сегментам экономики. Состав комитетов формируется Советом директоров Партнёрства из членов Партнёрства и третьих лиц, участие которых способствует эффективной деятельности комитета.Если провести параллель с международной организацией OASIS, то нетрудно заменить много общего - как и в случае OASIS, создание профильного комитета (подкомитета) Партнерства начинается с написания Положения (устава в терминах OASIS) - документа, определяющего его основные цели и задачи, сферу интересов, порядок формирования и деятельности.
Так, Подкомитет по финансовой отчетности занимается разработкой стандартов электронного обмена информацией, а также справочников, систем классификации и кодирования в области подготовки, публикации и обмена финансовой отчетностью между банками, их клиентами, а также иными организациями и ведомствами, при общей координации этой деятельности Комитетом по банковской деятельности Партнерства. Кроме того, работа Подкомитета предусматривает тесное взаимодействие с международными организациями по стандартизации финансовой отчетности, ЦБР и государственными органами.Оговоримся сразу, что поскольку первый стандарт Партнерства был подготовлен Подкомитетом по финансовой отчетности, то в дальнейшем при изложении будет фигурировать уровень подкомитета. Определение уровня организационной единицы, в которой будет формироваться стандарт, зависит от рамок последнего - комитет (подкомитет) может заниматься разработкой только тех видов стандартов, которые указаны в положении о данном комитете (подкомитете).
В определенной степени, учреждение профильного комитета Партнерства - это этап формулирования "идеи" (таблица "Пути стандартизации"), а точнее исходная точка этого этапа, поскольку формально первым шагом по созданию стандарта Партнерства является утверждение Определения стандарта.При внесении на рассмотрение подкомитета базового либо детального предложения по разработке стандарта создается документ (Определение стандарта), в котором указывается предлагаемое наименование разрабатываемого стандарта, обоснование необходимости разработки стандарта, описание рынков (отраслей), где будет применяться данный стандарт, предполагаемые пользователи стандарта, примерный перечень электронных документов, подлежащих стандартизации. В случае детального предложения данный документ также включает сведения о языке описания формата, начальном стандарте.
В упомянутом Определении стандарта также указывается Разработчик стандарта и Ответственный за разработку.Основанием для любого Определения стандарта (или формирования "Идеи") являются выявление существующих потребностей в определенном сегменте рынка и общая декларация (описание) потенциального решения. Поэтому появлению этого документа, как правило, предшествует большая исследовательская работа. Так, в случае "Стандарта публикации финансовой отчетности коммерческих банков" были выявлено, что в настоящий момент как клиенты, так и контрагенты финансовых учреждений банковского сектора испытывают сложности в получении достоверной и удобной для анализа и принятия решений финансовой информации. Многообразие информационных источников и отсутствие стандартов представления различных видов отчетов определило необходимость разработки единого стандарта публикации финансовой отчетности.
Одновременно были установлены потенциальные пользователи стандарта и их "ожидания". Условно были выделены три категории предполагаемых пользователей: поставщики финансовой информации (банки и другие финансовые учреждения), потребители финансовой информации (клиенты банков и сами банки), разработчики программного обеспечения (разработчики автоматизированных банковских систем и систем автоматизации предприятий). Первые смогут публиковать отчетность для автоматической обработки, обеспечивая естественную трансформацию финансовой отчетности в различные формы представления. У представителей второй группы появится возможность собирать, загружать и анализировать финансовую отчетность любого банка при помощи стандартных программных средств. Наконец, поставщики программных продуктов смогут встроить в свои системы стандартные модули представления и приема финансовой отчетности, предлагая своим клиентам более легкий и удобный, а при желании и полностью автоматический способ презентации и получения финансовой информации.Таким образом, сделалась очевидной и область применения разрабатываемого стандарта - банковский сектор, а именно та часть банковской деятельности, которая связана с публикацией и обменом финансовой отчетности между банками, их клиентами, а также иными организациями и ведомствами.
Следующим шагом стало определение рамок применения стандарта - в качестве исходных документов стандартизации было решено остановиться на двух основных формах отчетности: так называемых 101 и 102-ой формах ("Оборотной ведомости по счетам бухгалтерского учета" и "Отчету о прибылях убытках", соответственно). Основной критерий выбора данных документов - прагматизм: эти формы отчетности относятся к наиболее востребованным и позволяют наглядно продемонстрировать возможности и достоинства стандарта.Наконец, потребовалось провести анализ существующих языков описания структуры и форматов данных, а также существующих стандартов с целью выявления наиболее подходящих для решения данной задачи. Важность этого этапа, пожалуй, трудно преувеличить: "изобретение колеса" может элиминировать любые благие начинания.
Определение XML в качестве языка описания формата вряд ли нуждается в комментариях, что касается начального стандарта - спецификации XBRL 2.0 (eXtensible Business Reporting Language, Расширяемый язык бизнес-репортинга) - то данный выбор требует некоторого пояснения.Данная спецификация определяет элементы и атрибуты 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, проведение согласования и обсуждения стандарта осуществляется с применением "последних достижений информационных технологией", то есть путем отправки электронных писем, а также опубликования замечаний в специальном форуме, поддерживаемом на сайте Партнерства.По окончании этапа согласования проект выносится на окончательное рассмотрение подкомитета, и подкомитет принимает решение об утверждении стандарта. Решения подкомитета вступают в силу после проведения очередного заседания Совета директоров, после чего Исполнительная дирекция публикует утвержденный стандарт на официальном сайте Партнерства.
Подводя итог, можно констатировать, что рассмотренная методика во многом перекликается с порядком разработки стандартов, принятым в международной организации OASIS, и вполне укладывается в схему Камерона Стардеванта.В завершении добавим, что в настоящий момент проект "Стандарта публикации финансовой отчетности коммерческих банков" находится на рассмотрении членов Подкомитета по финансовой отчетности - по нему активно ведется переписка, и принимаются замечания и предложения.
Заключение
Злободневность темы стандартизации - вовсе не выдумка досужих умов.
Российские разработчики обладают опытом, знаниями и умениями, необходимыми для
разработки стандартов мирового качества. Они полностью компетентны в этом
вопросе. Наступил переломный момент, когда конечный пользователь должен
осознать важность стандартизации и принять самое активное участие в этом
процессе.
С автором статьи - Руководителем подкомитета по финансовой отчетности
Некоммерческого партнерства "Стандарты электронного обмена информацией"
(www.stp.ru), Ответственным за продвижение XML-стандартов компании Intersoft
Lab (www.iso.ru) Александром Кудиновым - можно связаться по e-mail:
kudinov@iso.ru
Автор: А.Кудинов
Источник: itWeek (PC Week/RE)