Биллинг, что это такое?

Вид материала

Закон

Содержание Замена, модификация биллинговой системы Ближайшие перспективы развития биллинговых систем

Подобный материал:

• Наркотики – страшное зло, 13.34kb.
• Т. П. Возможно ли «объективистское» религиоведение?, 75.66kb.
• «Что такое семья?», 64.33kb.
• Это сладкое слово свобода! Что такое свобода, 89.79kb.
• 1. что такое нефтехимия, 823.72kb.
• Что такое самооценка и как она складывается в младшем школьном возрасте, 132.04kb.
• Сочинение. Что такое словесный мусор?, 32.51kb.
• Десять нерешенных проблем теории сознания и эмоций. Эмоции, 306.48kb.
• Проблема психологической готовности ребенка к школе возникла несколько десятилетий, 18.79kb.
• Что такое Глютамат натрия?, 54.75kb.

Замена, модификация биллинговой системы

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

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

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

При принятии решения на замену биллинговой системы необходимо:

1. Создать функциональную схему новой биллинговой системы;
   
2. На основании функциональной схемы сформулировать задачу о производстве технического задания на систему;
   
3. Оценить состояние технических средств и разработать план по модификации технического парка, используемого в автоматизированных системах обработки данных;
   
4. Оценить финансовые затраты на создание новой системы;
   
5. Найти исполнителя новой системы.
   

При производстве новой системы, во избежание трудностей по вводу и уменьшение затрат, необходимо:

• соблюсти принцип преемственности методологии и технологий
  
• стремится к максимальной степени консолидации данных
  
• максимально использовать типовые решения.
  

6. Ближайшие перспективы развития биллинговых систем

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

• фактор субъективности в данных оценках (съем показаний контролером);
  
• методическая погрешность в оценке потребления, связанная с несовпадением отчетного и расчетного периодов.
  

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

Таким образом, создание АСКУЭП – это первый, объективно необходимый шаг в переоснащении биллинговых систем.

В мировой практике подобные системы имеют обозначение "AMR systems" (Automatic meter reading (AMR) - система автоматического считывания показаний счетчиков). Почти все мировые приборостроительные компании мира много лет работали над созданием простых, надежных и "дешевых" систем для бытовых потребителей. При разработке таких систем соблюдались два основных подхода: система должна быть окупаемой и обеспечивать повышенную надежность функционирования. В настоящее время такие системы созданы, производятся серийно и массово внедряются во многих странах как развитых, так и развивающихся. С 2000 года ежегодно составляется отчет "Международное распространение AMR". Самый последний вариант отчета был представлен на международной конференции "Metering Asia-Pacific 2002" (Измерения в Азиатско-Тихоокеанском регионе-2002) в Сингапуре в апреле 2002. В отчете авторы утверждают, что AMR очевидно становится международной технологией.

Анализируя состояние дел в разных странах отмечено, что наряду с пионерами в области использования AMR - США, Канадой, Японией, Францией, Израилем, Германией, Швейца­рией и Италией, являющимися лидерами в этой области, появилось несколько стран с развивающейся экономикой, таких как Испания, Украина, Бразилия, верящих в перспективу AMR. Особо отмечено, что внутри Европы Украина стала третьим, самым большим потребителем AMR.В дополнение к этим ярким событиям есть более существенные новости. В Италии, крупная энергоснабжающая компания Enel возвестила, что она развертывает AMR для всех 27 миллионов потребителей внутри страны.

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

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




Рис.1.

2. О системах принятия решений
   

Одним из основных направлений развития корпоративных систем обработки данных является создание систем поддержки и принятия решений (СППР). В общем-то, все проблемы автоматизации процессов, связанных с накоплением данных, замыкаются, в конечном счете, на проблеме использования этих данных – на проблеме выбора или решения.

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

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




Рис.2


Пока что, в открытых источниках, нет информации о готовых продуктах СППР именно в области энергосбыта. Но в свое время велись работы по созданию подобных систем для диспетчерских пунктов управления регионального значения (Москва и Московская область). Данные системы строились по методологии экспертных систем (ЭС), но оказались не состоятельными, по причине:

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

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

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

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

Решая задачу создания СПР, разработчики, прежде всего, должны решить задачи:

1. Формализация модели бизнес-процессов энергосбыта с применением биллинговой технологии
   

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

• финансовых вложений и поступлений
  
• финансовых затрат
  
• финансовых рисков
  
• финансовых выигрышей.
  

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

Финансовые вложения и поступления энергосбыта формируются в результате:

