В.Г. ГОРБАЧЕВ (ПСИ «Интегро», Уфа)

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

То, что интеграции информационных ресурсов в рамках единой ИС необходима, понимают сегодня все управленцы. Это понимание базируется на единстве объекта (территория города одна, объекты недвижимости одни и те же) и органа управления (администрации города) при множестве разрозненных взгядов на направления развития территории (рис. 1). Только сложность и громоздкость системы управления территориальными процессами вынуждает декомпозировать задачу управления на подзадачи и для решения каждой из них создавать специализированные учреждения и предприятия, которые уполномочены регулировать процессы определенного типа, создавая собственные информационные ресурсы. Эти организации и работают в большой степени самостоятельно, не сильно заботясь о согласованности данных о территории. Интеграция данных в единые информационные ресурсы и согласованная работа с ними проблема № 1 для городского управления, поскольку технологические процессы в настоящее время имеют ярко выраженный межведомственный характер.

Рис. 1. Упрощенная архитектура системы городского управления

Поэтому в разрешении проблемы интеграции информационных ресурсов заинтересована каждая организация, входящая в состав администрации: управления архитектуры и градостроительства (УАиГ), комитеты по управлению муниципальным имуществом (КУМИ), землеустроительные организации (условно «горкомземы», земельные агентства администраций), жилищные МУП, инженерные и дорожные службы и др., поскольку в повседневной деятельности часто требуется увязывать собственные информационные ресурсы с данными других информационных систем.

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

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

Цели создания интегрированных муниципальных систем
Задачи, для решения которых создаются интегрированные системы, по большому счету, следующие:
объединение разных ИС с целью организации межведомственных технологических (информационных) и документарных процессов. К таковым, например, относятся процессы подготовки разрешительных документов в УАиГ, договоров аренды муниципальных объектов недвижимости в КУМИ, процессы подготовки документов для проведения аукционов на предоставление земельных участков и др. Все это межведомственные процессы, в которых на разных стадиях оформления документов участвуют многие организации. Сроки оформления затягиваются, организации часто не знают, какие данные об объекте изменились (например, статус объектов недвижимости) в смежной организации;
объединение данных с целью предотвращения повторного ввода информации в различных муниципальных структурах и устранение ошибок несоответствия данных в разных ИС. Например, общегородские данные адресный реестр, реестры физических и юридических лиц, картографическая основа позволяют в интегрированной системе опираться на одни эталонные данные и не заниматься многократным вводом данных в свои ИС при работе с одними и теми же документами. Такие общегородские справочники и реестры задают эталонные массивы единые для разных организаций, что создает принципиальную возможность использовать в своей работе информацию смежных организаций;
подготовка интегрированной отчетности, при формировании которой требуется обработать разнородные, но взаимосвязанные данные разных организаций, использующих для их ведения собственные ИС.

К важным задачам относится также стремление муниципальных организаций сократить затраты на сопровождение ИС: проектные, информационные, технические и инфраструктурные.

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

Рис. 2. Интегрированная муниципальная система в области недвижимости

Итак, проблемы интеграции:
1. Каждая интегрированная ИС уникальна вследствие большой сложности и «замкнутости» на местные условия. В каждом городе существуют своя насыщенная событиями история развития систем, свои властные решения, свои специалисты, особенности нормативной базы и т. д. Поэтому не существует модели интегрированной системы, которую легко было бы установить в данном большом городе и быстро получить результат. Четких методик «как надо строить ИС» не существует: в каждом городе внедрению предшествует обследование, во время которого специалисты знакомятся с существующим состоянием дел и затем разрабатывают концепцию создания интегрированной ИС именно в городе N, которая предписывает действовать только так, как можно действовать именно здесь, с этой структурой управления, с этим составом специалистов.
2. Интегрированная ИС система большая, сложная и уникальная. Следовательно, создается в течение длительного периода времени, за который творчество депутатских и чиновничьих масс породит большое количество изменений нормативно-правовой базы. Чаще принципиальных, чем косметических. Поэтому создание ИС приходится вести в условиях постоянно изменяющихся требований (кроме изменений нормативной базы сюда можно отнести смену концепций управления городскими организациями с приходом нового руководителя, реструктуризацию системы управления и др., причем не только в целом, но и в каждой отдельной подсистеме). Как известно, изменения нормативной и директивной базы происходят на всех уровнях управления, и законотворчество в нашей стране «успешно» мешает интеграции. Если ИС обширна и охватывает много подсистем, то объем постоянно и неожиданно возникающих изменений трагически велик. Иногда, начиная с некоторого масштаба сложности интегрированной ИС, группа разработчиков уже не успевает развивать систему, а вынуждена заниматься исправлением уже созданных подсистем ИС с учетом новых требований. Работа по развитию системы замораживается, и планируемый эффект от интеграции не достигается. Во избежание таких ситуаций сформулировано важнейшее требование к инструментальным программным средствам, которые используются для создания ИС, а также к интегрируемым ИС их модифицируемость, т. е. свойство, позволяющее вносить изменения быстро и без серьезных затрат. Таких систем очень мало, и заказчику надо быть очень внимательным, чтобы в красивой упаковке не купить систему, для внесения изменений в которую потребуется постоянно обращаться к коллективу разработчиков. Проблему усугубляют ошибки выбора архитектуры системы, поскольку их учет и «обход» также требует много усилий. Хорошо, если все эти проблемы только снижают тонус групп «внедренцев», но когда кто-то из разработчиков увольняется, начинается процесс дезинтеграции.
3. Существует очень сложная проблема согласования уже имеющихся в системах данных, которые надо объединить в рамках ИС. Частные информационные системы содержат большой объем накопленных данных. Например, КУМИ и УАиГ имеют реестры физических и юридических лиц, состоящих из тысяч и десятков тысяч записей, информация которых имеется: в КУМИ в постановлении и договоре аренды земельного участка, в УАиГ в разрешительных документах на строительство объекта на участке, в земельном комитете в землеустроительном деле. Задача интеграции этих трех систем в единую ИС предполагает, что информация о всех документах должна быть связана между собой и отнесена к одной записи, например, юридического лица. Однако, не тут-то было! Может оказаться, что в каждой организации наименование одного и того же юридического лица записывали по-разному. Пусть некоторая фирма «Астра» в каждой из трех объединяемых БД записывается тремя разными способами: ООО «Астра», Общество с ограниченной ответственностью «АСТРА», ООО Астра (без кавычек).

