CustisWiki - Новые страницы [ru]

Современная IТ-стратегия для динамичного банка — исполнение по заказу

2008-09-19T16:10:57Z

BenderBot: 1 версия

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы».

«Современная IТ-стратегия для динамичного банка — исполнение по заказу»^[1]

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

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

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

↑ «Банки и технологии», № 4-2003, стр. 32-36.

Экономичная стратегия проектов по заказной разработке

2008-09-19T16:10:51Z

BenderBot: 1 версия

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы».

«Экономичная стратегия проектов по заказной разработке»^[1]

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

В книге известного консультанта в области управления Дэвида Майстера «Управление фирмой, оказывающей профессиональные услуги» приводится классификация, которой, на наш взгляд, вполне удовлетворяет и все разнообразие ИТ-проектов. В терминологии автора книги, это проекты типа «мозги», «седина» и «процедуры». Для того, чтобы объяснить логику подобного разделения необходимо ввести понятие «рычаг» проекта.

В каждом ИТ-проекте задействуются исполнители различной квалификации. Состав проектной команды можно образно представить в виде треугольника, вершина которого — наиболее квалифицированные кадры фирмы-исполнителя, а основание — менее квалифицированный персонал. В терминологии Д. Майстера, «рычаг» проекта — это соотношение вовлеченного в работу старшего, среднего и младшего персонала фирмы-исполнителя. Для каждого из перечисленных типов проектов будет характерен свой тип «рычага» — один из видов треугольника, приведенных на рис. 1.

Рис.1. «Рычаг» проекта по Д. Майстеру

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

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

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

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

↑ Журнал Intelligent Enterprise (Корпоративные системы),№ 20, 31 октября 2005, стр.40-43.

Какой расчетный сервис нужен поставщикам ЖКУ

2008-09-19T16:10:46Z

Пресс-служба: переименовал «Какой расчетный сервис нужен поставщикам ЖКХ» в «Какой расчетный сервис нужен поставщикам ЖКУ»

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы».

«Какой расчетный сервис нужен поставщикам ЖКХ»^[1]

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

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

Эти тенденции заключаются в настойчивом стремлении поставщиков услуг и ресурсов к созданию или развитию собственных абонентских служб. Более того, крупные поставщики и управляющие компании строят вполне серьезные планы по созданию собственных расчетных центров. Предполагается, что эти новые расчетные центры придут на смену существующим муниципальным ВЦ/РКЦ, а те, в свою очередь, «отомрут», как уже «отмирают» во многих городах муниципальные поставщики ЖКУ.

Рассмотрим некоторые аспекты, которые, на наш взгляд, определяют перспективы взаимоотношений поставщиков и управляющих компаний с расчетно-кассовыми центрами (РКЦ):

влияние на деятельность поставщиков и управляющих компаний начавшегося процесса коммерциализации ЖКХ;
взаимоотношения РКЦ и собственных сбытовых компаний поставщиков;
риски поставщиков при организации сбыта их услуг через РКЦ.

В настоящее время в ЖКХ выбор сфер деятельности достаточно прибыльных, интересных с точки зрения частного бизнеса, весьма ограничен: это сетевые компании электроэнергетики вместе с предприятиями энергосбыта, а также управляющие компании по обслуживанию жилого фонда. Остальные сферы зачастую не являются достаточно привлекательными из-за тарифного дисбаланса и высоких рисков.

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

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

Биллинговая система в большом городе

2008-09-19T16:10:41Z

BenderBot: 1 версия

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы».

«Биллинговая система в большом городе»^[1]

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

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

Многие тиражные продукты начинаются как заказные разработки

2008-09-19T16:10:35Z

BenderBot: 1 версия

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы».

«Многие тиражные продукты начинаются как заказные разработки» ^[1]

Как бы вы охарактеризовали ключевые отличия заказного ПО от тиражного?

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

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

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

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

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

Можно ли, на ваш взгляд, сравнить заказные и тиражные системы по характеристикам жизненного цикла?

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

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

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

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

Насколько сложнее, из вашей практики, стоятся отношения с заказчиком при разработке на заказ? Какие ключевые риски связаны с подобными проектами?

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

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

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

Если оставить в стороне случаи саботажа или головокружения от успехов, то следует обозначить основную, фундаментальную причину сложностей комплексной автоматизации предприятия. Индустрия информационных технологий все же относительно молода. И если с подготовкой ИT-специалистов в наших вузах все обстоит далеко не блестящим образом, то в плане преподавания информатизации экономическое и бизнес-образование делают только самые начальные шаги. Хотя классики, вроде Фреда Брукса, еще в 70-е годы описали особенности создания программных решений в терминах инженерных систем, многие управленцы не допускают мысли о том, что корпоративная система — это такое же сложное техническое сооружение, как, например, современное офисное здание.

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

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

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

Как, из вашей практики, решаются вопросы сопровождения в рамках заказных проектов?

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

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

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

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

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

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

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

Какие направления разработки являются сегодня для вас приоритетными?

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

В малотиражных решениях приоритет принадлежит коммунальному биллингу (система «Радей»), автоматизации социальной защиты населения (система «Радей-Соцзащита»), а также новому решению для финансовых компаний — CustIS General Ledger, XML edition.

Каковы ваши планы по развитию бизнеса в ближайшие годы?

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

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

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

↑ Обзор-интервью на сайте CNews («Рынок корпоративного ПО-2005»).

Вне тиража

2008-09-19T16:10:29Z

BenderBot: 1 версия

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы» (CustIS).: Текст интервью Владимира Рахтеенко в материале Елены Некрасовой «Вне тиража»; Публикация в журнале CIO (Chief Information Officer), № 8, 21 августа 2006, стр. 143^[1]

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

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

Внутренняя разработка — это разработка силами ИТ-специалистов внутри организации.

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

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

[svg]

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

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

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

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

Гибкость архитектуры и возможность масштабирования при изменении бизнес-процессов не свойственны ПО собственной разработки, несмотря на то, что руководители зачастую убеждены в обратном. Бытует мнение, что «если своим прикажем — все сделают». Однако в реальности бессистемное развитие решений рано или поздно достигает своего предела. Для тиражных решений архитектурная гибкость может быть обеспечена только отчасти. Ее относительно несложно добиться для количественных, линейных характеристик в рамках заданной отраслевой модели, но гораздо труднее — для масштабирования логики бизнеса.

[svg]

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

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

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

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

↑ Журнал CIO (Chief Information Officer), № 8, 21 августа 2006, стр. 143, «Вне тиража».

Заплатить за квартиру в Саратове? Легко!

2008-09-19T16:09:08Z

BenderBot: 1 версия

Татьяна Богатова, Начальник финансового отдела Министерства по строительству и ЖКХ Саратовской области:

«Заплатить за квартиру в Саратове? Легко!»^[1]

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

(Из выступления участника саратовского семинара):

Сегодня куда ни бросишь взгляд — он обязательно уткнется в реформирование и преобразование. Реформа образования, вооруженных сил, ветеранских льгот, административная реформа, пару лет назад ко всему этому прибавилось еще и жилищно-коммунальное хозяйство (ЖКХ). «Следует констатировать, что реформа ЖКХ в масштабах страны идет слабо» — этими словами открыл межрегиональный семинар коммунальщиков мэр Саратова Юрий Аксененко. Однако главным замыслом семинара была вовсе не констатация этого печального факта, а презентация интересного саратовского опыта по организации Единого расчетно-кассового центра (ЕРКЦ) для оплаты коммунальных услуг в городе с почти миллионным населением.

↑ «PC Week/RE», № 26-2004, 20 июля 2004.

Комплекс мер по реализации социальной поддержки населения

2008-09-19T16:09:04Z

BenderBot: 1 версия

Автор: Новикова Лариса Николаевна, Начальник финансового отдела Министерства по строительству и ЖКХ Саратовской области.

«Комплекс мер по реализации социальной поддержки населения»^[1]

Современная стратегия реформы ЖКХ определена подпрограммой «Реформирование и модернизация ЖКХ Российской Федерации» ФЦП «Жилище». В ней перечислены основные подходы и экономические принципы необходимых в этом секторе преобразований.

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

Для отработки нового механизма предоставления гражданам адресной целевой социальной помощи в Российской Федерации в 2002-2003 гг. проведен соответствующий эксперимент при оплате жилищно-коммунальных услуг с использованием персонифицированных социальных счетов. В проведении эксперимента приняло участие 19 субъектов Российской Федерации, в том числе и Саратовская область. На территории Саратовской области эксперимент проводился в Балаковском, Балашовском, Марксовском и Энгельсском муниципальных образованиях, в 2004 г. — в Новобурасском муниципальном образовании.

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

С целью перехода на систему адресного предоставления субсидий в г. Саратове ЕРКЦ г. Саратова совместно с Комитетом по труду и социальному развитию администрации города проводят совместную работу по созданию единого информационного пространства^[2]

Внедрение этой системы также поможет:

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

Установление единого информационного пространства для ЕРКЦ г. Саратова и Комитетом по труду и социальному развитию администрации города является практическим шагом по формированию областной информационной системы по учету плательщиков ЖКУ, первый этап которой — создание базы данных получателей адресной социальной помощи. Конечная реализация этой задачи позволит обеспечить открытый доступ к новой, объективной и актуализированной информации, необходимой для принятия корректных решений органами государственной власти и местного самоуправления, а также всеми субъектами хозяйственной деятельности в области ЖКХ, социальной сферы, экономики.

В настоящее время на территории региона проводится централизованная работа по созданию программного обеспечения, формированию единой базы данных получателей адресной помощи и оборудованию техническими средствами служб субсидий^[3].

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

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

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

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

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

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

Органы местного самоуправления могут:

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

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

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

↑ Ежемесячный журнал руководителя и главного бухгалтера «ЖКХ», №10, ноябрь 2005, стр. 12-13.
↑ Проект автоматизации для КТСР г. Саратова.
↑ Начат проект автоматизации для ЖКХ Саратовской области на базе «Радей-Соцзащита»

