Автоматизация управленческого учета

234

Когда начинать, или Диагностика проблемы

Практика показывает, что при внедрении учетных систем лишь немногие остались довольны результатами. Потому что практически все потратили на внедрение намного больше времени и средств, чем планировали, а получили значительно меньше, чем оплатили. И об этом, как правило, публично не пишут и не говорят. Поэтому хотелось бы рассмотреть несколько основных вопросов, которые помогут критически оценить все, что вы как финансисты знаете или думаете о внедрении систем. Затем сделать выводы. И, наконец, провести следующее внедрение менее затратно и более результативно.

Вы как специалисты по управленческому учету живете в прошлом веке, если:

  • не имеете программного обеспечения, позволяющего анализировать, сравнивать, реклассифицировать ваши учетные данные;
  • руками перекладываете список статей из плана счетов в MS Excel, а потом из MS Excel – в бюджетную программу;
  • руками (своими или программиста) прописываете отчеты, которые использовались вами более одного раза;
  • на вопросы руководства, во сколько нам обходится производство полуфабриката X или на сколько увеличились продажи продукта Y за последние три года, или сколько мы уже потратили на проект Z и имеет ли смысл его прекратить, вы не можете ответить сразу или, по крайней мере, в течение часа;
  • при возрастающем объеме учетных данных нанимаете все больше и больше специалистов для их обработки.

Приведем один характерный пример. Российская компания – ритейлер одежды ведет управленческий учет в MS Excel. Когда магазинов было не так много, бюджет составлялся по каждой номенклатурной позиции и каждому магазину. С ростом бизнеса объемы данных в таблицах MS Excel стало обрабатывать невозможно. Но, тем не менее, решили продолжить использовать MS Excel и составлять укрупненный бюджет только по брендам и регионам. Планы по номенклатурным позициям не составлять, план-фактный анализ прибыльности каждого магазина опустить. С нововведениями MS Excel ожил, но исчезли анализ планируемой и фактической прибыльности каждого магазина и Like-for-like анализ (сопоставимые продажи), которые критически важны в ритейле. Потери от такого компромисса сразу увидеть в цифрах трудно, но спрогнозировать в ближайшем будущем вполне возможно.

А альтернатива? Почему бы не развернуть современную систему планирования и анализа, которая способна обрабатывать необходимый объем данных и дает массу других преимуществ, например, позволяет осуществлять сквозное планирование с участием менеджеров на местах, мгновенный перерасчет и консолидацию планов, обновление фактических данных так часто, как это необходимо, и т.д.


Ключевой совет

Чтобы начать автоматизацию, не надо ждать возникновения трудно решаемых проблем или снижения прибыли.


Как убедить руководство, или Волшебство ROI

Просто так, «на игрушки», руководство средства не выделит, особенно если кроме эмоций никаких других доводов не окажется. Поэтому убедительно и доказательно продемонстрировать выгоды от внедрения новой системы – приоритетная задача. Для этого лучше использовать подход, который основан на расчете ROI (Return on Investment) – возврат средств на инвестиции. Но расчет ROI и бухгалтерское оформление проекта по внедрению – это не одно и то же. Не стоит увлекаться уточнением сроков постановки основных средств на учет, так же как и прогнозированием курсовых разниц и отложенных налогов. Ваш расчет – это в первую очередь оценка выгодности проекта, которая необходима для принятия решения и расстановки основных реперных точек по ходу проекта. Не увлекайтесь ненужной работой. В дополнение к расчету ROI можно привести примеры успешного опыта прошлых внедрений.

Затраты на автоматизацию (I в ROI). Рассмотрим, какие инвестиции могут потребоваться при двух наиболее часто встречающихся в наши дни видах автоматизации: традиционном серверном внедрении и внедрении в облаке (см. табл. 9.1 на стр. 147). Мы намеренно не будем разделять расходы на капитальные вложения и операционные затраты, поскольку в облаке эта граница пока достаточно условна.

Прочие затраты зависят от внутреннего распорядка на предприя тии, традиций, отрасли и индивидуальных предпочтений руководства. Они могут включать, например, организационные и мотивационные встречи участников проекта; участие в конференциях производителя программного обеспечения; затраты на подбор персонала и т.д.