1. оплат клиентов компании за потребленную электроэнергию
   
2. банковских (коммерческих) кредитов
   
3. других источников поступления.
   

Финансовые затраты включают затраты на:

1. поддержание сетей энергоснабжения (технические)
   
2. инвестиционные издержки (программы)
   
3. заработная плата и формы материального стимулирования
   
4. социальные программы.
   

Финансовые риски – оценка возможных потерь связанных с:

1. изменениями политической системы
   
2. изменениями законодательства
   
3. изменения условий работы рынка
   
4. действиями конкурентов
   
5. форс-мажорными обстоятельствами.
   

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

2. Выбор технологии и модели системы принятия решений
   

Существует два основных подхода к созданию таких моделей:

• отображение действующих процессов
  
• создание нового оптимизированного проекта.
  

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

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

Для задач, решаемых энергосбытом, приемлем первый подход, по причинам:

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

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

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

Чаще всего для аналитической обработки данных изменения баз данных, производящихся в рабочем порядке, не существенны. Таким образом, возникает необходимость создавать так называемые агрегаты данных – периодически формируемые наборы данных, объединенных по неким семантическим признакам, доступные только для чтения. Процесс создания таких агрегатов называется агрегирование данных.

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

1. OLAP – технология
   

OLAP (On-line Analytical Processing) – процесс аналитической обработки данных. OLAP- технологии представляют собой класс так называемых интеллектуальных систем обработки данных.

OLAP – системы строятся на двух основных принципах:

• работа с предварительно агрегированными данными
  
• язык пользователя системы сконструирован на базе языка проблемной области.
  

Пользовательские оболочки таких систем уже сконструированы разными компаниями. Так как СУБД Oracle уже используется в некоторых технических решениях холдинга, то, возможно, представит интерес разработка компании Oracle – Oracle Express, интегрированную в универсальный Oracle Server. В общем-то, оболочка Oracle Express являет собой прообраз технологии MOLAP (Multidimensional OLAP). Также компанией Oracle разработана система Discoverer 3.0, реализующей технологию ROLAP (Relation OLAP). Системы, использующие технологии MOLAP и ROLAP различны в методологии построения базы данных в части касающегося реализации ключевого понятия (объекта) OLAP систем – гиперкуб.

Гиперкуб или многомерный куб данных – это условно создаваемый объект, который образно можно представить в виде совокупности ячеек, сформированных многомерными таблицами. В случае 2-х мерного куба, это обычная и привычная нам таблица (типа EXEL), например, с данными оплат абонентом по периодам. Добавляя к оплатам и периодам еще и потребление – получаем трехмерный куб. А если добавить данные еще и о количестве посещения контролером данного абонента – четырехмерный. Ну, а если все данные, которые могут полностью воссоздать информационный «портрет» абонента» - получим n-мерную ячейку такого вот гиперкуба, где n – количество размерностей или параметров составляющий единицу агрегата данных. Гиперкуб, n – размерность, агрегат данных и прочее – это все семантические единицы, служащие для описания некой специфичной проблемной области.

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

В случае, ROLAP-методологии данные сначала помещаются в специальную многомерную базу (MDB, Multidimensional Date Base), как прообраз виртуального гиперкуба. А в дальнейшем средства OLAP-сервера позволяют эффективно распоряжаться этими данными. Скорость доступа к данным поменьше, чем в предыдущем методе, но выигрыш за счет минимизации потерь памяти вычислительной системы.

OLAP-технологии разработаны в контексте, с так называемыми, технологиями разработки Хранилищ Данных (Date Warehouse) (ХД). Данная технология разрабатывалась с целью обеспечить быстрый доступ к консолидированным базам данных большой группы специалистов, предварительно обеспечив эти данные средствами интеллектуальной обработки. В общем, ХД – это особым образом сгруппированные данные, снабженные механизмами и средствами доставки их к потребителю, сообразуясь потребностям потребителя.

Технологии ХД оказались очень трудоемки, громоздки и дорогостоящие. Окупаемость их составляет на сегодняшний день, в среднем 40%. Хотя компании-разработчики усердно их рекламируют, указывая на некую их перспективность – еще бы, компаниям-разработчикам подобного ПО необходимо окупать свои разработки как-то.

Но в результате работ над технологией ХД возникла идея создания, так называемых Витрин Данных (ВД) (Date Mart).

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

Естественно, компании разработчики ХД сразу же представили свои продукты, использующие технологию ВД. Компания Oracle - пакет Date Mart Suit (DMS).

