Сначала отчет, потом учет: почему автоматизация усложняет жизнь бизнесу

В данной статье хочу поделиться видением, как уменьшить сложности при внедрении информационных систем и автоматизации процессов жизненного цикла компаний (продажа товаров/услуг, комплексное исполнение проектов).

Как не надо делать, или типовой сценарий развития цифровизации

В малом и среднем бизнесе (МСБ) регламентированный учет чаще всего ведется в 1С Бухгалтерия, а управленческий зачастую обходится Excel-файлами.

Компания развивается, деятельность и организационная структура усложняется. Финансовый и оперативный блоки начинают прирастать в части автоматизации. Первыми обычно стартуют финансы, при полной поддержке руководства – ведь это обязательная задача для любого бизнеса. Однако парадокс заключается в том, что потребности финансистов – не главные. Основные пользователи отчетности – операционные менеджеры и линейный персонал, которым придется вносить новые данные в систему. Если пользователи не увидят для себя пользы в этом процессе, они будут его саботировать.

Итак, финансы лидируют, формируя управленческую отчетность, определяя планы автоматизации, в том числе, регламентируя операционные процессы таким образом, чтобы свою отчетность собирать. Таким образом, часто данные оперативной деятельности дублируются в информационной системе (ИС), архитектура которой разрабатывается финансистами, потому что линейные сотрудники продолжают вести свои файлы учета.

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

Параллельно накапливается критическая масса недовольства операционного блока от двойного занесения данных, оперативного информационного вакуума, а также непонимания механизмов формирования финансовых показателей. Появляются инициаторы изменений в операционных подразделениях, которые толкают процесс вперед уже со своей стороны. Начинает развиваться цифровизация оперативной деятельности – запускается активное внедрение ERP, CRM, BI. Если это первая попытка, то до конца она доходит редко и практически никогда не приносит облегчения сотрудникам, а совсем наоборот: всех только раздражает необходимость заполнять новые формочки. Народ начинает халтурить, неполные данные обесцениваются, и эта работа становится совсем бессмысленной.

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

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

Пример создания отчета для операционной деятельности

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

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

1. Объем контрактации:

  • Факт-объем подписанных договоров: размещенных в системе заказов.
  • План-факт – сравнение с бюджетом.
  • План – краткосрочное прогнозирование в будущих периодах.

2. Дебиторская задолженность:

  • Факт – ожидаемое поступление денежных средств по подписанным договорам.
  • План – прогноз денежного потока в будущих периодах.

3. Выручка (реализация):

  • Факт – отгруженная продукция-реализация.
  • План-факт – состояние обеспечения текущих заказов.
  • План – ожидаемое обеспечение текущих заказов.

4. Маржинальность

  • Факт – по отгруженной продукции (по выручке).
  • План-факт – сравнение с бюджетом.

Неплохо бы еще иметь аналитику в разрезе клиентов и продающих подразделений, если оно не одно, а также по продающему сотруднику. В компаниях с широким номенклатурным рядом желательно добавить аналитику по продуктовому направлению.

Вопросы для самопроверки отчетности в ИС:

  • Можете ли вы собрать все данные, описанные выше, в своих ИС?
  • Есть ли системы, которые могут это собирать?
  • Понимаете, в каких документах должны быть данные, чтобы формировались отчеты?
  • Есть ли понимание, как наращивать и усложнять ИС, чтобы увеличивать объем автоматически собираемых показателей?
  • Как консолидировать данные из разных цифровых инструментов, которыми пользуются разные подразделения?
  • Какая аналитика должна сквозным образом проходить по цепочке продажи?
  • Как должны выглядеть финальные отчеты?

Вопросов много – вывод один: сначала придумать отчетность, потом внедрить и автоматизировать учет. И уже для этого завести полезную систему – ERP, CRM или обе сразу. Или доработать имеющуюся. По-другому никак.

