Поделиться
Банковский консорциум: автоматизация колосса
Одним из средств выживания бизнеса в современном мире является создание консорциумов. Автоматизация такого гиганта – дело нешуточное, требующее серьезного и вдумчивого подхода. Как достичь этой цели и избежать ловушек, рассказал генеральный директор компании "ПрограмБанк".Кроме того, предложенный вариант автоматизации дает возможность сделать выбор учетных систем, которые будут заменять существующие системы низового уровня, более осмысленным, учитывающим опыт развития требований отчетной системы. Заодно появляется время для формирования набора требований к учетным системам низового уровня – пока внедряется и становится устойчивой система консолидации отчетности.
Следует также упомянуть снижение напряженности в переходном периоде от "набора предприятий" к консорциуму за счет снижения объема изменений ("сохранения среды") на низовом уровне.
Очень важным результатом "наложенной" автоматизации является получение возможности решать ИТ-проблемы бизнеса не все сразу, а по мере их возникновения и обострения. Конечно, в рамках такого поэтапного подхода что-то все время не работает, что тоже является источником дискомфорта для управленцев. Однако не работает лишь что-то, а не все вообще. Есть разница, и существенная!
Возможно, перечисленные преимущества описываемого подхода покажутся поклонникам "принципиальных" решений не очень важными. Однако тем, кто хоть раз на себе испытал прелести периода формирования консорциума, все это вряд ли покажется непринципиальным.
Вертикальные решения
Как уже отмечалось, получение консолидированной отчетности на основе выгружаемых аналитических таблиц вовсе не исключает доступа к первичным документам. Другое дело, что для оправдания систематического доступа к ним нужна соответствующая бизнес-цель. Обычно речь в таких случаях идет о формировании специализированных вертикальных ИТ-решений под соответствующие организационные структуры.
В качестве примера часто "вертикализуемых" функций можно назвать снабжение всеми видами ресурсов, сбыт всех производимых товаров и услуг и финансовый сервис.
Реже "вертикализуются" конкретные производственные функции. Наличие таких решений позволяет получать ряд консолидированных отчетов несколькими способами (путем консолидации аналитических данных, выгруженных из первичных систем, и на основе данных вертикальных решений). Расхождения в таких отчетах часто ценнее, чем совпадения, поскольку дают "наводки" на имеющиеся "дыры" в первичном учете, заставляют совершенствовать систему аналитических таблиц, являющихся основой консолидированной отчетности.
Описываемая архитектура общего ИТ-решения консорциума характеризуется тем, что каждая бизнес-задача в ней поддерживается специализированным прикладным решением, что позволяет не деформировать бизнес-задачи под свойства и возможности программного обеспечения (ПО), а решать их в исходном виде. При этом система подготовки консолидированной отчетности играет роль "клея", интегрирующего отдельные приложения и задающего им требования к их выходной отчетности.
Проблема смены ПО
Обычно сменой ПО занимаются совсем не те люди, которые его внедряли. Это позволяет и интеграторам, и принимающим решение о внедрении не задумываться о том, каким требованиям должно удовлетворять ПО, чтобы его удобно было заменять на более совершенное.
А между тем обновление сложной системы дается значительно тяжелее, чем узкопрофилированного ПО. С другой стороны, чем шире специализация системы, тем эффективнее она решает бизнес-задачи (впрочем, этот тезис не работает для предприятий, подверженных частым организационным и технологическим изменениям). Таким образом, существует объективное противоречие между сиюминутной эффективностью и стратегическими потерями при обновлении или замене системы.
Каждая организация по-своему разрешает указанное противоречие. Однако очень мало сколько-нибудь крупных организаций, где действовало бы единственное полностью интегрированное решение.
В скобках стоит отметить, что единственность ИТ-решения довольно часто декларируется. Однако внимательный анализ легко находит незаметные функции, обойденные вниманием и исполняемые с помощью самых различных "самоделок".
Ограничимся лишь выводом о неизбежности некоторой "лоскутности" применяемых ИТ-продуктов, который собственно и оправдывает предлагаемую архитектуру общего ИТ-решения консорциума.
Особенности первого удара
Поскольку первым шагом в наведении порядка в консорциуме является внедрение системы получения консолидированной отчетности, от ее соответствия предъявляемым требованиям во многом зависит эффективность всей дальнейшей процедуры. Но каковы эти требования?
Если говорить об общих требованиях, то это масштабируемость в очень широких пределах (от сотен до миллионов документов в день); мощный генератор отчетов с развитыми средствами описания и проектирования отчетов; структурированность и высокая эффективность средств загрузки данных; наличие встроенных средств повышения качества исходных данных, мониторинга процесса поставки данных низовыми предприятиями, а также распределенного доступа к данным и отчетам при безусловном исполнении требований по безопасности.
Менее очевидна потребность во встроенных развитых средствах представления и анализа данных, однако с течением времени эта потребность становится все более острой.
Если говорить о специальных требованиях, то обычно речь идет о наличии готовых средств для решения наиболее типовых управленческих задач, таких как бюджетирование, оперативное финансовое управление и CRM-подсистема.
Впрочем, говоря о типовых задачах, стоит помнить, что, по замечанию классика, все счастливые семьи похожи друг на друга, несчастливые же несчастны по-своему. Создание консорциума уже по одному перечню требующих решения задач не выглядит периодом безоблачного счастья, а значит требует очень индивидуального подхода. Поэтому стоит завершить список требований к внедряемой системе последним, но, может быть самым важным. Такая система должна обладать способностью быстро изменяться, в том числе глубоко, согласно запросам заказчика.
В известной степени это требование не столько к самому программному продукту, сколько к его поставщику/разработчику.
Короткая ссылка