О правах ЕРКЦ

2008-09-19T16:09:02Z

BenderBot: 1 версия

Автор

Татьяна Лисина, ведущий аналитик ООО «Заказные ИнформСистемы».
«О правах ЕРКЦ»^[1]

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

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

Так, в отдельных публикациях и выступлениях высказываются сомнения в праве единых расчетно-кассовых (информационно-расчетных центров) — ЕРКЦ оказывать некоторые виды услуг. Более того, ставится под вопрос само существование этих организаций. В данной статье мы попробуем ответить на наиболее серьезные сомнения по поводу деятельности расчетно-кассовых центров.

↑ «Коммунальный комплекс России», №2 (февраль) 2005, стр.20-21.

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

2008-09-19T16:09:00Z

BenderBot: 1 версия

Автор

Татьяна Лисина, к.ф.-м.н., главный эксперт ООО «Заказные ИнформСистемы».
«Единые информационные расчетные центры как инфраструктурное обеспечение реформы жилищно-коммунального хозяйства»^[1]

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

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

В отличие от чисто платежных систем основные функции ЕИРЦ составляют полный биллинговый цикл:

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

Рисунок. Основные функции единых информационных расчетных центров

Надо сказать, что расчет квартплаты специалистами вычислительных центров существовал еще с советских времен. Так, например, в городе Туле гордятся тем, что областной «ИВЦ ЖКХ» создан в 1988 г. на базе Кустовой машинно-счетной станции, а первые шаги механизации учета в жилищно-коммунальном хозяйстве Тульской области были сделаны в далеком 1967 г. на основе счетно-клавишной техники. В массовом порядке центры по расчету оплаты за жилищно-коммунальные услуги стали создаваться в форме муниципальных унитарных предприятий или муниципальных учреждений с 2000 г. в соответствии с Постановлением правительства РФ от 3 августа 1999 г. № 887 «О совершенствовании системы оплаты жилья и коммунальных услуг и мерах по социальной защите населения». В связи с этим аргументы сторонников использования ЕИРЦ основаны на опыте многолетней работы (самые существенные из них приведены в таблице). В зависимости от того, какие проблемы в муниципалитете наиболее злободневны на момент принятия решения о схеме организации работы с оплатой за ЖКУ, любой из перечисленных доводов может стать решающим.

Таблица. Аргументы в пользу централизованного биллинга

Более подробно выгоды и преимущества для всех заинтересованных сторон описаны в статье Андрея Борейко^[2].

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

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

Попробуем оценить эти положения.

↑ «Имущественные отношения в РФ», №11 (ноябрь) 2007, стр.3-9.
↑ Борейко А.А. На стыке интересов // ЖКХ. 2005. № 7.

Проблемы исполнения на местах Правил предоставления коммунальных услуг гражданам

2008-09-19T16:08:56Z

BenderBot: 1 версия

Татьяна Лисина, к.ф.-м.н., ведущий аналитик ООО «Заказные ИнформСистемы»

«Проблемы исполнения на местах Правил предоставления коммунальных услуг гражданам»^[1]

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

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

Для решения этой задачи 23 мая 2006 года вышло постановление Правительства Российской Федерации № 307, которым утверждены Правила предоставления коммунальных услуг гражданам. Анализ указанного документа выявил ряд вопросов, однако в письмах-разъяснениях к этому постановлению Министерства регионального развития Российской Федерации от 13 февраля 2007 года № 2478-РМ/07 и от 4 июня 2007 года № 2479-РМ/07, № 10611-ЮТ/07 на большую часть этих вопросов ответов нет.

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

↑ «Имущественные отношения в РФ», № 5 (май) 2008, стр.35-40.

РКЦ как основа единой городской информационной системы

2008-09-19T16:07:55Z

BenderBot: 1 версия

Авторы

Кулапин Алексей Иванович, директор МУП «Единый расчетно-кассовый центр г. Саратова», доктор химических наук, депутат Саратовской городской Думы.
Новожилов Владислав Владимирович, первый заместитель директора МУП «Единый расчетно-кассовый центр г. Саратова».

«РКЦ как основа единой городской информационной системы»^[1]

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

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

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

Система стандартов позволила повлиять на снижение разброса в стоимости отдельных видов услуг коммунального назначения по регионам России с 30-50 раз до 15-30, чему способствовало упорядочение формирования себестоимости и тарифообразования. Однако, нельзя не отметить, что принятие Советом Федерации поправки к Закону РФ о продлении сроков перехода на новую систему оплаты жилья и коммунальных услуг увеличивает пропасть между потребностями отрасли в финансировании и возможностью государства поддерживать эти процессы.

В органах местного самоуправления, понимающих это, как правило, активно работают в двух направлениях:

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

Многие регионы идут по пути увеличения уровеня оплаты населением коммунальных услуг сверх установленных субъектом Федерации значений, понимая, что переход на 100% оплату является единственно выходом в ситуации реального финансирования при рыночных методах хозяйствования.

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

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

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

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

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

В качестве преимуществ организации системы управления коммунальными платежами на базе современного РКЦ можно отметить следующие аспекты:

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

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

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

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

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

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

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

Такой подход требует серьезного технического обеспечения. Только за один год работы с новым программно-технологическим комплексом МУП «ЕРКЦ г. Саратова» увеличило собственную базу данных более чем на 90 миллионов финансовых проводок. Не каждое техническое решение способно выдержать такую нагрузку.

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

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

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

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

МУП «ЕРКЦ г. Саратова» на сегодняшний день обслуживает почти 200 тысяч лицевых счетов жителей города. Для обеспечения удобства жителей, предприятием создана широкая сеть собственных пунктов. Она насчитывает 25 абонентских и 7 отдельных кассовых пунктов. Все они через высокопроизводительные каналы связи работают с единой базой данных. Всего для обработки обращений населения и бесперебойного приема платежей на предприятии функционирует 54 автоматизированных рабочих места операторов абонентских пунктов и 26 рабочих мест операторов кассовых пунктов.

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

На сегодняшний день создана и функционирует разветвленная сеть по сбору платежей по платежному документу МУП «ЕРКЦ г. Саратова». Платежи принимаются всеми отделениями управления федеральной почтовой службы (62 пункта приема), отделениями Сбербанка (40 пунктов), десятью коммерческими банками. Всего на территории города заплатить за жилищно-коммунальные услуги по платежным документам МУП «ЕРКЦ г. Саратова» можно в 179 местах.

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

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

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

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

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

Уже на первом этапе формирования такой системы пользователями и одновременно поставщиками информации в единую систему должны стать:

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

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

↑ Ежемесячный журнал руководителя и главного бухгалтера «ЖКХ», №9, сентябрь 2004, стр. 36-39.

Задачи информационных расчетных центров в реализации новых положений жилищного законодательства

2008-09-19T16:07:50Z

BenderBot: 1 версия

Автор: Кулапин Алексей Иванович, председатель Ассоциации расчетно-кассовых центров Саратовской области, директор «Единого расчетно-кассового центра г. Саратова, депутат Саратовской городской Думы.

«Задачи информационных расчетных центров в реализации новых положений жилищного законодательства»^[1]

В 2005 г. реформирование ЖКХ России вступило в стадию интенсивного практического воплощения и активного юридического закрепления.

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

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

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

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

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

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

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

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

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

о гражданах,
характеристиках жилых помещений,
истории оплат потребленных жилищно-коммунальных услуг,
поставщиках,
объеме и качестве.

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

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

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

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

Еще один аспект. Для осуществления расчета платы за жилищно-коммунальные услуги (при их непредоставлении или ненадлежащем качестве), а также в случае перерасчета платы за отдельные коммунальные услуги при временном отсутствии граждан по месту жительства очень важен тот факт, что определение порядка и методики расчета платы в этом случае отнесено новым Жилищным кодексом к компетенции Правительства РФ.

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

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

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

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

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

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

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

Эффективный интегратор должен:

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

Значение информации как основы для принятия экономически корректных и своевременных решений очень велико. Опыт реализации реформы социальной поддержки населения в соответствии с Федеральным законом от 22 августа 2004 года № 122-ФЗ показал, что недооценка информационного и соответствующего коммуникационного обеспечения может привести к нарушениям финансовой стабильности системы ЖКХ и, как следствие, ухудшению уровня жизни значительной части населения.

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

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

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

↑ Всероссийская конференция руководителей предприятий ЖКХ, Москва, 10 октября 2005.

Команда ИТ-проекта: как избежать проблем

2008-09-19T16:07:41Z

BenderBot: 1 версия

Алексей Кайдалов, ведущий эксперт ООО «Заказные ИнформСистемы»
«Команда ИТ-проекта: как избежать проблем»^[1]

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

↑ Публикация на сайте Cnews, раздел «Аналитика», 20 июня 2005.

Новый коллективный разум

2008-09-19T16:07:36Z

Пресс-служба:

Алексей Кайдалов, ведущий эксперт ООО «Заказные ИнформСистемы»
«Новый коллективный разум»^[1]

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

↑ "Банки и технологии", № 4-2004, стр.12-17.

Как автоматизировать получение отчетности по МСФО

2008-09-19T16:07:05Z

BenderBot: 1 версия

Андрей Гермейер, ведущий эксперт управления банковских технологий ООО «Заказные ИнформСистемы».
«Как автоматизировать получение отчетности по МСФО»^[1]

Сравнение отечественных и международных стандартов убеждает, что простыми корректировками, без ведения соответствующего учета, отчетность по МСФО можно получить только в некотором приближении, слабо пригодном для анализа и управления. Аналитика для ведения учета по международным стандартам существенно отличается от той, что требует сейчас Банк России. Альтернатива содержанию штата второй (международной) бухгалтерии банка — полная автоматизация обоих видов учета и отчетности. Создание и развитие разнообразных учетных моделей в рамках единой системы автоматизации — одна из основных компетенций компании «Заказные ИнформСистемы».