Идеальный план развития ИС

  1. Выявить ключевые бизнес-процессы (БП) и главных пользователей отчетов по ним. Нарисовать формы отчетов. Главными пользователями будут не только финансисты, но и операционные руководители: отдел продаж, маркетинг, производство – все, кто связан с данными. Нужно понимать, что не все смогут сразу сказать, какие отчеты им нужны, для решения таких задач нужны навыки и управленческий кругозор. Поэтому составляйте формы отчетности с заделом на будущее, на последующую автоматизацию. Лучше всего поручить эту задачу руководителям верхнего уровня. Стоит обсудить и дополнить проекты отчетов с самыми продвинутыми линейными пользователями, чтобы всем было максимально полезно, а финальную версию утвердить у генерального директора.
  2. Определить сотрудников или структуру (проектный комитет или специальный департамент), которые будут отвечать за планирование, координацию и реализацию развития информационных систем компании. Важно предоставить им административные и финансовые ресурсы.
  3. Определить исполнителей работ по автоматизации. Базовое техническое задание (ТЗ) и простейший KPI для исполнителей – это разработанные формы отчетов, которые внедряемая система должна создавать на выходе.
  4. Запланировать и провести обучение пользователей всех уровней. Чтобы усилия, вложенные в автоматизацию, не пошли прахом, нужно сделать внедренный инструмент максимально удобным, а цели его использования максимально понятными. Особенно важно показать пользователям – как формируются данные и попадают в отчеты, чтобы все видели объективную оценку, хорошо работает система или нет.

Выводы

Прозрачная отчетность – основа качественного управления, без которого компания не может расти. Это не единственное условие для быстрого роста, но точно необходимое. Не будет прозрачной отчетности, не будет и масштабирования. Быстрая и эффективная цифровизация процессов вам в помощь!

Также читайте:

Расскажите коллегам:
Комментарии

На мой взгляд, ключ к тому, чтобы отчетность перестала быть «посмертной», лежит не только в формах отчетов, но и в жестком регламенте внесения документов и ежедневном закрытии периода в 1С:ERP / 1С:КА: кто, что и до какого времени обязан провести, какие статусы должны быть у заказов, отгрузок, платежей и производственных операций.

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

Евгений Равич пишет:
Ольга Сырышева пишет:
Евгений Равич пишет:

Пока сомнения остаются.

Исполнитель - внутренний или внешний - отчёты не читает, результатами пользоваться не будет, давать задания руководителям департаментов не может. Хуже, что он не может самостоятельно накопить для них данные и протестировать правильность.

Отсылка к кому-то всесильному и всезнающему. Еще менее понятна идея "последующей автоматизации".

Обычно, по крайней мере, в компании среднего размера, отдел IT, администрирующий, расширяющий и эксплуатирующий существующую корпоративную систему, разрабатывает и добавляет отчеты по мере необходимости и возможности - с учетом доступности соответствующих данных и производительности системы. И это только часть списка плановых задач, связанных с развитием и поддержанием системы в рабочем состоянии.

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

Проверим, с чего мы начинаем. Пользователи обсуждаемой системы имеют доступ к каким-то её частям и функционалу. Но они эту систему не проектировали, не развивают и не поддерживают.

Тут то как раз и необходимо надфункциональное управление автоматизацией сквозных процессов с пониманием ценности и стоимости внесения и необходимости использования. То есть предварительное проектирование отчетности по процессам- что есть предмет данной статьи.

Это стандартные шаги при внедрении любой  корпоративной системы. Начиная с формулирования требований и проектирования на их основе.

"Предварительное проектирование" и есть проектирование. Отчеты - часть результатов работы будущей системы.

Я согласен с вами, Евгений. Одна из частых причин неудовлетворенности внедрением (да и разработкой) в недостаточном обследовании. Особенно часто это возникает  при внутреней разработке. ИТ-отдел, разрабатывающий систему, обычно ставится на вторичное место после ряда таких вспомогательных служб ("Делай, что бухгалтерия скажет"). 

Внешний разработчик к предварительному обследованию относится серьёзнее, понимая, что ему же и влетит, если что. Но у него другая особенность: уж сильно лезть на рожон против заказчика он не будет.

