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

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

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>

TestSetRemove.html (TestLink-RU)

2007-08-28T11:26:45Z

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

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.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 http-equiv="expires" content="-1" />
    <meta http-equiv="pragma" content="no-cache" />
    <meta name="author" content="Martin Havlat" />
    <meta name="copyright" content="GNU" />
    <meta name="robots" content="NOFOLLOW" />
    <title>
      TestLink Instructions
    </title>
    <style media="all" type="text/css">
/*<![CDATA[*/
    @import "../../css/testlink.css";
    @import "../../{$smarty.const.TL_THEME_CSS_DIR}testlink.css";
    /*]]>*/
    </style>
    <script type="text/javascript" src="../../javascript/testlink_library.js">
</script>
  </head>
  <body>
    <div class="workBack">
      <h1>
        Удаление теста из плана тестирования
      </h1>
      <h2>
        Назначение:
      </h2>
      <p>
        На этой странице пользователь может сделать тесты неактивными.
        Неактивные тесты не будут показаны на странице прогона тестов.
      </p>
      <p>
        <i>Примечание: Результаты более раннего прогона уже неактивного теста
        будут присутствовать в отчетах.</i>
      </p>
      <h2>
        Что делать:
      </h2>
      <ol>
        <li>Выберите категорию для просмотра всех входящих в нее тестов.
        </li>
        <li>Установите флажки для тестов, которые будут удалены из плана.
        </li>
        <li>Нажмите кнопку "Удалить...".
        </li>
      </ol>
      <h1 align="right">
        см. также: <span class="help" onclick=
        "javascript:open_popup('./content.html');">Справка TestLink</span>
      </h1>
    </div>
  </body>
</html>

TestSetAdd.html (TestLink-RU)

2007-08-28T11:26:42Z

StasFomin: внес свои правки и адаптацию к 1.7.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" 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="ru" />
    <meta http-equiv="expires" content="-1" />
    <meta http-equiv="pragma" content="no-cache" />
    <meta name="author" content="Martin Havlat" />
    <meta name="copyright" content="GNU" />
    <meta name="robots" content="NOFOLLOW" />
    <title>
      Справка TestLink: Добавить тестовый пример в тест-план
    </title>
    <style media="all" type="text/css">
/*<![CDATA[*/
    @import "../../{$smarty.const.TL_THEME_CSS_DIR}testlink.css";
    /*]]>*/
    </style>
  </head>
  <body>
    <div class="workBack">
      <h1>
        Добавить тест (тестовый пример) в план-тестирования
      </h1>
      <h2>
        Назначение:
      </h2>
      <p>
        Этот раздел предназначен для того, чтобы пользователь с правами не ниже
        руководителя (leader) мог добавлять тесты в план тестирования.
      </p>
      <h2>
        Что делать:
      </h2>
      <ol>
        <li>Позиционируйтесь по иерархии групп тестов и отметьте флажками те тесты, которые вы хотите добавить в текущий план тестирования.
        </li>
        <li>Нажатие кнопки "Добавить выбранные тесты" перенесет тесты в текущий
        план, при этом Testlink проверяет, чтобы каждый тест не мог быть
        добавлен многократно.
        </li>
        <li>Вы можете также отобрать тесты по ключевому слову.
        </li>
      </ol>
      <h1 align="right">
        см. также: <span class="help" onclick=
        "javascript:open_popup('./content.html');">Справка TestLink</span>
      </h1>
    </div>
  </body>
</html>

TestPlan.html (TestLink-RU)

2007-08-28T11:26:39Z

StasFomin: внес свои правки и адаптацию к 1.7.

