Просмотр исходного текста страницы Биллинговая система в большом городе

[[:Категория:Владимир Рахтеенко (Статьи)|Владимир Рахтеенко]], генеральный директор ООО «Заказные ИнформСистемы».

«Биллинговая система в большом городе»<ref>Ежемесячный журнал руководителя и главного бухгалтера «ЖКХ» № 1, январь 2005, стр. 73-78.</ref>


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

== Полный цикл коммунального биллинга ==

Основное требование к биллинговой системе по обслуживанию мегаполиса — это поддержка полного цикла биллинговых услуг (Рис. 1).

[[Image:Полный цикл коммунального биллинга (2005).gif|frame|Рисунок 1. Полный цикл коммунального биллинга]]

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

На практике связи между услугами имеют более сложный характер, чем показано на схеме. Так, изменения базы данных могут происходить не после формирования отчетов, а по выполнении начислений или диспетчеризации (расщепления) платежей. Упрощаем картину, чтобы подчеркнуть одно важное обстоятельство. А именно — каждый этап биллингового цикла представляет собой серьезную технологическую задачу. Вместе с тем, успешное решение каждой из этих задач возможно только в рамках интегрированного решения, в рамках единой платформы.



== Характеристики промышленной системы ==

Рассмотрим некоторые общие характеристики промышленной информационной системы.

* Во-первых, промышленные системы, рассчитанные на обслуживание большой территории или на значительное число клиентов, обладают большим сроком жизни. Большой срок жизни влечет за собой целый ряд следствий. Например, необходимость как можно более точно «угадать» архитектуру системы, чтобы меньше менять ее на разных этапах жизненного цикла. Естественным также будет требование предоставить гарантии длительного сопровождения.

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

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

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

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

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

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

== Условия успешного внедрения биллинговой системы ==

== Профессиональный IT-партнер ==

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

Что дает городу привлечение профессиональной IT-компании? Прежде всего — это выход на современный уровень автоматизации. Дело здесь не в том, чтобы следовать за веяниями моды. Программные продукты и даже платформы быстро устаревают. Специалисты, в отличие от кустарей, следят за изменениями в своей отрасли и вовремя переходят на новые инструменты и стандарты.

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

Современные технологии — далеко не единственное преимущество работы с профессиональным поставщиком. Независимый разработчик, его специалисты и технологии — это ресурсы, которыми можно пользоваться в критических ситуация. Таким образом, IT-партнер предоставляет клиенту определенный запас прочности. Это особенно актуально в тех случаях, когда клиент расширяет задачи проекта, хочет выйти на новый уровень обслуживания поставщиков ЖКУ и органов власти.

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

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

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

== Технологические критерии выбора поставщика ==

Для компании-разработчика те требования, которые надо предъявлять к поставщику программного комплекса, очевидны. Состоявшиеся IT-компании сами довольно часто привлекают партнеров на субподряд. Поэтому им понятно, что нужно требовать и чего можно ожидать от партнера. Что должен продемонстрировать партнер, чтобы его пригласили выполнить общегородской биллинговый проект?

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

В идеале поставщику нужно иметь опыт именно в области коммунальных биллинговых систем. Если такого опыта нет, он должен продемонстрировать успехи в других отраслях с близким уровнем сложности, например, на финансовых рынках, в автоматизации торговли или промышленных предприятиях.

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

* В-третьих, поставщик должен продемонстрировать, что предлагаемая системная технология отчуждаема, что она может быть передана заказчику, что заказчик не становиться заложником поставщика. Каковы механизмы защиты заказчика от заложничества? Главной гарантией может служить подтвержденный опыт отчуждения технологии в прошлых проектах. Поставщик демонстрирует как налажен процесс передачи технологии другому коллективу.

Вторая гарантия свободы заказчика — искусство договорной работы. Хорошо продуманный пакет договоров не позволит довести ситуацию до конфликта и разрыва отношений.

== Организационно-экономические критерии выбора поставщика ==

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

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

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

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

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

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

== Апробированная проектная технология ==

=== Кривая стоимости IT-проектов ===

Чем отличаются разные типы проектных технологий, которые сегодня представлены на рынке? Если проанализировать различия в разрезе всего двух характеристик — сложности и стоимости — то результаты анализа можно представить в виде графика (см. Рис. 2), охватывающего широкую линейку подходов, начиная от так называемого «коробочного» программного продукта к уникальному проекту. На полученной непрерывной кривой можно обозначить следующие реперные точки.

[[Image:Кривая стоимости проектов автоматизации (2005).gif|frame|Рисунок 2. Кривая стоимости проектов автоматизации]]

