В предыдущих материалах мы обсуждали задачи финансового директора.
Отчеты с возможностью предоставления каждому пользователю только своих данных и трассировкой до первичной транзакции являются удобным и эффективным инструментом. Возникает вопрос – как внедрить подобную систему. У трех специалистов найдется пять ответов – и каждый (специалист) с жаром будет отстаивать свое.
Перед серией материалов стоит посмотреть доводы за и против, попытаться найти разумное зерно в каждой позиции.
- В качестве примера рассмотрим внедрение Оперативного PL – ежедневный отчет о прибылях и убытках в разрезе видов деятельности (БЕ). Включает бюджет/квоту, фактические и прогнозируемые данные. Основные фактические показатели суммарно по всем БЕ, в основном, совпадают с данными бухгалтерского учета. Возможно включение в «Оперативный PL» количественных и расчетных показателей – например, число «проданных табуреток» по видам продукции или выручка и расходы на одного покупателя (unit-экономика). Распределение по видам деятельности и дополнительная аналитика может отличаться от бухгалтерии.
- Ежедневное формирование такого рода отчета не должно требовать много ресурсов. В идеале подобная консолидация и объединение в один отчет плановых, прогнозируемых, количественных и расчетных показателей должно быть полностью автоматизировано.
- Внедренная система должна обладать устойчивостью и гибкостью. С одной стороны, добавление нового вида деятельности, изменение оргструктуры должно гибко поддерживаться соответствующими настройками. С другой – необходимо обеспечить непрерывность. Результаты прошедших и закрытых периодов не должны меняться со временем. Если продажи табуреток в марте 44 штуки и 250 тугриков. То и в апреле, и в сентябре и через 3 года отчет за прошедший март должен выдавать те же показатели с расшифровкой до первичного документа.
Тема 1. Можно ли ограничиться бухгалтерией?
А – Процентов 90 информации, необходимой для финансов, содержится в бухгалтерском учете. Руководителю нет нужды разбираться в различных видах учета. Бухгалтерия необходима и отвечает за первичные документы – пусть, и финансы базируются на 1С
Б – Оперативные финансы должны включать много информации, отсутствующей у бухгалтерии. Планы, прогнозы, количественные и расчетные показатели трудно, а иногда и невозможно вести в 1С. Наверное, поэтому крупные компании тратят огромные бюджеты для внедрения разных систем типа CRM и ERP
А – Последние версии 1С – «почти ERP». И функциональность «Управления предприятием» позволяет реализовать многое. А чего не хватает – на рынке полно разработчиков и компаний, которые в 1С смогут сделать все, что угодно
Б – Не стоит путать рекламные зазывалки и реальные возможности. То же ERP базируется на организации жесткой цепочки от планирования продаж до обеспечения ресурсов и контроля исполнения. Подобные требования сильно мешают оперативной работе бухгалтеров и вряд ли будут нормально реализованы в 1С в течение ближайших 5-7 лет. Специализированные доработки принесут множество проблем. Кто обеспечит перенос с одной версии на другую? Кто изменить настройки по видам деятельности? Кто обеспечит новые аналитические разрезы и новые KPI. Все такие задачи, особенно с учетом меняющейся специфики бизнеса, требует специалиста на месте. Нельзя просто купить и настроить систему, даже с учетом разовых дополнений. Нужно постоянно поддерживать процесс – адаптироваться к изменениям и новым требованиям.
Предлагаю подвести итог: Решение об IT-архитектуре для организации финансового и управленческого учета принимается на основе анализа конкретной ситуации. Желательно иметь в штате компании специалиста, хорошо понимающего бизнес процессы и способного настраивать и адаптировать систему. При наличии такого ресурса, позволяющего успешно решать задачи системной интеграции, можно разрабатывать и внедрять модульную распределенную информационную систему. Каждый участок, Бюджет, CRM, проектное управление, бухгалтерия может эффективно выполнять свои функции. Задача специалиста – консолидировать все данные и оперативно получать и предоставлять всем пользователям итоговую информацию.
Тема 2. Одна система или разные кусочки?
А – Мы уже набили себе шишки с зоопарком. Разные списки покупателей, контрактов, товаров. Данные, не согласующиеся друг с другом. Постоянная головная боль и поиск расхождений. Чему верить? Кто будет разбираться в чем дело и на что можно опереться? Пусть, уж, лучше все работают в одной системе – да, не идеал, но нет технических и технологических проблем и всегда можно «найти крайнего»
Б – Уважаемые пассажиры! Мы приветствуем вас на борту нашего самолета. На первом этаже вы можете посетить бар. На втором – бассейн и спортивный зал…. И со всеми такими наворотами мы постараемся взлететь..
Решение «все в одном» плохо, прежде всего, тем, что каждый участок реализован далеко не самым эффективным образом. Попытки навесить дополнительный функционал в стабильно работающую большую систему потенциально очень опасны. Известно, что, например, коррекция себестоимость под управленческие требования в простой ERP часто занимает несколько месяцев работы. И дальнейшая поддержка таких доворотов требует очень много сил и ресурсов. При этом большая часть функционала лежит мертвым грузом. Не случайно статистика дает крайне удурчающую картину вовлечения всех служб в единую систему. Каждому требуется свое и у каждого найдется серьезный довод против. Если система мне неудобна и мешает работать, то я теряю 10-15% продаж за счет дополнительной нагрузки. Спросите акционера – он готов мирится с такой существенной потерей доходов?
А – Так что же с разнобоем в данных и несоответствием результатов в различных системах?
Б – Проблема очень болезненна. Значительную часть расхождений можно решить, грамотно наладив репликацию данных – автоматический перенос из одной системы в другую, по возможности, сократив дублирование, отслеживание исправлений и удалений (очень помогает система posting). Однако, практика показывает, что технология далеко не всесильна. В таком случае дополнительно строится система «контроллинг» или внутреннего аудита. Конечно, это – дополнительные ресурсы, но грамотная постановка задачи и продуманная реализация поможет оптимизации.
Предлагаю подвести итог: Минусы одной системы значительны. При наличии квалифицированных ресурсов перспективнее системная интеграция. К тому же грамотная технология распределенной обработки позволяет не только адаптироваться под требования и пожелания различных структур, но и поможет навести порядок в понимании бизнес-процессов.
Тема 3. Работа on-line или ежедневный ETL?
А – Пользователи требуют, чтобы каждая транзакция в любой системе сразу же отражалась во всех видах учета и во всех отчетах. Никто не хочет ждать, когда все данные соберутся в единую шину и все отчеты посчитаются
Б – На практике часто такое требование излишне – вменяемым пользователям вполне можно объяснить. Только введенные данные часто не выверены – кто захочет перекосить свои результаты из-за того, что у операциониста дрогнула рука и транзакция не прошла полный цикл проверки. К тому же on-line работа приводит к чудесам. Две минуты назад был результат 100. А сейчас 90. Что изменилось за эти 2 минуты – сказать невозможно. Гораздо удобнее иметь стабильную картину в течение дня. Утром прошла полная технологическая проверка. Все отчеты сформированы. В течение дня итог 100 и все расшифровки дают тот же результат. Я уже не говорю, что сложные отчеты требуют значительных ресурсов. Смотреть 20 минут на песочные часы, пока сервер пересчитывает отчет раздражает – гораздо приятнее иметь результат через секунду – ведь, все посчитано в 5 утра и к началу рабочего дня сформирован репозитарий.
Предлагаю подвести итог: On-line работа нужна редко. На практике, пожалуй только в системах бронирования. В большинстве случаев гораздо эффективнее работа по данным на вчера вечер. На практике встречаются случаи неполного обновления репозитария несколько раз в день (не более 2-3) – обычно в части ожиданий и прогнозов.