В 2004 году банковской системе России предстоит начать поэтапный переход на международные стандарты финансовой отчетности (МСФО). Уже много статей написано о разнице между действующим российским стандартом учета (РСБУ) и МСФО. Гораздо реже затрагивается тема об инструментальных средствах для получения новой отчетности, которую Банк России предполагает выводить корректировками из РСБУ.

Известно, что для получения полного свода отчетов по РСБУ многие банки рядом со своей автоматизированной банковской системой (АБС) создают хранилище данных, чтобы уже с его помощью формировать сложные аналитические отчеты. Такая связка баз данных — операционная АБС и хранилище — стала общепринятой для крупных банков. Сможет ли подобная конструкция автоматически обеспечить отчетность также и по МСФО?

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

Рисунок 1. Этапы получения отчетности по МСФО

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

Практически полноценное внедрение международных стандартов подразумевает реальную поддержку нескольких учетных моделей. Аналитика для ведения учета по международным стандартам существенно богаче той, что требует сейчас Банк России. Мощность учета определяется количеством его аналитических параметров-разрезов. Откуда же возьмутся силы у бухгалтерского отдела для параллельного ведения двух учетов, когда второй (так сказать, пока еще побочный) не слабее основного? Нанимать еще сотрудников? Альтернатива содержанию штата второй (международной) бухгалтерии — полная автоматизация обоих видов учета и отчетности.

Вот тут уже по настоящему пригодится компьютер. Второй учет должен быть полностью автоматизирован: открытие/закрытие лицевых счетов, формирование проводок и отчетных форм по документам должны производиться автоматически. Никто никаких мемоордеров во втором учете сочинять не должен, их можно только распечатать, чтобы проконтролировать работу программы. Никаких дополнительных сил для такого учета от бухгалтерии банка не потребуется. Итак, если автоматизировать учет, то отчетность по МСФО получится «автоматом» (см. Рис.2.).

Рисунок 2. Получение отчетности по МСФО при автоматизации учета по МСФО

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

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

Именно так работает банковская система GROSS (с сентября 2004 г. CustIS Bank), созданная в компании «Заказные ИнформСистемы» на базе учетно-аналитического ядра CustIS Accounting® (одна из торговых марок компании «Заказные ИнформСистемы»). Ядро CustIS Accounting® разработано на основе промышленной СУБД Oracle. Особенность GROSS заключается в том, что аналитические данные, полученные из бизнес-процессов, трансформируются в настроенную учетную структуру. То есть аналитическое хранилище не отделено физически от операционной банковской системы, а погружено в нее и фактически составляет ее базовый компонент. Целесообразность гибкой структуры данных хранилища обусловлена тем, что динамика бизнеса приводит к постоянному потоку новых требований к информационным системам. Как пример подобного требования — необходимость поддерживать новую учетную систему для МСФО параллельно действующей РСБУ.

Базовый принцип, который обеспечивает параллельное решение операционных и аналитических задач в GROSS — это последовательное преобразование разнородной информации, характерной для первичных документов, в однородную — для учета и анализа (см. Рис.3).

Рисунок 3. Последовательное преобразование информации в АБС GROSS

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

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

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

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

Приведем типовой перечень базовых аналитических атрибутов-размерностей:

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

Специалисты банка могут сами пополнять список аналитических атрибутов.

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

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

Особенность всех видов учета — хранение сальдо и оборотов на определенные даты, проведение проводок на любую дату в будущее и в прошлое, «откат» и «накат» дней с перерасчетом проводок. Тем самым поддерживается постоянная актуальность хранилища: архивные данные не замораживаются, сохраняется возможность отслеживать все изменения, происходящие в операционной АБС. Это свойство кардинально отличает GROSS как от обычных АБС, так и от традиционных хранилищ данных, объединяя ключевые функции тех и других.

Перечислим основные этапы работы с оперативным хранилищем:

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

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

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

↑ «Расчеты и операционная работа в коммерческом банке», № 3, март 2004, стр. 91-95.

В настоящий момент принципиально меняется концепция организации совместной работы

2008-09-19T16:06:38Z

BenderBot: 1 версия

Алексей Фролов, руководитель проекта, ООО «Заказные ИнформСистемы».

«В настоящий момент принципиально меняется концепция организации совместной работы» ^[1]

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

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

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

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

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

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

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

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

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

Каковы основные трудности, если судить по вашей практике, внедрения и сопровождения ИТ-решений для органов государственной власти? Каковы, с вашей точки зрения, пути преодоления этих трудностей?

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

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

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

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

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

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

Какие решения в сфере информатизации органов государственной власти предлагает ваша компания? В чем вы видите ключевые преимущества ваших решений?

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

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

Технология SharePoint отвечает такому критерию, как простота использования и минимальные затраты на обучение конечных пользователей. Большая часть взаимодействия с системой осуществляется непосредственно из приложений Microsoft Office, которым неплохо владеют большинство офисных служащих. При этом в SharePoint есть развитые возможности разграничения прав доступа и аудита действий пользователя, чего практически нельзя было встретить ранее в «стихийной» модели использования офисных приложений Microsoft.

Немаловажным преимуществом в нынешних условиях оказываются и сжатые сроки внедрения.

Чтобы проиллюстрировать нашу оценку преимуществ Microsoft SharePoint, достаточно сказать, что прежде, чем начать предлагать это решение клиентам, мы внедрили его у себя в компании.

Каковы отличительные черты решения на базе Microsoft Sharepoint Server 2007? В чем его преимущество по сравнению с решениями конкурентов?

Здесь стоит говорить не только о Microsoft Sharepoint Server 2007, а о комплексных интеграционных решениях, построенных на базе Microsoft Office System. Основными преимуществами таких решений является то, что они позволяют получить развитые информационные сервисы на базе стандартных программных продуктов, опираются на существующие в организации системы и обладают низкой совокупной стоимостью владения.

Особо следует отметить, что непосредственно в самом портальном продукте Microsoft Sharepoint Server 2007 появились развитые встроенные средства для построения решения масштаба организации, как говорится «прямо из коробки». Это средства интеграции со сторонними системами, средства построения бизнес-отчетности, средства создания приложений для работы с электронными формами, средства построения системы поиска масштаба предприятия.

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

Расскажите о наиболее интересном(-ых) проекте(-ах), выполненном(-ых) вашей компанией на базе Microsoft Sharepoint.

Специалистами компании «Заказные ИнформСистемы» был выполнен целый ряд проектов на технологиях Microsoft Sharepoint. Однако особо следует выделить проект по построению внутреннего портала для одного из ключевых департаментов Банка России. Этот департамент собирает информацию из многих внешних источников, создает самостоятельно информационные ресурсы.

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

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

Мы проанализировали ситуацию и предложили создать портал на базе Microsoft SharePoint Portal Server 2003. Ключевым фактором было то, что предложенное решение носит интеграционный характер. Оно не заменяет существующие системы, а наоборот, опирается на них и объединяет существующие источники информации. Портал предоставляет пользователям единую точку входа в информационное пространство.

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

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

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

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

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

Естественно, мы оказываем заказчику полный спектр ИТ-услуг: помимо НИР и консалтинга мы выполняем также проекты внедрения, адаптации и сопровождения решений. Что касается сопровождения, то в работе с госорганами мы придерживаемся индивидуального подхода. С заказчиком работают выделенные специалисты. Это позволяет обеспечить VIP-сервис. Причем сопровождение часто соединяется с дальнейшим развитием решения.

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

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

Как вы оцениваете динамику развития этого сегмента ИТ-рынка — создание портальных решений — ориентированного на органы государственной власти? Как вы оцениваете число игроков в этом сегменте рынка? Их много или мало? Насколько сильна конкуренция в этой сфере?

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

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

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

↑ Обзор на сайте CNews «ИТ в органах государственной власти России 2007».

АБС — эволюция от товара к услуге

2008-09-19T16:06:16Z

BenderBot: 1 версия

Андрей Гермейер, ведущий эксперт управления банковских технологий ООО «Заказные ИнформСистемы».
«АБС — эволюция от товара к услуге»^[1]

Предстоящая реорганизация банковской системы — какой она будет? Что может уравнять российские банки с «мировыми»?

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

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

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

Как же тогда под эти строящиеся новые технологии должны подлаживаться АБС? Что в них должно появиться новое и характерное для такой специализации?

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

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

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

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

При ведении торговых контрактов клиентов (Trade Finance) характерными модельными приложениями являются некий описатель внешних нефункциональных отличительных черт товарной продукции и монитор транспортного трафика товара. Описатель продукции работает в выверках коносаментов на товар, а монитор товарного трафика определяет и вексельные негоции, и фазы в обработке аккредитивов. Шлюзы к этим специальным программам задают и темп документооборота в банке, и саму структуру документов. Набор бизнес-процессов существенно зависит от того, кем является клиент банка — продавцом товара или его покупателем. Для продавца акцент документооборота будет смещен в вексельную сторону, для покупателя — в аккредитивную. А если клиент — посредник, то документооборот будет представлять собой уникальную смесь вексельных и аккредитивных операций. Попробуйте запрограммировать такое заранее… Учетные системы здесь распадаются на две части: собственно банковскую с особым детальным ведением позиций на корреспондентских счетах и клиентскую со своими платежными позициями по его торговым и производственным планам. Если первую в банке еще можно как-то представить, то вторая для банка совершенно необычна. А ведь без подобного учетного механизма банк не сможет оставаться конкурентноспособным на рынке Trade Finance.

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

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

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

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

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

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

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

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

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

Описанную нами тенденцию миграции информационных систем от товара к услуге поддерживают корпоративные технологии и универсальные учетные ядра, разработанные в компании «Заказные ИнформСистемы».

↑ "Банки и технологии", № 5-2004, стр. 30-33.

Автоматизация бэк-офиса банка: 3D-представление

2008-09-19T16:06:08Z