Мне кажетсмя, что у Ольги именно такой случай произошёл. Явно не хватает аналитических отчетов, более гибких отчетов. Ну кто из управленцев смотрит в бухгалтерский баланс? Ну максимум - в дебиторскую задолженность.

Так что понимаю Ольгу прекрасно.

Игорь Мандрин пишет:
Борис Кондрабаев пишет:

Отличная статья о реальности многих компаний по использованию ИИ-1.

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

Самое примечательное для меня, что Ольга ставит концептуальные вопросы прежде вопросов локальных улучшений. Это безусловный прогресс!

Самый главный вопрос даже после успешных внедрений рекомендаций Ольги будут ли договариваться между собой финансисты, инженеры, продажники и операционные менеджеры производств?

Сейчас на первом месте стоят финансисты и чисто по человеческим качествам и сформированным привычкам и убеждениям захотят ли они действовать "под дудку" инженеров или продажников и т.п.?

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

То есть в тех компаниях, где руководство действовало по такой схеме может банально не оказаться нужных компетенций для изменеий.

По старому действовать могут, а по новому не умеют и поэтому не хотят. Это же является и одним из признаков и причин революционных ситуаций!

Поэтому, прежде чем делать новые ИТ проекты лучше договориться об общем новом понимании ситуации и готовности учиться действовать по новому, в том числе и сообща!

Феодальный принцип разделения сфер влияния и не вмешательства в дела "своих соседей" сейчас может очень мешать развитию организаций, проектов и продуктов.

Разработка концепций развития организаций и блок-схем составляющих организацию должна лежать в начале, а не после окончания ИТ-проекта, как это принято сейчас!

Если "телегу запрягают перед головой лошади", то это ведет к тому что "бардак на входе увеличивает бардак на выходе"!

 

Все так и есть, причем чем больше компания, тем более выражена эта проблема, так как возникает классическая проблема империй внутри империи: каждый строит свою, ограждаясь от соседей, но часто финансисты в этой борьбе выигрывают. Мы внедряем уже вторую, а проектируем четвертую ERP, но каждый раз выходит ТЗ на 1С:Бухгалтерию. Внедряем, конечно же, с названием ERP.

Понимание ситуаций, особенно ее проблематики может, если развернуть это на 180 градусов указывать на идеальные решения!

Как правило идеальные, чаще бывают не реализуемы по разным причинам на практике.

А вот решения, скажем под углом 120 градусов или хотя бы 60 градусов могут сильно облегчать и улучшать ситуации.

Это я к тому, что область подходящих решений может иметь огромный размер и количество! 

Здесь главное подобрать что из этого окажется подходящим для конкретных исполнителей по их компетенциям и мотивации.

Меня впечатляет и восхищает то, какие огромные возможности лежат в области коллективных взаимодействий, особенно когда "все начинают понимать, что находятся в одной лодке"!

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

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

Это сложившаяся культура с которой бороться бесполезно, да и не нужно!

Можно просто рядом со сложившейся культурой начать формировать новые "привычки", которые со временем могут сложиться в новую культуру.

На мой взгляд похожим образом действовал Генри Форд и Тойити Оно.

 

Анатолий Курочкин пишет:
Я согласен с вами, Евгений. Одна из частых причин неудовлетворенности внедрением (да и разработкой) в недостаточном обследовании. Особенно часто это возникает  при внутреней разработке. ИТ-отдел, разрабатывающий систему, обычно ставится на вторичное место после ряда таких вспомогательных служб ("Делай, что бухгалтерия скажет"). 

Внешний разработчик к предварительному обследованию относится серьёзнее, понимая, что ему же и влетит, если что. Но у него другая особенность: уж сильно лезть на рожон против заказчика он не будет.

Конечно.

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

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

1 2 4
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Половина россиян верит в финансовые приметы

Наиболее распространенными оказались приметы, связанные с обращением с деньгами.

5 профессий с самым высоким риском выгорания

Список возглавили – HR-специалисты.