Кроме того, существует понятие общей стоимости владения – TCO (Total Cost of Ownership). Оно включает перечисленные затраты на приобретение и внедрение и постоянные затраты на обслуживание и поддержку. Универсальной формулы расчета TCO не существует, поскольку многое зависит от индивидуальных факторов. Но задача удешевления общей стоимости владения ИТ-решением должна быть поставлена в самом начале проекта по автоматизации и отслеживаться на всех этапах существования решения. Однако на практике зачастую происходит иначе: если в начале внедрения задача удешевления озвучивается и даже проводятся расчеты, то на третьем – пятом годах работы системы внимание к ней ослабевает. И напрасно. Стоимость поддержки устаревающих систем со временем может возрастать, а не уменьшаться. Приведу для примера известную ситуацию с Y2K – эффектом 2000 года. России она коснулась мало, но в Америке, например, компании потратили заоблачные суммы на аудит и перепрограммирование устаревших программ: они просто могли прекратить функционировать в связи с обнулением года, который на заре автоматизации часто обозначался всего двумя циф рами.

Возврат средств, вложенных в автоматизацию (R в ROI). Вариантов возврата средств, вложенных в автоматизацию, может быть много. Приведем несколько примеров полезных эффектов, чтобы задать направление в построении модели расчетов.

1. Сокращение трудозатрат. Этот пункт обязательно должен присутствовать в расчетах, иначе автоматизация бессмысленна. Даже если сокращение персонала не планируется, новая информационная система обязана перераспределить баланс времени сотрудников в пользу более производительных задач. Например, внедрение программного обеспечения для планирования и анализа освобождает 50, а иногда и все 90 процентов времени сотрудников от ручного труда по сбору, перемещению и консолидации данных, что позволяет перераспределить это время на задачи, связанные с анализом корпоративных данных, поиском закономерностей и подготовкой предложений руководству.

2. Оптимизация рабочего времени руководителей. Например, административный директор крупной компании ежедневно тратил около двух часов на одобрение заказов транспортных средств. Для этого в программе открывалась соответствующая форма и нажималась кнопка. Когда его спросили, был ли хотя бы один случай, когда он отказал в заказе, он честно ответил, что таких случаев не было. Кнопку автоматизировали, заказы стали одобряться системой автоматически, а директор получил примерно 2  5  4 = 40 дополнительных часов в месяц на решение более важных проблем. Фактически это равноценно возврату ранее бесполезно расходовавшейся недельной заработной платы руководителя плюс все его льготы и выплаты в социальные фонды.

3. Сокращение рисков использования ошибочной информации. Систематически проводимые исследования показывают, что около 90 процентов моделей в MS Excel содержат ошибки. Эти ошибки увеличивают риски потерь, начиная от незначительных в виде штрафов и пеней от неправильно рассчитанной амортизации до катастрофических. Вероятные потери от ошибочной информации в финансовом отчете или в прогнозе движения денежных средств можно оценить.

4. Сокращение рисков бизнеса в связи со ставшей доступной дополнительной информацией. Если новая система дает возможность получать более глубокую аналитику, и при этом повышается качество и достоверность данных, многие риски, которые раньше отработать было невозможно, становятся регулируемыми.

5. Сокращение затрат на внешний аудит и на приведение бизнеса в соответствие с требованиями регуляторов.

6. Сокращение затрат на администрирование и обновление устаревших систем и технологий.

7. Прекращение действия лицензий и поддержки заменяемой технологии (если она была) и т.д.


Ключевой совет

Внимательно проанализируйте этапы и проблемы процесса – и найдутся многие монетизируемые доказательства необходимости внедрения современной информационной системы.


И в заключение о ROI. При составлении оценочных расчетов полезно объединить усилия с ИТ-директором, который, вероятно, уже неоднократно проводил подобные расчеты.

Как выбирать решение

К выбору программного продукта надо подходить серьезно и прагматично, так же как к выбору квартиры, в которой собираетесь жить. Вам точно не нужна квартира не по размеру, не по карману и не в том районе. Так же и информационная система. Сначала изучите рынок программного обеспечения, поймите разницу между облачными, традиционными серверными, коробочными и самостоятельно разработанными программами. Поинтересуйтесь у коллег, что, как и с помощью чего они автоматизировали, какие проблемы при этом решили и какие дополнительные опции получили. Расспросите консультантов, но с осторожностью. Системные интеграторы, как правило, имеют договоры с одним-двумя производителями программного обеспечения и другого не посоветуют. На рынке же зачастую выбор шире и вместо одного-двух успешно продаются и внедряются десяток и более хороших решений. Если с выбором определиться сложно – пригласите управленческих консультантов, специализирующихся на бизнес-процессах, потратьте небольшую сумму на проект по оценке ваших потребностей и выбору наиболее подходящего решения. Это многократно окупится позже.

Приведем несколько факторов, которые обязательно следует учесть при выборе программного решения.