Пакет DMS включает пять компонент, естественно, легко интегрируемых в Oracle Server (а то, иначе – зачем они нужны все эти приложения):

• Date Mart Designer – позволяет описывать структуру Витрины и запоминать ее в Репозитарии (хранилище описаний), на выходе будем иметь описание на языке DDL SQL, которое подается на вход Oracle7 Enterprize Server. В результате создается структура данных, реализующая ВД. В ходе построения ВД пользователь может применять существующие описания структур или строить новую ВД. Кроме того, Date Mart Designer позволяет строить приложения для Oracle Web Server на базе PL/SQL.
  
• Date Mart Builder – извлекает данные из внешних источников, включая реляционные СУБД и CVS-файлы) и заполняет Витрину.
  
• Oracle7 Enterprize Server
  
• Web Server – предоставляет открытую платформу для разработки Web- приложений. Он включает в себя Web Request Broker (WRB), реализованный на технологии картриджей и позволяющий разрабатывать Web- приложения, встраиваемые в Web Server. В качестве средств разработки могут использоваться Java, PL/SQL, LiveHTML, C, C++.
  
• Discoverer 3.0 – это средство конечного пользователя, позволяющего генерировать счета, а также выполнять некоторые OLAP-операции с ВД. Отчеты, созданные в Discoverer 3.0, можно экспортировать в HTML-файл, делая их доступными для Web-браузеров. Также Discoverer 3.0 позволяет таблицы агрегированных данных.
  

В пакете Date Mart Suit (DMS) есть ряд готовых приложений, который в виде оболочек сконструированы ВД, например Sales Analyzer (Анализ продаж). Эти приложения можно адаптировать к сходным задачам ЭК, но лучше, все же, создавать свои, оперирующие понятными терминами реальных бизнес-процессов.

Не плохо, естественно, нанять хорошую компанию и заказать ей некий весьма универсальный продукт максимально автоматизирующий процессы. Стоимость таких продуктов весьма высока. Даже самые «дешевые» OLAP-решения, например, фирмы SAS Institute дешевле $200 тыс. не бывают.

Но, увы, электроэнергия это не тот продукт, на котором наживаются сверхприбыли, особенно на рынке стран бывшего СССР. Таким образом, нужно использовать готовые решения или, как всегда, создавать что-то подобное и даже лучше самим.

2. Специализированные системы
   

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

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

Как конструируется обычная и привычная глазу двумерная таблица (многомерные абстракции это только для теории или внутримашинной реализации)? Таблица (матрица) содержит ячейки на пересечении строк и столбцов. Значения параметра (m-номер строки, n-номер столбца) в каждую ячейку выбираются из БД согласно некому критерию . Если организовать удобную выборку параметров из базы метаданных (описания параметров, репозитария) и соответствующих критериев выборки, то можно создать конструктор отчетов, что и есть основой технологии Витрин Данных в случае применительно к энергосбытовой деятельности. Ведь основой принятия решения менеджера энергосбыта, в основном, служат именно данные, взятые из специальных таблиц. «Специальность» или специфичность данных таблиц позволяет говорить о создании специализированной автоматизированной системы поддержки и принятия решений.

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

• Менеджер, имеющий соответствующие права, дает задание программисту на формирование соответствующего отчета и хорошо, когда менеджер понимает, чего он хочет, и еще лучше, если программист понял, чего от него хотят;
  
• Программист старается как-то формализовать критерии выборки данных и затем, написав соответствующие процедуры или, в простейшем случае, используя язык типа SQL, делает нужные выборки данных, транслируя их в «красивую таблицу», например, типа EXEL.
  

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

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

• Менеджер определяет тип отчета на уровне семантических формул (обычных речевых конструкций, ранее оговоренных и описанных в репозитарии). Например:
  
  • название отчета «Безнадежная дебиторская задолженность компании» - формируется таблица с таким названием;
    
  • далее идут выборки наименований параметра столбца под общим названием «Группы потребителей» («Промышленность», «Железная дорога», «Сельхозпотребители», «Жилкоммунхоз» и прочее.
    
  • затем выбирают параметры строк по названием: «Активная», «Реактивная», «Штрафные и финансовые санкции».
    
• Выбрав строки и столбцы таблицы, задается критерий выборки , например, «За текущий месяц».
  
• Далее запуск системы и получаем сконструированный отчет, на создание которого при обычной технологии ушло бы несколько дней.
  

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

В принципе, энергосбытовая деятельность должна соответствовать неким критериям «строгости». Сфера энергетики