<!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">Закрыть</a>
      <a href="javascript:%20history.back();" class="tlButton">Назад</a>
      <a href="content.html" class="tlButton">Оглавление</a>
    </div>
    <h2>
      Обзор
    </h2>
    <p>
      Если пользователь не видит ни одного плана тестирования в выпадающем
      меню, и все ссылки, касающиеся тест-плана для него недоступны, то он
      должен обратиться к пользователю с правами руководителя (leader) или
      администратора для включения его в число лиц, ответственных за выполнение
      того или иного плана. Кроме того, он может самостоятельно создать для
      себя тест-план.
    </p>
    <h2>
      Прогон тестов
    </h2>
    <p>
      В этом разделе пользователи могут выполнять прогон тестов, т.е.
      записывать результаты тестирования и выводить на печать тесты из плана.
      Здесь же пользователь может отслеживать ход выполнения плана.
    </p>
    <h2>
      Управление планом тестирования
    </h2>
    <p>
      Раздел, в котором дается возможность управлять параметрами плана
      тестирования, доступен только пользователям с правами руководителя
      (leader). Администрирование плана включает создание, редактирование,
      удаление плана; добавление, редактирование, удаление и обновление тестов
      в плане, а также создание версий (сборок), на которых план выполняется.
      Кроме того, имеется возможность назначения лиц, ответственных за
      выпонение того или иного плана.<br />
      Пользователь с правами руководителя (leader) также может устанавливать
      важность, риск, приоритет и принадлежность набора тестов (по категориям),
      а так же задавать этапы выполнения плана тестирования.
    </p>
  </body>
</html>

Tc exec assignment.html (TestLink-RU)

2007-08-28T11:26:35Z

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" xml:lang="en" 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 http-equiv="expires" content="-1" />
    <meta http-equiv="pragma" content="no-cache" />
    <meta name="author" content="Martin Havlat" />
    <meta name="copyright" content="GNU" />
    <meta name="robots" content="NOFOLLOW" />
    <title>
      Справка TestLink: Назначение тестов тестировщикам
    </title>
    <style media="all" type="text/css">
/*<![CDATA[*/
    @import "../../{$smarty.const.TL_THEME_CSS_DIR}testlink.css";
    /*]]>*/
    </style>
  </head>
  <body>
    <div class="workBack">
      <h1>
        Назначение тестов тестировщикам
      </h1>
      <p>
        Эта функциональность позволяет установить ответственного за выполнение каждого теста.
      </p>
    </div>
  </body>
</html>

TcSearch.html (TestLink-RU)

2007-08-28T11:26:28Z

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

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.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 Instructions
    </title>
    <style media="all" type="text/css">
/*<![CDATA[*/
    @import "../../{$smarty.const.TL_THEME_CSS_DIR}testlink.css";
    /*]]>*/
    </style>
    <script type="text/javascript" src="../../javascript/testlink_library.js">
</script>
  </head>
  <body>
    <div class="workBack">
      <h1>
        Страница поиска тестов
      </h1>
      <h2>
        Назначение:
      </h2>
      <p>
        Для поиска используются ключевые слова и строки поиска по всем полям
        описания тестового примера. Поиск не чувствителен к регистру. Результат
        поиска включает тесты только активного продукта.
      </p>
      <h2>
        Что делать:
      </h2>
      <ol>
        <li>Впишите строку поиска в нужное поле. Неиспользованные поля оставьте
        пустыми.
        </li>
        <li>Выберите требуемое ключевое слово, или оставьте значение "не
        применимо".
        </li>
        <li>Нажмите кнопку "Искать".
        </li>
        <li>Все тесты, соответствующие строкам поиска, показаны. Вы можете
        модифицировать выбранные тесты, используя кнопку "Редактировать",
        расположенную под строкой заголовка теста.
        </li>
      </ol>
      <h1 align="right">
        см. также: <span class="help" onclick=
        "javascript:open_popup('./content.html');">Справка TestLink</span>
      </h1>
    </div>
  </body>
</html>

TcPrint.html (TestLink-RU)

2007-08-28T11:26:24Z

StasFomin: внес свои правки и адаптацию к 1.7.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.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>
    <style media="all" type="text/css">
/*<![CDATA[*/
        @import "../../{$smarty.const.TL_THEME_CSS_DIR}testlink.css";
    /*]]>*/
    </style>
    <script type="text/javascript" src="../../javascript/testlink_library.js">
