От процессов до работающей системы: автоматизация системы управления финансами
Система в системе
Любая компания представляет собой сложную систему элементов, связанных между собой потоками различных ресурсов (материальных, информационных). Само собой, чем лучше ее руководство умеет контролировать эти потоки и в нужный момент воздействовать на них, корректируя существующие и создавая новые, тем выше вероятность того, что цели, стоящие перед компанией, будут достигнуты. То есть, факторы времени и качества получаемой информации выходят на первый план. По мере роста компании ее процессы усложняются, и требования к качеству и своевременности получаемой информации возрастают. По этой причине компания неизбежно приходит к необходимости автоматизации своих процессов.
Особенно актуальным вопрос грамотного подхода к автоматизации становится в период кризиса, когда в условиях ограниченности ресурсов (как финансовых, так и человеческих, и временных) и необходимости управления затратами компания не может себе позволить неграмотно спланированный проект, заканчивающийся ничем. Кстати, в таких условиях наибольшее внимание уделяется пересмотру и автоматизации процессов таких областей, как бюджетирование и управленческий учет, а также оперативное управление денежными средствами и задолженностью. Вопросы эффективного управления затратами и процессами стоят на первом месте у клиентов, которые приходят к нам на обучение.
Разумеется, при автоматизации систем управления финансами можно выделить первостепенные области, такие как бюджетирование и оперативное управление денежными средствами (платежный календарь) и, скажем так, менее очевидные, такие как документооборот или бизнес-моделирование. Бухгалтерский учет, в наши дни в той или иной степени автоматизируемый по умолчанию, рассматривать в этой статье не будем. Остальные блоки системы управления финансами могут автоматизироваться в разной степени и при помощи различных инструментов и их комбинаций, в зависимости от потребностей и возможностей конкретной компании.
Основные шаги
Как показывает опыт, автоматизацию систем управления, в частности, системы управления финансами, необходимо проводить комплексно, оценивая эффект от нее на компанию в целом, а не только отдельный автоматизируемый блок. В противном случае можно получить, при более благоприятном исходе, работающий автоматизированный участок системы, не связанный с ее остальными компонентами, при менее благоприятном – впустую потраченные время, деньги и нервы. Обычно автоматизация процессов проводится в форме проекта. Напомню основные шаги.
- Итак, прежде всего нужно определить, для чего нам нужна автоматизация? Какой результат от нее мы хотим получить? Только ответив на эти вопросы, мы сможем оценить эффект от внедрения системы и оправданность произведенных вложений в нее.
- До запуска проекта важно также решить организационные вопросы: определение сроков, выделение ресурсов на подготовку и проведение проекта, формирование проектной команды, планирование проекта, а также определение «на берегу» вопросов стимулирования сотрудников, вовлеченных в проект по автоматизации. На организационных аспектах не буду подробно останавливаться, это тема для отдельной статьи.
- Анализ существующих бизнес-процессов и формирование модели «как надо». От полноты и правильности проведенного анализа зависит судьба всего проекта, поскольку переделывать в будущем уже сделанные настройки будет гораздо дороже, нежели изначально потратить чуть больше усилий на то, чтобы выстроить правильную модель. А ведь нами движет желание повысить эффективность наших процессов, не так ли?
- Поняв автоматизируемый процесс, определяем правила, по которым он будет работать, то есть его методологическую составляющую. Ниже остановлюсь на ней подробнее.
- Сформулированные правила и принципы работы выливаются в технические требования к будущей системе, на основе которых выбирается программный продукт, в котором будет реализовываться система, и формируется задача разработчикам.
- Собственно настройка и/или доработка программного продукта для отражения в нем всех особенностей методологии автоматизируемого процесса. То, что чаще всего имеют в виду, говоря об автоматизации. Но мы же видим, что это только один из необходимых шагов, так?
- Обучение сотрудников работе в новой системе. Несомненно, важный этап, пренебрежение которым может существенно затруднить адаптацию компании к жизни в новой системе. По моему опыту, часто только за счет качественного информирования и обучения сотрудников существенно облегчается принятие нововведений сотрудниками, которые в силу разных причин могут быть изначально негативно настроены, вплоть до откровенного саботажа.
- Опытная эксплуатация. Здесь исправляются обнаруженные ошибки и пользователи привыкают к работе в ней. Мне встречались случаи, когда руководство компании без понимания относилось к этапу опытной эксплуатации, стремясь сократить его, неохотно выделяло сотрудников для участия в нем, и т. д. Такое отношение, как правило, меняется, когда в процессе эксплуатации выявляются недоработки, которые могут быть вызваны как ошибками в настройке системы, так и недостаточно корректно сформулированными целями и задачами новой системы (вспомните первый вопросы, на который я обратил внимание в этой статье!).
- После завершения опытной эксплуатации и перехода к промышленной эксплуатации компания начинает работать в новой системе в полную силу. И только тогда появляется возможность оценить эффект от проведенной автоматизации: достигнуты ли, и насколько хорошо, поставленные цели.
На отдельных важных шагах я остановлюсь ниже более подробно.
Анализ бизнес-процессов
Поскольку мы уже упомянули автоматизируемые процессы компании, необходимо их выявить, проанализировать и, в идеале, описать. Понимание взаимосвязей между отдельными действиями, направленными на достижение цели компании (не для этого ли в ней работают процессы?) и ответственных за их выполнение позволяют корректно сформулировать цели и задачи каждой операции, проконтролировать ее не наделать ошибок при проектировании автоматизированной системы. Выявление и анализ «узких мест» существующих процессов (в том числе нефинансовых) позволяет спроектировать будущую систему с наименьшими затратами. Отсутствие понимания того, что придется в дальнейшем автоматизировать, неважно в каком программном продукте, может существенно затруднить, а в худшем случае сделать бессмысленным весь проект по автоматизации. Описание существующих бизнес-процессов и, при необходимости, их переработка, - отдельная большая задача, на которой я не буду здесь подробно останавливаться.
Для описания и анализа бизнес-процессов применяется различный инструментарий, включая BPWin, Visio, Aris и другие. В результате компания получает текстовое и графическое описание каждого процесса (см., например, Рисунок 1), исходя из которого можно выявить его узкие места и внести необходимые коррективы в его дизайн.
Рисунок 1. Графическое описание процесса (на примере процесса бюджетного планирования)
Кликните мышкой по изображению, чтобы увеличить его
При описании и проработке процессов необходимо ориентироваться прежде всего на основной бизнес-процесс компании (то есть, тот, который описывает ее основную деятельность, например, куплю-продажу товаров), а обслуживающие и вспомогательные процессы строить таким образом, чтобы они работали на пользу основного процесса.
Пример
Собственники группы компаний (специализирующейся на логистике и оптовой и розничной торговле продуктами алкоголем и продуктами питания) сформулировали для себя необходимость построения единой системы управленческого учета и пригласили для этой цели внешнего консультанта. Начать решили с анализа существующих процессов и разработки единой методологии планирования и учета. В ходе анализа существующих процессов выяснилось, что основная проблема состоит в том, что в группе есть несколько направлений деятельности (фактически самостоятельных бизнесов), которые исторически осуществляли планирование и ведение оперативного учета по отдельности, каждый по своим сложившимся правилам, и у каждого бизнеса было свое видение того, как надо правильно управлять бизнесом, и свои аргументы в пользу этого. Выявление и анализ существующих процессов помогли выявить особенности каждого направления бизнеса (момент возникновения затрат, особенности ценообразования, способы распределения затрат) и приступить к разработке методологии с учетом этих особенностей.
Методология
Теперь, когда понятны применяемые в системе управления финансами процессы и ответственные за них, нужно определить, какие финансовые и нефинансовые показатели будут использоваться, каким образом они будут определяться и представляться руководству для анализа. Как показывает опыт проведенных проектов, чаще всего у компании нет целостной и отвечающей ее информационным потребностям методологии. В некоторых случаях она может существовать, но требовать доработки и актуализации исходя из современных требований к предоставляемой информации. В единичных случаях методологическая основа может быть хорошо проработанной и позволяющей брать ее за основу для разработки технического задания на автоматизацию. В любом случае, в компании должен быть центр компетенции, ответственный за ее постоянный мониторинг и поддержку имеющейся методологической модели и, при необходимости, внесения в нее изменений, а также владелец модели системы, который будет принимать решения, касающиеся ее поддержания и изменения, и нести ответственность за ее работоспособность и выполнение поставленных перед ней задач.
Пример
Продолжая пример, уточню, что в группе отсутствовала единая методология планирования управленческого учета, и каждое направление бизнеса уделяло им внимание в меру своего понимания необходимости тех или иных показателей и запросов собственника. Также не было единых форматов отчетности, сотрудники присылали в центр данные в произвольном формате, которые потом сводились в отчет для руководства, который включал только выборочные показатели деятельности, не давая таким образом полной картины бизнеса. Таким образом, основной задачей при разработке методологии стала унификация учетных принципов с учетом разработанной финансовой структуры группы и особенностей процессов. Привлеченный консультант помог разработать финансовую структуру группы, единую управленческую учетную политику и методику планирования, четко определив ответственных за те или иные показатели и установив единые правила формирования показателей по всем направлениям бизнеса группы.
Имея методологическую составляющую, можно приступать к описанию требований к функционалу системы, которую мы хотим получить. Методология должна работать, не так ли? На практике это не всегда оказывается очевидным, и многие проекты заканчиваются пачкой ненужных бумаг. Чтобы этого не произошло, следует подробно сформулировать полный перечень требований к будущей системе, включая необходимые аналитики, форматы вводных документов, отчетов и правила расчета показателей, ожидаемое количество документов, число одновременно работающих в системе пользователей и т. д.
Выбор программного продукта и настройка
Теперь, когда у компании имеются сформулированные требования к будущей системе, она может приступить к осознанному выбору программного продукта для настройки системы. Поскольку на рынке присутствует довольно большое число компаний, занимающихся продажей и внедрением различных программных продуктов, обладающих разными характеристиками, имеет смысл сравнить несколько предлагаемых решений, чтобы оценить их преимущества и недостатки. На практике, выбор системы далеко не всегда происходит в процессе полноценного тендера, как правило, это характерно для государственных и крупных частных компаний. В других случаях компания может обратиться к консультантам либо провести исследование рынка программных продуктов своими силами (например, с привлечением специалистов ИТ службы). На российском рынке довольно высока популярность программных продуктов, совместимых с продуктами 1С, не в последнюю очередь в силу популярности 1С как программного обеспечения для ведения бухгалтерского учета.
Однако правильно выбранного программного продукта – это далеко не все, как бы производитель его ни описывал. В моей практике случаи, когда приобретенную программу было достаточно развернуть на компьютерах и без донастройки, а часто и без более или менее глубокой доработки под специфические нужды компании, не встречались. Настройку и последующую поддержку программного обеспечения компания может осуществлять своими силами, или же доверить эти задачи сторонним консультантам. В любом случае, специалисты, которые будут осуществлять настройку и/или доработку, оценивают способы, которыми можно реализовать систему с учетом требований компании и функциональных возможностей программного продукта. В результате появляются технический проект системы и техническое задание на настройку и/или доработку программы – документы, на основе которых будет осуществляться настройка системы.
Как было сказано выше, настройку и/или доработку программы компания может осуществлять своими силами, а может обратиться к консультантам, или же комбинировать эти способы, например, привлекая консультантов только для решения отдельных задач. Разумеется, для любого выбранного пути нужно выделить бюджет и оценить возможные связанные с этим риски.
Пример
Рассмотренная выше группа компаний самостоятельно внедряла единую систему бухгалтерского и управленческого учета в течение нескольких лет. Однако в силу того, что исторически компании группы рассматривались собственником как самостоятельные бизнесы, ИТ служба, в отсутствие определенных полномочий по управлению таким проектом, была вынуждена откликаться на частные запросы отдельных подразделений. Таким образом, долгое время в группе отсутствовал владелец системы и единый контрольный центр. Ситуация начала выправляться после приглашения стороннего консультанта, который решил задачу разработки финансовой структуры группы, единой методологии бюджетирования и управленческого учета, а также донес до руководства группы важность формирования единого центра управления процессами бюджетирования и учета. Руководители отдельных бизнесов были заинтересованы в сохранении статус-кво, а к сотрудникам, которые предлагали какие-то нововведения собственник не прислушивался!