Значит программа согласования данных уже в БД интегрированной ИС создаст запись не об одном юридическом лице, а о трех разных. Конечно, есть облегчающие моменты: возможность сравнивать юридические лица по ИНН, по другим признакам, выделять организационно-правовую форму «ООО» тремя способами (интеллектуализация конвертора) и др. Однако некоторые организации не всегда вводили в свою базу ИНН для юридического лица, а иногда и делали ошибку в таком ИНН. Тогда интеграцию данных не удается выполнить автоматически: появляются дубликаты одного и того же юридического лица. Значит, и интеграция данных полной не получается: информация о юридическом лице будет «разорванной»: либо землеустроительное дело, либо договор арены будут связаны с разными «формами записи», т. е. фактически с двумя разными копиями системы. И таких разночтений в «сливаемых» базах данных тысячи. В результате после слияния нескольких баз, множество данных остаются разорванными и кто-то из понимающих задачу специалистов должен в течение нескольких недель, а то и месяцев проверять все несовпадения и исправлять их. Часто для этого приходится использовать бумажные документы. Плохо, что поправить данные нелегко: и правильные, и ошибочные данные потому и присутствуют в БД, что уже нашли отражение в юридических документах, и документы становятся несоответствующими электронным данным. А по всем нормативным документам «если данные в электроном виде и в бумажном не совпадают, то приоритет имеют данные в бумажном документе». Вот и получается в результате такой интеграции «немая сцена»!
4. Сильно влияет на интеграцию систем отсутствие тесной оперативной связи между интеграторами и специалистами объединяемых систем. Иногда внедренцы/разработчики интегрированной ИС в процессе ее создания даже не подозревают, что в объединяемых, но еще не объединенных ИС (процесс-то растянут во времени!) что-то уже изменилось и это создаст неожиданные новые трудности. Например, в одной из частных систем вдруг поменяли справочники. А в интегрированной ИС этот факт еще не отразили по разным причинам. Ситуация усложняется, когда в составе ИС имеется федеральная система, например, Единый государственный реестр земель (ЕГРЗ), Государственный кадастр недвижимости (ГКН), система налоговой службы или федерального казначейства. На уровне города можно долго и с воодушевлением заниматься разработкой конверторов данных для обмена информацией между системами, и вдруг 15 января нового года в земельной палате появляется новая версия ЕГРЗ с новым интерфейсом. Или казначейство вводит новые КБК вместе с муниципальной реформой, которые никто в свои базы данных еще и ввести не успел, потому что работать до конца года надо было со старыми КБК. И делается это аккурат 29 декабря предшествующего года. Ясно, что интегрированная ИС оказывается в ситуации, когда один из каналов связи а именно с ЕГРЗ таинственным образом перестает работать. Земельная кадастровая палата не обязана никого предупреждать, что им пришла новая версия ЕГРЗ, да и не подозревает об изменениях. У интеграторов начинаются очевидные трудности. То же самое может случиться и с системами налоговой службы, и регистрационной палаты, и другими федеральными информационными системами. На федеральном уровне часто не учитывают тот факт, что в городах кто-то занимается информатизацией, и не задумываются о том, что в одну минуту рушат работу общегородской системы.
5. В результате интеграции возможно некоторое перераспределение части функций между организациями-участниками, особенно в случае реинжиниринга межведомственных процессов. Когда люди собираются в какой-то коллектив, им приходится «притираться» друг к другу. Это означает, что большинству придется чем-то пожертвовать ради того, чтобы коллектив был работоспособен, распределить между собой функции и ответственность. При интеграции ИС организации опасаются, что перераспределение функций окажется не такими, как они себе представляют, что это приведет к усилению позиций других организаций, что организация будет отстранена от справедливого распределения ресурсов и т. д. Поэтому иногда затягиваются сроки согласования, появляются неоправданные «капризы» некоторых организаций, а то и саботаж интеграционных процессов. Собственно, эти опасения небезосновательны: часть функций вместе с соответствующими рабочими местами может быть легко передана в другую организацию, если такое распределение полномочий окажется оптимальным. Наличие интегрированной ИС облегчает реорганизацию: системе безразлично, где работает сотрудник, главное наличие доступа к ней.
6. До сих пор имеются фирмы-разработчики программных систем, которые стараются не поставлять заказчикам конверторы на экспорт данных в признанные форматы, чтобы как можно дольше вынуждать заказчиков оставаться «приверженцами» их ограниченных продуктов.
7. Разработчики «пропали» (уехали в Гондурас на заработки, фирма развалилась, молодежь ушла в армию) и корректировать подсистемы вдруг стало некому. Эта ситуация весьма распространена и связана в целом с низкой развитостью индустрии разработки программного обеспечения в нашей стране, следствием чего являются невысокие относительные заработки программистов. Слабое представление заказчиков об истинных затратах на «интеллектуальный» труд и низкое финансирование проектных работ в нашей стране ведут к тому, что из этой области вымываются специалисты и уезжают либо в Москву, либо сразу на Запад, где платят в разы больше. С нашей точки зрения, если компания-разработчик смогла просуществовать в регионе в течение как минимум трех лет, то в этом случае она научилась быть нужной в России и имеет надежные результаты.