</script>
  </head>
  <body>
    <div class="workBack">
      <h1>
        Вывод тестов на печать
      </h1>
      <h2>
        Назначение:
      </h2>
      <p>
        В этом разделе пользователь может отобрать и вывести на печать тесты,
        входящие в выбранную группу тестов, или распечатать набор тестов,
        входящих в проект.
      </p>
      <h2>
        Что делать:
      </h2>
      <ol>
        <li>
          <p>
            Щелкните мышью на пиктограме "+" группы тестов или проекта, группа
            будет развернута и будет показано количество входящих в них тестов.
          </p>
        </li>
        <li>
          <p>
            В таблице "Опции печати" навигационной панели определите состав и
            формат выводимых данных. Для подробной информации см. <span class=
            "help" onclick=
            "javascript:open_popup('./printFilter.html');">справку</span>.
          </p>
        </li>
        <li>
          <p>
            Нажмите на строку группы тестов для вывода содержащихся в них
            тестов.<br />
          </p>
        </li>
      </ol>
      <h1 align="right">
        см. также: <span class="help" onclick=
        "javascript:open_popup('./content.html');">Справка TestLink</span>
      </h1>
    </div>
  </body>
</html>

TcEdit.html (TestLink-RU)

2007-08-28T11:26:21Z

StasFomin: внес свои правки и адаптацию к 1.7.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.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>
    <style media="all" type="text/css">
/*<![CDATA[*/
    @import "../../{$smarty.const.TL_THEME_CSS_DIR}testlink.css";
    /*]]>*/
    </style>
    <script type="text/javascript" src="../../javascript/testlink_library.js">
</script>
  </head>
  <body>
    <div class="workBack">
      <h1>
        Редактирование тестов
      </h1>
      <h2>
        Назначение:
      </h2>
      <p>
        Раздел <span class="help" onclick=
        "javascript:open_popup('./glosary.html#testspec');">"Описание
        тестов"</span> – это место, где пользователь может просмотреть и
        отредактировать <span class="help" onclick=
        "javascript:open_popup('./glosary.html#testcase');">тесты</span> и
        группы тестов тестов, относящиеся к заданному тестовому <span class=
        "help" onclick=
        "javascript:open_popup('./glosary.html#product');">проекту</span>.
        Пользователь может просмотреть различные версии теста.
      </p>
      <h2>
        Что делать:
      </h2>
      <ol>
        <li>Выберите название тестового проекта из выпадающего меню,
        расположенного в правом верхнем углу экрана.
        </li>
        <li>Создайте новый тест или группу тестов для этого проекта. (Вы можете
        сменить тестовый проект в правом верхнем углу).
        </li>
        <li>Используя древовидную структуру панели навигации слева,
        отредактируйте описания тестовых примеров.
        </li>
        <li>4. Когда тест будет готов, включите его в <span class="help"
        onclick="javascript:open_popup('./glosary.html#testplan');">План
        тестирования</span>.
        </li>
      </ol>
      <p>
        Все тестовые примеры в TestLink’е распределяются по N уровням тестовых
        наборов. Вы можете описать содержание тестовых наборов. Эта информация
        может быть распечатана вместе с описанием самих тестов.
      </p>
      <h1 align="right">
        см. также: <span class="help" onclick=
        "javascript:open_popup('./content.html');">Справка TestLink</span>
      </h1>
    </div>
  </body>
</html>

ShowMetrics.html (TestLink-RU)

2007-08-28T11:26:17Z

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

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.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 Instructions
    </title>
    <style media="all" type="text/css">
