Прежде чем начать свое повествование, автор убедительно просит уважаемого читателя не забывать, что данная статья — не научное исследование и даже не консалтинговый отчет. Это краткий рассказ о конкретной работе. И хотя я гарантирую терминологическую точность и корректность описания методов работы, они (описания) не претендуют на полноту.
В маленькой стране Латвии, где я живу большую часть времени, консультант вынужден работать с предприятиями самых разных отраслей и иметь дело с самым разным программным обеспечением. И, по моим наблюдениям, для небольших и средних предприятий вид ПО не имеет принципиального значения. Гораздо важнее, чтобы руководитель умел пользоваться той системой показателей, которую ему предоставляет этот самый управленческий учет. И если топ-менеджер отлично справляется со своими обязанностями, подсчитывая что-то, по презрительному выражению программистов, «на коленке», то лучше ничего не трогать и не менять. Конечно, ключевое слово здесь — «справляется», а главный критерий — показатели деятельности предприятия, причем не только финансовые. И если они неудовлетворительны или если предприятие стремительно расширяется и ограниченность расчетов «на коленке» уже маячит на горизонте, то схемы работы нужно менять принудительно.
Именно на этом, можно сказать, предкризисном этапе многие руководители начинают задумываться о помощи со стороны. Но до обращения к консультанту надо пройти длинный и непростой путь и к тому же быть прижатым обстоятельствами, о которых ты знаешь: справиться можно, но своих сил не хватит. И то, насколько глубоки будут изменения, зависит в конечном счете от желания руководителя. Потому что это на самом деле страшно.
Страшно ясно увидеть, сколько просчетов сделал ты сам. Страшно понять, что в ближайших помощниках у тебя ходит лентяй, а продажами руководит бездарь. Иногда удается обоснованно заподозрить, что в кредитном отделе берут взятки, и даже доказать это. В ходе экономического анализа проступают покрываемые бухгалтерией хищения, которые не «берутся» аудитом, так как по документам все оформлено абсолютно грамотно… Руководителю требуется немалое мужество для того, чтобы увидеть реальное положение дел. «Открывать глаза» можно только тогда, когда ты внутренне созрел для того, чтобы проводить серьезные изменения в своем деле.
Я считаю, что в этом страхе и в неготовности менять себя, своих людей и свою компанию — одна из основных причин того, что у консультантов не слишком много клиентов. Не каждый собственник или топ-менеджер может наступить на горло своему самолюбию, которое кричит о том, что никто лучше него не знает его собственный бизнес.
Я действительно знаю их бизнес гораздо хуже. Но я знаю параметры и признаки идеального, пропорционального предприятия и могу наполнить их конкретными данными фирмы. Мне не только не страшно — наоборот, интересно увидеть компанию такой, какая она есть, понять заблуждения руководителя, которые заставляют его делать ошибки, и подсказать решение. Именно с этих шагов обычно начинается наша совместная работа.
Странность первая, иерархическая
Заказчик, к которому я ехала этим утром, представлялся мне весьма необычным. Во-первых, инициатором и «двигателем» консалтингового проекта со стороны заказчика — крупной оптовой фирмы, торгующей шинами и аккумуляторами, выступал не владелец фирмы, а финансовый директор — наемный работник, к капиталу предприятия отношения не имеющий. А дело в том, что на первом этапе такой работы проводится экономический и финансовый анализ ситуации на предприятии, а на последнем — появляется система показателей, которая будет отражать результаты деятельности и фирмы в целом, и ее подразделений. И тогда дело может дойти до оценки работы каждого конкретного управленца, что не всякому придется по вкусу.
Но почему именно финансовый директор? Ведь анализ показателей финансовой отчетности ясно говорит о том, что фирма не имеет проблем с продажами, — они заметно опережают рост местного автомобильного рынка. С персоналом особых сложностей тоже нет — зарплатоотдача хоть и «пляшет», но в целом растет, и колебания не уходят дальше сезонных скачков. Значит, работа с людьми у них тоже поставлена более или менее четко. Правда, есть проблемы с магазинами, часть которых неэффективна (низкорентабельны или вообще убыточны), но это решается просто.
А главные проблемы — это дебиторская задолженность и ошибочная политика излишне льготных скидок.
Скорость оборота дебиторской задолженности составляет 119 дней при сроке оплаты счетов по договорам 56 дней. Соответственно сочетание быстрого роста продаж и плохой клиентской дисциплины приводит к разбуханию кредитов. Хорошо еще, что кредитная линия была оформлена заранее, иначе кто-нибудь из поставщиков уже подал бы в суд. Но банк уже недоволен и периодически намекает на недостаточную финансовую устойчивость. Кстати, примечательная деталь: ни банковский клерк, подсчитывающий финансовые коэффициенты, ни сотрудники предприятия вкупе все с тем же финансовым директором не понимают связи между дебиторами, противостоящими им кредитами и показателями финансовой устойчивости… Что ж, бывает.
С ценами дело обстоит еще более грустно. Товар фирмы вообще-то дорогой в том смысле, что при продаже в розницу через собственные магазины на него уверенно ставят наценку в 50—70, а то и 80% — и он уходит. Но стоит появиться покупателю, который сам себя объявляет оптовым, и он сразу получает скидку в 25% — просто по факту появления. Если же его заказ и в самом деле оказывается более или менее существенным, то скидка возрастает до 30—35%. Результат? Средневзвешенная наценка по всей товарной массе составляет 30,2% при том, что для безубыточной работы фирме нужно как минимум 28%. То есть потенциально высокорентабельное предприятие, по сути, еле сводит концы с концами, балансируя на грани рентабельности (2% —маржа несерьезная), и обрастает кредитами.
Ответственность за происходящее несет — или по крайней мере должен нести — тот самый финансовый директор, который настоял на приглашении консультанта.
Странность вторая, управленческая
Странность эта проявилась в заявлении владельца предприятия о том, что «внедрять у себя на фирме они будут только те изменения и предложения, которые можно реализовать через систему Scala». Надо сказать, Scala они купили около полугода назад и испытывали по этому поводу смешанные чувства: с одной стороны, были ужасно горды собой — система дорогая, и не так много латвийских компаний могут похвастаться тем, что работают на ней. С другой стороны, похоже, их никто не предупредил о том, что внедрение дорогого ПО стоит зачастую больше, чем само это ПО. И не только в смысле прямых дополнительных расходов, но и в смысле сбоев в работе, обучения сотрудников, перестройки организационной структуры, изменений в документообороте и т. п.
Наверное, по этим причинам и появилось требование: либо делаем то, что может Scala, либо не делаем ничего. На самом деле в управлении, как и в жизни, нужно делать не то, для чего особо хорош твой инструментарий, а то, что поможет твоей компании выжить и преуспеть. Однако в этом вопросе заказчик стоял насмерть.
В позиции этой были и плюсы, и минусы. Система Scala создавалась не вчера, ей уже лет 25. С одной стороны, она достаточно жесткая, как все ПО, уходящее корнями в те времена. С другой — за столько лет ее успели отладить, ошибки исправили, массу чьих-то пожеланий учли. Кредитный блок хорошо проработан, механизм скидок весьма разветвленный. В общем, идея с перенастройкой Scala представлялась небезнадежной.
Парадоксы ориентации на клиента
Работа, начавшаяся после заключения договора, выявила много интересного. Финансовый экспресс-анализ среди прочего показал, что дебиторская задолженность росла быстрее, чем объем реализации, а значит, скорость ее оборота замедлялась. Напрашивался вывод: компания ориентирована преимущественно на отгрузку товара, к получению выручки относится с пренебрежением. Логически это кажется нонсенсом, но в реальной практике встречается очень часто.
Кредиторская задолженность увеличивалась параллельно дебиторской, т. е. товарный кредит клиентам предоставлялся в первую очередь за счет поставщиков, что крайне рискованно. Вывод: риск разрыва отношений с клиентами компания ставит выше, чем опасность ухудшения отношений с поставщиками.
Замедление оборота дебиторской задолженности привело предприятие к накоплению долгов, для покрытия которых приходилось брать все новые и новые кредиты. Компания уже подошла к пределам своей финансовой устойчивости. По всей видимости, руководство фирмы не понимало допустимых пределов задолженности — как своей, так и чужой.
От финансового анализа мы перешли к экономической оценке эффективности работы предприятия (к области экономического анализа относятся все натуральные единицы — тонны, метры, штуки, люди, часы и т. п.). Углубленный анализ дополнил и конкретизировал наши первоначальные выводы.
Структура клиентской базы предприятия оказалась очень неоднородной, как по виду и размеру клиентов, так и по их платежной дисциплине. Среди клиентов были автоцентры (магазин плюс сервис), в том числе весьма респектабельные, магазины запчастей и автосалоны, автосервисы, заправки и даже одна мойка машин в какой-то глуши. Каждую из этих групп представляли клиенты крупные и мелкие, причем условия их обслуживания сильно разнились. Крупные, а особенно «почетные» по тем или иным субъективным причинам клиенты имели самую длинную отсрочку платежа и самый большой кредитный лимит. В результате на скромную по численности группу «злостных неплательщиков» приходилась серьезная доля просроченной дебиторской задолженности. Это в целом неудивительно: по отношению к подобным процессам действует принцип Парето, согласно которому на меньшую часть факторов (допустим, 20% клиентов) приходится большая часть (скажем, 80%) приращения функции — в нашем случае дебиторской задолженности.
А вот что было удивительно, так это то, что такая же сумма просроченной задолженности пришлась на неактивных клиентов, т. е. тех, которые появлялись от случая к случаю, даже не каждый месяц. И это было очень скверно, потому что говорило о крайне низком уровне кредитной работы на предприятии. Другими словами, пока клиент не появился и не захотел что-нибудь купить, состояние его счета никого не интересовало.
Как уже говорилось, средняя наценка на продукцию фирмы, если ее рассчитывать по прейскурантным ценам, составляет от 50 до 70%. Торговая наценка, рассчитанная по отгруженному товару, в лучшем случае достигает 32%. Получить скидку проще простого — приходишь и заявляешь, что ты потенциальный оптовик. Некоторые контрагенты ухитрились доторговаться до скидки в 40% — и при этом задерживать оплату!
И еще одна маленькая деталь: наценка рассчитывается к уровню закупочной цены, а скидка — от прейскурантной. В результате если была поставлена наценка, скажем, 50%, а скидка предоставлена в 35%, то товар уходил ниже закупочной цены.
В итоге выявилось одно-единственное заблуждение, правда, довольно серьезное. Заключалось оно в «прогибе» перед клиентом. Низком-низком.
— Как это мы пошлем ему напоминание? Штраф?! Он же уйдет!
— Куда?
— К конкуренту!
— А Вам не кажется, что пусть лучше уйдет? Вы избавитесь от мошенника, который получает товар чуть ли не по себестоимости и при этом поддерживает дебиторскую задолженность на уровне полугодовых закупок. И конкуренту свинью подсунете — с ним он будет вести себя точно так же, ведь платежная мораль не меняется.
Правда, один из менеджеров, специализирующийся на зимних шинах, глядя куда-то в сторону, сказал: «А почему уйдет? Мы вот в мае прошлого года, спустя восемь месяцев после отгрузки товара, на всех своих должников в суд подали. Уж сколько крику было — все как один твердили, что больше с нами дела иметь не будут. А как октябрь начался, так все и пришли. Точно все — я вчера их подсчитал».
Штурм вершины
Самой интересной частью работы оказалась настройка той самой Scala. Точнее, перенастройка, потому что какие-то параметры туда уже были заведены и полгода проработали. Стали выяснять, что именно настроено и по каким принципам. Задействованными оказались:
- ABC code — обозначение важности клиента.
- Кредитный лимит, который рассчитывается автоматически на базе «остатка клиента», т. е. разницы между установленным ему максимальным лимитом и уже отгруженным товаром.
- Максимальный кредитный лимит.
- Delivery Block, который показывает, не заблокирована ли отгрузка товара данному клиенту. Может включаться автоматически или вводиться вручную.
- Market Subsidy — обычная скидка за объем закупок.
- Discount Taken — скидка, полученная особо важным клиентом.
- Payment Terms — условия оплаты (отсрочка в днях) для данного клиента.
Вроде бы не так мало. В чем же дело? А проблема оказалась в том, что при настройке не была учтена «экономическая взаимосвязь» скидки, отсрочки и платежной дисциплины клиента. Логика этой взаимосвязи проста: если клиент получил большую скидку, то он должен заплатить быстро; если он хочет отсрочку подольше, то скидка должна быть уменьшена; а если его закупки и в самом деле настолько велики, что он заслужил и скидку, и отсрочку, то он должен платить точно в срок.
В нашей же фирме получалось, что важным клиентам проставили самый большой кредитный лимит, самую длительную отсрочку и категорию А, т. е. разрешение превысить лимит на максимальную сумму. И увенчивался весь этот экономический беспредел массовым возвратом сезонного товара, который набирался клиентами ради имитации «важности и нужности» и до следующего сезона оставался лежать на складе.
Вот она, причина катастрофического роста дебиторской задолженности. А если учесть еще и фантастические скидки, то вот вам и причина падения рентабельности.
Scala и алгоритмы
С теоретической точки зрения задача разработки показателей товарного кредита, которая фактически стояла перед фирмой, решается достаточно просто. Нужно установить такую связь между кредитным лимитом, сроком кредита и скидками, чтобы максимальный срок и лимит компенсировались ценой, а максимальный срок и скидки не распространялись на большую сумму — и так далее «по кругу». Но реализовать этот образ действий в Scala не представлялось возможным, так как система не поддерживает никаких алгоритмов внутри себя*. Однако к тому времени позицию директора «делать только то, что умеет Scala» удалось немного поколебать, и было проведено обучение менеджеров процедуре выбора условий товарного кредита. Удалось также активизировать часть параметров Scala, которые не были задействованы в ходе первоначальной настройки: Category (соответствует типу клиента) и Collection Customer (указывает, включен ли данный клиент в ту или иную группу для отчетности).
* Автор еще раз подчеркивает, что не является специалистом в настройке ПО вообще и Scala в частности. Поэтому фразы типа «в Scala это сделать нельзя» на самом деле означают «мне и специально обученному программисту, работающему у заказчика, это сделать не удалось даже после получения дополнительной консультации у поставщика Scala».
Клиентов поделили на кластеры, различающиеся по уровню риска задержки оплаты и риска полного неплатежа (см. схему).
| Уровень риска неоплаты | Высокий | Крупные автосервисы Примечание: Если не заплатили вовремя, надо привлекать юристов или инкассовые фирмы для получения оплаты |
Небольшие автосервисы Примечание: Нужно стимулировать к своевременной оплате и постоянно контролировать |
| Низкий | Фирмы, имеющие большой собственный автопарк, автоцентры и автомагазины среднего размера, но с частыми закупками Примечание: Лучшие клиенты, "золотой фонд |
Автоцентры и автомагазины размером больше среднего Примечание: Почти наверняка вовремя оплаты не будет, но в конце концов заплатят |
|
| Низкий | Высокий | ||
| Уровень риска задержки платежа | |||
К этим группам привязали функции Reminder Blocked (очень полезная функция, которая показывает, отправлять ли данному клиенту напоминания автоматически или нет) и Number of Reminder — количество отсылаемых напоминаний. Заодно отредактировали текст напоминаний с тем, чтобы первое было самым мягким, а последнее (обычно третье) — достаточно категоричным. Тут, правда, обнаружилась своеобразная ирония создателей Scala: в напоминаниях свободному изменению поддаются только три последние строчки.
Впрочем, это не столь существенно по сравнению с тем, что выяснилось дальше. Оказалось, что в Scala имеются те или иные серьезные ограничения практически на все меры кредитной политики. Это вдвойне обидно, потому что «намеки» на эти меры в системе тоже есть, и в изобилии. Например, в программе представлен механизм сконто-скидок: если клиент заплатил в установленный укороченный срок, ему автоматически начисляется скидка некоторого заранее установленного уровня. Этот уровень легко рассчитывается на основании финансовых показателей компании, но ввести его автоматически в Scala не получится. Приходится входить в карточку каждого клиента и проставлять цифры руками. У нашей компании клиентов оказалось чуть больше 500 — работа вполне посильная. Но ведь есть предприятия, у которых десятки тысяч клиентов, и такой способ действий им категорически не подходит.
Следующая сложность была связана с отслеживанием платежной дисциплины клиента. У Scala есть специальный блок Invoicing, отслеживающий поступление средств, и наш заказчик не пожалел денег на его покупку. Вроде бы очень удобно: клиент проставляет внутренний номер накладной Scala в платежке, по которому система идентифицирует оплаченный счет, сравнивает дату получения денег с датой оплаты и рассчитывает задержку. Но вот неожиданность: дальше с этим числом задержки ничего не происходит! По нему нельзя без вмешательства человека начислить скидку или штраф, нельзя узнать, как часто клиент задерживал платеж или, наоборот, платил с опережением, нельзя строить никаких кредитных стратегий. Хотя вся необходимая для этого информация в системе содержится.
Да и содержится она как-то ненадежно — сегодня есть, завтра нет. Например, можно сегодня послать клиенту напоминание с указанием набежавшего штрафа и распечатать его. Но если не печатать, а просто послать по Интернету и через несколько дней попытаться этот документ восстановить, ничего не выйдет. Штраф будет соответствовать новому дню.
Можно рассчитать средний срок оплаты клиентом своих счетов, сравнить со сроком в договоре и оценить его платежную дисциплину. Но нельзя рассчитать этот срок на несколько разных дат и посмотреть, а как же эта дисциплина менялась.
Если в платежке клиент не проставил номер накладной Scala, а ограничился обычным номером, идентификации не происходит. Счет «зависает», и разбираться с тем, кто и когда заплатил и какие за это положены штрафы/скидки, приходится потом менеджеру вместе с представителями плательщика.
В общем, пока менеджеры предприятия не разобрались с происходящим, а программист не изменил настройки системы, возмущению — совершенно справедливому! — не было предела. И даже после настройки Scala со многими клиентами приходится работать отдельно, «по-человечески». Так что желание начальства «делать только то, что умеет Scala» потихоньку превратилось в очевидную для всех утопию.
Scala и управленческая информация
Разобравшись с настройкой показателей кредитной политики, можно было приступить к составлению управленческой документации. Управленческий учет в привычном объеме предприятию не был нужен, и соответственно заказчик не собирался тратить на него время и деньги. Но руководство компании остро нуждалось в оперативном получении управленческой информации — настолько остро, что загодя приобрело дополнительно к основным блокам Scala еще и специальное приложение Crystal Reports, предназначенное для формирования отчетов. И теперь предстояло научиться получать с его помощью оперативный баланс и отчет о прибыли и убытках, все вытекающие из них абсолютные и относительные показатели и в дополнение — графики и необходимые комментарии.
Коротко говоря, ничего не получилось. Точнее, не получилось с помощью Crystal Reports. Во-первых, этот инструмент оказался не очень удобным. Его настройка напоминает составление отчета в Access, а потому понятна, но достаточно неповоротлива. И если учесть, что оперативный баланс отличается от официального и его структура может пересматриваться в зависимости от решаемой управленческой задачи, использовать ПО с негибкой настройкой не хотелось.
Во-вторых, что оказалось гораздо серьезнее, баланс не существует в Scala в виде файла, а потому на него нельзя «опереться». Программа каждый раз по запросу сводит его заново и либо представляет на экране, либо выводит на печать. Все.
Конечно, выход был найден. Им оказалось использование PIVOT-отчетов с дальнейшей обработкой полученных данных в Excel. Исходную информацию получал из базы данных программист, т. е. с формированием оперативной отчетности проблем не стало. А Excel — штука знакомая и удобная. Так что Crystal Reports оказался не у дел.
Выводы и итоги
Реальный результат работы, каковым я всегда считаю решение финансовых и экономических проблем предприятия, оказался весьма удовлетворительным. Продажи за год возросли на 24%, но в этом, конечно, заслуга работников фирмы, а не консультанта. Впервые за пять лет фирма закончила год с той же суммой кредитов, что и в предыдущий отчетный период, — и это несмотря на продолжающееся расширение. Срок оплаты клиентами своих счетов сократился на 24 дня, зарплатоотдача повысилась. Но самое, безусловно, приятное — это то, что руководство компании стало более рационально смотреть на бизнес и свое место в нем. «Прогиб» перед клиентами исчез. Рыночная стратегия стала более наступательной, а финансовая — более осторожной. Менеджеры ежедневно проверяют поступление средств от клиентов и половину переменной зарплаты получают «от выручки», а не «от продаж». Это изменение системы оплаты прошло пусть и не безболезненно, но оказалось для менеджеров понятным.
Удалось договориться об изменении сроков договоров с поставщиками, и их собственные платежи теперь уходят большей частью вовремя.
Так что на скалу мы все-таки взобрались. Правда, нет уверенности, что нельзя было подняться выше — в смысле каких-то возможностей, которые мы не сумели задействовать. И этот очерк пишется, кроме прочего, и для того, чтобы кто-то мог пойти дальше, а потом указать нам путь.
| Елена Бреслав — консультант, специализируется в области финансового и экономического анализа, управленческого учета и связанных с ними задач: бюджетирования, управления денежными потоками и кредитной политики. С ней можно связаться по адресу ebreslav@intalev.ru |
