Компания-заказчик |
Крупный торговый холдинг, группа компаний. Название не называется по условиям конфиденциальности |
Отрасль |
Торговля и производство |
Содержание проекта |
Внедрение автоматизированной системы в казначействе |
Компания имеет штаб-квартиру в Москве, 5 региональных управленческих офисов и свыше сотни крупных магазинов.
До внедрения автоматизированной системы в казначействе, заявки в компании «ходили» в бумажном виде. Свыше 100 заявок передавалось по факсу из регионов в центр, где они рассматривались в департаментах. И, естественно, часть документов терялась или обрабатывалась с большим опозданием. По мере роста компании бумажный документооборот стал настолько большим, что впору было создать новую организационную единицу – «отдел по поиску заявок». Количество информации так захлестнуло компанию, что стало сложно отслеживать, у кого находится тот или иной документ, а главное – в какой стадии находится бизнес-проект или процесс, в рамках которого и был создан определенный документ. В БД можно определить реквизиты документа, но из них часто не понять его статус и уж точно не понять, в каком состоянии находится бизнес-процесс, результата которого ожидает сотрудник или покупатель.
В компании применялся западный программный продукт для автоматизации бюджетирования, но он был информационно оторван от фактических данных, и логика его работы не позволяла контролировать прохождение отдельных документов.
Компанией был выбран многофункциональный программно-методический комплекс для управления предприятием. Продукт ориентирован на средние и крупные компании, холдинги, объединяющие разнородные виды бизнеса (реализована поддержка консолидации информационных ресурсов). Выбор был сделан именно такой, поскольку продукт обладает как возможностями бюджетирования, так и гибкой автоматизации казначейства.
Благодаря внедрению автоматизированной системы казначейства на базе «Инталев: Корпоративные финансы 2005» достигнуто:
Общая логика работы системы имеет такую последовательность:
Вот основные качественные показатели, которых удалось добиться благодаря внедрению автоматизированной системы в казначействе на основе программных продуктов по бюджетированию и документообороту.
Точный экономический эффект от внедрения управленческих информационных систем такого масштаба привести довольно сложно. Но все же попробуем, помня о некоторых условностях.
По статистике работы системы в казначействе было подмечено, что около 20% заявок шли с первоначальным превышением бюджета. В среднем, 1 заявка составляется на общую сумму в 5 000 USD. В день составляется около 150 заявок. Допустим, в случае превышения заявки, величина превышения составляет только 10% (хотя на практике возникают куда большие отклонения).
Приведем расчет экономии расходов: [150 заявок в день] * [30 дней в месяц] * [20% заявок шли с превышением] * [5 000 USD «стоит» 1 заявка] * [10% величина превышения заявленной суммы над утвержденной по бюджету] = 450 000 USD в месяц!
Даже если в расчетах была допущена погрешность в несколько раз, в любом случае окупаемость проекта измеряется в пределах нескольких месяцев эффективной продуктивной работы.
На первом этапе была разработана схема бизнес-процесса. Для этого был выбран еще один продукт, как средство моделирования бизнес-процессов.
Была описана оргструктура компании, список участников процесса и используемых документов, выделены роли (должности). Общая логика выполнения методических работ при внедрении приведена на рисунке: Рисунок 1.
Рисунок 1 . Последовательность методических работ при внедрении.
В итоге, получилась довольно сложная схема (см. Рисунок 2), с учетом реалий сложной распределенной структуры филиалов и исторических особенностей компании.
Рисунок 2 . Схема бизнес-процесса заявки на выплату денежных средств.
На первом этапе описания процесса наиболее важным критерием была наглядность описания, поэтому был выбран формат EPC. Когда топ-менеджеры компании увидели полученную схему, то они ужаснулись ее сложности и стали ее упрощать.
В ходе оптимизации консультанты следовали нескольким принципам:
После утверждения схемы процесса в «бумажном» виде, были выработаны требования к модели управленческого учета и бюджетирования. В них вошли: управленческий план счетов, бюджеты и статьи в них, форматы ввода данных.
Разработанный процесс был так же визуально настроен в модуле workflow системы бюджетирования.
Особым преимуществом созданного программного решения является автоматический контроль лимитов, в разрезе видов бюджетов, статей, контрагентов и договоров. На этапе планирования финансовый департамент утверждает отдельные и консолидированный бюджеты движения денежных средств по компании, которые вводятся с большой степенью детализации. По введенным заявкам программа автоматически не позволяет тратить свыше утвержденных лимитов, с учетом всех аналитических разрезов и ранее совершенных платежей. Только утвержденные заявки (по бюджету, или с визой полномочного лица) попадают в бухгалтерию и могут быть оплачены. При этом весь процесс происходит в режиме реального времени. Общая логика системы создания и сопоставления заявок приведена на рисунке: Рисунок 3.
Рисунок 3 . Логика работы системы заявок.
Для бухгалтерского учета в компании применялась традиционно «1С: Бухгалтерия 7.7», с множеством баз для различных юридических лиц. Был разработан модуль загрузки фактических данных о платежах, поступающих в бухгалтерскую систему из системы банк-клиента. Режим работы модуля позволял ежедневно перегружать фактические данные о платежах, а также по запросу (чаще) синхронизировать данные о контрагентах и договорах.
Пример регулярного отчета о движении денежных средств (БДДС) приведен на рисунке: Рисунок 4. Данные можно также изучать с помощью средств desktop OLAP, встроенных в систему бюджетирования.
Рисунок 4 . Фрагмент примера отчета по БДДС.
Отдельно была настроена довольно «изощренная» система разграничения доступа к данным, благодаря уникальным возможностям программного продукта. Была составлена матрица ролей, по географическому и функциональному признаку, для более быстрой (модульной) модификации. Затем для каждого элемента классификаторов ЦФО, статей бюджетов, сценариев планирования и других аналитических признаков были поставлены права доступа: «нет никакого», «только на чтение» (для отчетов), «полный» (включая запись). Всего было настроено более 300 ролей: 300 ролей * 15 справочников классификаторов * 300 элементов в каждом = 135 000 значений настроек. Это требование очень сильно могло повлиять на производительность системы. Потребовались усилия разработчиков по оптимизации продукта, и грамотный подход консультантов к настройке. Но благодаря гибкости продукта в будущем настройки модифицировались неоднократно без перекодирования системы.
После настройки в системе бюджетирования модели учета было проведено несколько серий обучения пользователей. В течение 1 месяца проходила опытно-промышленная эксплуатация, в течение которой подразделения компании постепенно переходили на единую автоматизированную систему. Наиболее важные платежи дублировались привычными бумажными документами.
По результатам опытно-промышленной эксплуатации было принято решение о переводе системы в продуктивную работу.
Для сопровождения пользователей и системы на территории заказчика консалтинговая компания организовала постоянный пункт, в состав которого вошли: руководитель группы, бизнес-аналитик и специалист по техподдержке пользователей. Эти специалисты не только поддерживают пользователей и обслуживают систему, но и постоянно развивают её, описывая и автоматизируя новые процессы.
В проекте в полной мере использованы новейшие технологии workflow. Это означает:
Что в этом нового и замечательного?
Всем управляет действительно автоматизированная система, в которой корпоративными аналитиками прописана логика бизнес-процессов.
Компания развивается очень динамично. За полгода эксплуатации среднее количество активных пользователей увеличилось с 50 до 70 человек. Возникали и изменения в логике функционирования процесса, за полгода было опубликовано (введено в действие) более 40 (!) новых версий. Гибкость продукта очень пригодилась заказчику, агрессивно скупающему менее крупных игроков на рынке и встраивающих их как подразделения в собственную бизнес-машину.
Возрастание сложности процесса и нагрузки со стороны пользователей привело к повышению требований к «железу», в частности, критическими факторами были выявлены производительность сервера с MS SQL Server и сервера приложений «1С:Предприятие 8.0». Производится апгрейд компьютерного парка, особенно серверов. Также планируется переход на «1С: Бухгалтерия 8.0».
Большая часть опыта проекта была обобщена в виде рекомендаций в базе знаний по системе бюджетирования.
Важно, что было положено начало процессному подходу и его автоматизации в компании. После налаживания казначейства, компания готовится к автоматизации договорной деятельности, также применяя возможности workflow, которые позволяют разрозненным сотрудникам компании действовать как единая бизнес-машина.