Возможна ли оценка эффективности затрат на внедрение системы бюджетирования?

Во-первых, я бы хотел поблагодарить организаторов этого круглого стола за приглашение, сказать что-нибудь про экономическую эффективность. Мы достаточно много узнали про системы бюджетирования пока здесь сидели, спасибо. Второй вопрос заключается именно в процессе оценки экономической эффективности систем бюджетирования и вообще IT- систем. Хорошо, что на столе нет помидоров, потому что люди, которые пытаются рассказывать про экономическую эффективность IT-систем, особенно среди IT-шников, достаточно быстро попадают в ситуацию, когда их спрашивают, как они себя чувствуют, как можно вообще оценить эффективность IT-систем. Невозможно это по целому ряду причин, я не буду говорить список, почему этого нельзя сделать, все присутствующие его хорошо знают. Тем не менее, сделать это можно. У нас есть опыт оценки эффективности серьезных корпоративных информационных систем хороших российских предприятий, с оборотом повыше миллиарда, если считать в долларах, При этом эти предприятия обладали своими собственными экономическими институтами, собственными предметными институтами, и когда мы предложили им что-то сделать в этом плане, понятно, что это не было встречено с радостью местными товарищами. Тем не менее, сделать что-то удалось и это получило положительную оценку в плане коммерческом. Поэтому первый вопрос, на который мы с вами должны попробовать ответить: А зачем вы хотите считать экономическую эффективность? Мы вчера его довольно долго обсуждали на семинаре в высшей школе экономики. Так вот, на самом деле правильный ответ звучит так: Если вы хотите получить денег на эту разработку. Потому, что если вы умеете получать деньги каким-либо другим путем, лучше экономической эффективностью не заниматься. Для этого есть очень много способов. Первый, если удастся получить деньги в обмен на слова, это прекрасно. Последнее интервью Дениса Ганстера, президента "Comshare"... Он говорит, что находятся под давлением лица, принимающие решения, что от них требуют, чтоб они ROI показали, или период окупаемости. А есть, говорит, шесть бонусов замечательных, которые получает каждый, внедривший любую IT-систему, в том числе и систему бюджетирования. Они опять-таки всем хорошо известны: прозрачность, коллективное решение, интеллектуальность, оперативность и прочее, прочее, прочее. В том числе даже эффект Уол Стрита так называемый, это когда инвесторы выше оценивают вашу компанию, если вы показываете какая у вас замечательна система бюджетирования, и все можно учесть. Если это не прошло, есть второй рубеж обороны, попробуйте работать на основании того, что у нашей отрасли принято, предположим, полтора процента от оборота класть на информационные системы. Если опять не прошло, есть прекрасная вещь под названием TCO. Это уже первый шаг к некоторым цифрам, но не страшный. Есть некоторая путаница, с нашей точки зрения ТСО не есть экономическая эффективность IT-системы, ТСО - есть попытки обосновать заданную функциональность и показать, что эта функциональность с данным набором решается либо лучше, либо хуже. И только вот если все это не получилось, приходится переходить к расчету вот этой, выше означенной экономической эффективности. Таким образом, расчет экономической эффективности есть не измышление ума, а настоятельная необходимость, почему он все чаще и чаще звучит? Мы немножко смотрели на рынок, это одно из направлений, которым мы сейчас занимаемся. А звучит по очень простой причине, мы ее уже называли, все чаще и чаще вашими заказчиками становятся не распорядители кредитов и не люди, которым надо потратить средства. Во время социалистической экономики основная идея была в том, чтобы освоить те деньги, которые дали. Если не освоили, в будущем году получишь меньше. В эпоху раннего капитализма, дикого капитализма в России неожиданно люди поняли, что те деньги, которые раньше были безналичными, легко делаются наличными, отсюда сразу появилось понятие экономической эффективности, только не для предприятий, где работает лицо, принимающее решения, а лично для этого лица. Все это проходили, экономическая эффективность определялась разными цифрами, 10, 15, 5 процентов от тех денег, которые инвестированы в IT. Последствия мы разгребаем до сих пор. Зоопарки на разных предприятиях с этим связаны. Так вот, сейчас заказчиком оказывается собственник, у него нет проблем потратить эти деньги как-нибудь иначе, они его. У него нет проблем переложить их из одного кармана в другой, ему не нужно их обналичивать, это его деньги. И он задает очень простой вопрос: что будет с этими деньгами? Я здесь уже сказал про помидоры со стороны IT-шника, так вот, ситуация может быть развернута ровно наоборот. Посмотри с другой стороны: к некоторому инвестору приходит кто-то и говорит: я принес замечательный проект. Ну, например, как я вчера говорил, свечной завод будем ставить. Прекрасный проект. Я точно посчитал текущие затраты, вот нужно будет столько-то воды, столько стеарина, столько жира, столько фитилей. Я прекрасно знаю капзатраты, и говорю тебе, что это будет лучший вариант, я только одного не могу тебе сказать, сколько денег я при этом заработаю и когда я тебе отдам твои деньги. Как вы думаете, сколько шансов у соискателя получить инвестиции под свой проект? С моей точки зрения, люди, занимающиеся информационными технологиями все больше и больше от первой модели, с высоты высокоинтеллектуального IT-шника, они не интересуются такой мелочью как окупаемость затрат, тем более что на самом деле вчистую они гарантировать ее они и не могут, это чистая правда. Они все больше и больше входят в ситуацию, когда деньги даются в обмен на деньги, и деньги не даются в обмен на слова. Эта ситуация воспринята сейчас практически везде, у нас достаточно большой опыт работы в инвестиционных проектах, и я боюсь, что это уже так. По крайней мере, в области ERP-систем, эти вопросы возникают достаточно часто. Возможно, что в области систем бюджетирования эта актуальность тоже потихонечку возникает. Если мы договорились, что мы говорим об обмене денег на деньги, то дальше оказывается долго придумывать ничего не надо. Есть понятие - инвестиционный проект. И эта картина хорошо известна всем людям, занимающимся инвестиционным проектированием. То, что вы делаете это инвестиционные проекты на действующем предприятии. Вы должны понимать, какие проблемы вы пытаетесь решить, каких целей надо достичь, какие возникают задачи, и вот возник ваш проект. Что есть, чего нет, получаемые эффекты, затраты, доходы по проекту. Эта картинка расписана и долгое время, как ни странно, будет достаточно простой. Существует де факто стандарт на разработку инвестиционных проектов российский, это методические рекомендации, во всем мире известно как их считать, и более того, если вы пошли этим путем, вы получаете два преимущества. Одно мне в свое время подсказал начальник крупного управления, крупного российского предприятия, если вы пошли этим ходом, вы перестали просить деньги, вы не просите деньги, вы предлагаете инвестиционный проект, и если под него не дают деньги, всегда можно поставить вопрос: почему? Если что-то не устраивает в расчете можно разговаривать. При этом сразу можно уйти от одной болезненной темы, одни говорят надо считать ROI, нет, говорят другие, мы считаем период окупаемости, нет present value, говорят третьи, economic value, это четвертые и т.д. и т.д. Важно следующее, если вы пошли этим путем и взяли на себя труд строить потоки cash flow, для данного инвестора на данном предприятии, вы сможете дать ему именно эти цифры, и дальше вопрос пойдет ровно так же, как в случае проекта, скажем, покупки нового станка. Они написаны одним языком и одними словами, все, что остается здесь сказать, если считается, что это инвестиции более рискованные, в инвестиционном проекте есть способ учета риска инвестиций, если считается, что этот период больше чем хотелось бы, можно разобраться, как его сокращать и т.д. и т.п. Если мы прошли этим путем, мы вышли на инвестиционный проект и достаточно долго вам будет просто. Что такое инвестиционный проект, это хорошо известно, это капитальные затраты, мы пока не сталкивались с людьми, которые бы сказали, что они не могут примерно прикинуть капзатраты на внедрение системы, думаю все присутствующие легко по просьбе заказчика это могут сделать. Проблема остается только одна, проблема с доходной частью. В чем проблема то? Проблема в том, что разговор IT-шника и инвестора идет на разных языках. Все, что хотел бы увидеть от вас человек, который дает вам деньги, - это либо увеличение дохода, либо снижение текущих затрат, либо снижение капзатрат, либо минимизация выплат и т.д. и т.п. Вот, если он эти цифры увидел, он может с вами разговаривать, он понимает, что может ему дать, вот эти вещи уже превращаются в так называемую составляющую cash-in доход предприятия. С другой стороны, когда вы с ним разговариваете о системе бюджетирования, если вести себя честно, здесь уже было сказано, вы можете оживить посмертный учет, вы можете из кладбища данных сделать хранилище данных, оперативность, объективность, точность и т.д. и т.п. Возникает вопрос как эти характеристики привести к измеримым величинам, и насколько это можно сделать. Сразу могу сказать, цитируя одну известную монографию, что очевидных методов оценки финансовых результатов нет ни у нас, ни у них, однако в каждом конкретном случае что-то похожее можно попробовать сделать. Вот конкретный примерчик, взятый из реальной жизни, я очень быстро по нему пробегусь. Мысль заключается в том, что с одной стороны внизу есть некоторое IT-шное решение, наверху есть некоторое решение на уровне собственника. Одинаково плохо пробовать сказать, мы считаем, что нужно увеличить или уменьшить период оборота дебиторской задолженности на, скажем, 20 дней, или получить за счет оборота дебиторской задолженности вот столько денег. Неизвестно можно это сделать или нельзя и при чем здесь IT. С другой стороны IT-шники могут сказать, ты знаешь, вот если мы сейчас сделаем бюджетирование, то ты сможешь видеть, что делается с дебиторами не раз в полгода, как ты ими занимаешь, а хоть каждый день. Ну и что? Кому это надо? Вывод видится очень простой, для того чтобы этого достичь необходимо движение сверху вниз и снизу вверх, от IT-шных вещей до выгоды в бизнесе. Пример очень схематический, но, тем не менее, многое показывающий. Прежде всего, если вы взялись считать деньги, вы должны понять, зачем вы это делаете. Пусть сформулировали, но у нас есть некоторая проблема с использованием ресурсов. Пусть на основании этого анализа выяснено, что мы полагаем, что у нас велика величина дебиторской задолженности, мы соображаем, что величина дебиторской задолженности связана с тем, что мы просто не охватываем того количества дебиторов, которое у нас есть, и за ними просто не успеваем смотреть. Если это так, то мы можем попробовать. Выясняется, что на самом деле иметь дело с критичными дебиторами, многие из которых просто критичны из внутренней вредности, они превышают условия контракта, на большой фирме их могут быть и тысячи. Когда они меряются тысячами, и вы их не ведете, они просто не торопятся с этим. Скажете - дадим денег, более того вы порой сами того не зная, проводите последующую отгрузку критичным дебиторам, тем которые вам не дали денег за прошлый раз. Они платежеспособны, и вам даже не надо выдвигать никаких требований в арбитраж, ничего не надо, вам надо просто сказать: "Вань, где деньги?" А тебе надо? Вот, пожалуйста. Только сказать надо, а для того чтобы принять вот такие вот решения, информирование нарушителей и прекращение поставок критичным дебиторам, вот этого нельзя сделать без системы бюджетирования, просто нельзя. У нас не получается. Дальше пошло. Вот поставим мы эту систему, что можно сделать? О дальнейшем разговаривайте с людьми, которые занимаются этим. Здесь возникает некоторая проблема, как это оценить, есть очень много способов, не буду сейчас вдаваться в разные методики и Balance Score Card и прочее, и прочее. На наших предприятиях, этого, к сожалению, пока не очень видно. Возникает простой вопрос, - спросить.. Если вы это спросили, вы приходите к некоторой цифре, что вот так примерно уменьшатся нарушения условий оплаты и это даст сокращение дебиторской задолженности. Мы не спрашиваем здесь от человека сидящего, на сколько рублей ты сократишь, мы его спрашиваем, что ты конкретно извлечешь из этих процедур, а дальше ничего делать не надо. Дальше, если мы знаем сокращение периода дебиторской задолженности, есть некоторые аналитические соотношения, которые позволяют привести это просто к конкретным деньгам, вот так мы прошли. А теперь задаем вопросы. Вот из этой цепочки можно попробовать получить такое-то количество денег, мы не знаем нужно это или нет, мы говорим о том, что есть такая возможность, нужно это делать, тогда мы получаем свой инвестиционный проект, вот выигрыш этого инвестиционного проекта, теперь можно считать, что для этого нужно сделать. Это очень простенький пример. Я уже говорил, что мы не специалисты в области систем бюджетирования, однако простой пример показал, что двигаясь вот таким путем, мы выявляем какое-то количество возможных эффектов третьего уровня, только за счет того, что мы увидели две проблемы: нам нужно сократить потери в доходной части бюджета и уменьшить потребности в оборотных средствах. Это большая и серьезная работа, делать такие вещи, могу сказать на основании некоторого опыта проведения этого через отраслевые институты и т.д. разрабатывают специальные матрицы, вы садитесь со специальными людьми и долгое время пытаетесь понять, что они говорят и чего с этим можно сделать. Только надо задавать те вопросы, которые здесь возникают, потому что просто внизу спрашивать, сколько денег мы получим на верхнем уровне равно также бессмысленно, как спрашивать, если мы тебе сейчас на полчаса что-нибудь уменьшим, чего будет хорошего? Ни тот, ни другой не ответит. Вот эту картинку снизу вверх, сверху вниз приходится строить. Последний вопрос. Построили вы эти картинки, но никто вам, честно говоря, не скажет 20% или 25%. Точную цифру сложно назвать. И потом, как было сказано, есть всякие риски, всякие замечательные вероятности. Вот тут-то что с этим делать? Опять-таки в инвестиционных проектах нет никаких гарантий на самом деле. Когда вы разрабатываете инвестиционный проект, и рассказываете, что вот сейчас я буду зарабатывать вот столько денег, это нормальный проект, система свечного завода, свечка будет стоить столько. Но кто сказал, что она будет стоить столько? Кто сказал, что есть такой платежеспособный сегмент рынка? Очевидно это проблема присущая не только информационным технологиям, может она здесь еще хуже смотрится. Я постарался показать, что задача бюджетирования есть цикл. Из задачи бюджетирования вы получаете постановку. Уточняя постановку, вот так вот, аккуратно, организуете этот циклический процесс. На самом деле в первом приближении есть один из способов, - как говорится, давай так, он скажет цифру и вероятность, а мы перемножим оно на другое, получим матожидание. На наш взгляд это произвол, это загнание проблемы только глубже. Откуда он знает вероятность? Ниоткуда. А вот попробовать запросить интервал у человека, который занимается этим, - "откуда до куда?", - можно, интервал дают люди, глубоко сидящие внизу. Это плохо, конечно он может быть и 15%, и 20%. Вот вы набрали этих интервалов, дальше что делать? А дальше поначалу все просто, есть понятие анализ чувствительности. Программные продукты, считающие инвестиционные проекты это не проблема, значит вы просто аккуратно берете и качаете что происходит. Да, это достаточно заметная вычислительная работа, но ее понятно как делать. Дальше здесь работает правило Паретто, 20% людей выпивает 80% пива, 20% эффектов от общего количества дают 80% эффективности. Этот подход позволяет выбрать наиболее существенные факторы и зависимости.