1. Соответствие бизнес-процессам компании. Планирование, управленческий учет и составление отчетности, а также управление рисками и внутренний конт роль – процессы, как правило, динамичные, нестандартные, очень отличающиеся от предприятия к предприятию.

2. Соответствие смежным бизнес-процессам. Если вы автоматизируете планирование доходов и расходов, то стоит договориться с казначейством и сразу автоматизировать прогноз движения денежных средств и календарь платежей. Если планируете проводить сравнение плановых и фактических показателей в режиме реального времени – задумайтесь об интеграции с существующими системами учета.

3. Примерный объем данных, подлежащих обработке. Не все транз акционные системы справляются с десятками тысяч номенклатурных позиций или многоитерационными расчетами при распределении косвенных расходов.

4. Компетенции персонала. Всегда проще использовать существующие компетенции, чем научить новым. Это относится как к финансовым, так и к ИТ-специалистам.

5. Существующие системы и политики. Если стандартная база данных на вашем предприятии Oracle, то приобретение программного обес печения, которое работает только на SQL Server, потянет за собой дополнительные расходы.

6. Общая стоимость владения (TCO). Как уже говорилось, это не только стоимость серверов и лицензий, но еще и стоимость обновлений, поддержки, квалифицированного персонала. Не забудьте добавить оценку рисков.

Кому доверить работу

Универсальных рецептов и здесь нет. Можно сделать самим, прочитав инструкции. Можно нанять системного интегратора и поручить ему все и сразу, и «под ключ». И то, и другое – в какой-то степени крайности. При самостоятельной автоматизации решение обходится дешево, но часто страдает серьезными техническими недостатками и функциональной бедностью. При найме системного интегратора возникают иные не удобства: дорого, долго, конфликтно. Комментарии излишни, наверное, многие побывали в этой ситуации хотя бы раз и примерно представляют, что можно ожидать. Для непосвященных стоит отметить, что проекты автоматизации, выполненные в рамках первоначально заявленных бюджета, сроков и результатов, чрезвычайно редки.

Наиболее функциональна и производительна небольшая смешанная команда, состоящая из высококвалифицированного технического архитектора-консультанта, опытного руководителя проекта и исполнителей задач, работающих на проекте на полную ставку. Это может быть персонал, нанятый на рынке, позаимствованный у системных интеграторов или производителя программного обеспечения либо подготовленный из собственных кадров. Возможно, речь идет всего об одном человеке с весомым опытом и репутацией. Предвижу восклицания: где это вы такое видели?! Видела, часто, но, к сожалению, не в России. И не при наших привычных условиях ИТ-контрактов – «под ключ».

Так ли хороши проекты «под ключ»

Теперь немного подробнее об условиях. Существует два основных вида контрактного взаимодействия заказчика и исполнителя ИТ-услуг: это договор на условиях фиксированной цены «под ключ» и договор на условиях «время и командировочные расходы». Во всем мире преобладает второй. В России преобладает первый, так уж сложилось. Но для большинства ИТ-систем, а особенно для систем управленческого учета, планирования и анализа, условия «под ключ» губительны.  Просто потому, что «под ключ» такую систему возможно только установить (инсталлировать) и проверить, готова ли она технически к построению процессов, отчетов и расчетов. А вот моделирование и построение процессов в понятие «под ключ» укладывается с трудом. Причин тому множество. Во-первых, динамичность бизнеса и, соответственно, требований к управленческому учету, планированию и анализу лишает смысла попытки довести решение до окончательного результата. Любые требования, как правило, устаревают до момента сдачи системы. Поэтому при традиционном подходе «под ключ» слишком часто производятся работы по настройке уже ненужных процессов, проводок, отчетов, а критически нужные работы не проводятся или проводятся за дополнительную плату. Во-вторых, при переходе на современную информационную систему открывается масса возможностей, о которых на момент описания требований заказчику ничего не было известно. Понятно, что при более подробном знакомстве с системой очень часто возникает необходимость отредактировать требования, чего фиксированный контракт не позволяет. И, в-третьих, в процессе построения решения по фиксированной цене и заказчик, и исполнитель часто манипулируют ценами, объемами и сроками работ, что неизбежно вызывает противоречия и конфликты.

Запад давно внедряет большинство систем на условиях «время плюс расходы». При таком подходе работы оцениваются точнее, так как риски распределяются более равномерно, заказчик и исполнитель нацелены на результат, становится возможной адаптация к изменениям, при этом минимизируются ненужные работы и резко снижается возможность манипулирования.

Наилучшим образом на практике работает следующий алгоритм внедрения программного обеспечения:

1) определение объема работ и требований к архитектуре решения, проектирование архитектуры;