BenderBot: 1 версия

Андрей Борейко, заместитель директора по развитию бизнеса ООО «Заказные ИнформСистемы».
Андрей Гермейер, ведущий эксперт управления банковских технологий ООО «Заказные ИнформСистемы».
«Автоматизация бэк-офиса банка: 3D-представление»^[1]

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

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

↑ "Банки и технологии", № 6-2003.

Цена реформы

2008-09-19T16:04:46Z

BenderBot: 1 версия

Андрей Борейко, заместитель директора по развитию бизнеса ООО «Заказные ИнформСистемы».

«Цена реформы»^[1]

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

↑ «Российская муниципальная практика», № 2 (октябрь) 2004.

Основные этапы перехода на предоставление адресной социальной помощи

2008-09-19T16:04:39Z

BenderBot: 1 версия

Авторы

Андрей Борейко, заместитель директора по развитию бизнеса ООО «Заказные ИнформСистемы».
Татьяна Лисина, финансовый директор ООО «Заказные ИнформСистемы».

«Основные этапы перехода на предоставление адресной социальной помощи»^[1]

↑ Ежемесячный журнал руководителя и главного бухгалтера «ЖКХ», № 3, март 2005, стр. 52-55.

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

2008-09-19T16:04:33Z

BenderBot: 1 версия

Авторы

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы»
Андрей Борейко, заместитель директора по развитию бизнеса ООО «Заказные ИнформСистемы».

«Риск под контролем. Внедрение коммунальной биллинговой системы»^[1]

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

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

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

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

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

[svg]

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

Наши первые проекты в городах с населением до 100 тыс. человек сразу выявили ключевые риски, возникающие про внедрении высокотехнологичных информационных систем в ЖКХ в масштабе целого города. Их преодоление помогло нам перестроить свои проектные технологии так, чтобы в крупномасштабном проекте внедрения биллинговой системы в г. Саратове, население которого составляет 900 тыс., риски постоянно контролировались и минимизировались.

Эти специальные риски также могут быть условно разбиты на три группы:

политические риски
кадровые риски
инициализационные риски

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

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

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

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

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

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

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

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

[svg]

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

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

↑ «Коммунальный комплекс России», №6 (декабрь) 2004, стр.26-27.

Приглашенный биллинг. Две модели организации расчетов на розничном рынке энергоресурсов

2008-09-19T16:04:27Z

BenderBot: 1 версия

Андрей Борейко, заместитель директора по развитию бизнеса ООО «Заказные ИнформСистемы».

«Приглашенный биллинг. Две модели организации расчетов на розничном рынке энергоресурсов»^[1]

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

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

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

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

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

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

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

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

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

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

Оптимальным решением является реорганизация расчетных центров, их преобразование из муниципальных учреждений и унитарных предприятий в акционерные общества по аналогии с нарастающим процессом акционирования управляющих компаний. В реорганизованном предприятии поставщики энергоресурсов могут претендовать на существенную долю в акционерном капитале коммунального биллингового центра. По расчетам Фонда «Институт экономики города» их доля в структуре стоимости коммунальных услуг в среднем по стране составляет порядка 64% (см. Диаграмму 1).

При этом потребность в контроле над расчетами более чем 60% поставляемых ресурсов и услуг не обязательно означает необходимость вкладывать в модернизацию биллингового центра прямо пропорциональные этой доле денежные средства. Чтобы вывести расчетный центр на новый уровень можно привлечь средства других акционеров, а также кредиты банков, заинтересованных как в обслуживании биллингового центра и поставщиков, так и в работе с населением. В результате, собственные вложения поставщика энергоресурсов могут составить не более 10-15% от потребности в капиталовложениях на модернизацию биллинга (см. Диаграмму 2).

Единственным заметным недостатком данного подхода является необходимость договариваться с другими участниками проекта, а также снижение оперативного контроля над жизненно важным бизнес-процессом. Эти риски необходимо учитывать. Их минимизация достигается с помощью комплекса методов: через схему собственности и управления, на организационном и на технологическом уровне.

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

↑ «Коммунальный комплекс России», №5 (март) 2005, стр. 22-23.

Комплексная модель коммунального биллинга

2008-09-19T16:04:23Z

BenderBot: 1 версия

Андрей Борейко, заместитель директора по развитию бизнеса ООО «Заказные ИнформСистемы».

«Комплексная модель коммунального биллинга»^[1]

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

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

Технико-экономический комплекс коммунальных расчетов в ЖКХ

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

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

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

оптимальная схема собственности,
организационные know how,
современный программно-технологический комплекс.

[svg]

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

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

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

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

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

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

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

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

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

↑ «Коммунальный комплекс России», №4 (октябрь) 2004, стр.26-27.

РКЦ в рыночных условиях. Выживут ли расчетные центры в реформе ЖКХ?

2008-09-19T16:04:19Z

BenderBot: 1 версия

Андрей Борейко, заместитель директора по развитию бизнеса ООО «Заказные ИнформСистемы».

«РКЦ в рыночных условиях. Выживут ли расчетные центры в реформе ЖКХ?»^[1]

В ходе реформы ситуация на рынке ЖКХ постоянно меняется. Появляются субъекты рынка, которые создают конкуренцию уже действующим структурам. Выживут ли расчетно-кассовые центры новых экономических условиях? Будущее РКЦ зависит от того, насколько они сумеют осуществить на практике свои преимущества.

Реформу жилищно-коммунального хозяйства часто связывают с изданием федеральных нормативных актов, прямо и непосредственно влияющих на положение дел в этой отрасли. В действительности на ситуацию в ЖКХ оказывает влияние гораздо большее число факторов. Будущее коммунальной отрасли будет зависеть практически от всего комплекса российских реформ. В результате их осуществления одни формы хозяйственной жизни появятся, а другие — исчезнут. Сохранятся ли в будущем городские расчетно-кассовые центры (РКЦ)?

↑ «Коммунальный комплекс России», №3 (март) 2005, стр. 26-27.

Круглый стол «Внедрение единого расчетно-кассового центра»

2008-09-19T16:04:14Z

BenderBot: 1 версия

Андрей Борейко, заместитель директора по развитию бизнеса ООО «Заказные ИнформСистемы».

«Круглый стол ’Внедрение единого расчетно-кассового центра’»^[1]

↑ «Коммунальный комплекс России», № 11 (ноябрь) 2007, стр. 30-34. (Материал круглого стола подготовлен редактором журнала Юлией Подымовой).

Расчетные центры в реформе ЖКХ

2008-09-19T16:04:10Z

BenderBot: 1 версия

Андрей Борейко, заместитель директора по развитию бизнеса ООО «Заказные ИнформСистемы».

«Расчетные центры в реформе ЖКХ»^[1]

Никто точно не знает каким будет жилищно-коммунальное хозяйство России через десять лет, через пять лет и даже через два года. Внезапный интерес к теме ЖКХ со стороны крупных финансово-промышленных групп — у всех на слуху проекты РКС, «Интерроса», «Реновы» и РКИ — заставляет предположить, что рынок добрался-таки до коммунального хозяйства.

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

Все прочие соображения о том, как в действительности сложится баланс интересов, относятся к области догадок и предположений. Среди этих догадок есть и такие, которые уже находят практическое подтверждение. Это технологии и проекты, способные в корне изменить направление развития отрасли. Нам видится, что к их числу можно смело отнести проекты развития единых расчетно-кассовых центров (ЕРКЦ).

У ЕРКЦ есть свои сторонники и противники. Противники, среди прочего, указывают на западный опыт, говорят о необходимости производить расчеты между участниками рынка только через коммерческие банки, сделать все «как у людей», оставив за ЕРКЦ только информационные функции, то есть сделать их информационно-расчетными центрами (ИРЦ).

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

↑ Ежемесячный журнал руководителя и главного бухгалтера «ЖКХ», № 8, сентябрь 2004, стр. 47-50.

На стыке интересов

2008-09-19T16:04:04Z

BenderBot: 1 версия

Андрей Борейко, заместитель директора по развитию бизнеса ООО «Заказные ИнформСистемы».

«Расчетные центры в реформе ЖКХ»^[1]

↑ Ежемесячный журнал руководителя и главного бухгалтера «ЖКХ», № 8, сентябрь 2004, стр. 47-50.

Пять рынков коммунального биллинга

2008-09-19T16:02:14Z

BenderBot: 1 версия

Андрей Борейко, заместитель директора по развитию бизнеса ООО «Заказные ИнформСистемы».

«Пять рынков коммунального биллинга»^[1]

Региональные и местные власти уже осознали пользу расчетно-платежных центров.

Частному же капиталу и IT-сообществу еще предстоит убедиться, что автоматизация расчетов в ЖКХ может стать перспективным направлением высокотехнологичного бизнеса.

↑ «Бизнес-Форум IT», № 10, октябрь 2003, стр. 62-66.

Коммунальная страна

2008-09-19T16:02:05Z

BenderBot: 1 версия

Андрей Борейко, заместитель директора по развитию бизнеса ООО «Заказные ИнформСистемы».

«Коммунальная страна»^[1]

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

В разных городах их именуют по-разному: расчетный центр, информационно-расчетный центр, расчетно-кассовый центр и т. д., хотя основное назначение этих учреждений везде одинаково — выставлять счета за коммунальные услуги, те самые красиво отпечатанные листочки бумаги, которые ежемесячно ложатся в почтовые ящики по всей стране. За год цифры в этих листочках складываются во внушительную сумму. Например, в 2002 году, по данным Минэкономразвития, в России было начислено 512 млрд рублей и оплачено с учетом льгот и субсидий 270 млрд рублей, иными словами, через руки сборщиков коммунальных платежей прошло порядка 8,7 млрд долларов, и немалую долю этих средств собрали и распределили между поставщиками коммунальных услуг именно РКЦ.