/*<![CDATA[*/
    @import "../../{$smarty.const.TL_THEME_CSS_DIR}testlink.css";
    /*]]>*/
    </style>
  </head>
  <body>
    <div class="workBack">
      <h1>
        Отчеты о результатах тестирования
      </h1>
      <h2>
        Показатели выполнения тест-плана
      </h2>
      <p>
        В данном отчете показаны результаты тестирования текущей версии
        (сборки) продукта.
      </p>
      <h2>
        Показатели выполнения тест-плана по всем версиям
      </h2>
      <p>
        В данном отчете показан итоговый результат прогона тестов по всем
        версиям продукта.<br />
        Это означает, что если тест пройден в версии 1 и затем провален в
        версии 2, то в даном отчете этот тест будет считаться проваленным.
      </p>
      <h2>
        Суммарный результат прогона по версиям
      </h2>
      <p>
        В данном отчете показан суммарный результат прогона тестов по каждой
        версии продукта.
      </p>
      <h2>
        Запрос по параметрам
      </h2>
      <p>
        Данный отчет формируется на основе выбора пользователем следующих
        параметров испытаний: версия продукта, владелец теста, ключевые слова,
        статус результата последнего прогона теста.
      </p>
      <h2>
        Отчет о прогоне тестов
      </h2>
      <p>
        В данном отчете показаны тесты и результаты их прогона для всех версий
        продукта.<br />
        В данном случае доступен экспорт отчета в файл формата Excel.
      </p>
      <h2>
        Блокированные тесты
      </h2>
      <p>
        В данном отчете показаны все тесты, блокированные в настоящий
        момент.<br />
        Например, если тест был пройден в версии 1 и блокирован в версии 2, то
        он будет показан в этом отчете.<br />
        А если он был блокирован в версии 1 и пройден в версии 2, то не будет.
      </p>
      <h2>
        Проваленные тесты
      </h2>
      <p>
        В данном отчете показаны все тесты, которые в настоящий момент
        провалены.
      </p>
      <h2>
        Отчет об обнаруженных багах
      </h2>
      <p>
        В данном отчете показаны все тесты заданного плана и все обнаруженные
        баги.
      </p>
      <h2>
        Отчет о выполнении требований
      </h2>
      <p>
        В данном отчете показаны результаты прогона тестов, спроецированные на
        покрываемые ими требования.
      </p>
      <h2>
        Результат тестирования требований
      </h2>
      <p>
        В данном отчете показаны все тестируемые требования и результаты
        прогона соответствующих им тестов.
      </p>
      <h2>
        Отослать отчет на e-mail
      </h2>
      <p>
        Здесь пользователю предлагается возможности отправки на любой адрес
        электронной почты отчета по всему плану тестирования или по конкретной
        версии продукта
      </p>
      <h1 align="right">
        см. также: <span class="help" onclick=
        "javascript:open_popup('./content.html');">Справка TestLink</span>
      </h1>
    </div>
  </body>
</html>

Shortcuts.html (TestLink-RU)

2007-08-28T11:26:14Z

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">Закрыть</a>
      <a href="javascript:%20history.back();" class="tlButton">Назад</a>
      <a href="content.html" class="tlButton">Оглавление</a>
    </div>
    <h2>
      Обзор
    </h2>
    <p>
      Для быстрой навигации по программе в Teslink предусмотрено использование
      "горячих" клавиш (ALT + &lt;клавиша&gt;).
    </p>
    <p>
      Список доступных клавиш:
    </p>
    <ul>
      <li>[h] Домой
      </li>
      <li>[i] Мои данные
      </li>
      <li>[q] Выход
      </li>
      <li>[u] Персонал (только для администратора)
      </li>
    </ul>
    <h2>
      Поддержка браузеров
    </h2>
    <p>
      Использование "горячих" клавиш поддерживается следующими web-браузерами:
    </p>
    <ul>
      <li>Internet Explorer 4 (Windows) 5+ (Mac)
      </li>
      <li>Mozilla (Windows + Linux)
      </li>
      <li>Netscape 6.1+ (Windows)
      </li>
      <li>Opera 7 (Windows + Linux)
      </li>
    </ul>
  </body>
</html>

SearchTc.html (TestLink-RU)

2007-08-28T11:26:10Z

StasFomin: откат и поправка.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.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>
    <style media="all" type="text/css">