2) инсталляция и техническое тестирование работоспособности программного обеспечения;

3) обучение администраторов и пользователей – сотрудников, которые будут работать вместе и наравне с консультантами;

4) анализ бизнес-процессов и технологических инструментов;

5) определение приоритетности внедрения процессов в системе;

6) построение прототипа первого процесса;

7) итеративное улучшение прототипа процесса до готовности к эксплуатации, его запуск;

8) повторение шагов 4–6 для каждого последующего процесса. На этом этапе можно поблагодарить консультантов за работу и продолжать проект самостоятельно;

9) составление инструкций в соответствии с готовым решением.

Естественно, такой подход уместен только на условиях договора «время плюс расходы». И только при таком подходе возможно создание функциональных работающих решений за месяцы или даже за недели.

Сколько времени потратить на проект

Работающие системы внедряются быстро. Поэтому при выборе не стоит рассматривать предложения, которые предполагают год или более до запуска в эксплуатацию первого этапа системы (модуля, приложения, процесса). Любое решение, внедряемое более одного года, неэффективно и устаревает уже к моменту запуска. Транзакционную (учетную) систему надо запустить за восемь-девять месяцев. Предложение о внедрении аналитической системы, рассчитанное на срок более шести месяцев, должно насторожить. Лучшие проекты по автоматизации планирования и анализа занимают не более двух-трех месяцев.

Методологии внедрения

Большинство финансистов, вероятно, знакомы с каскадной методологией (waterfall development) создания систем. Ее принцип – строго последовательный переход от одной фазы разработки к другой, подразумевает, что следующая фаза начинается только при условии успешного завершения предыдущей, – широко известен и хорошо отработан в договорах с системными интеграторами. Каскадная методология предполагает, что до начала программирования или конфигурации процесса должна существовать исчерпывающая документация; что проектирование системы должно быть завершено до ее реализации; что тестировать нужно только готовую систему. Она также предусматривает строгий порядок поэтапной сдачи системы заказчику и проведения оплат. При этом формальности соблюдаются, но сроки, качество и стоимость проекта часто страдают.

Гибкая методология (agile development) предполагает быстрое создание, демонстрацию и утверждение прототипа процесса, а также, по мере необходимости, возврат к нему и его доработку по мере отлаживания следующих процессов. При этом подразумевается минимум документации, максимум взаимодействия между участниками проекта, адаптация системы к изменяющимся обстоятельствам и лучший индикатор прогресса – работающее программное обеспечение, удобное, гибкое и современное.

Сколько должно быть документации

Не существует статистически достоверной корреляции между качеством документации и ее объемом. Созданная до завершения проекта, она устаревает, прежде чем ею успевают воспользоваться. Документ объемом более 10–15 страниц никогда не прочитается целиком.

Исходя из этих посылов, легко расставить приоритеты по созданию документации, сопутствующей процессу внедрения:

  • минимум регламентов в начале проекта автоматизации. Диаграмма процесса на одном листе важнее, чем тысячи слов. Описание функционала будущей системы на двух-трех страницах вполне способно удержать всех участников проекта в рамках выбранного курса. Модель расчетов в Excel – это тоже полноценный документ;
  • разумный набор документов по окончании проекта автоматизации. Администраторы и пользователи должны иметь подсказки, особенно если в ходе внедрения они не научились работать с системой. Новым сотрудникам также требуются обучающие материалы. Но если документация не обновляется после каждого изменения системы – она скорее вредна, чем полезна.

Наличие образцовой документации совсем не свидетельствует о качестве проекта, чаще бывает наоборот. В одной компании при внедрении ERP-системы было создано четыре тома описания бизнес-процессов, каждый по 150–200 страниц. При этом потратили около года на исследование процессов и их оформление. Под каждым процессом стояла подпись ответственного сотрудника финансовой службы, удостоверяющая, что процесс описан правильно. Документация была завизирована руководством. При тестировании законченного решения пришло понимание, что с построенной системой работать нельзя, так как запрограммированные процессы не соответствуют требованиям бизнеса и правилам учета. После того как затраты на внедрение превысили 160 процентов от первоначальной стоимости контракта, с консультантами распрощались и доводили систему до рабочего состояния своими силами. Как такое могло произойти? К трем причинам, уже перечисленным в разделе «Так ли хороши проекты “под ключ”», добавим еще одну: излишняя опора на документацию и отстранение будущих пользователей системы от процесса ее создания, что обычно и происходит на проектах «под ключ». В приведенном примере финансисты, доложив на этапе первичного описания процессов о том, как они работают, дальше уже никак не участвовали в построении системы, а жестко зафиксированная документация и консультанты, действующие в отрыве от меняющихся реалий, оказались теми оковами, которые и привели к созданию неработающего решения.

