НовостиСобытияКонференцииФорумыIT@Work
Документооборот/ECM:

Блог

Требования регулятора и требования заказчика. В чем разница?

Андрей Колесов
24.01.2012 14:55:31

Дискуссия по теме "Требования в СЭД ФОИВ" продолжается. И как я понимаю, она все же упирается в вопрос, который я пытался обозначить еще на начальном этапе обсуждения темы. А именно: как СЭД-отрасль должна относиться к подобным документам: как к некоторой данности, которую можно лишь "понимать", но нельзя изменять (участвовать в ее формировании), или к вещи, в создании которой можно и нужно напрямую участвовать?

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

Цитата
Михаил Романов
24.01.2012 08:51:45

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

Почему-то мы оставляем право за коммерческой компанией на определение собственных потребностей. А вот за государственным аппаратом - нет. Странно это.


Я ему собирался возразить, но меня опередил новый участник обсуждения:

Цитата
Павел Исопенко (master@pauli.ru)
24.01.2012 12:35:02

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

От себя я все же тоже хочу добавить.

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

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

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

Т.е. вопрос соответствия данным "Требованиям" – это проблема не поставщика, а потребителя. Хотя, конечно, это автоматически становится проблемой и поставщика-исполнителя (по цепочке).

Еще один принципиальный момент заключается в том, что выработка любого ТЗ на проект – это процесс диалога между исполнителем и заказчиком, а само ТЗ – это результат некоторого компромисса.

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

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

Вот еще одна цитата Михаила Романова:

Цитата
Кстати, еще большой вопрос - что к разработке того же ЗПД эксперты не привлекались. Мы просто не знаем персоналий, только и всего.


И тут возникает естественный вопрос: а почему мы не знаем этих персоналий?

И еще: кто же все-таки отвечает в правительстве (министерстве) за данные Требования? Кому адресовать вопросы, предложения и пр…. Кто должен отвечать на них?
Кто сегодня формирует процедуры проверки соответствия СЭД утвержденными Требованиям?
И т.д. и т.п….

Комментариев: 2

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

24.01.2012 16:16:15

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

Андрей, а как это влияет на процедуру выработки требований к ИС?
На сами требования, да несомененно, а вот на то как эти требования создаются - сомневаюсь.

Цитата
отличие требований заказчика по конкретному проекту от нормативных требование регулятора заключается в том, что первые обращены к исполнителю работ, а вторые – к самому заказчику, пользователю

Андрей, вы опять все смешали. Требования к СЭД ФОИВ распространяются только на СЭД ФОИВ - какой это регулятор? Разве они к чему-то обязывают поставщиков СЭД? Нет - только заказчиков СЭД в ОИВ. Это самые что ни на есть внутрикорпоративные требования! Только не для холдинга, для органов власти.
Почему бы не принять как данность, что люди работающие в этих структурах лучше чем кто бы то ни было еще знают свою "внутреннюю кухню" и свои потребности?

Цитата
И тут возникает естественный вопрос: а почему мы не знаем этих персоналий?

Не менее естественный вопрос: а зачем нам их знать?

24.01.2012 18:04:30

Уважаемые комментаторы легко согласились пользоваться термином "регулятор" в ситуации, когда о регулировании-то собственно речи нет. Легко видеть отличия на примере классики регулирования. Так, Центральный Банк является регулятором банковской деятельности. в частности:

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

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

В США родственные вопросы (разработка типовых требований к решениям records management для госслужб) решались методологически иначе. Наиболее известное своей пунктуальностью ведомство (оставим в стороне вопрос об истоках такой репутации) - Министерство обороны, разработало и опубликовало стандарт DoD 515.2, требования этого документа были обязательны для заказчиков из Минобороны, а прочие желающие заказчики (не только из госсектора) могли кратчайшим образом сформулировать свои (неспецифические) требования к системе в виде ссылки на этот стандарт. К разработке стандарта (он развивается с 1997 года) были привлечены не только военные, но и представители компаний разработчиков ПО, теоретики и практики в области ИТ, информационной безопасности, юриспруденции, делопроизводства и архивного дела. Сертификация ПО на соответствие стандарту проводится относительно независимой организацией J ITC («Объединенная группа тестирования систем на взаимодействие») агентства информационных систем министерства обороны. DoD 5015.2 стал де-факто национальным стандартом США. Соответствующую сертификацию проходят продукты всех без исключения компаний-лидеров на рынке СЭД – к этому их стимулирует не только желание продавать свою продукцию военным, но и то, что сертификация по DoD 5015.2 стала повсеместно рассматриваться как доказательство качества СЭД. Экспертное сообщество, естественно, как-то комментировало пост-фактум содержание стандарта, но, сколько мне известно, ничего похожего на демократию по типу обсуждения MoReq 2010 (по крайней мере, до 2005 года, когда был опубликован проект 3-й версии) не было (готов с интересом выслушать уточнение Н.А.Храмцовской).

В России само по себе (без специального нормативного давления) так не получается. Некоторым историческим примером аналогичной устрожающей трансляции норм ("делай как наиболее требовательный заказчик") может служить распространение ряда норм проектирования и производства военных самолетов на гражданское самолетостроение и внедрение в гражданском секторе соответствующих испытательных и сертификационных процедур. Я склонен улавливать отголоски такого подхода (равняйсь!) в повышенном внимании (см., например, соседнюю ветку этого блога) всех участников рынка к практике внедрения СЭД в госсекторе Татарстана. В качестве ориентирующего эталона (на который все должны равняться) выступает не «пунктуальность» Минобороны как в США, и не сравнительная конкурентоспособность (как советские ВВС эпохи СССР), а эдакая слабоуловимая сравнительная на общем фоне «дисциплинированность» татарстанских ИТ-интеграторов и обслуживаемых ими госзаказчиков.

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