Информатизация российских регионов.
Как прекратить бег по кругу и всех осчастливить?

Статья призвана решить две задачи:

• напомнить всем о накопленном опыте, проделанной работе в рамках информатизации региональных органов исполнительной власти, оградить от «хождения» по кругу и повторения прежних ошибок;
• «вбросить» на обсуждение уважаемой публике один из вариантов дальнейшего развития информатизации региональных властей Государства Российского.

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

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

Для создания позитивного настроения у читателя надо отметить, что в части региональной информатизации было сделано достаточно много, вспомним госпрограммы «Электронная Россия» (2002-2010 гг.) и «Информационное общество» (2011-2020 гг.). А чего стоят «Майские указы» 2012 года? Можно по-разному относиться к результатам государственных программ, но надо признать тот факт, что существование самих программ - это уже успех, а результаты, даже если они и мало приемлемые, это тоже результаты. Надо уметь извлекать пользу из неудач, пользоваться ими наравне с удачами, не стыдиться их и оставаться честными перед собой и общественностью. Систематическая ошибка «выжившего» учит нас, что в негативном опыте куда больше пользы, чем в редких успехах, ставших таковыми по воле стечения множества обстоятельств.

Федеративное устройство Российской Федерации предоставляет достаточно обширные полномочия региональным органам исполнительной власти, а 131-ФЗ о местном самоуправлении - практически не ограниченные возможности органам местного самоуправления. Данные обстоятельства несут как позитивные возможности, так и массу сложностей для страны в целом. Давайте проанализируем наши победы и неудачи, с которыми мы столкнулись, реализуя цифровизацию власти в регионах Российской Федерации.Как с помощью EvaProject и EvaWiki построить прозрачную бесшовную среду для успешной работы крупного холдинга

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

Банальность №1. Самостийность.

В большинстве случаев создание региональных и муниципальных ИС ограничено только законодательством РФ, а также фантазией заказчика и разработчика, с которой в регионах все в порядке. Также значимым ограничителем является региональный бюджет, в противном случае сложно себе даже представить, к чему бы привели эти фантазии. Свобода и самостоятельность, разбавленные недюжинной фантазией, дают нам решение одной и той-же региональной задачи 85 раз! (по количеству субъектов РФ), а если говорить о муниципальных задачах, то эту цифру нужно умножать на тысячу. При данной Банальности каждый регион и муниципалитет сам за себя, все для себя и ради себя. Безусловно, это хорошо для бизнеса, это хорошо для местных чиновников, одни зарабатывают деньги, вторые реализуют свои фантазии. Но пытливый читатель задаст справедливый вопрос: а хорошо ли это для Государства Российского и его граждан?

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

Банальность №1 многим видна и понятна, но наряду с ее пониманием есть причины ее принятия, тихого умалчивания – человеческий фактор, нахождение ИТ-чиновников внутри самой этой проблемы. Являясь частью проблемы сложно ее воспринимать и решать, пчелы против меда - заведомо абсурдная история. По этой причине Банальность №1 непобедима, она с разной степенью влияния в разные годы вела регионы, и иногда даже в каком-то согласованном направлении. Она живет и будет дальше существовать, поддерживаемая сепаратистскими настроениями, подогреваемая региональной уникальностью, самобытностью и неповторимостью.

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

Банальность №2. Типизация.

Суть Банальности №2 сводится к созданию и предоставлению для использования регионам типового прикладного программного обеспечения, разработанного профильными федеральными ведомствами. В разработке таких систем преуспел Национальный оператор инфраструктуры электронного правительства. Им по заказу федерального регулятора было создано и национальное «облако», и прикладное ПО для здравоохранения, образования, земельно-имущественных отношений, МФЦ и т.д. На бумаге все выглядит гладко и логично, и кажется, что Банальность №2 – это решение и это победа! Но… как всегда, человеческий фактор и банальный конфликт интересов. В чем же дело, спросит пытливый читатель?

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

