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