Во-первых, «коробочные» программы. Это программное обеспечение, которое не может быть должным образом изменено под конкретного заказчика. Идеология таких продуктов следующая: приспособить потребности клиента под возможности программы, а не наоборот — возможности программы под потребности клиента. Характерный пример — это типовые бухгалтерские программы, правовые программы, стандартные офисные пакеты, специальные приложения для инженерного проектирования или статистического анализа. Устраивает — берете, не устраивает — не берете.

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

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

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

На представленном графике хорошо видно, что одна из основных трудностей IT-индустрии состоит в том, что стоимость проекта является экспоненциальной функцией от его масштаба и сложности. Эксперты приводят разные оценки: от <tt>1,5</tt> в степени «трудность» до 2 в степени «трудность». И когда начинается проект, хоть в чем-то более сложный, чем установка «коробочного» ПО, значительные усилия участников проекта направлены на то, как удержать объем задания и его сложность, чтобы не выйти за пределы установленного бюджета и сроков.

== Выбор между готовой программой или готовым решением ==

Готовые решения востребованы прежде всего там, где не удается найти на рынке программу, подходящую хотя бы на 80 %. Чтобы определить это, заказчик должен составить предварительную спецификацию или просто начальный список требований и затем, изучая доступные продукты один за другим методично ставить галочки: есть — нет, есть — нет. Если для каждой из существующих на рынке программ анкета будет заполнена менее чем на <tt>80 %</tt>, и при этом известно, что это «коробки», а не готовые решения, но начинать внедрение не имеет смысла.

Программу нельзя будет внедрить не потому, что это технически невозможно. Как раз в технической области возможности информатизации сегодня сильно превышают даже самые смелые потребности. Но если отклонение прототипа и «коробки» от реальной ситуации заказчика больше, чем <tt>20 %</tt>, то стоимость доработки недостающих блоков программы будет настолько превышать лицензионную стоимость, что ни один здравомыслящий человек с этими цифрами не согласится. Из этого следует такой вывод, что, вообще говоря, при серьезной постановке задачи выбираются технологии, а не прототипы. И, как ни парадоксально это звучит, при этом менее важно, насколько готовое решение подходит под начальные требования.

Вторая причина, которая побуждает выбирать готовые решения и отказываться от «коробок» — это отсутствие сложившейся бизнес-практики, стандартных бизнес-процессов. Например, в банковской системе основные бизнес-процессы хорошо известны и описаны в специальной литературе. А в коммунальном биллинге такого однообразия пока не наблюдается. Поэтому каждый раз, когда заказчик сталкивается с нестандартной ситуацией, ему приходится выбирать уже не между «коробкой» и готовым решением, а между готовым решением и уникальным проектом.

Еще один довод в пользу готовых решений приводят международные исследования, которые говорят, что практически в любом крупном проекте информатизации требования к функциональным возможностям создаваемого продукта растут от <tt>2</tt> до <tt>10 %</tt> в месяц. Эти цифры заслуживают самого пристального внимания. Они означают, что если проект рассчитан, к примеру, на один год, то при отсутствии должного контроля за объемом требований ситуация изменится на <tt>120 %</tt>. При этом не исключено, что фантастические, на первый взгляд, <tt>20 %</tt> поверх <tt>100 %</tt> означают возвращение к первоначальным планам на новом уровне понимания сложности. К сожалению, это не только теория. Такие случаи происходят довольно часто.

Откуда берутся эти <tt>2-10 %</tt> в месяц? Дело в том, что по мере внедрения системы все начинают лучше понимать, что они делают. Кроме того, жизнь не стоит на месте и появляются новые рыночные вызовы. Новый уровень понимания и неожиданные рыночные вызовы делают динамику требований к системе изначально не предсказуемой. Вчера требования были одни, сегодня — другие, а завтра могут оказаться третьи (Рис. 3).

[[Image:Типичная динамика роста требований в больших проектах (2005).gif|frame|Рисунок 3. Типичная динамика роста требований в больших проектах]]

На схеме приведена ситуация, при которой начальные требования (область 1) и возможности прототипа (область 3) совпадают не полностью. Тем не менее, клиент делает выбор и пытается внедрить «коробочное» решение, потому что области вроде бы неплохо перекрывают друг друга. Но, скажем, через год-два получается, что текущие требования ушли совершенно в другую сторону (область 2). И теперь потребности заказчика не совпадают с прототипом в гораздо большей степени, чем этого бы хотелось и казалось допустимым в начале проекта. Именно поэтому искусство выполнения сложных проектов состоит в разумном проектном управлении.


== Технологии управления IT-проектом ==


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

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

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

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

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

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

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


== Ссылки ==
<references />


[[Категория:Владимир Рахтеенко (Статьи)]]
[[Категория:Технологии для ЖКХ]]
[[Категория:ЖКХ (Публикации)]]
[[Категория:2005 год (Статьи)]]

{{replicate-from-custiswiki-to-lib}}