Следует рассказать об интересном опыте автоматизации казначейских функций в очень сложной организационной структуре компании, где я работаю.
На момент моего прихода в компанию казначейские операции были централизованы на уровне Управляющей компании, не подчинялись напрямую ни собственнику туроператора, ни финансовому директору. Примерно через 3 месяца формально казначейство переподчинили мне (ФД) и я смог заняться их оптимизацией. Отмечу, что со мной одновременно пришли: экономист по управленческому учету, главный бухгалтер, через 2 месяца еще 2 ведущих бухгалтера, и через полгода 2 казначея. Все с прошлого места работы, так что у меня была большая уверенность что все получится.
Ограничения:
- казначейство не подчиняется директивно. Подчиняется только функционально, через регламенты взаимодействия через системы документооборота между нашими подразделениями одной большой компании
- на момент старта у нас разработка 1С была на нулевом уровне, через подрядчика, который тоже не с первого дня нам подчинялся (хотя 1С в компании только для финансового департамента)
- у меня не было (об этом я узнал потом) полномочий в управлении ФОТ департамента, найме сотрудников. Никакой поддержки в подборе кандидатов с рынка.
Особенности задачи:
- у туроператора 15 000 партнеров, поставляющих клиентов (турагенты) и 7 000 отелей и других поставщиков, которым надо оплачивать
- в день около 3 000 входящих оплат от клиентов и 1 500 исходящих поставщикам
- есть жгучее желание бизнеса войти в рынок быстрых продаж, когда на оплату клиентов отводится 20 минут и туроператор должен эти деньги получить и подтвердить бронь у поставщика. Иначе аннуляция брони
- есть отдельная учетная система бронирования (КСБ), в которой ведутся все взаимоотношения с клиентами и поставщиками, кроме фактов оплат. Собственно, только для этого бизнесу и нужна 1С как полезный продукт (не будем преувеличивать необходимость управленческой отчетности в оперативном управлении бизнесом, это не так). Также в КСБ нужны все факты оплат от нас к поставщикам (так как мы платим из 1С, а менеджеры по работе с поставщиками должны понимать какой счет и когда оплачен). Для получения этой информации на тот момент пользовались только электронной почтой или телефоном.
В этой статье рассмотрим оптимизацию оплат поставщикам, а клиентов рассмотрим в другой.
Поставщики
На момент начала моей работы в деятельности было занято 6 бухгалтеров и 3 казначея. Бухгалтера сильно перерабатывали, оплачивали поставщикам очень долго (порой просто платили заранее побольше чтобы не слетели брони).
У поставщиков довольно разношерстный спектр учета – вот несколько примеров их требований к оплатам:
- оплачивать за Х дней до начала заезда клиентом;
- оплачивать спустя Х дней после бронирования;
- оплачивать каждую бронь отдельной платежкой либо в целом по договору и распределять их по ФИФО;
- нужна предоплата по заявкам или раз в месяц постоплата (таких очень мало);
- некоторые отели жили по старым правилам и непременно выставляли бумажные счета. Реквизиты этих счетов нам надо было указывать в платежном поручении. Соответственно, была организована работа по сбору этих счетов отделом работы с поставщиками и внесением их в учетную систему финансовым департаментом.
Как была организована работа
6 бухгалтеров каждый день просматривали ведомость расчетов с поставщиками, в которой были только списки заявок и даты заездов к ним. Бухгалтера работали по направлениям (Крым, Краснодарский край и так далее). Ничего иного кроме как скопировать данные по бронированиям в гугл-диск для передачи на оплату на тот момент не было придумано. 1-2 тыс. скопированных строк из 1С ЕРП в гугл таблицу. Далее оттуда казначеи копировали информацию, создавали руками платежные поручения в той же учетной системе, отправляли, проставляли оплату.
Когда мы разобрались во всей этой кухне, а также у нас сложилась команда ИТ из архитектора и программистов in-house, мы приступили к автоматизации. По этой задаче было 1 большое ТЗ на разработку большой ведомости взаиморасчетов с поставщиками, а также более 20 ТЗ дорабатывающих изначальную разработку. На разработку ушло 3 месяца, уволили одного программиста, доделывал другой.
Всегда в процессе оптимизации какой-то функции я оперирую двумя взаимоисключающими требованиями:
- нужно сократить сроки и затраты на проведение единицы операции
- нужно предотвратить риски реализации сценария что «все перестало работать»
На первом этапе мы создали ведомость, в которую по запросу бухгалтера выгружаются бронирования, которые надо оплатить к определенному дню (а не все возможные брони). Это сократило объем ведомости более чем в 2 раза, конечно ее стало удобнее смотреть. Если ведомость работает правильно, бухгалтер видит только то, что надо платить, например, сегодня.
Также мы добавили признак «нужен ли бумажный счет» и «есть ли он в наличии». Теперь не надо было как-то проверять отдельно его наличие. Программа сама подсвечивала если нет счета.
И самое внушительное изменение, но оно же и самое логичное. Мы сделали создание платежек напрямую из этой ведомости. Сократили процесс, убрав из него:
- копирование в гугл-диск информации для платежей бухгалтерами
- копирование оттуда в 1С ЕРП информации и создание платежек
- набитие этих платежек
Примерно месяц ушло на процесс перехода. С каждым бухгалтером работали отдельно. По ходу дописывались доработки к этой глобальной разработке, например исключить тех кому платим по договору.
На втором этапе мы начали укрупнять участки. Вышел казначей, которого я смог привести с собой. За месяц работы он смог собрать 5 из 6 глобальных участков поставщиков в одном лице.
Оставались еще мелкие нюансы по некоторым поставщикам. Также новый человек всегда имел свежий взгляд. Выяснилась большая ручная работа по передаче менеджерам информации о том, что бронь оплачена.
У нас давно существует нормальная интеграция между КСБ и 1С. И КСБ была давно готова принимать от нас информацию.
Мы достаточно быстро дописали наш обмен и начали передавать признаки. Ушло примерно 30 запросов в день от менеджеров по этому поводу.
На третьем этапе мы уже начали делать системные вещи совместно с отделом работы с поставщиками.
Часть поставщиков перевели на оплату по договору. Вообще, унификация отношений с ними – будущее такого технологичного бизнеса. Платить лучше каждому как-то одинаково. Либо указывать всегда бронь, без бумажных счетов. Либо платить по договору в целом и обе стороны по методу ФИФО распределяют поступившие ДС.
Перейти на оплату по договору согласились примерно 20% поставщиков. Это первый шаг, дальше должно быть больше, так как у систем онлайн бронирования типа Яндекса или тех же AirBnB нет никаких кастомных решений. Мы сократили долю запросов бумажных счетов.
Более 30% отелей согласились перейти на постоплату раз в месяц. То есть вместо платежек каждый день (а иногда и по каждой брони более 1 в день) мы делаем 1 платежку в первые числа в начале месяца одновременно с рассылкой им отчета агента. Тут была двойная польза – добавленное кеш-фло для нас и снижение ручного труда по созданию в 30 раз. Ну и прицепом – сокращение платы банку за РКО.
Ниже представлены схематически итоги этой работы.
Контакты автора: https://t.me/VeselovAndrew. +7 916 743 8142