После окончания одного, начинается второй проект, и так цикл за циклом. В этом и заключается проблема Банальности №2: разработанное и бесплатно передаваемое ПО - это крючок для региона. Получив бесплатное ПО, регион вынужден заказывать работы по созданию ИС, настройке ПО и дальнейшей ее технической поддержке. Говорите 44-ФЗ? Вы уверены? Думаете, много найдется камикадзе, готовых взяться за внедрение ПО, разработанного сторонней компанией? По этой причине работы по созданию и развитию ИС в регионах в основном исполняли компании-разработчики этого самого прикладного ПО.

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

Но даже не это являлось главной проблемой Банальности №2. Управление версионностью типового ПО – вот основная причина, погубившая Банальность №2. Заказчики не всегда могли сдержать свою фантазию, требуя развития функциональности ПО, а для бизнеса (компании-разработчика) - это деньги, консалтинговые, вкусные и такие желанные деньги. Прикладное программы «допиливались» под требования и ТЗ каждого региона в отдельности, и очень скоро мы получили множество версий одного и того же прикладного ПО, которое объединяло только одно – общее название. Для поддержания этого разнообразия разработчикам приходилось создавать региональные сети команд, держать под конкретный вариант ПО отдельную команду специалистов, а это, как вы понимаете, приводит к удорожанию и всем сопутствующим недостаткам. Эффект масштаба потерян, возврат к Банальности №1, круг замкнулся.

Банальность №3. Облака.

Почувствовавшего успех Национального оператора было уже не остановить. Креатив топ-менеджеров и подоспевшие технологии родили Банальность №3. Она была лишена основного недостатка Банальностей №1 и №2, а именно «расползания» бюджета и плохой управляемости версионностью ПО. При этом эффект масштаба сохранялся. Эта Банальность использовала модный подход SaaS – программное обеспечение как сервис. Она пришлась ко двору Национальному оператору, так как полностью соответствовала структуре его бизнеса и подразумевала так любимую операторскую модель, строительство сети ЦОДов и защищенных каналов связи. Все складывалось отлично, если бы не частичная потеря региональными ИТ-министрами управляемости над своей вычислительной инфраструктурой и информационными системами. Кому же такое понравится?

Со своими чиновниками государство разберется само, это дело времени. Но как справиться со своими же системами бюджетного планирования и бухгалтерского учета? Ведь много десятилетий государство покупало оборудование, ставило его на баланс, заказывало работы по настройке и эксплуатации ИС, а контролеры строго следили, чтобы все было именно так и никак иначе (Банальность №1). Модель SaaS подразумевает совсем другой подход, а именно осуществление небольших, регулярных, разнесенных во времени платежей. К регулярным платежам за интернет и телефонную связь все давно привыкли, и это не вызывает вопросов, но вот использование ПО из «облака» выглядит как диковинка, в первую очередь, для финансистов и контрольных органов. Государство тратит деньги на информатизацию, при этом у него не появляется «ящика» под лестницей с гордым названием ЦОД. Время лечит, и есть уверенность, что и эта проблема также будет устранена. Ну так в чем же главный недостаток банальности №3? Он все в том же конфликте интересов и пересекается с основной проблемой банальности №2.

Оператор SaaS предоставляет множество сервисов, созданных на базе прикладного ПО, ему не принадлежавшего. Оператор физически не в состоянии самостоятельно разработать и поддерживать в актуальном состоянии множество прикладного ПО. Если читатель дочитал статью до этого места, значит обладает достаточным понимаем специфики работы отечественных ИТ-компаний. В России прикладное ПО разрабатывается ИТ-компаниями под решение определенной задачи по техническому заданию конкретного заказчика, при этом львиную долю стоимости подобных проектов составляет консалтинг. Консалтинговые деньги - это и есть основной заработок ИТ-компаний. SaaS же, в свою очередь, значительно сокращает объем консалтинга в проектах, тем самым очень негативно влияет на бизнес компаний – разработчиков прикладного ПО. Тут мы имеем классическую «Уловку 22» с парадоксом взаимоисключающих правил - разработка для оператора SaaS качественного и функционально полноценного прикладного ПО убивает бизнес его создателя.

