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

Статья переехала, новый адрес: «Новый коллективный разум» на lib.custis.ru

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

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

Содержание 1 Голод среди изобилия 2 Как это работает 2.1 Сбор данных 2.2 Структурирование данных 2.3 Информационное обслуживание 2.4 Проектирование пользовательских отчетов 2.5 Коррекция настроек и функциональности системы 2.6 Система информационного обслуживания OLRIS 3 Ссылки

1 Голод среди изобилия

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

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

Увы, как часто бывает, теперь многие склоняются к другой крайности: считают, что все предприятия обязательно должны внедрить так называемые системы класса ERP (Enterprise Resource Planning) — мощные интегрированные программные решения, позволяющие в единой логике автоматизировать большинство служб предприятия и их бизнес-процессов. Казалось бы, что может быть лучше? Но ничто не дается даром. Внедрение ERP-системы накладывает огромную тяжесть и ответственность на предприятие: высокая стоимость систем, консалтинга и дальнейшего обслуживания, серьезные требования к квалификации персонала предприятия, в первую очередь — сотрудников информационной службы, объективно длительный срок внедрения. Поэтому на отечественном рынке практически все попытки внедрить ERP-систему целиком пока кончались неудачей. Относительно удачными можно признать только отдельные проекты внедрения одного или нескольких программных модулей, без покрытия полного контура бизнес-процессов предприятия — большинство ERP-систем это позволяют. В этом же ключе следует рассматривать многочисленные успешные внедрения специализированных программных решений, таких, как мини-бухгалтерии, системы документооборота или управления логистикой. Но во всех случаях положительный эффект от внедрения многократно ниже, чем от интегрированного решения. Главное, чего при этом не удается достичь — получить информацию для принятия управленческих решений руководством. А без этого успех работы предприятия — под вопросом.

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

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

2 Как это работает

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

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

Рисунок 1. Схема работы системы информационного обслуживания.

Работа системы информационного обслуживания (рис. 1) осуществляется в несколько стадий.

2.1 Сбор данных

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

Данные поступают в систему следующими путями:

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

2.2 Структурирование данных

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

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

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

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

2.3 Информационное обслуживание

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

Такой подход получил название OLAP (On-Line AnalyticalProcessing) — аналитическая обработка данных в реальном времени. Системы, поддерживающие этот принцип работы, могут хранить информацию в виде многомерных или реляционных баз данных. Но вне зависимости от физической реализации единым является логическая организация хранения данных в виде ячеек так называемого многомерного куба. По осям такого куба откладываются разрезы или показатели, которые могут иметь простую или иерархическую структуру. Разрезы, по сути дела, представляют собой различные взгляды на одни и те же данные с нескольких точек зрения: например, расходы бюджета предприятия можно представить через иерархию проектов и других прикладных задач или через иерархию подразделений и служб. Собственно же учитываемые данные хранятся в ячейках такого куба, причем не все ячейки могут быть заполнены.

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

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

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

2.4 Проектирование пользовательских отчетов

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

2.5 Коррекция настроек и функциональности системы

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

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

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

Рисунок 2. Технология системы информационного обслуживания.

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

2.6 Система информационного обслуживания OLRIS

В качестве примера удачной реализации принципов информационного обслуживания можно привести программную систему OLRIS (On-Line Reference and Information System) компании ООО «Заказные ИнформСистемы» (Москва) — интегрированный программный комплекс для формирования единого информационного фонда предприятия или корпорации.

Функциональность OLRIS полностью отвечает всем требованиям, предъявляемым к системам информационного обслуживания и описанным выше. Система включает в себя:

• хранилище различных типов данных, организованных в многомерные структуры;
• административное приложение для управления настройками хранилища;
• подсистему автоматического и полуавтоматического импорта данных в хранилище;
• механизм совместного хранения учетных данных, первичных документов и отчетов;
• удобный пользовательский интерфейс на основе Internet Explorer;
• возможность быстрого создания и редактирования отчетов пользователями, сохранения отчетов под уникальными именами;
• средства графического отображения отчетов и их экспорта в MS Excel;
• подсистему управления разделением доступа пользователей;
• механизм обмена входящими и исходящими объектами.

Для загрузки данных используется подсистема, осуществляющая импорт файлов данных формата MS Excel или текстовых в полуавтоматическом или автоматическом (пакетном) режиме. Данная подсистема позволяет создавать шаблоны, на основе которых информация известной структуры может загружаться автоматически в любых объемах и с любой периодичностью без вмешательства пользователей. Имеется также возможность ввода данных в ячейки вручную с помощью специального административного приложения (среда разработки PowerBuilder). Это приложение позволяет производить практически любые действия по развитию и настройке хранилища данных: создавать новые структуры хранения, разрезы, справочники, управлять разделением доступа пользователей. Отличительной особенностью OLRIS, осуществляемой через административное приложение, является возможность сохранять в ячейках вместе с учетными данными связанные с ними первичные документы в любых оригинальных форматах: текст, графика, бинарные данные и т. д. В дополнение к этому система имеет средства поиска таких документов по заголовкам или даже по их контексту (в зависимости от типа данных).

Размещение данных осуществляется в специально организованном объектном хранилище. В нем выполнено разделение физического уровня хранения в СУБД Oracle, используемой в данной системе, и логического уровня сущностей, атрибутов и их связей, т. e. структур, непосредственно используемых для хранения данных. Управляет работой и настройкой хранилища объектное метаядро CustIS Objects, содержащее средства поддержания целостности и обеспечения доступа к данным — специальные дополнительные структуры настроек и пакеты хранимых процедур. Метаядро позволяет создавать новые логические структуры данных, не изменяя структуру таблиц Oracle, а это упрощает управление хранилищем. В данном случае можно говорить, что хранилище данных OLRIS занимает промежуточное положение между реляционной и многомерной организацией базы данных. Часть метаядра реализует полномасштабный механизм разделения доступа пользователей, имеющий в своей основе встроенный механизм СУБД Oracle.

Для вывода отчетов используется рабочее место пользователя на основе броузера MS Internet Explorer. Использование этого программного средства существенно упрощает обучение пользователей и снимает большинство вопросов сетевого взаимодействия — для подключения к системе пользователю достаточно иметь доступ в Интернет. Взаимодействие между хранилищем данных и броузером пользователя осуществляет трехуровневая программная подсистема CustIS Web, серверная часть которой (язык разработки PL/SQL) отвечает за формирование выборки данных, а в качестве промежуточного уровня используется MS Internet Information Server с установленным Web-брокером (язык разработки C++). Для реализации элементов пользовательского интерфейса на клиентском уровне подсистема предоставляет JavaScript-объекты, использующие динамический код HTML для генерации экранных форм.

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

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

Рисунок 3. Схема программной системы OLRIS.

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

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

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

3 Ссылки

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

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

Статья переехала, новый адрес: «АБС — эволюция от товара к услуге» на lib.custis.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ссылки

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