И второй момент. Мы с этим столкнулись в практике. Ведь мы все время говорим внедрение типовых программных решений. Если мы говорим, что на коленке уже никто не разрабатывает, почему возникает идея допустимости типовых программных решений, более того, это вечный спор мышей и лягушек, когда приходит поставщик готового ERP-решения, и они начинают ругаться с заказчиком. Когда заказчик говорит, что мне твое готовое решение не нужно, у меня такие бизнес-процессы, быстро мне переписывай, чтобы было под меня. А он ему говорит, что я не буду переписывать под тебя, потому что за моими бизнес-процессами стоит мировой опыт, а у тебя просто бардак внутри, и поэтому этого так делать нельзя. Понятно, что истина лежит посередине, все нельзя изначально формализовать, но с другой стороны, если вы серьезно перерабатываете систему, то скорей всего, что-то у вас не так. Не могут все дружно ошибаться, хотя с другой стороны, понятна идея поставщика решений, чем меньше нарабатывать, тем эффективней он поработал. Если сама по себе идея типизации более или менее проходит, отсюда возникает, что есть более или менее типовые бизнес-процессы. Отсюда не следует, что цели будут близкими, у разных предприятий они могут быть немножко различны. Но чем ниже мы спускаемся вниз до IT-процедур, до тех вещей, которые поставляются типовыми программными средствами. Не возникает ли ощущения, что типовые программные средства дают примерно типовые, по крайней мере, на качественном уровне, результаты. Отсюда следует еще одна мысль, это нам удалось в первом приближении сделать, сейчас мы продолжаем этим заниматься, на одном российском очень распределенном предприятии была применена очень интересная схема внедрения ERP-систем, называлась метод последовательного прототипирования. Понятно, что происходит. Строился некий прототип, он внедрялся в одном месте, а поскольку таких мест похожих было очень много, после этого он рассылался на все места, и говорили, ребята, давай внедрять. Оттуда начинались крики, что это не так, это не так, это наоборот, эти крики аккуратно анализировались, и когда таких было достаточно много, в эталон вносились необходимые изменения. Так называемая тонкая настройка. И теперь новый эталон предлагался всем системам. Отсюда возникает и некоторая идея, что если есть типовые эталоны, возможно, есть, по крайней мере, на качественном уровне, за счет такого подхода типовые решения. Это не значит ни в коем разе, что мы перешли к тому, о чем я говорил в начале, в нашей отрасли тратят 1,5% от дохода, мы пришли к тому что похожие бизнес-процессы на похожих предприятиях, скорее всего, обслуживаются похожими IT-решениями, которые могут приводить к похожим на качественном уровне эффектам. А отсюда возникает некоторая идея библиотеки эффектов, кои мы тоже уже в настоящее время пробуем строить. Таким образом, когда мы приходим к кому-то с некоторыми вопросами, мы уже имеем в своих матрицах некоторые предложения, как бы это могло выглядеть. Это не значит, что это так будет у него, но это позволяет как-то организовать работу. Исходя из вышеизложенного, я рискую дать ответ на вопрос, вынесенный в заголовок нашей презентации положительный. Да, возможно, но это большой и достаточно серьезный труд, наиболее интересно что оценки этих вещей, а именно разработки бизнес-плана инвестиционного проекта и оценки эффективности информационных технологий, взятые из разных источников достаточно близко совпадают. По мнению специалистов в области IT, для того, чтобы оценить обоснованность или эффективность затрат на что-нибудь надо потратить примерно 1,5-2% от суммы этих затрат. Стоимость инвестиционного проекта составляет от 0,5 до 1,5% объема инвестиционных вложений.