“Прогибать” систему под себя - нерезонно

ПРОЕКТЫ

Муниципальные информационные системы выделяются среди других им подобных не только тем, что получают более щедрую финансовую поддержку, но и своими масштабами. Недаром для согласования действий в области информационной политики российской столицы было признано целесообразным проводить ежегодную конференцию “Информационные ресурсы г. Москвы” с выездом на речные просторы. В предыдущем номере PC Week/RE (№ /99, с. 1) мы постарались дать общее впечатление о прошедшем с 29 июля по 1 августа городском мероприятии, в этом мы продолжаем эту тему рассказом о новой информационной системе Московского городского бюро технической инвентаризации (МосгорБТИ), с докладом о которой выступил на конференции Юрий Будовский, зав. аналитическим сектором МосгорБТИ (кстати, это был единственный доклад, посвященный внедрению R/3).

От добра добра ищут

Ядро новой команды автоматизаторов образовалось в МосгорБТИ в 1996 г. Перед ней была поставлена задача выработать и утвердить долгосрочную информационную политику московского бюро недвижимости, разбить на тактические шаги и начать ее реализацию (при условии поддержки в стабильном, жизнеспособном состоянии действующей ныне системы).

Эта система, надо сказать, вполне работоспособна: в ее состав входят два не интегрированных между собой программных продукта, выполненные в архитектуре файл-сервер (один - собственной разработки, написанный на Clarion, другой - созданный на базе бухгалтерского ПО “Парус”); на каждой площадке обработка информации производится в сети; обмен информацией между площадками и центром осуществляется с помощью магнитной ленты и дискеты. В качестве сетевой ОС используется Windows NT, все клиентские места стандартизованы, что гарантирует быструю замену вышедшего из строя оборудования или ПО.

Юрий Будовский (слева) и Андрей Елагин: “Теперь мы чувствуем себя

уверенней - за нашей спиной четыре погонных метра документации SAP”

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

Юрий Будовский: “На мой взгляд, до сих пор на разных городских уровнях еще как следует не осознаются преимущества интегрированных систем управления. А это фундаментальное свойство корпоративных ИС, дающее возможность повсеместно использовать информацию, введенную один раз в любом функциональном модуле. Интегрированная ИС берет на себя ответственность за своевременное обновление данных, их хранение в одном массиве, внесение изменений в связанные документы, архивирование данных, резервное копирование и другие важные процедуры, которые в случае лоскутной автоматизации должны быть обеспечены сложными организационными действиями”.

Чтобы перечисленные недостатки не стали тормозом, в 1997 г. был предложен стратегический план развития ИС МосгорБТИ на 10 лет, который предусматривает плавную интеграцию данных Бюро в информационные ресурсы города (см. рисунок). Юрий Будовский подчеркивает, что с самого начала в план был заложен главный принцип - развитие системы должно идти в интересах городских структур, потребляющих информацию технического учета недвижимости (а к ним относятся многие муниципальные службы, занимающиеся регистрацией сделок купли-продажи и сдачи в аренду недвижимости; ремонтом, техническим обслуживанием, тепло-, водо- и энергоснабжением; а также милиция, пожарные, страховые компании и др.). Проделанный на первом этапе анализ показал, что потребителей информации технического учета в 100 раз больше, чем ее создателей. Поэтому будет удобно операторам работать по-новому или нет, - это не влияло на выбор решения. Для обучения в БТИ существует специально оборудованный учебный класс и с переквалификацией проблем не бывает.

Направо пойдешь - костей не соберешь. А налево?

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

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

Окончательные требования к новой ИС выглядели так:

- неограниченные возможности для описания объектов недвижимости (как по количеству, так и по качеству информации);

- прямая и обратная интеграция семантической и графической информации о недвижимости (поэтажные и адресные планы, планы инженерного оборудования);

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

- реализация концепции “универсального рабочего места”, при которой его функциональное наполнение происходит динамически в зависимости от прав пользователя;

- поддержка распределенной работы пользователей;

- нечувствительность к смене аппаратной и программной платформы;

- доступность данных в сочетании с безопасностью их обработки и надежностью хранения;

- применение открытых стандартов обработки и хранения информации;

- наличие встроенного механизма протоколирования действий пользователей;

- возможность администрирования системы на уровне распределения ролей и функций.

После формулирования требований к ИС на предпроектном этапе решалась стандартная для крупных предприятий дилемма - стоит ли разрабатывать ПО привлеченными силами (делать на заказ) или лучше купить готовое программное решение. После взвешивания всех pro et contra инициативная группа остановилась на готовом решении. Выбор осуществлялся из семи интегрированных систем: “Парус”, “Галактика”, “Альфа”, R/3, Baan, Concorde XAL, Oracle Applications.

Предпочтение было отдано R/3, прежде всего потому, что в этой системе имелся специализированный модуль управления недвижимостью (Real Estate). Кроме того, выбирающую сторону устроил уровень локализации продукта и его поддержки в России, а также стратегическая надежность партнерства с SAP.

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