/*<![CDATA[*/
    @import "../../css/testlink.css";
    @import "../../{$smarty.const.TL_THEME_CSS_DIR}testlink.css";
    /*]]>*/
    </style>
    <script type="text/javascript" src="../../javascript/testlink_library.js">
</script>
  </head>
  <body>
    <div class="workBack">
      <h1>
        Страница поиска тестов
      </h1>
      <h2>
        Назначение:
      </h2>
      <p>
        Для поиска используются ключевые слова и строки поиска по всем полям
        описания тестового примера. Поиск не чувствителен к регистру. Результат
        поиска включает тесты только текущего проекта (продукта).
      </p>
      <h2>
        Что делать:
      </h2>
      <ol>
        <li>Впишите строку поиска в нужное поле. Неиспользованные поля оставьте
        пустыми.
        </li>
        <li>Выберите требуемое ключевое слово, или оставьте значение "не
        применимо".
        </li>
        <li>Нажмите кнопку "Искать".
        </li>
        <li>Все тесты, соответствующие строкам поиска, показаны. Вы можете
        модифицировать выбранные тесты, используя кнопку "Редактировать",
        расположенную под строкой заголовка теста.
        </li>
      </ol>
      <h1 align="right">
        см. также: <span class="help" onclick=
        "javascript:open_popup('./content.html');">Справка TestLink</span>
      </h1>
    </div>
  </body>
</html>

RequirementsCoverage.html (TestLink-RU)

2007-08-28T11:26:07Z

StasFomin: внес свои правки и адаптацию к 1.7.

<!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">Закрыть</a>
      <a href="javascript:%20history.back();" class="tlButton">Назад</a>
      <a href="content.html" class="tlButton">Оглавление</a>
    </div>
    <h2>
      Обзор
    </h2>
    <p>
      Эта функция показывает степень покрытия требований тестовыми примерами.
      Для просмотра требований пользуйтесь ссылкой "Управление требованиями"
      на рабочем столе (главной странице).
    </p>
    <h2>
      Группы требований
    </h2>
    <p>
      Требования собраны в группы, связанные с проектом (продуктом). TestLink не
      поддерживает версионность для требований и их групп.
    </p>
    <p>
      Общее количество требований служит для оценки покрытия требований
      тестами, поэтому не все требования, предъявляемые к программному
      продукту, целесообразно вносить в TestLink. Значение поля "Всего
      требований" определяет количество требований, используемых для построение
      отчетов.
    </p>
    <p>
      <i>Например, некая программа включает 200 требований, но только 50 тестов
      внесены в TestLink. Тестовое покрытие в этом случае составляет 25% (если
      все требования - тестируемы).</i>
    </p>
    <h2>
      <a name="req" id="req">Требования</a>
    </h2>
    <p>
      Нажмите на название уже созданной группы требований. Для этой группы вы
      может создавать, редактировать, удалять или импортировать требования.
      Каждое требование включает название, содержание и статус. Статус
      определяет, является ли данное требование тестируемым или нет.
      Нетестируемые требования не подсчитываются при формировании отчетов.
    </p>
    <p>
      На странице "Редактор требований" вы можете создавать тесты привязанные к
      выбранным требованиям. 
    </p>
  </body>
</html>

Product.html (TestLink-RU)

2007-08-28T11:26:03Z

StasFomin: внес свои правки и адаптацию к 1.7.

