Я сам изначально придерживаюсь второй позиции, а вот первую отстаивает (как я понимаю) Михаил Романов. Вот выдержка из его довольно подробных комментариев:
[spoiler]
| Михаил Романов 24.01.2012 08:51:45 Что касается требований к СЭД, то моя точка зрения здесь проста - требования СЭД для госорганов ни чем принципиально не отличаются от требований к СЭД, выдвигаемых коммерческой компанией. Можете рассматривать государство как холдинг, который выработал общие требования для всех входящих в него компаний. Да, в деталях они могут различаться, но в целом - обязательны для исполнения всеми компаниями, входящими в холдинг (в нашем случае - всеми гос. органами). … Почему-то мы оставляем право за коммерческой компанией на определение собственных потребностей. А вот за государственным аппаратом - нет. Странно это. |
Я ему собирался возразить, но меня опередил новый участник обсуждения:
| Павел Исопенко (master@pauli.ru) 24.01.2012 12:35:02 Нет, не странно. И объяснение этому очень простое. Государство отличается от коммерческого предприятия тем, что с коммерческим предприятием, выдвигающим необоснованные, нелогичные, неприемлемые требования гражданин (или корпорация) вправе не общаться. Не взаимодействовать вовсе. На то и принципы конкуренции, чтобы можно было выбирать контрагента, выдвигающего более приемлемые условия общения. Тогда как с государственными институтами мы общаться обязаны. По закону. И вариант сменить государство - плохой вариант, негодный, мы такое уже проходили. Остается договариваться о требованиях, взаимоприемлемых для государственных органов с одной стороны и граждан государства (индивидуальных или объединенных в корпорации) - с другой. Таким образом, прав именно Андрей: регулятор, экспертное сообщество, прозрачные процедуры принятия решений. И только так. |
Аналогия работы государственной машины с корпораций вполне логична, но нужно понимать серьезные ограничения такой аналогии. Качественно иные масштабы и качественно иной уровень разнородности приводит к тому, что и система управления должна строить качественно иначе. Автоматический перенос методов управления заводом и даже Газпромом на управление страной невозможен.
Собственно говоря, советский эксперимент заключался именно в попытке такого переноса и хорошо известно, чем он закончился. Более того, мы сейчас являемся свидетелями того, что еще одна попытка воспроизведения такой систему управления в нашей стране (вертикаль власти) тоже не очень удалась. Сформированная за последние 10 лет модель управления исчерпала свои возможности для развития, и сейчас мы видим начало процесса ее демонтажа.
К сказанному Павлом Исопенко, нужно добавить еще одну важную вещь: отличие требований заказчика по конкретному проекту от нормативных требование регулятора заключается в том, что первые обращены к исполнителю работ, а вторые – к самому заказчику, пользователю.
Т.е. вопрос соответствия данным "Требованиям" – это проблема не поставщика, а потребителя. Хотя, конечно, это автоматически становится проблемой и поставщика-исполнителя (по цепочке).
Еще один принципиальный момент заключается в том, что выработка любого ТЗ на проект – это процесс диалога между исполнителем и заказчиком, а само ТЗ – это результат некоторого компромисса.
И даже, если заказчик занимает самую жесткую и бескомпромиссную позицию, то по крайней мере, всегда можно напрямую выяснить (в режиме того же диалога) – что же он имел в виду под тем или иным пунктом.
Конечно, по-хорошему, и у регулятора можно было бы спросить, уточнить. Но проблема нашей нынешней ситуации заключается в том числе и в том, что не очень понятно – у кого именно спрашивать.
Вот еще одна цитата Михаила Романова:
| Кстати, еще большой вопрос - что к разработке того же ЗПД эксперты не привлекались. Мы просто не знаем персоналий, только и всего. |
И тут возникает естественный вопрос: а почему мы не знаем этих персоналий?
И еще: кто же все-таки отвечает в правительстве (министерстве) за данные Требования? Кому адресовать вопросы, предложения и пр…. Кто должен отвечать на них?
Кто сегодня формирует процедуры проверки соответствия СЭД утвержденными Требованиям?
И т.д. и т.п….
На сами требования, да несомененно, а вот на то как эти требования создаются - сомневаюсь.
Почему бы не принять как данность, что люди работающие в этих структурах лучше чем кто бы то ни было еще знают свою "внутреннюю кухню" и свои потребности?
1) его регулятивные требования строго обязательны и распространяются на всех участников банковского рынка, а не являются высказанными (пусть, в несколько директивной форме) требованиями к условиям получения займов той или иной категорией заемщиков;
2) регулятор имеет право отзыва у участников рынка лицензий и т.п. санкций за нарушение требований регулятора;
3) регулятору не приходит в голову выдвигать общие требования к информационным системам банка (выходящие за рамки его взаимодействия с ним как подведомственным его регулятивным действиям экономическим субъектом).
Минсвязи же выступает тут не как регулятор, а как координатор и контролер ИТ-политики заказчиков в госсекторе (даже не во всем госсекторе, а на федеральном его уровне). Давно замечено, что отечественные ведомства и предприятия любят известную политическую автономию. Побороться с этим недостатком, собственно, и призвано в данном конкретном случае Минсвязи.
В США родственные вопросы (разработка типовых требований к решениям records management для госслужб) решались методологически иначе. Наиболее известное своей пунктуальностью ведомство (оставим в стороне вопрос об истоках такой репутации) - Министерство обороны, разработало и опубликовало стандарт DoD 515.2, требования этого документа были обязательны для заказчиков из Минобороны, а прочие желающие заказчики (не только из госсектора) могли кратчайшим образом сформулировать свои (неспецифические) требования к системе в виде ссылки на этот стандарт. К разработке стандарта (он развивается с 1997 года) были привлечены не только военные, но и представители компаний разработчиков ПО, теоретики и практики в области ИТ, информационной безопасности, юриспруденции, делопроизводства и архивного дела. Сертификация ПО на соответствие стандарту проводится относительно независимой организацией J ITC («Объединенная группа тестирования систем на взаимодействие») агентства информационных систем министерства обороны. DoD 5015.2 стал де-факто национальным стандартом США. Соответствующую сертификацию проходят продукты всех без исключения компаний-лидеров на рынке СЭД – к этому их стимулирует не только желание продавать свою продукцию военным, но и то, что сертификация по DoD 5015.2 стала повсеместно рассматриваться как доказательство качества СЭД. Экспертное сообщество, естественно, как-то комментировало пост-фактум содержание стандарта, но, сколько мне известно, ничего похожего на демократию по типу обсуждения MoReq 2010 (по крайней мере, до 2005 года, когда был опубликован проект 3-й версии) не было (готов с интересом выслушать уточнение Н.А.Храмцовской).
В России само по себе (без специального нормативного давления) так не получается. Некоторым историческим примером аналогичной устрожающей трансляции норм ("делай как наиболее требовательный заказчик") может служить распространение ряда норм проектирования и производства военных самолетов на гражданское самолетостроение и внедрение в гражданском секторе соответствующих испытательных и сертификационных процедур. Я склонен улавливать отголоски такого подхода (равняйсь!) в повышенном внимании (см., например, соседнюю ветку этого блога) всех участников рынка к практике внедрения СЭД в госсекторе Татарстана. В качестве ориентирующего эталона (на который все должны равняться) выступает не «пунктуальность» Минобороны как в США, и не сравнительная конкурентоспособность (как советские ВВС эпохи СССР), а эдакая слабоуловимая сравнительная на общем фоне «дисциплинированность» татарстанских ИТ-интеграторов и обслуживаемых ими госзаказчиков.