Во многих городах (а на сегодняшний день РКЦ созданы уже едва ли не в каждом райцентре) эти учреждения пользуются большим влиянием, чем, скажем, ДЕЗы и любые другие управляющие компании жилищно-коммунального комплекса, и дело тут не только в обслуживаемых ими миллиардах рублей. Каждый такой центр аккумулирует у себя информацию о материальных и финансовых потоках поставщиков и потребителей, действующих на поле, где тесно переплетаются интересы населения, власти, управляющих структур, органов социальной защиты, банков, коммунальных монополистов и поставщиков энергоресурсов, — ключевую для контроля над коммунальным хозяйством в целом. Вот почему рано или поздно расчетно-кассовые центры оказываются желанной целью для различных структур, стремящихся взять расчеты и платежи за жилье и коммунальные услуги под свой контроль. Не случайно к деятельности РКЦ сегодня проявляют самый пристальный интерес многие представители крупного бизнеса.

Автоматизация расчетов в жилищно-коммунальном хозяйстве

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

Все это делает реформируемую сейчас «коммуналку» весьма привлекательным объектом для автоматизации. Здесь уместно провести аналогию с частным бизнесом: когда акционеры хотят привлечь стратегического инвестора или подороже продать свои активы, они задумываются над тем, как «причесать» свою компанию, сделать ее более прозрачной и управляемой. Они начинают перестройку компании и в рамках реорганизационных мероприятий внедряют учетные и управленческие системы — от самых простых до систем класса ERP. Потребность жилищно-коммунального хозяйства страны в инвестициях сейчас оценивается в 70-80 млрд долларов, так что отрасли совсем не помешает обрести хоть немного прозрачности, чтобы стать более привлекательной для потенциальных инвесторов. Биллинговая система расчетно-кассового центра фактически представляет собой ERP-систему для жилищно-коммунального хозяйства и уже хотя бы потому должна рассматриваться как обязательный элемент антикризисного управления.

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

[svg]

↑ «Эксперт», №31, 25 августа 2003, стр. 94-96.

Предстоит воссоздать или кардинально реконструировать целую отрасль государственных услуг населению

2008-09-19T16:01:10Z

BenderBot: 1 версия

Андрей Борейко, заместитель директора по развитию бизнеса ООО «Заказные ИнформСистемы».

«Предстоит воссоздать или кардинально реконструировать целую отрасль государственных услуг населению» ^[1]

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

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

Причины технологического характера известны — это низкое качество первичных данных, а как следствие — «плавающая» статистка и невозможность проверить информацию о реальном числе и составе льготников в отведенные сроки. Существующие федеральные программы, например, «Электронная Россия», эту проблему не решают, поскольку направлены на более высокий уровень управления. А статистика населения формируется на уровне муниципальных образований, на уровне районов, где состояние информационных фондов зачастую не отвечает современным требованиям ^[2].

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

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

К сожалению, есть некоторые сомнения в том, что такое знание востребовано. Как отмечают эксперты в области местного самоуправления ^[3], реформаторы в центре больше ориентируются на свое представление о должном и не уделяют внимания исследованиям и фактам. Нет нужды объяснять ИТ-специалистам, что любой масштабный проект автоматизации включает в себя оба подхода: надо описать ситуацию и «как есть», и «как должно быть». Иначе не ясен процесс перехода, и на реализацию проекта не хватит никакого бюджета.

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

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

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

Какие шаги следовало бы сделать российским властям в ближайшее время в отношении ИТ-поддержки социальной реформы? Какие действия они, вероятнее всего, предпримут?

Есть три необходимых шага: нормативное обеспечение, методическое обеспечение и программно-техническое обеспечение. Первый шаг уже отчасти пройден — принят известный федеральный закон №122. За ним должно следовать принятие региональных нормативных актов. Часть регионов позаботилась об этом заблаговременно, но далеко не все.

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

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

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

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

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

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

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

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

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

Когда ваша компания начала заниматься ИТ-решениями для социальной сферы и почему? Каких успехов вам удалось достичь?

В декабре 2004 г. мы заключили договор на поставку системы автоматизации для Комитета по труду и социальному развитию Администрации г. Саратова. Для компании «Заказные ИнформСистемы» этот проект — не первый опыт автоматизации социальных служб. Так, в 2000-2001 годах в общем контуре с городским расчетным центром была автоматизирована служба социальной защиты г. Саров Нижегородской области. Город небольшой, всего около 60 тыс. жителей, но хорошо известный как ядерный центр России. Установленная там система успешно работает до настоящего времени. Успех проекта был связан, в частности, с тем, что автоматизация соцзащиты проводилась одновременно с постановкой работы коммунального биллингового центра.

Саратовский проект отличается гораздо большими масштабами и полнотой функций. Численность населения города приближается к 1 млн., а число льготников, с учетом всех категорий, составляет более 170 тыс. человек. Здесь мы начинали с автоматизации единого расчетно-кассового центра (ЕРКЦ) г. Саратова, где в 2003-2004 гг. была внедрена система «Радей». Местный Комитет по труду и социальному развитию первое время оставался в стороне от общегородской системы и ограничился обменом информации, т.н. сверками данных. В первой половине прошлого года пришло понимание тех значительных выгод, которые дает бюджету использование единой системы, и лед, как говорится, тронулся.

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

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

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

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

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

Поэтому трудно представить себе, что в этом плавильном котле можно четко спроектировать и, тем более, реализовать некое целостное архитектурное решение, способное охватить страну сверху донизу и с востока на запад.

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

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

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

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

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

В государственных и муниципальных учреждениях еще живут мифы о чудо-программистах, которые в одиночку могут соорудить какую угодно систему. Такие слова, как «документация», «инструкции пользователю» и «сопровождение», поначалу просто вызывают недоумение. Надо ли после этого объяснять, куда «выпали» данные о четырех тысячах ни в чем не повинных пенсионеров?

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

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

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

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

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

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

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

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

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

Ранее вы говорили, что к теме информатизации единых расчетно-кассовых центров (ЕРКЦ) проявляют интерес не только представители власти, но и бизнес. Как вы видите дальнейшее развитие этого направления? Есть ли здесь какая-то связь с социальной реформой?

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

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

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

Сегодня поставщики электроэнергии, тепла, других ресурсов уже не могут мириться со сложившейся ситуацией. Для решения этих и смежных проблем РАО «ЕЭС России» создало РКС, «Ренова» — КЭС, «Базовый элемент» — РКИ, не говоря уже о проектах меньшего масштаба. К сожалению, не все проекты хорошо подкреплены в финансовом отношении. Не всем удается отстроить отношения с местными властями. Тем не менее, есть и первые успехи. Например, КЭС только в Свердловской области обслуживает около 60 муниципальных образований ^[4].

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

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

Из этой ситуации есть два выхода.

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

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

Связаны ли эти проблемы монетизации льгот с качеством реализации проектов внедрения единой социальной карты там, где они проводятся?

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

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

С какими проблемами российским властям предстоит столкнуться при автоматизации учреждений социальной защиты населения?

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

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

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

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

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

Каковы, на ваш взгляд, пути разрешения этих проблем и что вы планируете делать в этом направлении?

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

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

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

Приведет ли реализация социальной реформы к созданию нового сегмента в структуре рынка высоких технологий в нашей стране? Насколько это возможно в России и можно ли сегодня ожидать такого развития событий?

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

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

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

Рост общественного сектора — глобальная тенденция. Гуру теории управления Питер Друкер в своей последней книге пишет, что «почти все экономисты и огромное большинство руководителей считают, что гигантский экономический рост, наблюдавшийся в XX веке, был вызван экономическими факторами. А это не так. ...устойчивый рост наблюдался в четырех секторах: правительственные расходы, здравоохранение, образование, досуг» ^[5]. Социальная реформа в России затрагивает два из названных Друкером кластеров — бюджетные расходы и здравоохранение, а также такие важные отрасли жизнеобеспечения, как транспорт и жилищно-коммунальное хозяйство.

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

Вопрос в том, как мы можем цивилизованно сформировать новое направление информатизации к пользе всех заинтересованных сторон: и государства, и получателей социальной помощи, и компаний-разработчиков, и поставщиков коммунальных услуг. Задача очень сложная. Тут много разных факторов, а цена ошибки велика. Нам представляется, что на уровне поставщиков ИТ-решений успех можно обеспечить, во-первых, за счет грамотного управления проектами, а во-вторых, за счет создания партнерских цепочек, подобных тем «петлям роста», которые в свое время создавали западные ИТ-компании ^[6].

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

