Примеры внедрения узконаправленных инструментов анализа данных и подготовки отчетов

Меня зовут Николай Пикалёв. Я технический директор в ИТ-компании «КорТех». Занимаюсь 1С-разработкой более 20 лет. Сейчас занимаюсь как внедрением типовых, так и разработкой собственных решений различной направленности на платформе 1С.

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

• сбор факта для бюджетирования;

• формирование управленческой консолидированной отчетности.

Существующие распространенные подходы

Обычно данные задачи решают двумя способами:

• С помощью использования Excel или подобных ему инструментов. В этом случае мы максимально отдаем все на откуп пользователю. Он сам разберется и все, что нужно, сделает.

• Второй способ обычно используется в крупных проектах – мы выбираем под необходимые задачи готовое решение, настраиваем, где-то его дорабатываем, и получаем максимально автоматизированный инструмент.

Казалось бы, все здорово. Но в обоих подходах есть серьезные минусы.

Если мы идем по пути “все автоматизируем”, то это приводит к организации полноценного проекта, который подразумевает:

• Большую команду внедрения с большим числом сотрудников как со стороны исполнителя, так и со стороны заказчика;

• Длительный процесс реализации и сложную этапность, начиная с анализа и заканчивая внедрением.

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

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

Второй путь – это Excel. Казалось бы, все здорово:

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

• он чувствует себя нужным человеком, который занимается нужной задачей.

Но для его коллег и для бизнеса в целом все не так здорово:

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

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

Ситуация многократно усложняется, если в рамках данного похода внедряется система класса BI.

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

• С другой стороны, на основе этих исходных данных, различные финансисты и экономисты строят различные модели в BI-системе, и данный процесс выполняется принципу подобному Excel. Опять же, владельцем этого процесса является конкретный пользователь, что совсем не здорово.

«Золотая середина», с моей точки зрения, заключается в следующем:

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

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

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

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

На реальных жизненных примерах из личного опыта я хотел показать, как это может выглядеть.

1-й пример: Формирование консолидированного PnL

Первый пример – формирование консолидированного PnL.

История:

• Середина декабря. У крупной группы компаний возникает проблема – до конца года им нужно разработать автоматизированные инструменты формирования консолидированной отчетности.

• Все компании группы работают в 1С:Бухгалтерии, но у всех компаний разная деятельность, разные настройки в 1С:Бухгалтерии: у кого-то доработки, в том числе, на плане счетов и т.д. и т.п. Компании крупные, в том числе, производственные.

• Отчетность представлена в Excel, никаких прописанных методик нет. Как я говорил, когда отчетность формируется в Excel, компания зависит от конкретного человека, который эту отчетность до сих пор формировал вручную и уже отдавал в консолидированном виде. Методику формирования знает только конкретный человек, причем отдельно свой для каждой из организаций.

• Заказчик находит несколько подрядчиков, в том числе нас, и разбивает задачу на несколько по разным формам отчетности. Нам досталось формирование PnL. Мы посмотрели, у нас условно две недели до срока выполнения. Поняли, что в эти сроки мы сможем максимум их проинтервьюировать, но более ничего сделать не получится.

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

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

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

• Левый список – это учетные разделы, откуда нужно получать данные для PnL.

• Когда пользователь выбирает один из учетных разделов, во втором списке ему показываются данные, которые ему нужно отнести в консолидированный PnL. Причем данные показываются в древовидной структуре от верхних аналитик до более детальных.
  Ключевое: данные показываются с суммами – пользователь выбирает не какую-то абстрактную статью, а он видит суммы, какими он оперирует, данные для него становится более понятными.

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

• В третьем списке у нас также выводятся суммы, которые перенесены – пользователь сразу видит, что ему осталось еще реклассифицировать, а что уже реклассифицировано.

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

Мы реализовали решение и вовремя передали его заказчику:

• На анализ и разработку концепции у нас ушло 2 дня.

• И 4 дня – на разработку, которую выполняло два человека: функциональный архитектор и программист.

• Мы написали краткую инструкцию на полстраницы и вместе с обработкой по почте всем разослали. Даже обучения никакого не проводили.

• Далее месяц опытной эксплуатации, в рамках которой потребовались лишь небольшие доработки для исправления мелких ошибок.

Реакция пользователей:

• «Наконец-то программисты сделали то, что нам нужно. Мы никогда такого не видели».

• Вопросов не возникало даже без обучения.

• Все настройки выполнили пользователи самостоятельно.

Бизнес получил в нужный ему срок хороший инструмент, который позволит не зависеть от конкретного сотрудника – аналитики и аудиторы могут его проверить. Все замечательно.

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

2-й пример: Инструмент формирования бухгалтерских производственных документов на основании управленческих данных

Исходная задача:

• Небольшая производственная компания, управленческий учет ведется в 1С:ERP, бухгалтерский – в 1С:Бухгалтерии.

• По итогам операционной деятельности в ERP нужно автоматизировать формирование в БП бухгалтерских документов по выпуску продукции.

