Как мы от работы без выходных и до двух ночи пришли к завершению отчётности в рабочее время.
О цели
Бухгалтеры не специалисты в эффективном обслуживании большого числа организаций всё меньшими силами. Скорее наоборот, они специалисты в неэффективном обслуживании одной организации всё большими силами. Они в этом не виноваты, их жизнь толкает. Бухгалтеров хвалят и ругают не за нарастание эффективности, а условно за правильный по версии того, кто ругает, выбор полей в документе (иногда выбор/не выбор вообще ни на что не влияет).
У нас на старте было ложное ожидание, что бухгалтеры помогут сделать процесс значительно эффективнее. Ожидание было ни на чём не основано. Как теперь понятно, это всё равно, что ждать от водителя создания более совершенного автомобиля. Водитель не специалист в конструировании, а бухгалтер не специалист в создании эффективных процессов и поддерживающих их it-решений.
Стало понятно, что user centered design для нашей ситуации плохо подходит, я про это отдельно писал несколько раз. И возникла цель — научить разработчиков бухгалтерии, а бухгалтеров конструированию эффективных процессов и автоматизации. Чтобы все заговорили на одном языке. Это сильно усложнялось необходимостью продолжать обслуживать уже набранную базу в созданной за годы не слишком эффективной схеме. К тому же, сильно завязанной на закреплённого за организацией бухгалтера. У нас не было лишних денег, лишних разработчиков и лишних бухгалтеров. Этот корабль плыл, протекал, ломался и чинить его мы могли только на ходу.
Метод познания
А как научить разработчиков бухгалтерии? Этому люди учатся сначала 4 года в вузе, а потом несколько лет на практике. Тоже самое и с обучением бухгалтеров технологиям. У нас столько времени конечно не было. Нужно было как-то сузиться. Кого и чему учить.
Наши лучшие умы заперлись на пару недель и выдвинули очевидный тезис: люди просто так друг-другу деньги не платят. За этим в жизни всегда стоит какая-то сделка (поставка, продажа, займ и т.д.). Нужно как-то научиться определять какая ситуация в жизни и настраивать, как эту ситуацию отражать в учёте. Поскольку ситуации повторяются, мы, один раз настроив ситуацию, получим автомат для всех дальнейших её проявлений.
Например, если в банковской выписке написано «оплата аренды», то это сразу понятно, что проводить это нужно как оплату услуг.
Но какие ещё бывают ситуации и как всё это многообразие должно настраиваться и отражаться в учёте? Разработчики не знали про ситуации и учёт, а бухгалтеры про настройку и описание, но мы придумали метод познания.
Мы решили создать язык описания. На самом деле бухгалтерия – это тоже язык, как, например, и математика. Свой язык это звучит конечно страшно, но это был очень простой язык. Там не нужно было программировать математику, правила вывода, транслятор, просто мы писали на С# очень простые конструкции вида: если в поле документа есть вот такая подстрока, то счета учёта в бух системе у этого документа должны быть вот такие, а контрагента взять из документа, а договор повесить вот такой.
И мы начали постепенно описывать учёт клиентов и переводить их на новые рельсы. Бухгалтеры участвовали в описании, прямо на С#, по образцу это было несложно. У клиентов постоянно возникали новые, ранее не поддержанные ситуации. И для их поддержки разработчики расширяли язык. Впервые бухгалтеры и разработчики начали не ставить друг другу задачи, а работать вместе. И начали говорить на одном языке – нашем языке описания.
Так мы описали 100 клиентов и вытащили их из старой системы обслуживания. Обслуживание свелось к описанию и поддержке новых ситуаций. Мы уже достаточно много знали, на примере ситуаций этих 100 клиентов. Займы, лизинги, электронные кошельки, выдача под отчёт и т.д. И мы, почувствовав уверенность, сделали веб-интерфейс для описания. На самом деле просто сгенерировали визуальный конструктор, по уже имеющемуся языку.
Мы ожидали от искусственного интеллекта, что он будет решать и задачу классификации жизненных ситуаций клиентов и задачу корректного отображения ситуаций в учёте. Он конечно решал, но не всегда правильно и неизвестно где ошибался. Это не добавляло эффективности. Потому что когда ты перепроверяешь всё – это иногда даже хуже, чем просто сделать самому. Кроме того, такой подход заставлял нас относиться к учёту, как к чёрному ящику – пофигу как это работает, давайте мы в это вникать не будем, всё сделает ии. А когда ты понимаешь как это работает, ты получаешь буст от довольно очевидных автоматизаций намного больше, чем от ии.
И вот мы совершили фазовый переход от неуверенного искусственного интеллекта, к уверенному алгоритму, действующему по строгим настройкам. Я напомню, мы смогли описать правила определения ситуаций и их отражения в учёте для 100 клиентов. Мы начали это масштабировать.
Впервые у нас появилась система работы очень явно выражающая добавленную ценность, которую бухгалтер производит каждый день. Есть новые ситуации у клиента – опиши их. Нет – не нужно никакой ценности добавлять, ценности уже достаточно.
Обычная система управления трудом аутсорсеров совершенно не такая. Невозможно отслеживать, что и с каким качеством происходит каждый день, можно только отслеживать результат работы за 3 месяца (отчётность) и как-то судить о качестве отчётности (были ли корректировки и требования). Но качество учёта для масштабирования намного важнее.
Приведу такой метафорический пример. У вас есть в экселе 2 колонки цифр, в третью колонку нужно записать их сумму (давайте вот эту сумму считать результатом работы – отчётом). Можно сложить на калькуляторе числа в каждой строке и записать сумму. И это будет правильный результат, но немасштабируемый. Ещё 100 новых строчек вас полностью высадят. Это плохой учёт, и хорошая отчётность.
А можно записать в третий столбец формулу и протянуть её по всем строкам. И новые вычисления легко и быстро сделаются. И даже если результат будет неверный, вы просто впишите верную формулу и протянете её.
Система описания сделок позволила нам получить формальный тудулист действий, необходимый и достаточный для корректного учёта. Это уже была совсем другая жизнь. Обычно у нас было закреплено за бухгалтером несколько десятков клиентов. И мы стремились добавить больше, и это была постоянная борьба между бухгалтерами и компанией: «уже слишком много vs да не, ещё влезет».
И вот мы взяли и описали всех клиентов одного бухгалтера. Точнее всех мы описать конечно не смогли. Где-то языка описания не хватало и расширение было слишком большой задачей. А где-то описание не давало эффекта (условно каждый платёж требовал отдельного описания, не было повторяемости). Но процентов 80 мы описали. По пути мы выяснили, что заметная часть клиентов хоть и шли в статистику этого бухгалтера, но практически не генерировали никакой нагрузки. Там были операции, но это оплата за Кнопку, банковские комиссии и займы от учредителя на эти дела. Ну и раз в квартал какой-то ещё платёж. И оказалось, что с учётом этого, реальных клиентов у бухгалтера раза в 2 меньше, чем мы рисовали в своих дашбордах.
А ещё оказалось, что если описать сделки, то не потребуется закреплять бухгалтера за клиентом. Есть такой стандарт в индустрии. На самом деле, как теперь стало понятно, это происходит потому, что из учёта суть сделок непонятна бухгалтеру-аутсорсеру на 100%, особенно в малом бизнесе. Оплатил клиент куда-то с назначением: «оплата счета номер 2». А на самом деле это был возврат займа. О котором вы даже не знали. Но вы разобрались с клиентом и это запомнили у себя в голове. А потом пошли в отпуск, а ваш сменщик продолжает почему-то думать, что оплата счёта номер 2 – это оплата поставщику. А в описании сделок это всё конечно оседает, когда ты один раз разобрался, и это мотивирует, даже если разборки долгие.
Отрывание бухгалтера, прибитого гвоздями к клиентам, в сочетании с формальным тудулистом всех действий по настройке учёта и автоматическим учётом по настроенным один раз правилам – это я вам скажу очень мощная вещь, очень добавляет в стабильность, эффективность и качество.
А ещё оказалось, что для описания большинства сделок вообще не надо быть бухгалтером. Это про учёт ты можешь не знать, а понять и потом выбрать в интерфейсе, что «оплата аренды» это ситуация «оплата услуг» это не так уж сложно. И это позволило ещё лучше масштабироваться.
Что в итоге?
Мы поставили перед собой цель – ежедневно закрывать предыдущий день. Все платежи, документы, вообще все действия в жизни клиентов по вчера, должны быть корректно проведены уже сегодня. Так работают только банки, их цб заставляет. Большинство инхаус бухгалтерий на такое неспособны, потому что это правда трудно. Про аутсорс и говорить нечего – в клиента заходят сводить обычно раз в квартал, ну мы раз в месяц старались делать в нашем классическом подходе.
Ну я думаю вы теперь поняли. В первом квартале 2025 года мы сдаём отчётность за 2024 год. А весь 2024 год у нас сведён уже в первый рабочий день 2025 года. Остаётся только нажать кнопку и отправить отчёт. На самом деле всё не так просто, клиент увидев расчёт, может прислать ещё данных, которые до этого не присылал. И эти данные, как правило, прекрасно прожуются уже имеющимися правилами. Ну собственно всё, профит, в последние дни отчётности: ты просто ждёшь недостающие данные, кормишь ими систему и идёшь домой, как только рабочий день закончен.
Это организационно и технически определённо самый крутой проект, в котором я принимал участие. Я думаю никто в мире не умеет закрывать учёт тысяч юрлиц каждый день, да ещё и без закрепления за ними бухгалтеров.
Делалось ещё очень много вещей, работа с клиентскими ожиданиями, как не просить данные или согласовать отчёт у клиента бесконечно. Но это я думаю вам уже не так интересно.