↑ Обзор на сайте CNews «ИТ в органах государственной власти России 2005».
↑ См., например, заключительную часть публикации
↑ См. доклад профессора Вячеслава Глазычева [http://www.polit.ru/lectures/2004/09/21/glaz.html «Глубинная Россия наших дней»
↑ См. «КЭС выступают за комплексный подход в ЖКХ«
↑ Друкер, Питер, Ф. Задачи менеджмента в XXI веке. М., 2004. С. 78-79.
↑ Зафер Ачи, Эндрю Домэн, Оливье Сибони, Джаянт Синха, Стефан Витт. Парадокс быстрорастущих компаний. McKinsey Quarterly, 1995, № 3

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

2008-09-19T15:59:00Z

BenderBot: 1 версия

Андрей Борейко, заместитель директора по развитию бизнеса ООО «Заказные ИнформСистемы».

«Перспективы банковского обслуживания персонифицированных счетов для адресного субсидирования жилищно-коммунальных услуг» ^[1]

Тема, обозначенная в заголовке статьи, несмотря на длинное название, касается лишь небольшого блока работ, связанных с автоматизацией расчетов в жилищно-коммунальном хозяйстве^[2].

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

Чтобы пояснить масштаб вопроса, достаточно сказать, что за прошлый 2002 год все платежи населения и бюджетов в адрес поставщиков жилищно-коммунальных услуг составили 270 миллиардов рублей ^[3].

Льготы по оплате составили 30 млрд. рублей, начисленные субсидии — 12 млрд. рублей. Причем надо отметить, что при существующей системе социальной защиты до 30-40% населения имеют право на получение льгот и субсидий.

Даже с учетом хронического недофинансирования жилищной сферы значительные денежные потоки проходили и будут проходить через банковскую систему и другие финансовые институты, занятые обслуживанием ЖКХ. Более того, суммы начисления и оплаты коммунальных услуг растут существенно быстрее инфляции. Так, в 2002 г., по данным Госстроя, россияне заплатили за эти услуги на 100 млрд. руб. больше, чем в 2001 г. ^[4]. Проблема заключается в том, что даже совместные платежи населения и бюджета составляют всего лишь 53% от совокупной суммы, предъявленной к оплате, которая в 2002 году достигла 512 млрд. рублей.

У этой ситуации есть несколько причин:

неполный сбор платежей за ЖКУ за счет низкой платежной дисциплины потребителей услуг — населения и предприятий;
значительный объем льгот (см. выше), которые просто вычитаются из начисленного, уменьшая сумму оплаты;
субсидии также вычитаются из начисленного, но убытки, которые при этом возникают у поставщиков, покрываются государством не полностью, так как:
- субсидирование производится не адресно, а по категориям граждан, что принципиально затрудняет контроль за справедливостью предоставления субсидий;
- бюджеты по разным причинам задерживают или даже вовсе не перечисляют дотационные средства в адрес поставщиков ЖКУ.

[svg]

Примерная схема оплаты ЖКУ в большинстве регионов России по состоянию на сегодняшний день представлена на следуюющем рисунке:

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

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

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

Первый вариант представлен на следующей схеме:

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

Второй вариант предоставляет гораздо большую свободу гражданину и, как следствие, обслуживающему гражданина банку:

Потребитель услуг производит 100% оплату ЖКУ в соответствии с полной суммой, указанной в счете, то есть без учета субсидий. Затем он предъявляет квитанцию об оплате в банк, который выдает ему наличные деньги в соответствии с размером субсидии, начисленной отдельно в службе социальной защиты населения.

Сравнительный анализ двух способов адресного субсидирования представлен в следующей таблице:

Таблица 1. Сравнительный анализ возможностей банка и гражданина при разных схемах адресного субсидирования.
	Дотации поставщикам	Компенсации гражданину
Гражданин	не имеет права распоряжаться денежными средствами	имеет право снимать и переводить денежные средства
Банк	перечисляет дотации поставщикам по указанию информационно-расчетного центра или соцзащиты	выдает денежные средства гражданину по предъявлении квитанции; может сочетать обслуживание персонифицированных счетов с другими формами обслуживания.

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

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

Полный цикл обслуживания показан на следующем рисунке:

Он включает:

обслуживание специализированного бюджетного счета;
обслуживание персонифицированных счетов граждан-получателей субсидий;
обслуживание транзитного счета информационно-расчетного центра;^[5]
обслуживание расчетных счетов предприятий жилищно-коммунального комплекса и поставщиков услуг;
дополнительные услуги для участников расчетов.

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

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

Таблица 2. Адресные субсидии в регионах.
Адресные субсидии идут прямо поставщикам ЖКУ	Адресные субсидии поступают в распоряжение граждан
Республика Саха Санкт-Петербург	Тюменская область Чувашия Нижегородская область Ростовская область Белгородская область Татарстан

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

Какие конкретные цели ставит Госстрой РФ перед участниками эксперимента? Ответ на этот вопрос также представляет большой интерес для банковских учреждений. В эксперименте поставлено пять основных задач ^[6], из которых стоит обратить особое внимание на три последние задачи, непосредственно связанные с работой банков:

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

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

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

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

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

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

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

[svg]

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

Поэтому важнейшими задачами для банковских специалистов, экспертов-технологов и автоматизаторов станут, с одной стороны, создание единой городской (или региональной) информационной системы на базе современного программно-технологического комплекса ^[7] и, с другой стороны, расширение функциональных возможностей автоматизированных банковских систем.

↑ «Расчеты и операционная работа в коммерческом банке», №11, ноябрь 2003, стр. 47-52. Методический журнал, издательство БДЦ-Пресс.
↑ См., например, статью автора «Коммунальная страна» в еженедельнике «Эксперт» (приложение «Цифровой мир»), № 31 (384) от 25 августа 2003 г.
↑ Данные Национального фонда содействия жилищной реформе
↑ Башмаков И. РЕФОРМА ЖКХ: Рост тарифов имеет пределы. «Ведомости», 28 августа 2003 г.
↑ В разных городах можно встретить расчетный центр, информационно-расчетный центр, расчетно-кассовый кассовый центр и т.д. Особенно активно расчетные центры стали создаваться после постановления правительства России от 17 ноября 2001 г. N 797, утвердившего подпрограмму «Реформирование и модернизация жилищно-коммунального комплекса Российской Федерации» в составе федеральной целевой программы «Жилище».
↑ Из неопубликованного доклада Сиваева С.Б. (фонд «Институт экономики города») на семинаре Госстроя 28 марта 2003 г.
↑ В настоящее время число современных городских расчетных систем промышленного уровня весьма ограничено. Автор статьи работает в компании, занятой разработкой одной из таких систем — ПТК «Радей» (программно-технологический комплекс «Радей»). К числу наиболее распространенных систем на сегодня относятся система «Город» компании ЦФТ (Новосибирск), система «Инари» (Санкт-Петербург), система АЦК-ЖКХ компании Бюджетные Финансовые Технологии и системы местных разработчиков, большинство из которых реализовано с низким уровнем качества или с использованием устаревших технологий, но существенно дешевле промышленных систем.

Импорт документов из OpenOffice (MediaWiki)

2008-09-04T15:10:48Z

VitaliyFilippov: Массовая правка: замена PCRE \n+\[\[Категория:Справка\]\] на <noinclude>Category:Справка</noinclude>

Неплохо зарекомендовала себя технология http://www.activasoft.com/OpenOffice2MediaWiki

Но проще использовать работающий под Mozilla Firefox Javascript-редактор WikEd, который умеет конвертировать HTML-разметку, вставленную из Clipboard в MediaWiki-разметку.

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Импорт документов из OpenOffice (MediaWiki)»

Version Control and “the 80%”

2008-09-03T16:31:03Z

VitaliyFilippov:

Перевод статьи Version Control and “the 80%” (Контроль версий и «правило 80 процентов») выполнен сообществом компании «Заказные ИнформСистемы».

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

Version Control and the... Long Gradated Scale

2008-09-03T16:30:39Z

BenderBot: 1 версия

Перевод статьи Version Control and the... Long Gradated Scale («Контроль версий и далекие перспективы») выполнен сообществом компании «Заказные ИнформСистемы».

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

Многие со мной согласились, но огромное число людей обиделись на мои смелые обобщения. Я вижу бесконечные комментарии на мой пост (хотя среди них есть и поддерживающие меня — см. пост Джеффа Этвуда), где люди или пытаются решить — входят ли они в «80%» или в «20%», или несут пафосный бред, что все программисты попадают о обе категории одновременно.

Начну с извинений. Оно конечно приятно, читать эту статью и думать, что смысл в том, что «80% программеров — это тупые ведущиеся лохи, а другие 20% — клевые, толковые парни, прямо как я». Очевидно, я в это не верю. :-).

Несмотря на то, что в начале статьи я специально предупреждал, что для наглядности я буду использовать «упрощенные стереотипы», это не сработало и я многих обидел.

Конечно, мир не черно-бел и все программисты уникальны. Нет каких-либо отдельных интересов, которые бы явно свидетельствовали о вашей «20%»-ности. С другой стороны нельзя зайти в какую-нибудь контору и указать на команду программеров — «эти парни явно тупое 80%-е стадо». Нельзя так четко делить, нельзя.

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

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

Иными словами, имеет ли кандидат прирожденную страсть к программированию как к искусству? Именно это ведет к

участию в open-source,
написанию LISP-компиляторов,
[вставить здесь что-нибудь чумовое].

На этом я и основывал свои сверхсхематичные «80/20» метафоры в той статье, и, надеюсь, последнее определение будет менее скандально.

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

Основная мысль, которую я пытался донести, заключалась в том, что распределенные системы контроля версий (DVCS) пока не достигли такого уровня дружественности, да и Subversion только-только начинает достигать этого уровня (спасибо клиентам типа TortoiseSVN).

Я подписан на Google Alert в моей области в софтверном мире, т.е. каждый раз, когда Google находит новую веб-страницу, ссылающуюся на Subversion или на контроль версий, я об этом узнаю. Вы будете просто поражены числу новых постов в блогах, которые я вижу каждый день, по-существу говорящих «Эй, может наша команда должна начать использовать контроль версий! Subversion кажется достаточно удобной, вы с ней уже работали?»

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

Некоторые обратили внимание на то, что, в то время, когда я взываю к евангелистам DVCS не отбрасывать бездумно такие централизованые системы, как Subversion, сам я занят бездумным игнорированием DVCS (в той статье я жаловался, что большинство DVCS систем не работают под Windows, не имеют простого контроля доступа и не имеют приятных GUI клиентов). Нет, я действительно сталкивался с Mercurial в разных проектах, просто мои утверждения основывались на несколько устаревшей информации. Обратившись к википедии, я уверился в том, что был неправ. :-)

Репликация: База Знаний «Заказных Информ Систем» → «Version Control and the... Long Gradated Scale»

The Risks of Distributed Version Control

2008-09-03T16:29:58Z

BenderBot: 1 версия

Перевод статьи The Risks of Distributed Version Control выполнен сообществом компании «Заказные ИнформСистемы».

Да, забавно, как времена меняются. Когда мы начинали разрабатывать Subversion пять лет назад, CVS был огромным злобным монстром, которого мы хотели «низвергнуть».

