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