Личный опыт подсказывает: существует обратно пропорциональная зависимость между объемом документации и успешностью проекта. Если на каком-либо проекте существуют килограммы и гигабайты документов, вероятность того, что проект провален, очень высока.

Строить ли на века

И еще один важный фактор, который всегда нужно иметь в виду, начиная проект по автоматизации. Любая технология предназначается для использования в течение какого-то конечного периода времени. Давайте трезво посмотрим на реальности мира ИТ. Информационные технологии кардинально обновляются в среднем каждые пять лет, в некоторых направлениях – еще чаще. Производители программного обеспечения постоянно совершенствуют свои продукты, выпуская новые версии каждые год-полтора. При этом каждая последующая версия лучше, функциональнее и производительнее предыдущей, а каждая вторая или третья версия включает новое технологическое решение.

Это значит, что приобретаемая сегодня автоматизированная система через год-два потребует обновления, а через пять-шесть лет неизбежно устареет. Следовательно, тратить два-три года на внедрение просто непозволительно. Но не внедрять такие системы тоже нельзя. Работая с устаревшими технологиями (включая и информационные), компании быстро теряют свои конкурентные преимущества, а вместе с ними клиентов, денежные средства и сотрудников. Значит, автоматизация управленческого учета, планирования, анализа и отчетности рано или поздно неизбежна. И когда это время наступает – имеет смысл внедрять быстро, качественно и результативно.

Таблица 9.1. Затраты на автоматизацию

Виды затрат

Серверное решение

Облачное решение

Оборудование (серверы)

Да

Нет (включено в подписку)

Программное обеспечение (серверные лицензии разработчиков и администраторов, пользовательские лицензии)

Да

Подписка на доступ для администраторов и пользователей

Программное обеспечение (другие лицензии, например, дополнительная лицензия на операционную систему или базу данных для нового сервера)

Да

Нет (включено в подписку)

Обучение

Да

Да

Консультационные услуги (анализ бизнес-процессов, настройка, программирование, загрузка данных, тестирование)

Да

Да

Трудозатраты постоянных сотрудников  (во время внедрения)

Да

Да

Ежегодное обновление лицензий

Да

Нет (включено в подписку)

Техническая поддержка

Да

Нет (включено в подписку)

Дополнительный персонал, нанятый на проект и/или администрирование системы

Как правило, да

Как правило, нет

Прочие затраты

Да

Да

Еще по теме

1. Уроки автоматизации финансовых функций: успехи и провалы («Финансовый директор» № 2, 2013).

2. Как расставить приоритеты при автоматизации финансовых функций: решения, проверенные в компаниях («Финансовый директор» № 12, 2010).

Методические рекомендации по управлению финансами компании



Ваша персональная подборка

    Подписка на статьи

    Чтобы не пропустить ни одной важной или интересной статьи, подпишитесь на рассылку. Это бесплатно.

    Рекомендации по теме

    Школа

    Школа

    Проверь свои знания и приобрети новые

    Записаться

    Самое выгодное предложение

    Самое выгодное предложение

    Воспользуйтесь самым выгодным предложением на подписку и станьте читателем уже сейчас

    Живое общение с редакцией

    А еще...




    © 2007–2017 ООО «Актион управление и финансы»

    «Финансовый директор» — практический журнал по управлению финансами компании

    Зарегистрировано Федеральной службой по надзору в сфере связи,
    информационных технологий и массовых коммуникаций (Роскомнадзор)
    Свидетельство о регистрации ПИ № ФС77-62253 от 03.07.2015;
    Политика обработки персональных данных
    Все права защищены. email: fd@fd.ru

    
    • Мы в соцсетях
    ×
    Чтобы скачать документ, зарегистрируйтесь на сайте!

    Это бесплатно и займет всего 1 минуту.

    У меня есть пароль
    напомнить
    Пароль отправлен на почту
    Ввести
    Я тут впервые
    И получить доступ на сайт Займет минуту!
    Введите эл. почту или логин
    Неверный логин или пароль
    Неверный пароль
    Введите пароль

    Внимание!
    Вы читаете профессиональную статью для финансиста.
    Зарегистрируйтесь на сайте и продолжите чтение!

    Это бесплатно и займет всего 1 минут.

    У меня есть пароль
    напомнить
    Пароль отправлен на почту
    Ввести
    Я тут впервые
    И получить доступ на сайт Займет минуту!
    Введите эл. почту или логин
    Неверный логин или пароль
    Неверный пароль
    Введите пароль