Сегодня, хотя Subversion есть ещё куда развиваться, он уже достиг критической массы в мире свободного ПО. Список рассылки «users@» насчитывает тысячи подписчиков и стал самоподдерживаемым. Каждая достаточно крупная свободная операционная система поставляется с относительно новой версией Subversion. В книжных магазинах есть небедный выбор книг о Subversion. Десятки крупных проектов, таких как KDE, Apache и GCC перешли на него. Вы уже не удивляетесь, когда вы встречаете проект с открытым исходным кодом, использующий Subversion, ведь SVN стала стандартным выбором «по умолчанию» для большинства новых проектов.

А сейчас, приколитесь, появилось целое новое поколение систем контроля версий на горизонте:

И эти новички — распределённые системы контроля версий (DVCS, Distributed Version Control Systems) — хотят «подсидеть стариков». Да, вы не ослышались: Subversion сейчас «Старик». Интересно, когда это произошло? :-)

Это новое поколение систем в корне отличается тем, что доводит идею «изолированных операций» до крайности. У каждого пользователя на локальном компьютере хранится полная копия репозитория, т.е. 100% истории проекта. Каждый человек фактически сам по себе. Пользователи соединяют свои репозитории между собой как только им угодно и меняются изменениями как коллекциями марок, а система автоматически отслеживает, какие «чужие» изменения у вас отражены, а какие — нет.

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

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

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

И именно это поведение весьма вредно для open-source сообществ, где все должны:

работать совместно;
согласовывать общие цели;
обсуждать архитектуру и непрерывно просматривать работу друг друга.

В нашем Subversion-сообществе такое поведение мы именуем «сбрасывание бомбы», и считаем антиобщественным и даже аморальным. Ведь обычно, получаемая таким образом новая функциональность настолько велика и сложна, что её почти невозможно рецензировать.

А если её сложно рецензировать, то её сложно внедрить в основной ствол проекта, сложно поддерживать как качество кода, так и саму эту функциональность для всех, кроме, возможно, самого автора. И в таких случаях мы, за редким исключением, ругаем автора за «затворничество».

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

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

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

Т.е. основная цель — не быть застигнутым врасплох большим изменением в коде. Это помогает сообществу концентрироваться на общих целях, при этом держит его в курсе достижений каждого. И хотя многие говорят: «Классно, что я могу разветвить целый проект без ведома остальных!», на это я постоянно твержу: «Ну ёлки-палки, ну почему вы не работаете вместе с остальными? Почему вы не просите о доступе для фиксации изменений?». Это типичная проблема, которую нужно решать не техническими, а социальными методами: проектам следует активно поощрять стороннюю работу небольших команд и без промедления давать возможность заводить частные ветки.

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

Subversion’s Future?

2008-09-03T16:29:24Z

WikiSysop: 1 версия

Перевод статьи Subversion’s Future? («Что ждет Subversion?») выполнен сообществом компании «Заказные ИнформСистемы».

Согласно статистике Google Analytics, один из самых просматриваемых постов в моем блоге — это тот, который я написал годы назад — «Риски распределенного управления версиями». Там полно сердитых комментариев о том, насколько я неправ. Думаю, надо дополнить тот пост новостями и свежими идеями.

Итак, должен сказать, после некоторого времени использования Mercurial, я думаю, что распределенное управление версиями — штука весьма изящная.

Пока идет тестирование последней предрелизной 1.5 версии Subversion, в которой уже будут ограниченные возможности отслеживания слияний, в коллективе разработчиков Subversion присутствует некая неясность, каким же все-таки будет его будущее. Системы Mercurial и Git сейчас повсюду, и постоянно становятся все более популярными, особенно среди «20%» — разработчиков-новаторов. Какая роль у Subversion — «лучшей из лучших» централизованных систем контроля версий — в мире, где все потихоньку двигается в сторону использования децентрализованных систем?

Subversion четко выполнила задачу, которую мы поставили в 2000-м — «заменить CVS. Но останавливаться нельзя — если у Subversion не будет четких планов на будущее, то она будет заменена чем-то лучшим. Это могут быть Mercurial или Git, а может — чем-то еще. В идеале Subversion должна заменить себя сама. :-)

Итак, что бы мы заложили в «Subversion 2.0», если бы нам выпала честь его проектировать? На прошлой неделе один из наших разработчиков написал изящный e-mail, где очень хорошо обобщил возможную новую миссию. Это нужно видеть — вот неплохая аннотация:

Сейчас я бы почти наверняка не выбрал Subversion для небольшого нового open-source проекта. [...] Значит ли это, что Subversion мертва? Что нам пора сменить корабль, написать новый GUI для Git и добиться чтобы все это работало под Windows? Нет. Централизованный контроль версий все еще хорош для некоторых вещей.

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

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

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

Она будет продолжать использоваться в течение многих лет, причем в корпоративном мире — с громандной популярностью, пока не проиграет (окончательно) распределенным системам в мире open-source.

У всех нас, погруженных в «open-source», действительно несколько искаженное представление о реальности. Нам кажется, что «все переключаются на Git» но когда вы смотрите на график публичных (т.е. общедоступных, не частных) серверов Subversion под Apache, обнаруженных в Инете, видно, что Subversion никоим образом не «исчезает».

Как раз наоборот: его применение в корпоративном мире все еще растет квадратично, без малейших признаков замедления. Все это происходит независимо от новаторов-опенсорсщиков, теряющих интерес к Subversion.

Subversion может, в конце концов, стать полноценно «корпоративным» open-source проектом, (то есть, вся разработка будет финансироваться корпорациями-пользователями Subversion), но это прекрасный выход для зрелого программного обеспечения.

Репликация: База Знаний «Заказных Информ Систем» → «Subversion’s Future?»

Современный процесс разработки ПО (курс)

2008-07-23T12:07:31Z

StasFomin: +Лекция-презентация про системы контроля версий, и в частности, «Subversion».

Новости/Сопровождение ПТК Радей-Соцзащита в Саратовской области поручено авторизованному партнеру Заказных

2008-07-03T10:29:31Z

VitaliyFilippov: 1 версия

В Министерстве строительства и ЖКХ Саратовской области подписан договор на сопровождение автоматизированной системы расчета и выплаты субсидий ПТК «Радей-Соцзащита» на 2008 г. Программно-технологический комплекс (ПТК) «Радей-Соцзащита» будет сопровождать авторизованный партнер компании-разработчика Заказные ИнформСистемы — ООО «ЗИС-Саратов».

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

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

В настоящее время в Саратовской области функционирует актуальная единая база данных получателей субсидий на оплату жилья и коммунальных услуг, охватывающая территорию 37 районов области. Расчет и выплата персонифицированных субсидий по Постановлению Правительства РФ от 14 декабря 2005 г. № 776 ведутся с учетом особенностей региональных нормативов. В расчете субсидий ПТК «Радей-Соцзащита» предусмотрена возможность учета как натуральных, так и монетизированных льгот по оплате за жилищно-коммунальные услуги. Готовая база данных получателей социальной поддержки и хорошо зарекомендовавший себя механизм выплаты субсидий могут быть также использованы для выплаты льгот любых видов: монетизированных льгот на оплату ЖКУ, детских пособий, единовременных выплат на рождение ребенка, других персонифицированных или целевых выплат. Особенно важен отработанный механизм контроля прохождения выплаты с момента ее назначения до получения гражданином через банк или почтовое отделение.

Контактное лицо: Цатурян Галина Кимовна, заместитель директора по маркетингу компании Заказные ИнформСистемы

Тел.: (495)772-97-02 e-mail: radey@custis.ru

Диаграммы:ИНТУИТ

2008-07-02T14:28:15Z