<!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="ru" />
    <meta name="author" content="Martin Havlat" />
    <meta name="copyright" content="GNU" />
    <meta name="robots" content="NOFOLLOW" />
    <title>
      TestLink Help: Product
    </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'e относятся к тому или иному проекту (программному продукту или иному заказному проекту), который выбирается из меню в правом верхнем углу экрана.
    </p>
    <h2>
      Панели рабочего стола
    </h2>
    <p>
      Рабочий стол Testlink'a состоит из левой панели, где расположены разделы
      "Описание тестов", "Требования" (если они были определены при создании
      продукта), "Ключевые слова", "Проект" и правой панели,
      относящийся к планированию и выполнению тестирования продукта.<br />
    </p>
    <h3>
      Описание тестов
    </h3>
    <p>
      Этот раздел дает пользователю возможность создания, редактирования и
      удаления тестов и групп тестов. Так же в этом разделе
      можно выбрать определенные тесты из всего имеющегося набора, распечатать,
      а также импортировать тесты.<br />
      Пользователь с надлежащими правами может изменить порядок следования
      тестов в группе.
    </p>
    <h3>
      Ключевые слова
    </h3>
    <p>
      TestLink дает возможность пользователю отбирать тесты по группам и ключевым словам. Раздел управления ключевыми словами
      позволяет пользователю с надлежащими правами добавлять, редактировать и
      удалять ключевые слова.<br />
      <i>Примечание: Ключевые слова могут быть привязаны к тестам при
      редактировании последних, а также на специальной странице "Задать
      ключевые слова для теста" .</i>
    </p>
    <h3>
      Управление проектом
    </h3>
    <p>
      Раздел "Управление проектом" предназначен в первую очередь для
      пользователя с правами администратора, который может создавать и
      редактировать и удалять продукты.
    </p>
  </body>
</html>

Priority.html (TestLink-RU)

2007-08-28T11:26:00Z

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

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" 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 http-equiv="expires" content="-1" />
    <meta http-equiv="pragma" content="no-cache" />
    <meta name="author" content="Martin Havlat" />
    <meta name="copyright" content="GNU" />
    <meta name="robots" content="NOFOLLOW" />
    <title>
      TestLink Instructions
    </title>
    <style media="all" type="text/css">
/*<![CDATA[*/
    @import "../../{$smarty.const.TL_THEME_CSS_DIR}testlink.css";
    /*]]>*/
    </style>
  </head>
  <body>
    <div class="workBack">
      <h1>
        Параметры тест-плана: установка принадлежности и приоритетов
      </h1>
      <h2>
        Назначение:
      </h2>
      <p>
        В этом разделе можно установить принадлежность каждого набора тестов
        тому или иному пользователю, а также определить параметры риска и
        важности тестов. По ссылке "Правила назначения приоритетов"
        пользователь может определить приоритет для каждой пары параметров
        Важность/Риск. Эти правила действуют только для активного Плана
        тестирования.
      </p>
      <h2>
        Что делать:
      </h2>
      <ol>
        <li>Выберите тестовый набор и присвойте ему параметры риска и важности,
        а также определите владельца этого набора.
        </li>
        <li>Сохраните введенные данные нажатием кнопки "Обновить".
        </li>
      </ol>
      <h1 align="right">
        см. также: <span class="help" onclick=
        "javascript:open_popup('./content.html');">Справка TestLink</span>
      </h1>
    </div>
  </body>
</html>

PlanTesters.html (TestLink-RU)

2007-08-28T11:25:25Z

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

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" 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 Instructions
    </title>
    <style media="all" type="text/css">
/*<![CDATA[*/
    @import "../../{$smarty.const.TL_THEME_CSS_DIR}testlink.css";
    /*]]>*/
    </style>
  </head>
  <body>
    <div class="workBack">
      <h1>
        Назначение персонала, ответственного за выполнение плана
      </h1>
      <h2>
        Назначение
      </h2>
      <p>
        Раздел предназначен для установления перечня пользователей,
        ответственных за выполнение каждого тест-плана. Этим пользователям
        дается право изменять данные в рамках порученного им плана.
      </p>
      <h2>
        Что делать:
      </h2>
      <ol>
        <li>Выберите любой из двух способов назначения ответственных: от
        пользователя или от тест-плана.
        </li>
        <li>Выбрав пользователя, пометьте флажками все тест-планы, которые
        будут ему доступны.
        </li>
        <li>Выбрав тест-план, пометьте флажками всех пользователей, которым
        будет доступен этот план.
        </li>
      </ol>
      <h1 align="right">
        см. также: <span class="help" onclick=
        "javascript:open_popup('./content.html');">Справка TestLink</span>
      </h1>
    </div>
  </body>
</html>