Другие иллюзии сторон
Работы по созданию интегрированных ИС сопровождаются многочисленными иллюзиями как заказчиков, так и разработчиков.

Иллюзии руководства заказчика связаны, как правило, таковы:
интегрированная система создается легко, непринужденно и быстро;
создание интегрированной ИС процесс, не связанный со значительными затратами;
интегрированную ИС можно создать, не слишком помогая внедренцам: «есть договор исполняйте»;

Типичной ошибкой являются случаи, когда компании, называющие себя системными интеграторами, только поставляют технику, разворачивают сети и базовое программное обеспечение, а заказчик считает, что приобретает систему «под ключ». Часто заказчику внушают, что приобретение ГИС решит имущественную или градостроительную задачи. Прозрение наступает быстро сразу после подписания актов сдачи системы в эксплуатацию.

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

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

Способы построения интегрированной ИС
Способов построения интегрированных ИС много, однако, по большому счету это вариации двух «крайних».
Возведение интеграционного комплекса с нуля в «чистом поле». Это самый простой и предпочтительный случай, почти всегда гарантированно ведущий к успеху, если построить работу по созданию интегрированной ИС правильно. Подобная ситуация реальна для малых и некоторых средних городов, в которых серьезные ИС не использовались, но имеется желание руководства администрации города внедрить сразу интегрированную систему, минуя этап разработки самостоятельных ИС в разных организациях. В этом случае еще нет данных, которые надо выверять и согласовывать; нет разнородных систем, которые надо связывать между собой; нет устаревшего вычислительного и сетевого оборудования, которое для крупной системы будет необходимо заменить. Другими словами, нет отягчающих факторов. И, как известно, город строить в чистом поле легче, поскольку его сразу можно запроектировать и создать именно таким, как надо. Система «в чистом поле» имеет привилегию сразу стать правильной, развиваясь последовательно. Это означает, что ядро системы может строиться как единый для всех потребителей реестр данных, и все основные процессы обмена информации закладываются в единстве. Если к работе привлечь опытную компанию разработчиков и внедренцев, то результат может превзойти все ожидания. Разработка интегрированной ИС не будет намного дешевле, чем в других случаях, но экономия времени на создание будет вполне реальной и, следовательно, результат от использования очевидным. Для строительства интегрированной ИС в «чистом поле» лучший вариант во всех отношениях создание централизованной системы (см. рисунок) и последующее развитие ее в части специализированных предметных областей (КУМИ, УАиГ, землеустройство, ЖКХ и др.) путем создания на центральном сервере предметных подсистем, уже связанных с центральным ядром с помощью единых общегородских справочников и реестров.

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

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

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

В следующей статье автор попытается дать несколько рецептов решения задачи создания интегрированной ИС муниципалитета.
Продолжение в следующем номере