StasFomin: Новая: <graph> digraph G{ rankdir=LR; "Замечание об ошибке"->"Спасибо за комментарий. Ошибка исправлена" "Замечание об ошиб...

[svg]

A

2008-06-26T13:02:25Z

StasFomin: Содержимое страницы заменено на «{{tip}}»

Новости/Заказные ИнформСистемы на ММЛФ-2008

2008-02-21T17:15:21Z

VitaliyFilippov: 1 версия

13-14 февраля 2008 компания Заказные ИнформСистемы приняла участие в работе конференции и профессиональных сессий X Московского Международного Логистического Форума (ММЛФ-2008), который проходил в Москве в Гостинице «Ренессанс» (Олимпийский проспект, д. 18/1).

13 февраля в рамках 5-й Международной Конференции «Логистика и управление цепями поставок: новые вызовы и ответы» наша компания выступила спонсором секции «РЕШЕНИЯ В ОБЛАСТИ ЛОГИСТИКИ И УПРАВЛЕНИЯ ЦЕПЯМИ ПОСТАВОК».

На конференции с докладом «УПРАВЛЕНИЕ ТОВАРНЫМ ЗАПАСОМ В КРУПНОЙ ТОРГОВОЙ СЕТИ. Механизм логического сегментирования как ключевой инструмент управления товарным запасом в крупной торговой сети» выступила ведущий эксперт направления «Торговые сети» Наталья Кулакова.

Презентация выступления Натальи Кулаковой.

Новости/Семинар для клиентов ПТК Радей

2007-12-12T15:25:58Z

VitaliyFilippov: 1 версия

Учебный центр «Радей», недавно созданный в компании Заказные ИнформСистемы, 5 декабря провел первый семинар для своих клиентов из сферы ЖКХ. Тема семинара — «Радей»: новые возможности». В семинаре приняли участие специалисты единых расчетных центров (ЕРЦ) городов Саратов, Астрахань, Жуковский (Московская область), Курчатов (Курская область).

В ходе семинара специалисты направления «Радей» (биллинговые системы для ЖКХ) совместно с юридическим отделом компании представили доклады по наиболее актуальным проблемам деятельности единых расчетных центров и методам их решения в системе «Радей»:

Юридические вопросы, связанные с ведением баз данных физических лиц
Расчет платы за ЖКУ в соответствии с Постановлением Правительства РФ №307 от 23.05.2006 — эта тема фигурировала как в выступлении начальника абонентской службы ЕРКЦ г. Саратова Максима Сергеевича Зараева, так и в докладе ведущего аналитика компании Татьяны Лисиной о соответствующих возможностях в ПТК «Радей»
Реализация полнофункционального решения «Паспортный стол» в ПТК «Радей»
Проблемы подневного расчета при наличии приборов учета
Обзор возможностей новой версии ПТК «Радей» 2.3
Новое в расчете льгот в ПТК «Радей»

На семинаре был организован конкурс докладов. Лучшим был признан доклад ведущего аналитика Татьяны Лисиной «Как перейти в ПТК «Радей» к расчету за коммунальные услуги по Постановлению Правительства РФ №307 от 23.05.2006 г?». Также были отмечены выступления аналитика направления «Радей» Никиты Квитко и руководителя отдела внедрения Андрея Рябова.

На семинаре царила атмосфера делового и конструктивного общения. Участники обменялись мнениями и опытом решения проблем ЕИРЦ в разных регионах. Все представители клиентов оценили новую форму взаимодействия разработчиков и пользователей ПТК «Радей» как очень полезную для текущей работы и перспективную для дальнейшего сотрудничества.

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

Разработчик СУБД (курс)

2007-11-23T12:26:50Z

StasFomin: /* Организационные вопросы */

Курс «Разработчик СУБД» — экспресс-курс подготовки разработчиков (программистов) реляционных СУБД.

cпециализация: Oracle PL/SQL.
преподаватели: Стас Фомин (stas@custis.ru), Максим Цепков (maks@custis.ru)

(На самый худой конец — звоните 89166190438, Стас Фомин)

Учебные задачи по PL/SQL

2007-11-23T12:18:29Z

MaksTsepkov:

Интеграция Open Source-систем для управления разработкой ПО

2007-11-03T21:23:21Z

Alexdebre: /* Дополнения */

Стас Фомин: Заместитель директора по информационным технологиям / stas@custis.ru

«Интеграция Open Source-систем для управления разработкой ПО»^[1]

↑ Статья написана в 2007, к конференции SECR-2007, опубликована с сокращениями в «Открытые системы», февраль 2008

CruiseControl.NET

2007-10-26T11:15:45Z

WikiSysop: 1 версия

CruiseControl

2007-10-25T08:40:13Z

WikiSysop: 1 версия

Новости/Заказные ИнформСистемы на выставке Склад. Транспорт. Логистика—2007

2007-10-18T16:25:17Z

VitaliyFilippov: 1 версия

UserRights.html (TestLink-RU)

2007-08-28T11:26:53Z

StasFomin: начал первую версию.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
  <head>
    <meta name="generator" content=
    "HTML Tidy for Windows (vers 14 February 2006), see www.w3.org" />
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <meta http-equiv="Content-language" content="en" />
    <meta name="author" content="Martin Havlat" />
    <meta name="copyright" content="GNU" />
    <meta name="robots" content="NOFOLLOW" />
    <title>
      TestLink Help: User Rights
    </title>
    <link rel="stylesheet" type="text/css" href=
    "../../{$smarty.const.TL_THEME_CSS_DIR}tl_docs.css" />
  </head>
  <body>
    <h1>
      Права доступа
    </h1>
    <div id="menu">
      <a href="javascript:%20window.close();" class="tlButton">Закрыть</a>
      <a href="javascript:%20history.back();" class="tlButton">Назад</a>
      <a href="content.html" class="tlButton">Оглавление</a>
    </div>
    <h2>
      Обзор
    </h2>
    <p>
      В зависимости от назначенных прав доступа пользователи TestLink имеют
      различные возможности по просмотру и редактированию данных. Присвоить эти
      права может только администратор.<br />
      Каждому зарегистрированному пользователю по умолчанию даются права
      "Гостя", которые позволяют только просматривать описание тестов и
      результаты их прогона.
    </p>
    <h2>
      Описание
    </h2>
    <h3>
      Гость (guest)
    </h3>
    <p>
      Права гостя позволяют просматривать описания тестов, ключевых слов,
      результатов прогона, а также редактировать информацию о себе.
    </p>
    <h3>
      Тестер (tester)
    </h3>
    <p>
      Права тестера позволяют просматривать описания тестов, ключевых слов,
      результатов прогона, а также проводить прогон тестов, т.е. вносить и
      редактировать информацию о выполнении тестов в назначенном ему плане.
    </p>
    <h3>
      Разработчик тестов (test designer)
    </h3>
    <p>
      Права разработчика тестов позволяют редактировать описания тестов,
      ключевых слов и требований.
    </p>
    <h3>
      Старший тестер (senior tester)
    </h3>
    <p>
      Права старшего тестера позволяют редактировать описания тестов, ключевых
      слов, требований, а также проводить прогон тестов в назначенном ему
      плане. Кроме того, он может создавать версии (сборки).
    </p>
    <h3>
      Руководитель (leader)
    </h3>
    <p>
      Права руководителя позволяют редактировать описания тестов, ключевых
      слов, требований, проводить прогон тестов в назначенном ему плане. Кроме
      того, он может радактировать заданные версии (сборки) продукта и планы
      тестирования (включая приоритеты, этапы и взаимосвязи).
    </p>
    <h3>
      Администратор (admin)
    </h3>
    <p>
      Имеет все права, в том числе создавать и удалять продукты, а также
      создавать, изменять права доступа и удалять пользователей.
    </p>
  </body>
</html>

Testproject.html (TestLink-RU)

2007-08-28T11:26:49Z

StasFomin: начал первую версию

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
  <head>
    <meta name="generator" content=
    "HTML Tidy for Windows (vers 14 February 2006), see www.w3.org" />
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <meta http-equiv="Content-language" content="en" />
    <meta name="author" content="Martin Havlat" />
    <meta name="copyright" content="GNU" />
    <meta name="robots" content="NOFOLLOW" />
    <title>
      Справка TestLink: Проект
    </title>
    <link rel="stylesheet" type="text/css" href=
    "../../{$smarty.const.TL_THEME_CSS_DIR}tl_docs.css" />
  </head>
  <body>
    <h1>
      Проект
    </h1>
    <div id="menu">
      <a href="javascript:%20window.close();" class="tlButton">Close</a>
      <a href="javascript:%20history.back();" class="tlButton">Back</a>
      <a href="content.html" class="tlButton">Content</a>
    </div>
    <h3>
      Введение
    </h3>
    <p>
      Проект — это ключевая сущность TestLink'а. Проекты — это те продукты и
      решения, которые выпускает ваша компания. Проекты включают
      документированные требования, спецификации тестов, планы тестирования и
      ключевые слова.
    </p>
    <p>
      В каждый момент, TestLink работает в контексте какого-либо проекта
      (текущего проекта). Текущий проект выбирается из выпадающего списка в
      верхнем правом углу.
    </p>
    <h3>
      Описание тестов
    </h3>
    <p>
      В этом разделе пользователи создают тесты и группы тестов, там же
      возможен и поиск тестов. Пользователи с соответствующими правами могут
      также менять порядок, тестов и групп тестов, а также импортировать
      CSV-файлы.
    </p>
    <h3>
      Ключевые слова
    </h3>
    <p>
      Ключевые слова дают пользователям дополнительное «измерение с иерархией»
      при классификации тестов. С помощью ключевых слов удобно организовывать
      специфические коллекции тестов, например можно определить наборы:
    </p>
    <ul>
      <li>Регрессионных тестов;
      </li>
      <li>Тестов контроля стерильности;
      </li>
      <li>Тестов, определенных для конкретной платформы и т. п.
      </li>
    </ul>
    <p>
      Ключевые слова могут быть созданы пользователями с правами
      «mgt_modify_key», которыми по умолчанию владеют только имеющие роль
      «Leaders». Как только ключевое слово или группировка ключевых слов
      создана, их можно привязывать к тестам.
    </p>
    <p>
      Ключевые слова можно массово привязывать к тестам через страницу привязки
      ключевых слов (ссылка «Привязать ключевые слова» с главной страницы) или
      индивидуально для каждого теста при управлении тестами.
    </p>
    <p>
      Пользователи имеют возможность фильтрации (отбора) по ключевым словам:
    </p>
    <ul>
      <li>При поиске тестов в спецификации тестов.
      </li>
      <li>При группировке тестов в группы тестов и в планы тестирования.
      </li>
      <li>На странице выполнения тестов.
      </li>
    </ul>
    <h3>
      Управление проектами
    </h3>
    <p>
      Для создания нового проекта требуются уровень прав «admin». Каждый проект
      должен иметь уникальное имя. Также, если соответствующая функциональность
      включена в конфигурационном файле, каждому проекту можно присвоить свой
      собственный цвет фона, чтобы надежно визуально отличать их друг от друга.
      Например, с помощью такой цветовой градации можно отличать важные проекты
      от некритичных.
    </p>
    <p>
      Несколько замечаний:
    </p>
    <ul>
      <li>Удаление проекта из системы не рекомендуется, т. к. это приведет либо
      к большому числу «тестов-сирот», либо к удалению тестов из системы.
      </li>
      <li>Каждый план тестирования, является совокупностью тестов и
      представляет тестирование в проекте в разные моменты времени.
      </li>
      <li>TestLink поддерживает импорт CSV-данных в проект (будет рассмотрено
      далее, в разделе про импорт данных).
      </li>
    </ul>
    <p>
      Для редактирования и удаления проекта требуются уровень прав «admin».
      Можно изменить имя проекта, цвет фона (если такая функциональность
      включена) и доступность функциональности требований. Если проект устарел,
      его можно <i>деактивировать —</i> при этом он для всех кроме
      администратора, пропадет из верхнего навигационного списка выбора
      (администратор будет видеть такие проекты помеченными астериском '*').
    </p>
    <p>
      Можно также удалить проект, с удалением всех связанных данных из БД. Но
      это действие необратимо и мы настоятельно рекомендуем использовать
      деактивацию вместо удаления.
    </p>
  </body>
</html>