Данный парадокс привел к тому, что оператор SaaS пытается брать деньги у заказчика за подключение к сервису, но по сути продает консалтинг (чтобы не обидеть разработчика). Иногда сумма подключения к сервису Национального оператора равна стоимости создания собственной ИС, а потом еще заказчик вынужден брать абонентскую плату за использование ПО из «облака». Естественно, у регионального заказчика начали возникать резонные вопросы целесообразности использования Банальности №3. Регионы стали активно смотреть в сторону Банальности №1 и, поверьте, они найдут достаточно аргументов для использования именно ее, старой, понятной и такой близкой.

Не стоит забывать и тот факт, что создание «облака» и отраслевых прикладных сервисов - это инвестиционные проекты, реализуемые, в том числе, за средства оператора SaaS. При этом сроки окупаемости этих проектов значительные, более 5 лет. Много ли у нас технологичных компаний, готовых инвестировать в подобные проекты без государственных гарантий? Данный факт приводит к монопольному положению Национального оператора, который рано или поздно начинает преследовать свои чисто коммерческие интересы.

Банальность №4. Федеративность.

Следующая Банальность развивалась параллельно с Банальностью №3, она вобрала в себя лучшее из Банальностей №1, №2 и №3, и даже лишена их недостатков. Но вспоминаем закон сохранения энергии: если где-то прибыло, значит откуда-то убыло. Отраслевые федеральные органы исполнительной власти в какой-то момент поняли, что разработанное ими типовое ПО можно не раздавать в регионы (Банальность №2), а предоставлять как сервис (Банальность №3), и делать это как бы на безвозмездной основе. Не правда ли, отличная идея? Но и тут есть недовольные!

Бизнес недоволен тем, что консалтинговые «сливки» собирает только одна избранная компания - разработчик типового ПО. Региональные ОГВ тоже недовольны, так как исходя из их «уникальности и неповторимости» функциональность федеральной системы их не удовлетворяет. Тут стоит отметить, что данные претензии регионов небезосновательны, федеральные органы исполнительной власти, в первую очередь, закрывали свои потребности и создавали ИС, в первую очередь, под себя. «Федералы» не всегда внимательно прислушиваются к мнению и запросам «регионалов», а ведь работа с мнениями и чаяниями регионов - это непростая и кропотливая работа. Как результат, регионы пытаются всеми правдами и неправдами «отмазаться» от использования федеральных ГИС. Еще кто-то помнит ГИС ЖКХ? А может быть ТОР КНД?

Какой должна быть модель счастливого будущего

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

Такая модель должна:

• обеспечить федеральную координацию информатизации, но не ограничивать бизнес и самостоятельность регионов;
• позволить ИТ-компаниям разрабатывать прикладное ПО, а региональным заказчикам выбирать то, что нужно именно им, и при этом не потерять управляемость версионностью;
• эффективно расходовать бюджетные средства, но при этом обеспечить развитие ИТ-отрасли в целом;
• создавать и развивать региональные центры разработки, создать им условия доступа на рынки всех субъектов РФ;
• направить консалтинговый потенциал и фантазии региональных лидеров в созидательное русло на пользу всей России;
• удовлетворить качественные ожидания граждан – потребителей государственных сервисов.

Возможный сценарий

Так какая же у нас базовая ценность? Какие результаты мы хотим получить на пути региональной информатизации? Судя по принятым нормативным актам, мнениям экспертов и программе «Цифровая экономика» мы должны достичь прорывного развития реального сектора экономики Российской Федерации через применение новых информационных технологий во всех сферах деятельности. Базовое определение понятия «Цифровая экономика» говорит нам о максимальном снижении транзакционных затрат в реальном секторе экономики с помощью использования информационных технологий. Государство должно создавать благодатную почву для взращивания и становления нового бизнеса, поощрять инициативу, помогать открывать новые рынки и упрощать доступ к существующим. В нашем случае, бизнес - это компании-разработчики прикладного ПО, рынки – региональные и муниципальные заказчики.

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

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

Мы ведь согласимся с тем, что полномочия региональных минсельхозов или минтрансов на 90% пересекаются? Мы ведь не станем спорить с тем, что в том же региональном минсельхозе можно сформировать требования к содержанию и форматам хранения информации о посевных полях, а в минтрансах - к перечню, объёму и форматам хранения сведений о транспортных средствах? Да, будут отличия, но 90% совпадений – это основа и «обязательная программа» к реализации. Разработка и принятие на федеральном уровне базовых стандартов отраслевой цифровизации может быть первым шагом к победе.

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

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

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

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

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