• Причем выдвигались требования не просто загрузить документы, а сформировать их с точки зрения оптимизации налогообложения, т.е. совсем не «один в один».

• Все это осложнялось тем, что справочники Номенклатуры в базах ERP и БП были разные. По готовой продукции в ERP учет велся более детально, а бухгалтера такую детальность не хотели. Сырье тоже разное, в т.ч. по причине различия справочников.

• Причем сырье и по остаткам разное – это опять же к вопросу оптимизации налогообложения.

Достаточно сложная и большая задача.

Большинство автоматизаторов, решая данную задачу, разработали бы множество разных инструментов:

• Инструмент сопоставления номенклатуры.

• Хранение настроек выпуска продукции – что-нибудь наподобие справочника спецификаций.

• Множество инструментов для формирования документов выпуска..

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

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

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

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

Внешний вид этого АРМ показан на слайде – здесь множество закладок, показывающих:

• данные по сырью по разным разделам;

• данные по выпуску, которые система предлагает ему сделать,

• данные уже по записанным документам и т.д.

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

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

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

• 1 месяц анализа, подготовки концепции и согласования;

• 4 месяца разработки;

• потребовалось короткое обучение;

• 3 месяца опытной эксплуатации до расчета фин. результата за квартал;

• 3 человека: функциональный архитектор, аналитик и программист высокой квалификации. Задача с точки зрения программирования достаточно трудоемкая, т.к. требует автоматизированного формирования данных с учетом оптимизации налогообложения.

Что реализация этой задачи дала для пользователей:

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

• Прозрачность процесса и данных позволила пользователям и контролирующим лицам быть уверенным в результате.

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

Инструмент используется уже более трех лет.

3-й пример: «Калькулятор» расчета управленческой себестоимости

Исходная задача:

• Небольшая производственная компания.

• Множество самописных систем на 1С – для автоматизации управленческого учета, бюджетирования, производственного планирования и учета.

• Бухгалтерский учет ведется в типовой 1С:Бухгалтерии.

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

• Проект осложняется тем, что отсутствует взаимопонимание между подразделениями компании. Такое встречается часто. В чем это выражается? Владелец ищет пути оптимизации и увеличения прибыли, финансисты и экономисты рассчитывают, какие продукты производить выгоднее. Дают эту информацию коммерсантам и производству, которые отвечают: «Да вы неправильно посчитали! Как у вас так получилось?» А проверить и проконтролировать невозможно, расчет в Excel очень непрозрачен. Поэтому споры есть, а результата нет.

Задачей проекта было избавиться от Excel и предложить для калькуляции себестоимости достойную альтернативу.

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

Поэтому мы добавили отдельный справочник «Оценки себестоимости», каждый элемент которого содержит все необходимые для оценки данные:

• исходные данные по различным разделам (видам расходов);

• настройки по распределению затрат;

• настройки по классификации продукции и пр.

Исходные данные по каждому разделу загружаются из смежных систем по нажатию кнопки и могут корректироваться пользователем.

На слайде показано, как выглядит карточка элемента справочника «Оценка себестоимости» – фактически это тоже единый АРМ.

Здесь много закладок по каждому из разделов:

• перечень выпускаемой продукции, которую мы планируем выпустить за период;

• сырье и материалы;

• прямые затраты субподрядчиков на выпуск;

• общехозяйственные затраты;

• общепроизводственные затраты и т.д.

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

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

Настроек много.

Для выполнения этой задачи нам потребовалось:

• 3 месяца анализа, подготовки концепции, разработки методологии;

• 3 месяца разработки;

• обучение в виде краткой инструкции;

• 3 месяца опытной эксплуатации;

• 4 человека: функциональный архитектор, методолог, программист с высокой квалификацией и младший программист.

Результат для бизнеса.

• Выявлены нерентабельные продукты и направления.

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

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

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

Организация и эффект

Что же отличает приведенные примеры от стандартных?

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

• Нужно понимать, что заказчик никогда не скажет, что ему конкретно нужно. Это происходит по причине того, что пользователь не знает возможности автоматизации. Проще нам разобраться в предметной области, чем заказчику изучить возможности автоматизации. Второе в принципе некорректно. Заказчики приходят к нам для решения какой-то проблемы, а мы должны показать возможные пути для ее решения.

• Не надо бояться разрабатывать решения с нуля. Зачастую это гораздо проще, чем пытаться доработать какое-то типовое и универсальное.

• Не надо пытаться разрабатывать универсальное решение. Программисты очень любят универсальность, их нужно в этом останавливать. Решаем конкретную задачу конкретного заказчика. А потом, может быть, уже думаем об универсальности.

Сравнение эффекта при внедрении подобных инструментов и типовых подходов:

• левый столбик – это подход с разработкой индивидуальных решений;

• правый – классические подходы внедрения универсальных решений.

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

Один из важных результатов – сильно снижаются расходы на сопровождение.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART Анализ & Управление в ИТ-проектах.