Первые итоги

Юрий Будовский: “Только теперь, по прошествии четырех месяцев работы с системой, я стал спокойно читать документацию по R/3 и понимать ее. Первое время сильно уставал от того, что 24 часа в сутки ощущал себя идиотом.

А если серьезно, то R/3 - это гибкость адаптации и сложность настройки”.

Плюсы. “Главное преимущество решения на базе R/3 заключается в том, что можно быть спокойным за выбор стратегического пути развития ИС своего предприятия, - отмечает Юрий Будовский, имея в виду надежность партнерства с фирмой SAP. - Кроме того, система такого класса позволяет сосредоточиться на проблемах своего предприятия, осмыслить, что ты хочешь сделать, не беспокоясь о том, как это сделать”, - продолжает он.

“Главная ошибка тех, кто внедряет R/3, как мы сейчас понимаем, состоит в том, что люди стремятся "прогнуть" систему под свои "стереотипы", не пытаясь разобраться в процедурах, предлагаемых в R/3, - продолжает тему Андрей Елагин, зав. сектором проектных решений МосгорБТИ. - Мы очень быстро поняли, что разумнее реализовать стандартные процедуры, поскольку они гораздо более отточены. Остается только разобраться, как это сделать.

В принципе, внедрение R/3 можно провести и за 2 - 3 месяца при условии, что вы хорошо знаете, что хотите сделать. То есть к моменту внедрения необходимо иметь четкое представление о процедурной и информационной модели проекта информатизации”.

Сотрудники БТИ особо отмечают возможности встроенных в R/3 инструментальных средств, таких, как система классификации, техника условий, конфигурируемые объекты, служба изменений. Все это можно применить в отношении любого присутствующего в системе объекта, независимо от того, в каком модуле он находится.

Еще один важный аспект - исходные тексты системы открыты и посмотреть связи между объектами всегда можно (этим активно пользуются консультанты SAP).

Минусы. Крупные проекты не обходятся без проблем. Однако ни одна обнаруженная к сегодняшнему дню проблема не была названа разработчиками ИС БТИ фатальной.

Встретились трудности с адресным учетом объектов, поскольку в R/3 такая информация недостаточно структурирована (тип улицы, ее наименование, номер дома, корпуса и квартиры записываются в одно поле).

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

В системе МосгорБТИ обрабатывается около 20 видов основных отчетных документов государственного образца (отчеты по налогам, ипотечным взносам и проч.), которые в первую очередь связаны с регистрацией прав на недвижимость. Они имеют специфический для России вид и потому отсутствуют в стандартном комплекте поставки отраслевой версии R/3 (хотя в ней есть варианты отчетов для четырех европейских государств). Локализацию под российское законодательство выполняет представительство SAP в Москве.

Юрий Будовский: “Приступая к проекту, мы понимали, что совсем обойтись без привлечения консультантов SAP нам не удастся, но постарались все же минимизировать эти затраты и считаем, что это в значительной мере удалось”.

Стандартный эпилог

По составленным в конце 1998 г. планам развития пилотного проекта, в начале 2000 г. должен произойти переход к промышленной эксплуатации R/3 и начаться тиражирование настроенной системы на площадки БТИ (все это было бы вполне реально, по мнению руководителей пилотной команды) и, возможно, на отдельные рабочие места в других организациях управления городом. Однако существуют и не зависящие от пилотной группы проблемы финансового и организационного характера. Их решение может значительно отдалить светлые времена интеграции информационных ресурсов города. Тем не менее сотрудники пилотной группы настроены оптимистично и темпов работы не снижают. Капля камень долбит...

 Московское городское бюро технической инвентаризации

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

- База данных БТИ содержит информацию о 80 тыс. зданий, 3,5 млн. квартир (предметная БД занимает около 1 Гб, управленческая - 2 Гб)

- Ежедневно обрабатывается около 1500 заказов

- Организация расположена на 17 производственных площадках

- Численность персонала - 700 человек

- Существующая автоматизированная система охватывает 350 рабочих мест

Хроника проекта

5 - 8 марта прошла инсталляция R/3 с привлечением консультантов из SAP Consult для настройки параметров (эту процедуру очень сложно осуществить персоналу заказчика самостоятельно).

В конце апреля были сделаны все настройки в предметной области. Таким образом, через 1,5 месяца, по оценкам руководителей пилотной группы, система позволила уже решать примерно 80% прикладных задач, стоящих перед МосгорБТИ. Оставшиеся 20% требуют более сложной и тонкой доводки, которая займет еще несколько месяцев.

Помимо отраслевого решения Real Estate в БТИ планируется эксплуатировать пять универсальных модулей R/3 - техническое обслуживание и ремонт оборудования, управление сервисом, финансы, контроллинг, сбыт. Всего - 10 рабочих мест.

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