Все мы используем смартфоны, некоторые из них на платформе iPhone, некоторые на Android. Мы отлично знакомы с App Store и Play Market, соответственно. Когда мы ставим на телефон приложение показывающее прогноз погоды, мы не сильно смотрим на название производителя, мы не задумываемся о том, будет ли оно работать на нашем телефоне, сможет ли использовать данные о геолокации нашего телефона и т.д. Разработчик создавал приложение прогноза погоды с четким соблюдением стандартов, которые гарантировали ему включение разработки в Store, а потребителю - работоспособность и удовлетворение его ожиданий. Вы, как заказчик, можете выбрать другое приложение с прогнозом погоды, с другой ценой, другим интерфейсом, новыми дополнительными функциями и т.д., и это приложение также будет работать. Не правда ли, удобно? А почему тогда мы лишаем нашего уважаемого государственного заказчика таких возможностей?

Базовые отраслевые платформы и государственный магазин приложений (Gov.Store) – это Банальность следующего уровня, которая способна изменить и рынок ИТ, и подход к региональной информатизации, и процедуру закупок (44-ФЗ), и при правильной и мудрой государственной политике создать предпосылки к взрывному росту цифровой экономики Российской Федерации. Базовая отраслевая платформа обеспечивает формирование системной инфраструктуры (скелета, матрицы) и выполнение требований отраслевых стандартов. Это как лоток для яиц, где четко определена ячейка под яйцо определенной конфигурации. Яйцо – это данные, это функция, это микросервис. Яйца (микросервисы) и есть те сущности, которые в больших масштабах могут и должны генерировать разработчики (бизнес), после чего выкладывать их в управляемый государством магазин (витрину). Регионы, получив и развернув у себя базовые отраслевые платформы, могут «набирать» из магазина конкурирующие между собой системы (приложения, микросервисы), которые больше всего подходят под его специфику и удовлетворяют их ожидания.

Микросервисная архитектура системы — это архитектура, ориентированная на взаимодействие множества небольших, слабо связанных и легко изменяемых модулей (систем, приложений) - микросервисов. Если в традиционных вариантах сервис-ориентированной архитектуры (Банальности №1, 2, 3 и 4) модули могут быть сами по себе достаточно сложными программными системами, а взаимодействие между ними зачастую полагается на стандартизованные тяжеловесные протоколы, в микросервисной архитектуре системы выстраиваются из компонентов, выполняющих относительно элементарные функции и взаимодействующие с использованием экономичных сетевых коммуникационных протоколов. За счёт повышения гранулярности, микросервисная архитектура нацелена на уменьшение степени зацепления (меры неотрывности элементов) и увеличение связности, что позволяет проще добавлять и изменять функции в системе в любое время. В настоящее время такими микросервисами в значительной степени мы можем назвать сервис идентификации пользователей – ЕСИА, а также веб-сервисы СМЭВ.

Собирая из микросервисов функциональные модули и межотраслевые системы, как мозаику или конструктор Lego, мы сможем создавать новые сервисы для граждан и бизнеса, не прибегая к реализации сложных заказных проектов с непредсказуемым результатом. Да, рынок заказных разработок сильно сократится, но значительно вырастет рынок разработки прикладного тиражируемого ПО, а это открывает перед нами новые рынки, в том числе зарубежные.

Возможно, кто-то из читателей посчитает меня сказочником, писателем-фантастом, мечтателем или просто дураком, и, возможно, они окажутся правы. Один из древних мыслителей говорил, что все нас окружающее когда-то было мечтами и сказками, мысль порождает действие, а действия формируют быль. Книги писателей-фантастов тоже давали вдохновение гениальным изобретателям. Возможно, мое видение не совпадает с вашим, возможно ваша «сказка» окажется куда интересней. Если это так, то это прекрасно, давайте говорить об этом, давайте дискутировать, обсуждать, искать новые пути экономического развития регионов на благо всего государства Российская Федерация!