Почему отделы воюют друг с другом
Есть наивная корпоративная сказка: отделы конфликтуют, потому что начальники вредные, сотрудники не договорились, а коммуникации опять «недостаточно прозрачные».
Нет! Не поэтому!
Отделы конфликтуют прежде всего потому, что у них объективно разные цели.
Продажи хотят гибкости. Производство хочет стабильности. Финансы хотят контроля. Клиент хочет скорости. Закупки хотят дешевле. Юристы хотят, чтобы ничего не произошло. Безопасность хочет, чтобы вообще никто не двигался без письменного разрешения. И все по-своему правы.
Ключевая причина здесь – функциональное управление.
Функция внутри компании всегда начинает жить как отдельная группа. У неё есть свои границы, ресурсы, вожди, угрозы и свой инстинкт самосохранения. А где есть группа, там быстро появляются очень древние механизмы поведения: защита территории, борьба за статус, контроль доступа к ресурсам, вытеснение конкурентов, демонстрация силы и коллективная рационализация всего этого под видом «интересов бизнеса».
На всё это полезно смотреть не через психологию, а через биологию и социологию группового поведения. Не «у директора по финансам травма контроля», а гораздо проще: стая защищает кормовую базу. Звучит грубо, зато работает.
Любая функция хочет три вещи:
во-первых, сохранить себя;
во-вторых, расширить зону влияния;
в-третьих, получить больше ресурсов и меньше внешнего контроля.
Причём это не обязательно злой умысел. Чаще это нормальное групповое поведение людей в организации. Они быстро начинают защищать не компанию вообще, а свой контур. Отсюда и типовая корпоративная картина.
Продажи обещают клиенту особые условия. Производство возмущается, потому что эти условия ломают план. Финансы требуют согласований, потому что видят риск по деньгам. Юристы вставляют ограничения, потому что им потом отвечать за формулировки. Сервис просит больше людей, потому что клиент уже орёт. Собственник спрашивает, почему маржа опять похожа на следы жизни после ядерной зимы.
И каждый участник в этот момент принимает решение не в одном измерении, а в двух. Первый риск – корпоративный: что это решение даст или испортит для компании. Второй риск – личный: что за это будет лично мне.И вот второй риск почти всегда ближе к телу. Потому что компания – это абстракция, а выговор, потеря статуса, конфликт с начальником, провал KPI или сокращение бюджета – вполне конкретные вещи. Биология, знаете ли, не читала корпоративную миссию на сайте.
Поэтому сотрудник может прекрасно понимать, что для компании выгоднее принять одно решение, но для себя безопаснее – другое.
Главная проблема функционального управления в том, что ни одна функция сама по себе не несёт прямой ответственности за итоговый результат компании. Продажи отвечают за продажи.
Производство – за выпуск. Финансы – за контроль денег. HR – за персонал. ИТ – за системы. СБ – за безопасность. Юристы – за правовую чистоту.
А за результат компании в целом? Обычно «все вместе». То есть никто.
И когда результат провален, начинается прекрасный корпоративный балет – поиск виноватого или крайнего.
Отдельно нужно сказать про руководителей функций. Реальный мотиватор функции во многом определяется мотиваторами её руководителя. А там часто не стратегия, не миссия и не «ценности компании», а вполне базовые вещи: власть, статус, контроль, доступ к ресурсам, влияние на решения, защита своей территории. В приличном кабинете, с хорошим костюмом и словами «операционная эффективность», но по сути – всё тот же древний механизм иерархии.
Именно поэтому функциональные конфликты нельзя лечить тренингами по коммуникации. Проблема не в том, что люди «не договорились».
Проблема в том, что архитектура управления создаёт устойчиво разнонаправленные цели.
Если компания хочет меньше внутренних войн, ей нужно не уговаривать функции «быть командой», а менять контур ответственности.
Должен появиться объект управления выше функции: процесс, продукт, клиентский результат, цепочка создания ценности, бизнес-система. То есть то, за что можно отвечать целиком, а не по кускам.
И это, пожалуй, главная мысль.
Хорошего дня!
Есть наивная корпоративная сказка: отделы конфликтуют, потому что начальники вредные, сотрудники не договорились, а коммуникации опять «недостаточно прозрачные».
Нет! Не поэтому!
Отделы конфликтуют прежде всего потому, что у них объективно разные цели.
Продажи хотят гибкости. Производство хочет стабильности. Финансы хотят контроля. Клиент хочет скорости. Закупки хотят дешевле. Юристы хотят, чтобы ничего не произошло. Безопасность хочет, чтобы вообще никто не двигался без письменного разрешения. И все по-своему правы.
Ключевая причина здесь – функциональное управление.
Функция внутри компании всегда начинает жить как отдельная группа. У неё есть свои границы, ресурсы, вожди, угрозы и свой инстинкт самосохранения. А где есть группа, там быстро появляются очень древние механизмы поведения: защита территории, борьба за статус, контроль доступа к ресурсам, вытеснение конкурентов, демонстрация силы и коллективная рационализация всего этого под видом «интересов бизнеса».
На всё это полезно смотреть не через психологию, а через биологию и социологию группового поведения. Не «у директора по финансам травма контроля», а гораздо проще: стая защищает кормовую базу. Звучит грубо, зато работает.
Любая функция хочет три вещи:
во-первых, сохранить себя;
во-вторых, расширить зону влияния;
в-третьих, получить больше ресурсов и меньше внешнего контроля.
Причём это не обязательно злой умысел. Чаще это нормальное групповое поведение людей в организации. Они быстро начинают защищать не компанию вообще, а свой контур. Отсюда и типовая корпоративная картина.
Продажи обещают клиенту особые условия. Производство возмущается, потому что эти условия ломают план. Финансы требуют согласований, потому что видят риск по деньгам. Юристы вставляют ограничения, потому что им потом отвечать за формулировки. Сервис просит больше людей, потому что клиент уже орёт. Собственник спрашивает, почему маржа опять похожа на следы жизни после ядерной зимы.
И каждый участник в этот момент принимает решение не в одном измерении, а в двух. Первый риск – корпоративный: что это решение даст или испортит для компании. Второй риск – личный: что за это будет лично мне.И вот второй риск почти всегда ближе к телу. Потому что компания – это абстракция, а выговор, потеря статуса, конфликт с начальником, провал KPI или сокращение бюджета – вполне конкретные вещи. Биология, знаете ли, не читала корпоративную миссию на сайте.
Поэтому сотрудник может прекрасно понимать, что для компании выгоднее принять одно решение, но для себя безопаснее – другое.
Главная проблема функционального управления в том, что ни одна функция сама по себе не несёт прямой ответственности за итоговый результат компании. Продажи отвечают за продажи.
Производство – за выпуск. Финансы – за контроль денег. HR – за персонал. ИТ – за системы. СБ – за безопасность. Юристы – за правовую чистоту.
А за результат компании в целом? Обычно «все вместе». То есть никто.
И когда результат провален, начинается прекрасный корпоративный балет – поиск виноватого или крайнего.
Отдельно нужно сказать про руководителей функций. Реальный мотиватор функции во многом определяется мотиваторами её руководителя. А там часто не стратегия, не миссия и не «ценности компании», а вполне базовые вещи: власть, статус, контроль, доступ к ресурсам, влияние на решения, защита своей территории. В приличном кабинете, с хорошим костюмом и словами «операционная эффективность», но по сути – всё тот же древний механизм иерархии.
Именно поэтому функциональные конфликты нельзя лечить тренингами по коммуникации. Проблема не в том, что люди «не договорились».
Проблема в том, что архитектура управления создаёт устойчиво разнонаправленные цели.
Если компания хочет меньше внутренних войн, ей нужно не уговаривать функции «быть командой», а менять контур ответственности.
Должен появиться объект управления выше функции: процесс, продукт, клиентский результат, цепочка создания ценности, бизнес-система. То есть то, за что можно отвечать целиком, а не по кускам.
И это, пожалуй, главная мысль.
Хорошего дня!
👍10🔥8💯4❤3🤔1
Совещание как симптом плохой архитектуры
Если для нормальной координации работы вам постоянно нужны совещания, значит, вы не управляете – вы вручную компенсируете отсутствие управления.
Совещание – это потеря рабочего времени. Всегда! Даже хорошее. Потому, что в это время компания «не продает», не создаёт ценности. Просто иногда это оправдано, как выбор из двух зол – неверным решением и потерей продуктивного времени.
Совещания – не проблема календаря, секретаря или того несчастного человека, который «не так составил повестку». Совещания – это симптом архитектуры. Они показывают, что в компании не определены роли, границы ответственности, права решений и нормальные маршруты эскалации. Люди собираются не потому, что никто не понимает, кто имеет право решить проблему без коллективного обряда.
Компания зовёт людей в переговорку, когда не может ответить на четыре простых вопроса:
– кто владелец вопроса;
– кто принимает решение;
– кто имеет право возражать;
– кто потом отвечает за последствия.
Если ответов нет, появляется совещание. Такой корпоративный спиритический сеанс: все собрались вызвать дух ответственности, но он опять не пришёл.
Особенно смешны регулярные планёрки. Это когда десятки взрослых людей раз в неделю рассказывают друг другу, что у них происходит. Возникает простой вопрос, друзья, а почему система управления не знает этого без вашего устного пересказа?
Если руководителю нужно собрать людей, чтобы узнать статус работ, значит, у него нет контура контроля. Если подразделения не могут синхронизироваться без общего собрания, значит, у них не настроены интерфейсы. Если решение нельзя принять без присутствия половины штатного состава, значит, полномочия размазаны как масло тонким слоем по бутерброду.
И это уже не «культура коммуникаций». Это управленческая импотенция.
Значит ли это, что совещания вообще не нужны? Нет. Иногда нужны.
Совещание допустимо, когда есть реальная эскалация: конкретный вопрос, препятствие, решение, которое находится выше полномочий исполнителя. Не «давайте обсудим», а «вот развилка, вот последствия, вот что нужно решить».
Совещание допустимо, когда требуется выработка коллективного решения. Потому, что разные компетенции действительно меняют качество решения в нестандартной ситуации.
Совещание допустимо, когда нужно согласовать конфликт интересов между функциями. Но и тогда не надо созывать Великий Народный Хурал с участием всех племён и их шаманов. Нужны только те, кто влияет на конкретные решение или несёт ответственность за их последствия. Все остальные – зрители. А зрителей в рабочее время надо отправлять работать.
Есть ещё одно важное правило: если вы хотите получить настоящую инициативу снизу, обсуждение решения должно идти от младших к старшим.
Сначала говорят специалисты и исполнители. Потом руководители среднего уровня. Потом старшие. И только в конце – главный начальник, если он вообще нужен.
Почему так? Потому что если первым говорит Большой Босс, совещание заканчивается сразу. Дальше начинается не обсуждение, а конкурс художественного согласия. Люди начинают угадывать правильную интонацию, а не искать правильное решение.
В нормальной системе младший работник сначала докладывает обстановку и предлагает вариант. Старшие уточняют, проверяют, усиливают, ограничивают риск, а не давят инициативу своим авторитетом ещё до того, как она успела родиться.
Вообще, хорошее совещание должно быть редким, коротким и опасным для бездельников.
У него должен быть предмет, владелец, ожидаемый результат, список решений, ответственные за них исполнители. А если чего-то из этого нет – это групповая имитация управления.
Лечить надо не календарь – лечить надо систему.
Определить роли.
Назначить владельцев решений.
Развести зоны ответственности.
Настроить правила эскалации.
Сделать видимым статус работ.
Одним словом, нужно убрать необходимость человеческого хоровода там, где должна работать управленческая машина. И тогда выяснится, что большинство совещаний были попросту не нужны.
Хороших вам выходных!
#управление #производительность #совещания
Если для нормальной координации работы вам постоянно нужны совещания, значит, вы не управляете – вы вручную компенсируете отсутствие управления.
Совещание – это потеря рабочего времени. Всегда! Даже хорошее. Потому, что в это время компания «не продает», не создаёт ценности. Просто иногда это оправдано, как выбор из двух зол – неверным решением и потерей продуктивного времени.
Совещания – не проблема календаря, секретаря или того несчастного человека, который «не так составил повестку». Совещания – это симптом архитектуры. Они показывают, что в компании не определены роли, границы ответственности, права решений и нормальные маршруты эскалации. Люди собираются не потому, что никто не понимает, кто имеет право решить проблему без коллективного обряда.
Компания зовёт людей в переговорку, когда не может ответить на четыре простых вопроса:
– кто владелец вопроса;
– кто принимает решение;
– кто имеет право возражать;
– кто потом отвечает за последствия.
Если ответов нет, появляется совещание. Такой корпоративный спиритический сеанс: все собрались вызвать дух ответственности, но он опять не пришёл.
Особенно смешны регулярные планёрки. Это когда десятки взрослых людей раз в неделю рассказывают друг другу, что у них происходит. Возникает простой вопрос, друзья, а почему система управления не знает этого без вашего устного пересказа?
Если руководителю нужно собрать людей, чтобы узнать статус работ, значит, у него нет контура контроля. Если подразделения не могут синхронизироваться без общего собрания, значит, у них не настроены интерфейсы. Если решение нельзя принять без присутствия половины штатного состава, значит, полномочия размазаны как масло тонким слоем по бутерброду.
И это уже не «культура коммуникаций». Это управленческая импотенция.
Значит ли это, что совещания вообще не нужны? Нет. Иногда нужны.
Совещание допустимо, когда есть реальная эскалация: конкретный вопрос, препятствие, решение, которое находится выше полномочий исполнителя. Не «давайте обсудим», а «вот развилка, вот последствия, вот что нужно решить».
Совещание допустимо, когда требуется выработка коллективного решения. Потому, что разные компетенции действительно меняют качество решения в нестандартной ситуации.
Совещание допустимо, когда нужно согласовать конфликт интересов между функциями. Но и тогда не надо созывать Великий Народный Хурал с участием всех племён и их шаманов. Нужны только те, кто влияет на конкретные решение или несёт ответственность за их последствия. Все остальные – зрители. А зрителей в рабочее время надо отправлять работать.
Есть ещё одно важное правило: если вы хотите получить настоящую инициативу снизу, обсуждение решения должно идти от младших к старшим.
Сначала говорят специалисты и исполнители. Потом руководители среднего уровня. Потом старшие. И только в конце – главный начальник, если он вообще нужен.
Почему так? Потому что если первым говорит Большой Босс, совещание заканчивается сразу. Дальше начинается не обсуждение, а конкурс художественного согласия. Люди начинают угадывать правильную интонацию, а не искать правильное решение.
В нормальной системе младший работник сначала докладывает обстановку и предлагает вариант. Старшие уточняют, проверяют, усиливают, ограничивают риск, а не давят инициативу своим авторитетом ещё до того, как она успела родиться.
Вообще, хорошее совещание должно быть редким, коротким и опасным для бездельников.
У него должен быть предмет, владелец, ожидаемый результат, список решений, ответственные за них исполнители. А если чего-то из этого нет – это групповая имитация управления.
Лечить надо не календарь – лечить надо систему.
Определить роли.
Назначить владельцев решений.
Развести зоны ответственности.
Настроить правила эскалации.
Сделать видимым статус работ.
Одним словом, нужно убрать необходимость человеческого хоровода там, где должна работать управленческая машина. И тогда выяснится, что большинство совещаний были попросту не нужны.
Хороших вам выходных!
#управление #производительность #совещания
👍14🔥6💯3🤔1
Media is too big
VIEW IN TELEGRAM
Как и обещал, делюсь выступлением Алексея Игнатюка на III Практической конференции КОМОС ЦЕС «Инструменты повышения операционной эффективности бизнеса».
Человеческий фактор как неучтённый резерв бизнеса
В этом видео и презентации Алексей показывает практичный взгляд на одну из главных управленческих задач: как добиться лучшего соответствия между талантами человека, его функционалом и условиями работы.
Не «искать кентавра», а точнее понимать сильные стороны сотрудников и настраивать систему так, чтобы росли продуктивность, лояльность и результат компании.
В основе его подхода – идея синергии технологий и талантов: от диагностики способностей до изменения функционала, условий труда и повышения соответствия роли человеку. В презентации показан переход от условных 50% соответствия к 83% за счёт грамотной настройки функций и среды.
Хороший материал для руководителей, HR и всех, кто занимается развитием организаций не лозунгами, а инженерно – через систему, роли и людей.
#управление #менеджмент #hr #bpm
Человеческий фактор как неучтённый резерв бизнеса
В этом видео и презентации Алексей показывает практичный взгляд на одну из главных управленческих задач: как добиться лучшего соответствия между талантами человека, его функционалом и условиями работы.
Не «искать кентавра», а точнее понимать сильные стороны сотрудников и настраивать систему так, чтобы росли продуктивность, лояльность и результат компании.
В основе его подхода – идея синергии технологий и талантов: от диагностики способностей до изменения функционала, условий труда и повышения соответствия роли человеку. В презентации показан переход от условных 50% соответствия к 83% за счёт грамотной настройки функций и среды.
Хороший материал для руководителей, HR и всех, кто занимается развитием организаций не лозунгами, а инженерно – через систему, роли и людей.
#управление #менеджмент #hr #bpm
❤4👍3🔥2
Когда методика начинает жить без автора
Иногда лучший результат методологии – это когда тебя рядом нет. Не в смысле «ушёл пить кофе и забыл про клиента», а в хорошем инженерном смысле – люди сами взяли подход, разобрались, применили его к реальному предприятию – и получили рабочий управленческий инструмент, а не красивую папку с диаграммами.
На конференции в своей презентации Самарский «Электрощит» показал практику реального применения объектно-ориентированного подхода (ООП) к моделированию бизнес-системы машиностроительного предприятия и его внедрению.
В выступлении приводятся множество цифр полученного эффекта, показано внедрение ИИ на отдельных участках. Это здорово! Но лично для меня главный результат даже не в этих цифрах.
Главное – команда начала смотреть на предприятие как на целостную бизнес-систему – через бизнес-объекты, жизненные циклы, состояния, метрики результативности и эффективности, взаимодействия между процессами. Именно здесь начинается настоящее управление.
Не «нарисовали процесс». Не «повесили KPI». Не «прикрутили ИИ». А разобрали, какие объекты проходят через систему, в каком состоянии они находятся, кто и как переводит их в следующее состояние, где возникают потери, где ломается синхронизация и какие метрики действительно показывают качество работы.
И конечно, снимаю шляпу перед Элиной Манаховой – провести год реформ, создать 117 точек роста и 6 проектов организационного развития – это громадная работа и ответственность. Вот это уже не презентационный шум. Это нормальная управленческая работа: нашли, где система трётся шестерёнками, и превратили это в программу изменений.
Тогда и ИИ «зашёл». Не снизу: «давайте автоматизируем вот эту кнопку». И не сверху: «давайте срочно внедрим искусственный интеллект, потому что все внедряют». А через архитектуру бизнеса. Без шаманства, без корпоративной магии и без очередного «цифрового трансформационного шампура».
Для меня это хороший пример того, как нужно работать бизнес-архитектору, как реализовывать системные проекты, как должна внедряться цифровизация. И если говорить о том, какой бы проект я вынес, как лучший BPM проект 2026 года, то мой выбор был бы однозначным – этот!
Хорошего вам дня!
#управление #менеджмент #ооп #bpm
Иногда лучший результат методологии – это когда тебя рядом нет. Не в смысле «ушёл пить кофе и забыл про клиента», а в хорошем инженерном смысле – люди сами взяли подход, разобрались, применили его к реальному предприятию – и получили рабочий управленческий инструмент, а не красивую папку с диаграммами.
На конференции в своей презентации Самарский «Электрощит» показал практику реального применения объектно-ориентированного подхода (ООП) к моделированию бизнес-системы машиностроительного предприятия и его внедрению.
В выступлении приводятся множество цифр полученного эффекта, показано внедрение ИИ на отдельных участках. Это здорово! Но лично для меня главный результат даже не в этих цифрах.
Главное – команда начала смотреть на предприятие как на целостную бизнес-систему – через бизнес-объекты, жизненные циклы, состояния, метрики результативности и эффективности, взаимодействия между процессами. Именно здесь начинается настоящее управление.
Не «нарисовали процесс». Не «повесили KPI». Не «прикрутили ИИ». А разобрали, какие объекты проходят через систему, в каком состоянии они находятся, кто и как переводит их в следующее состояние, где возникают потери, где ломается синхронизация и какие метрики действительно показывают качество работы.
И конечно, снимаю шляпу перед Элиной Манаховой – провести год реформ, создать 117 точек роста и 6 проектов организационного развития – это громадная работа и ответственность. Вот это уже не презентационный шум. Это нормальная управленческая работа: нашли, где система трётся шестерёнками, и превратили это в программу изменений.
Тогда и ИИ «зашёл». Не снизу: «давайте автоматизируем вот эту кнопку». И не сверху: «давайте срочно внедрим искусственный интеллект, потому что все внедряют». А через архитектуру бизнеса. Без шаманства, без корпоративной магии и без очередного «цифрового трансформационного шампура».
Для меня это хороший пример того, как нужно работать бизнес-архитектору, как реализовывать системные проекты, как должна внедряться цифровизация. И если говорить о том, какой бы проект я вынес, как лучший BPM проект 2026 года, то мой выбор был бы однозначным – этот!
Хорошего вам дня!
#управление #менеджмент #ооп #bpm
👍6❤4🔥3
Друзья!
📆 20 мая, среда, 19:00 мск состоится zoom-встреча, посвященная теме объектно- ориентированного подхода (ООП) к управлению.
Передовым опытом поделится Элина Манахова, руководитель процессного офиса АО "Электрощит", бизнес-архитектор.
📌Несколько фактов о Элине:
- опыт управления >20 лет
- с 2023-го применяет ООП по книге "Инжиниринг корпорации"
- в 2025 изучила курс Концетуального мышления
- 08.04.2026 статья "ООП и процессное управление для цифровизации" на op-ex.ru
- 17.04.2026 – один из лучших докладов на III-й Практической конференции
"Инструменты повышения операционной эффективности бизнеса" – Практика применения ООП к моделированию бизнес-системы машиностроительного предприятия.
💫По участию пишите @AIgnatyuk
#ООП #КультивацияМышления
📆 20 мая, среда, 19:00 мск состоится zoom-встреча, посвященная теме объектно- ориентированного подхода (ООП) к управлению.
Передовым опытом поделится Элина Манахова, руководитель процессного офиса АО "Электрощит", бизнес-архитектор.
📌Несколько фактов о Элине:
- опыт управления >20 лет
- с 2023-го применяет ООП по книге "Инжиниринг корпорации"
- в 2025 изучила курс Концетуального мышления
- 08.04.2026 статья "ООП и процессное управление для цифровизации" на op-ex.ru
- 17.04.2026 – один из лучших докладов на III-й Практической конференции
"Инструменты повышения операционной эффективности бизнеса" – Практика применения ООП к моделированию бизнес-системы машиностроительного предприятия.
💫По участию пишите @AIgnatyuk
#ООП #КультивацияМышления
❤5👍2
Пять стадий принятия ИИ
Недавно произошла забавная история с одним моим клиентом. Компания выходит на новый рынок. Для этого наняли человека и попросили его составить план работ.
Человек план составил. А в сопроводительном письме честно написал, что использовал ИИ.
И тут у руководителя возник естественный корпоративный вопрос: «А так можно было? А это вообще он сделал или ИИ?»
С этого обычно и начинаются пять стадий принятия ИИ в компании.
Первая стадия – отрицание.
«Нет, так нельзя. Нам нужен план, который сделал сам человек».
При этом никто не требует от сотрудников писать документы гусиным пером, считать бюджет на счётах и искать аналитику в подшивках журнала «Экономика и жизнь» за 1987 год.
Excel можно. Google можно. PowerPoint можно.
А вот ИИ – подозрительно.
Наверное потому, что Excel хотя бы молчит.
Вторая стадия – тревога.
В комнате появляется служба безопасности.
Как системное уведомление Windows – внезапно, поверх всех окон и с правами администратора.
И начинаются вопросы. Какие данные он туда загрузил? Куда они ушли? Кто их видел? Почему мы об этом не знали? Где регламент? Почему регламент ещё не согласован? Кто согласовал отсутствие регламента?
Тут важно признать – вопросы правильные. Просто иногда их задают так, будто сотрудник не план рынка составил, а вынес серверную в целлофаном пакете через проходную. Да и адекватными они были бы в совершенно ином контексте. До, а не после.
Третья стадия – принятие через совещание.
На нём выясняется, что ИИ используют многие, нужен всем, но отвечать за него не хочет никто.
Половина компании уже тайно гоняет письма через ChatGPT, вторая половина просит нейросеть «сделать красиво», а руководитель получает от неё тезисы к совещанию и считает, что это просто его помощник за ночь сваял.
В итоге обсуждают не качество плана, а моральную чистоту его происхождения. Как будто плохой план, написанный человеком вручную, становится лучше от того, что он страдал лично.
Вот в этот момент и обратились ко мне, мол рассуди!
Моя логика была простой.
Вопрос не в том, пользовался ли человек ИИ. Вопрос в другом.
Понял ли он задачу? Проверил ли результат? Увидел ли риски? Отличил ли полезное от красивого? И главное – готов ли ли он отвечать за предложенный план?
Если человек составил план с помощью Excel, мы не говорим: «Это не он посчитал, это Excel».
Если он подготовил презентацию в PowerPoint, мы не спрашиваем, «кто настоящий автор слайда – сотрудник или Microsoft?»
Если сотрудник нашёл данные через Google, мы не пишем в KPI: «Самостоятельность снижена, пользовался поиском».
И оказалось, что все в порядке!
Тогда компания это приняла и пошла дальше.
Четвёртая стадия – пилот.
Чтобы разобраться, запускают безопасный эксперимент.
Берут задачу, убирают из неё реальные данные, контекст, рынок, клиентов, конкурентов, сроки, бюджет и всё, что могло бы иметь хоть какой-то смысл. Потом просят ИИ подготовить решение задачи с обезличенным продуктом для обезличенного клиента на обезличенном рынке.
ИИ выдаёт обезличенный результат.
После чего кто-то говорит: «Ну что-то... пока не впечатляет».
Что дальше? Будет попытка перейти к пятой стадии.
Пятая стадия – взросление.
До неё доходят не все.
На этой стадии компания наконец понимает простую вещь – ИИ надо не запрещать и не боготворить, а встраивать в нормальный управленческий контур: определить, какие задачи ему можно отдавать, какие данные нельзя загружать, кто проверяет результат, кто принимает решение и кто за него отвечает.
И главное.
ИИ не отменяет автора. ИИ не снимает ни с человека, ни с компании ответственности. Он отменяет некоторые ритуальные страдания.
А это для компании, конечно же, всегда удар.
Проблема не в том, что человек использовал ИИ.
Проблема была бы, если бы он использовал ИИ вместо головы. Но это, кстати, возможно и без ИИ. В корпорациях такой режим давно поддерживается штатно.
Хороших вам выходных!
#ИИ #управление
#пятничное
Недавно произошла забавная история с одним моим клиентом. Компания выходит на новый рынок. Для этого наняли человека и попросили его составить план работ.
Человек план составил. А в сопроводительном письме честно написал, что использовал ИИ.
И тут у руководителя возник естественный корпоративный вопрос: «А так можно было? А это вообще он сделал или ИИ?»
С этого обычно и начинаются пять стадий принятия ИИ в компании.
Первая стадия – отрицание.
«Нет, так нельзя. Нам нужен план, который сделал сам человек».
При этом никто не требует от сотрудников писать документы гусиным пером, считать бюджет на счётах и искать аналитику в подшивках журнала «Экономика и жизнь» за 1987 год.
Excel можно. Google можно. PowerPoint можно.
А вот ИИ – подозрительно.
Наверное потому, что Excel хотя бы молчит.
Вторая стадия – тревога.
В комнате появляется служба безопасности.
Как системное уведомление Windows – внезапно, поверх всех окон и с правами администратора.
И начинаются вопросы. Какие данные он туда загрузил? Куда они ушли? Кто их видел? Почему мы об этом не знали? Где регламент? Почему регламент ещё не согласован? Кто согласовал отсутствие регламента?
Тут важно признать – вопросы правильные. Просто иногда их задают так, будто сотрудник не план рынка составил, а вынес серверную в целлофаном пакете через проходную. Да и адекватными они были бы в совершенно ином контексте. До, а не после.
Третья стадия – принятие через совещание.
На нём выясняется, что ИИ используют многие, нужен всем, но отвечать за него не хочет никто.
Половина компании уже тайно гоняет письма через ChatGPT, вторая половина просит нейросеть «сделать красиво», а руководитель получает от неё тезисы к совещанию и считает, что это просто его помощник за ночь сваял.
В итоге обсуждают не качество плана, а моральную чистоту его происхождения. Как будто плохой план, написанный человеком вручную, становится лучше от того, что он страдал лично.
Вот в этот момент и обратились ко мне, мол рассуди!
Моя логика была простой.
Вопрос не в том, пользовался ли человек ИИ. Вопрос в другом.
Понял ли он задачу? Проверил ли результат? Увидел ли риски? Отличил ли полезное от красивого? И главное – готов ли ли он отвечать за предложенный план?
Если человек составил план с помощью Excel, мы не говорим: «Это не он посчитал, это Excel».
Если он подготовил презентацию в PowerPoint, мы не спрашиваем, «кто настоящий автор слайда – сотрудник или Microsoft?»
Если сотрудник нашёл данные через Google, мы не пишем в KPI: «Самостоятельность снижена, пользовался поиском».
И оказалось, что все в порядке!
Тогда компания это приняла и пошла дальше.
Четвёртая стадия – пилот.
Чтобы разобраться, запускают безопасный эксперимент.
Берут задачу, убирают из неё реальные данные, контекст, рынок, клиентов, конкурентов, сроки, бюджет и всё, что могло бы иметь хоть какой-то смысл. Потом просят ИИ подготовить решение задачи с обезличенным продуктом для обезличенного клиента на обезличенном рынке.
ИИ выдаёт обезличенный результат.
После чего кто-то говорит: «Ну что-то... пока не впечатляет».
Что дальше? Будет попытка перейти к пятой стадии.
Пятая стадия – взросление.
До неё доходят не все.
На этой стадии компания наконец понимает простую вещь – ИИ надо не запрещать и не боготворить, а встраивать в нормальный управленческий контур: определить, какие задачи ему можно отдавать, какие данные нельзя загружать, кто проверяет результат, кто принимает решение и кто за него отвечает.
И главное.
ИИ не отменяет автора. ИИ не снимает ни с человека, ни с компании ответственности. Он отменяет некоторые ритуальные страдания.
А это для компании, конечно же, всегда удар.
Проблема не в том, что человек использовал ИИ.
Проблема была бы, если бы он использовал ИИ вместо головы. Но это, кстати, возможно и без ИИ. В корпорациях такой режим давно поддерживается штатно.
Хороших вам выходных!
#ИИ #управление
#пятничное
👍6🔥3❤1
Начал делать серию постов о бюджетировании на основе процессов. Тема уложится в примерно в 10 постов. Конечно только основные идеи.
Но ресурс мой ограничен. Поэтому решил остановиться и спросить вас, а оно вам вообще интересно?
Но ресурс мой ограничен. Поэтому решил остановиться и спросить вас, а оно вам вообще интересно?
Anonymous Poll
72%
Да, очень нужно!
29%
Ну, интересно будет почитать о чем это
0%
Нафиг! Нам и обычного бюджетирования хватает
0%
А мы и без бюджетов не плохо живет
3%
Расскажи лучше о... (напишу в комментарии)
🔥4👍3
Бюджетирование на основе процессов.
Часть 1. Бюджетирование начинается не с бюджета
Большинство компаний уверены, что у них есть бюджетирование. Но открою вам секрет: как правило, они вообще ничего не бюджетируют! Ничего!!!
А как же БДР, БДДС и другие аббревиатуры, напоминающие своим звучанием работу отбойного молотка? Все эти документы полезны. Иногда даже очень. Но сами по себе они не являются бюджетами в управленческом смысле – это документы финансового планирования. Они описывают ожидаемые доходы, расходы и движение денег. Но это не делает их бюджетами.
То есть, очень часто финансовое планирование принимают за бюджетирование. Но финансовый план отвечает на вопрос, а «что будет с деньгами?» и показывает ожидаемую картину.
Бюджет же отвечает на другой вопрос – «какие действия мы разрешаем выполнить, за какие ресурсы и ради какого результата?» Бюджет – это не таблица будущих расходов, а управленческая гипотеза о том,
– какие действия нужно выполнить,
– сколько ресурсов они потребуют и
– какой результат (и не обязательно финансовый) они должны дать.
Документы финансового планирования показывают ожидаемые последствия деятельности, но не саму деятельность. Они агрегируют финансовую картину, а не управляют тем, где рождается результат. И от того, что вы произнесёте слово «бюджет» он не появится. Как не станет слаще от произнесения слова «халва».
Так что же такое бюджет? В классическом подходе – это договор между подразделением и компанией, в котором отражается:
– что компания получит от подразделения (доходная часть),
– какие ресурсы (и финансовые среди прочего) получит подразделение, чтобы получить эти результаты (расходная часть).
То есть в классическом подходе бюджет – это атрибут организационной единицы. Через бюджет, в отличие от финансового плана, можно (и должно) управлять деятельностью конкретных организационных единиц.
По аналогии и в бюджетировании на основе процессов бюджет – это тоже договор. Но в отличие от «классики» в процессном бюджетировании бюджет – атрибут процесса. Да, процессный бюджет можно свернуть к подразделению, продукту, проекту, клиенту, P&L. Но первичная логика другая – сначала планируем затраты процесса, а потом сворачиваем их в любом заранее выбранном аналитическом разрезе.
Безотносительно того, идете вы по пути классического бюджетирования, либо собрались строить бюджетирование на основе процессов, настоящее бюджетирование начинается с поиска ответов на вопросы:
– Какую деятельность мы собираемся выполнять?
– Какие результаты этой деятельности мы ожидаем получить?
– Сколько это будет стоить для нас?
– Каким образом мы будем считать эту стоимость?
И вот здесь разумно задать вопрос: зачем нужно процессное бюджетирование, если есть «классика»?
Процессное бюджетирование лучше «классики» потому, что оно ближе к месту, где реально возникает результат и сгорают ресурсы. Классика обычно отвечает на вопрос, сколько денег дать подразделению. Процессное бюджетирование отвечает на другой вопрос – какие действия нужно выполнить, чтобы получить результат, и сколько ресурсов эти действия потребуют? В этом и разница:
– Классическое бюджетирование прежде всего управляет лимитами и ответственностью подразделений. Процессное – стоимостью действий.
– Классика бюджетирует владельцев расходов. Процессное бюджетирует деятельность.
– Классика хорошо показывает, кто потратил. Процессное показывает, зачем потратили.
– Классика режет расходы. Процессное позволяет менять способ работы.
– Классика часто убивает результативность ради эффективности. Процессное держит связку результативность-эффективность-производительность-риск.
– Классика плохо работает с кросс-функциональной деятельностью. Процессное видит работу поперёк подразделений.
– Классика даёт бюджет как лимит. Процессное даёт бюджет как управленческую гипотезу.
То есть классическое бюджетирование управляет расходами. Процессное бюджетирование управляет стоимостью действий. И именно поэтому оно позволяет принимать решения не о том, кому урезать деньги, а о том, как улучшить работу компании.
#бюджетирование #планирование #управление #менеджмент
Часть 1. Бюджетирование начинается не с бюджета
Большинство компаний уверены, что у них есть бюджетирование. Но открою вам секрет: как правило, они вообще ничего не бюджетируют! Ничего!!!
А как же БДР, БДДС и другие аббревиатуры, напоминающие своим звучанием работу отбойного молотка? Все эти документы полезны. Иногда даже очень. Но сами по себе они не являются бюджетами в управленческом смысле – это документы финансового планирования. Они описывают ожидаемые доходы, расходы и движение денег. Но это не делает их бюджетами.
То есть, очень часто финансовое планирование принимают за бюджетирование. Но финансовый план отвечает на вопрос, а «что будет с деньгами?» и показывает ожидаемую картину.
Бюджет же отвечает на другой вопрос – «какие действия мы разрешаем выполнить, за какие ресурсы и ради какого результата?» Бюджет – это не таблица будущих расходов, а управленческая гипотеза о том,
– какие действия нужно выполнить,
– сколько ресурсов они потребуют и
– какой результат (и не обязательно финансовый) они должны дать.
Документы финансового планирования показывают ожидаемые последствия деятельности, но не саму деятельность. Они агрегируют финансовую картину, а не управляют тем, где рождается результат. И от того, что вы произнесёте слово «бюджет» он не появится. Как не станет слаще от произнесения слова «халва».
Так что же такое бюджет? В классическом подходе – это договор между подразделением и компанией, в котором отражается:
– что компания получит от подразделения (доходная часть),
– какие ресурсы (и финансовые среди прочего) получит подразделение, чтобы получить эти результаты (расходная часть).
То есть в классическом подходе бюджет – это атрибут организационной единицы. Через бюджет, в отличие от финансового плана, можно (и должно) управлять деятельностью конкретных организационных единиц.
По аналогии и в бюджетировании на основе процессов бюджет – это тоже договор. Но в отличие от «классики» в процессном бюджетировании бюджет – атрибут процесса. Да, процессный бюджет можно свернуть к подразделению, продукту, проекту, клиенту, P&L. Но первичная логика другая – сначала планируем затраты процесса, а потом сворачиваем их в любом заранее выбранном аналитическом разрезе.
Безотносительно того, идете вы по пути классического бюджетирования, либо собрались строить бюджетирование на основе процессов, настоящее бюджетирование начинается с поиска ответов на вопросы:
– Какую деятельность мы собираемся выполнять?
– Какие результаты этой деятельности мы ожидаем получить?
– Сколько это будет стоить для нас?
– Каким образом мы будем считать эту стоимость?
И вот здесь разумно задать вопрос: зачем нужно процессное бюджетирование, если есть «классика»?
Процессное бюджетирование лучше «классики» потому, что оно ближе к месту, где реально возникает результат и сгорают ресурсы. Классика обычно отвечает на вопрос, сколько денег дать подразделению. Процессное бюджетирование отвечает на другой вопрос – какие действия нужно выполнить, чтобы получить результат, и сколько ресурсов эти действия потребуют? В этом и разница:
– Классическое бюджетирование прежде всего управляет лимитами и ответственностью подразделений. Процессное – стоимостью действий.
– Классика бюджетирует владельцев расходов. Процессное бюджетирует деятельность.
– Классика хорошо показывает, кто потратил. Процессное показывает, зачем потратили.
– Классика режет расходы. Процессное позволяет менять способ работы.
– Классика часто убивает результативность ради эффективности. Процессное держит связку результативность-эффективность-производительность-риск.
– Классика плохо работает с кросс-функциональной деятельностью. Процессное видит работу поперёк подразделений.
– Классика даёт бюджет как лимит. Процессное даёт бюджет как управленческую гипотезу.
То есть классическое бюджетирование управляет расходами. Процессное бюджетирование управляет стоимостью действий. И именно поэтому оно позволяет принимать решения не о том, кому урезать деньги, а о том, как улучшить работу компании.
#бюджетирование #планирование #управление #менеджмент
❤10🔥8👍3
Бюджетирование на основе процессов.
Часть 2. Бухгалтерский учет не виноват.
Любое настоящее бюджетирование живет на учете. И видов этого учета уйма – финансовый, налоговый, бухгалтерский, управленческий. И возникает вопрос, на чем строить бюджетирование?
Ответ неприятный, но честный: не на базе бухгалтерского. И здесь не надо начинать войну с бухгалтерами. Бухгалтеры не виноваты. Более того, хороший бухгалтер – полезнейшее существо. Почти как домашний кот, только вместо мышей ловит налоговые риски.
Проблема в другом. Бухгалтерский учет не предназначен для управления вообще. У него другая задача – государство должно понимать, как оценить ваш бизнес. Оно хочет иметь информацию о результатах вашей деятельности. А налоговый учет нужен еще уже – чтобы государство понимало, сколько налогов с вас брать.
Например, бухгалтерская себестоимость показывает не «истинную стоимость продукции», а стоимость, собранную по правилам учета, которые установило государство. А правила учета пишутся не для того, чтобы собственник или менеджер понял, где у него сгорают деньги.
Более того, процессный бюджет интересует совсем другое. Его интересует не столько конечная себестоимость продукции, сколько то, как эта стоимость формируется. И уже на основе этого можно будет принять то или иное решение.
Бухгалтерский учет обычно работает с периодами, счетами, проводками, требованиями отчетности и правилами признания затрат. Процессный управленческий учет – с действиями, ресурсами, результатами, ответственностью, качеством и рисками.
Бухгалтерский учет отвечает перед государством. Управленческий – перед здравым смыслом.
Следовательно, раз разные задачи, то системы должны быть разными.
Именно поэтому при бюджетировании процессов неизбежно придется отделять управленческий учет от бухгалтерского. Прежде всего потому, что в итоге вы получите совершенно несопоставимые оценки. И если бухгалтерская себестоимость не совпадет с управленческой – это не ошибка. Это нормально. А если совпали, то не радуйтесь – скорее всего, это ошибка.
Например, амортизация оборудования может быть важна для бухгалтерии. Но в процессном учете нас интересует не бухгалтерская тень актива, а стоимость использования мощности: машино-час, смена, цикл, загрузка линии, простой, ремонт, энергия, оператор. Станок не «амортизируется» в процессе. В процессе потребляется его доступная производственная мощность.
То же самое с ФОТ. Оклад возникает как обязательство в одном месте, рабочее время потребляется в другом, а результат производится в третьем, а налоги на труд – в четвертом. Если просто повесить ФОТ на подразделение, мы узнаем стоимость подразделения. Но не узнаем стоимость работы.
И вот здесь возникает главное следствие. Когда компания пытается использовать бухгалтерский учет как основу для управления процессами, она нагружает бухгалтерию чужими функциями. Бухгалтерия начинает изображать управленческую аналитику, управленцы начинают ругаться на «не те цифры», а собственник смотрит на отчеты и чувствует, что где-то его аккуратно обманули. Причем, возможно, без злого умысла.
Лучший путь – освободить бухгалтерский учет от несвойственной ему задачи поддержки управленческих решений. Пусть бухгалтерия занимается бухгалтерией. Это нормальная, важная и достаточно формализованная функция. Именно поэтому она хорошо поддается стандартизации, регламентации и в конечном итоге – аутсорсингу.
А управленческий учет надо строить отдельно – под реальные решения, которые принимает компания. В процессном бюджетировании это особенно важно. Потому что здесь планируются не просто расходы, а стоимость деятельности. Поэтому учет должен показывать не только «что потрачено», но и «на что потрачено», «какой результат получен» и «кто отвечает за этот результат».
Так что, бухгалтерский учет не виноват. Виноваты те, кто пытается управлять бизнесом через… бухгалтерию.
#бюджетирование #управленческийучет #процессы #менеджмент
Часть 2. Бухгалтерский учет не виноват.
Любое настоящее бюджетирование живет на учете. И видов этого учета уйма – финансовый, налоговый, бухгалтерский, управленческий. И возникает вопрос, на чем строить бюджетирование?
Ответ неприятный, но честный: не на базе бухгалтерского. И здесь не надо начинать войну с бухгалтерами. Бухгалтеры не виноваты. Более того, хороший бухгалтер – полезнейшее существо. Почти как домашний кот, только вместо мышей ловит налоговые риски.
Проблема в другом. Бухгалтерский учет не предназначен для управления вообще. У него другая задача – государство должно понимать, как оценить ваш бизнес. Оно хочет иметь информацию о результатах вашей деятельности. А налоговый учет нужен еще уже – чтобы государство понимало, сколько налогов с вас брать.
Например, бухгалтерская себестоимость показывает не «истинную стоимость продукции», а стоимость, собранную по правилам учета, которые установило государство. А правила учета пишутся не для того, чтобы собственник или менеджер понял, где у него сгорают деньги.
Более того, процессный бюджет интересует совсем другое. Его интересует не столько конечная себестоимость продукции, сколько то, как эта стоимость формируется. И уже на основе этого можно будет принять то или иное решение.
Бухгалтерский учет обычно работает с периодами, счетами, проводками, требованиями отчетности и правилами признания затрат. Процессный управленческий учет – с действиями, ресурсами, результатами, ответственностью, качеством и рисками.
Бухгалтерский учет отвечает перед государством. Управленческий – перед здравым смыслом.
Следовательно, раз разные задачи, то системы должны быть разными.
Именно поэтому при бюджетировании процессов неизбежно придется отделять управленческий учет от бухгалтерского. Прежде всего потому, что в итоге вы получите совершенно несопоставимые оценки. И если бухгалтерская себестоимость не совпадет с управленческой – это не ошибка. Это нормально. А если совпали, то не радуйтесь – скорее всего, это ошибка.
Например, амортизация оборудования может быть важна для бухгалтерии. Но в процессном учете нас интересует не бухгалтерская тень актива, а стоимость использования мощности: машино-час, смена, цикл, загрузка линии, простой, ремонт, энергия, оператор. Станок не «амортизируется» в процессе. В процессе потребляется его доступная производственная мощность.
То же самое с ФОТ. Оклад возникает как обязательство в одном месте, рабочее время потребляется в другом, а результат производится в третьем, а налоги на труд – в четвертом. Если просто повесить ФОТ на подразделение, мы узнаем стоимость подразделения. Но не узнаем стоимость работы.
И вот здесь возникает главное следствие. Когда компания пытается использовать бухгалтерский учет как основу для управления процессами, она нагружает бухгалтерию чужими функциями. Бухгалтерия начинает изображать управленческую аналитику, управленцы начинают ругаться на «не те цифры», а собственник смотрит на отчеты и чувствует, что где-то его аккуратно обманули. Причем, возможно, без злого умысла.
Лучший путь – освободить бухгалтерский учет от несвойственной ему задачи поддержки управленческих решений. Пусть бухгалтерия занимается бухгалтерией. Это нормальная, важная и достаточно формализованная функция. Именно поэтому она хорошо поддается стандартизации, регламентации и в конечном итоге – аутсорсингу.
А управленческий учет надо строить отдельно – под реальные решения, которые принимает компания. В процессном бюджетировании это особенно важно. Потому что здесь планируются не просто расходы, а стоимость деятельности. Поэтому учет должен показывать не только «что потрачено», но и «на что потрачено», «какой результат получен» и «кто отвечает за этот результат».
Так что, бухгалтерский учет не виноват. Виноваты те, кто пытается управлять бизнесом через… бухгалтерию.
#бюджетирование #управленческийучет #процессы #менеджмент
🔥4👍3💯2
Бюджетирование на основе процессов.
Часть 3. Где рождаются затраты
А где вообще возникают затраты?
Обычный ответ звучит так: в подразделениях. Производство потратило столько-то. Продажи потратили столько-то. Логистика потратила столько-то. HR, финансы, IT, склад, служба качества – все получили свои строчки, свои лимиты, свои маленькие радости.
Проблема в том, что это удобно для оргструктуры, но не для управления работой. Потому, что затраты возникают не в подразделении.
Затраты возникают, когда мы что-то делаем. Подразделение – это место, где сидят люди, числятся должности, лежат полномочия и копится корпоративная пыль. А затраты рождаются там, где выполняется действие: обрабатывается заказ, привлекается клиент, проверяется качество, готовится партия, ремонтируется оборудование, разбирается претензия.
Вот это место и называется местом возникновения затрат.
В классическом понимании место возникновения затрат – это разграниченная зона ответственности, по которой можно собрать затраты и потом отнести их на нужный носитель: продукт, услугу, клиента, проект, подразделение. Но в процессной логике всё жестче. Место возникновения затрат – это не кабинет, не отдел и не ячейка в оргструктуре. Это процесс или его часть: подпроцесс, блок работ, операция, транзакция. Если выполнение деятельности приводит к возникновению затрат, значит именно там и находится место возникновения этих затрат.
Самый простой пример – фонд оплаты труда. В традиционном учете ФОТ обычно вешают на подразделение. Работник числится в цехе – значит ФОТ цеха. Работник числится в отделе продаж – значит ФОТ отдела продаж. Все привычно, спокойно, мертвенно.
Но если смотреть процессно, картинка распадается. Оклад возникает как обязательство в процессе обеспечения трудовыми ресурсами. Человек пришел работать в компанию, подписал трудовой договор – компания взяла на себя обязательство платить ему оклад.
Рабочее время потребляется уже в конкретных процессах. Человек не просто «стоит в штате». Он выполняет конкретные операции: обрабатывает заказ, производит деталь, проверяет документ, звонит клиенту, чинит оборудование. Выработка возникает в процессе создания этого результата. Поработал – получил выработку. Хорошо поработал – получил премию. А процесс потратил ресурс. Возникли затраты.
И вот здесь бухгалтерская привычка ломается. Если просто повесить ФОТ на подразделение, мы узнаем стоимость подразделения. Но не узнаем стоимость работы. А управлению нужна именно стоимость работы. Сколько стоит обработать один заказ? Сколько стоит привлечь одного клиента? Сколько стоит проверить одну партию? Сколько стоит провести один ремонт? Сколько стоит исправить одну ошибку?
Пока мы не знаем, в каком процессе родились затраты, мы не можем нормально управлять стоимостью деятельности. Мы можем только резать расходы по отделам. Это любимый управленческий спорт людей, которые не понимают, как устроена работа.
Порезали ФОТ – получили меньше людей. Порезали материалы – получили хуже качество. Порезали обслуживание оборудования – получили простой. Порезали обучение – получили ошибки. Потом героически боремся с последствиями собственных решений.
Процессное бюджетирование начинается с другого вопроса. Не «какому подразделению сколько денег дать?», а «какие процессы должны быть выполнены, какие ресурсы они потребят и какой результат должны дать?»
Для этого затраты надо учитывать по местам их возникновения. А в процессной системе такими местами становятся процессы и их элементы. Именно поэтому иерархия процессов постепенно превращается в иерархию мест возникновения затрат. Операция собирает свои затраты. Блок работ собирает затраты операций. Подпроцесс собирает блоки работ. Процесс собирает подпроцессы. А потом всё это можно свернуть хоть к подразделению, хоть к продукту, хоть к клиенту, хоть к P&L.
Пока компания не понимает, где рождаются затраты, она не управляет стоимостью. Она просто смотрит, в каком отделе дым сильнее.
Хороших вам выходных!
#бюджетирование #управленческийучет #процессы #менеджмент
Часть 3. Где рождаются затраты
А где вообще возникают затраты?
Обычный ответ звучит так: в подразделениях. Производство потратило столько-то. Продажи потратили столько-то. Логистика потратила столько-то. HR, финансы, IT, склад, служба качества – все получили свои строчки, свои лимиты, свои маленькие радости.
Проблема в том, что это удобно для оргструктуры, но не для управления работой. Потому, что затраты возникают не в подразделении.
Затраты возникают, когда мы что-то делаем. Подразделение – это место, где сидят люди, числятся должности, лежат полномочия и копится корпоративная пыль. А затраты рождаются там, где выполняется действие: обрабатывается заказ, привлекается клиент, проверяется качество, готовится партия, ремонтируется оборудование, разбирается претензия.
Вот это место и называется местом возникновения затрат.
В классическом понимании место возникновения затрат – это разграниченная зона ответственности, по которой можно собрать затраты и потом отнести их на нужный носитель: продукт, услугу, клиента, проект, подразделение. Но в процессной логике всё жестче. Место возникновения затрат – это не кабинет, не отдел и не ячейка в оргструктуре. Это процесс или его часть: подпроцесс, блок работ, операция, транзакция. Если выполнение деятельности приводит к возникновению затрат, значит именно там и находится место возникновения этих затрат.
Самый простой пример – фонд оплаты труда. В традиционном учете ФОТ обычно вешают на подразделение. Работник числится в цехе – значит ФОТ цеха. Работник числится в отделе продаж – значит ФОТ отдела продаж. Все привычно, спокойно, мертвенно.
Но если смотреть процессно, картинка распадается. Оклад возникает как обязательство в процессе обеспечения трудовыми ресурсами. Человек пришел работать в компанию, подписал трудовой договор – компания взяла на себя обязательство платить ему оклад.
Рабочее время потребляется уже в конкретных процессах. Человек не просто «стоит в штате». Он выполняет конкретные операции: обрабатывает заказ, производит деталь, проверяет документ, звонит клиенту, чинит оборудование. Выработка возникает в процессе создания этого результата. Поработал – получил выработку. Хорошо поработал – получил премию. А процесс потратил ресурс. Возникли затраты.
И вот здесь бухгалтерская привычка ломается. Если просто повесить ФОТ на подразделение, мы узнаем стоимость подразделения. Но не узнаем стоимость работы. А управлению нужна именно стоимость работы. Сколько стоит обработать один заказ? Сколько стоит привлечь одного клиента? Сколько стоит проверить одну партию? Сколько стоит провести один ремонт? Сколько стоит исправить одну ошибку?
Пока мы не знаем, в каком процессе родились затраты, мы не можем нормально управлять стоимостью деятельности. Мы можем только резать расходы по отделам. Это любимый управленческий спорт людей, которые не понимают, как устроена работа.
Порезали ФОТ – получили меньше людей. Порезали материалы – получили хуже качество. Порезали обслуживание оборудования – получили простой. Порезали обучение – получили ошибки. Потом героически боремся с последствиями собственных решений.
Процессное бюджетирование начинается с другого вопроса. Не «какому подразделению сколько денег дать?», а «какие процессы должны быть выполнены, какие ресурсы они потребят и какой результат должны дать?»
Для этого затраты надо учитывать по местам их возникновения. А в процессной системе такими местами становятся процессы и их элементы. Именно поэтому иерархия процессов постепенно превращается в иерархию мест возникновения затрат. Операция собирает свои затраты. Блок работ собирает затраты операций. Подпроцесс собирает блоки работ. Процесс собирает подпроцессы. А потом всё это можно свернуть хоть к подразделению, хоть к продукту, хоть к клиенту, хоть к P&L.
Пока компания не понимает, где рождаются затраты, она не управляет стоимостью. Она просто смотрит, в каком отделе дым сильнее.
Хороших вам выходных!
#бюджетирование #управленческийучет #процессы #менеджмент
🔥12👍4✍2
Бюджетирование на основе процессов.
Часть 4. Процесс без границ – это не объект управления
Теперь неприятный разговор для тех, кто уже «описал процессы». Да, я в курсе, как вы их описали.
В 85% случаев это десятикилометровые портянки в BPMN, EPC или еще какой-нибудь адской нотации, где на одной схеме живут люди, документы, системы, решения, согласования, циклы, возвраты, исключения, уточнения, повторные проверки, начальник Петрович, секретный Excel и священная стрелочка «на доработку». Выглядит сложно. Иногда даже красиво.
Но к управлению это часто имеет примерно такое же отношение, как наскальная живопись к инженерному чертежу.
Главная проблема не в нотации. BPMN не виноват. EPC тоже не виноват. Виноваты те, кто рисует не модель процесса, а коллективную психотравму компании.
Обычно в таких схемах нет трех вещей.
Во-первых, нет четкой границы, где процесс начинается. И не нужно мне тыкать в 100500 событий-триггеров, которые запускают этот процесс. Это и есть размытая граница, если вы этого не поняли!
Во-вторых, нет четкой границы, где процесс заканчивается. И не надо показывать мне пять альтернативных окончаний. Это не гибкость. Это отсутствие границы!
В-третьих, нет одного валидного результата, ради которого процесс вообще существует.
Результатов несколько, и среди них невозможно выделить главный. Ответственность размазана по пяти подразделениям. Обратные связи и циклы торчат во все стороны. Входы и выходы перепутаны с документами. Исключения смешаны с нормальным ходом процесса. А потом это гордо называется «моделью бизнес-процесса».
Нет, друзья, это что угодно, но только не модель. Это карта местности, нарисованная не очень трезвым человеком, который шел ночью по болоту и очень хотел домой.
Конечно, обычно на это мне отвечают, мол, у нас так устроен бизнес. Ложь! Так устроена ваша привычка смотреть на хаос и называть его «спецификой бизнеса». Если процесс нельзя ограничить, измерить и привязать к результату, то это не объект управления. Это управленческий туман.
А туман бюджетировать сложно. Можно, конечно, выделить деньги на туман. Многие так и делают. Но потом не надо удивляться, что из тумана выходит не прибыль, а очередное совещание.
Для процессного бюджетирования процесс должен быть объектом учета и управления. А значит, у него должны быть минимальные признаки нормального процесса. Если вы не понимаете, где процесс начинается, вы не сможете посчитать спрос на процесс, загрузку, очередь, длительность цикла и потребность в ресурсах. Если вы не понимаете, где процесс заканчивается, вы не сможете посчитать стоимость результата. Вы будете считать стоимость бесконечного движения по коридорам компании.
И здесь мы упираемся еще в одну вещь, которую многие процессные художники очень не любят. Забегая вперед, скажу, что для процессного бюджетирования вам понадобится иерархия – да, та самая декомпозиция, от которой вы отказались в самом начале, сочтя её ненужной, избыточной или слишком трудоёмкой.
Вам лень было? А зря! Или вы просто не понимали, что декомпозиция – это не бюрократическое украшение, а инструмент управления сложностью. Отказ от неё и приводит в мир десятикилометровых портянок.
Да, технически можно учитывать затраты даже на плохо смоделированный процесс. Можно добавить аналитику, собрать цифры, построить отчет и показать собственнику красивую диаграмму. Но управленческих решений из этого не получится. Потому что, если процесс не имеет границ, вы не знаете, какие затраты относятся к нему, а какие просто пролетели мимо. Если процесс не имеет результата, вы не знаете, за что платите. Если процесс не имеет ответственного, вы не знаете, с кого спрашивать. А трудоемкость внедрения такого бюджетирования увеличивается на порядки! Не в разы – на порядки!
Процессный бюджет появляется только тогда, когда процесс превращается в нормальный объект управления. Все остальное – художественная самодеятельность. Можно рисовать. Можно защищать на совещаниях. Можно даже повесить на стену.
Но бюджетировать это нельзя.
Хорошей вам трудовой недели!
#бюджетирование #процессы #управленческийучет #менеджмент
Часть 4. Процесс без границ – это не объект управления
Теперь неприятный разговор для тех, кто уже «описал процессы». Да, я в курсе, как вы их описали.
В 85% случаев это десятикилометровые портянки в BPMN, EPC или еще какой-нибудь адской нотации, где на одной схеме живут люди, документы, системы, решения, согласования, циклы, возвраты, исключения, уточнения, повторные проверки, начальник Петрович, секретный Excel и священная стрелочка «на доработку». Выглядит сложно. Иногда даже красиво.
Но к управлению это часто имеет примерно такое же отношение, как наскальная живопись к инженерному чертежу.
Главная проблема не в нотации. BPMN не виноват. EPC тоже не виноват. Виноваты те, кто рисует не модель процесса, а коллективную психотравму компании.
Обычно в таких схемах нет трех вещей.
Во-первых, нет четкой границы, где процесс начинается. И не нужно мне тыкать в 100500 событий-триггеров, которые запускают этот процесс. Это и есть размытая граница, если вы этого не поняли!
Во-вторых, нет четкой границы, где процесс заканчивается. И не надо показывать мне пять альтернативных окончаний. Это не гибкость. Это отсутствие границы!
В-третьих, нет одного валидного результата, ради которого процесс вообще существует.
Результатов несколько, и среди них невозможно выделить главный. Ответственность размазана по пяти подразделениям. Обратные связи и циклы торчат во все стороны. Входы и выходы перепутаны с документами. Исключения смешаны с нормальным ходом процесса. А потом это гордо называется «моделью бизнес-процесса».
Нет, друзья, это что угодно, но только не модель. Это карта местности, нарисованная не очень трезвым человеком, который шел ночью по болоту и очень хотел домой.
Конечно, обычно на это мне отвечают, мол, у нас так устроен бизнес. Ложь! Так устроена ваша привычка смотреть на хаос и называть его «спецификой бизнеса». Если процесс нельзя ограничить, измерить и привязать к результату, то это не объект управления. Это управленческий туман.
А туман бюджетировать сложно. Можно, конечно, выделить деньги на туман. Многие так и делают. Но потом не надо удивляться, что из тумана выходит не прибыль, а очередное совещание.
Для процессного бюджетирования процесс должен быть объектом учета и управления. А значит, у него должны быть минимальные признаки нормального процесса. Если вы не понимаете, где процесс начинается, вы не сможете посчитать спрос на процесс, загрузку, очередь, длительность цикла и потребность в ресурсах. Если вы не понимаете, где процесс заканчивается, вы не сможете посчитать стоимость результата. Вы будете считать стоимость бесконечного движения по коридорам компании.
И здесь мы упираемся еще в одну вещь, которую многие процессные художники очень не любят. Забегая вперед, скажу, что для процессного бюджетирования вам понадобится иерархия – да, та самая декомпозиция, от которой вы отказались в самом начале, сочтя её ненужной, избыточной или слишком трудоёмкой.
Вам лень было? А зря! Или вы просто не понимали, что декомпозиция – это не бюрократическое украшение, а инструмент управления сложностью. Отказ от неё и приводит в мир десятикилометровых портянок.
Да, технически можно учитывать затраты даже на плохо смоделированный процесс. Можно добавить аналитику, собрать цифры, построить отчет и показать собственнику красивую диаграмму. Но управленческих решений из этого не получится. Потому что, если процесс не имеет границ, вы не знаете, какие затраты относятся к нему, а какие просто пролетели мимо. Если процесс не имеет результата, вы не знаете, за что платите. Если процесс не имеет ответственного, вы не знаете, с кого спрашивать. А трудоемкость внедрения такого бюджетирования увеличивается на порядки! Не в разы – на порядки!
Процессный бюджет появляется только тогда, когда процесс превращается в нормальный объект управления. Все остальное – художественная самодеятельность. Можно рисовать. Можно защищать на совещаниях. Можно даже повесить на стену.
Но бюджетировать это нельзя.
Хорошей вам трудовой недели!
#бюджетирование #процессы #управленческийучет #менеджмент
🔥11👍3👏2✍1
Бюджетирование на основе процессов.
Часть 5. Элемент затрат и статья затрат – не одно и то же
Когда перейдем к практике? Скоро, очень скоро. Но пока нам бы разобраться с понятиями. Чтобы мы одинаково понимали значения терминов, которые с неотвратимой неизбежностью нам придется применять, как только мы перейдем практическую область. Поэтому сейчас поговорим о вещи, на которой ломается половина разговоров про учет, планирование и бюджетирование.
Элемент затрат и статья затрат – это не одно и то же.
Звучит просто. Даже скучно. Но именно здесь часто начинается управленческий бардак, аккуратно оформленный в Excel.
Элемент затрат отвечает на вопрос: что потреблено? Труд. Материалы. Энергия. Внешняя услуга. Транспортный ресурс. Использование оборудования. Информационный ресурс. Деньги, в конце концов.
То есть элемент затрат описывает экономическую природу потребленного ресурса.
А статья затрат отвечает на другой вопрос: на что это потреблено? На привлечение потребителей. На обработку заказов. На контроль качества. На обслуживание оборудования. На урегулирование претензий. И так далее.
Разница принципиальная. Элемент затрат говорит, какой ресурс был использован. Статья затрат говорит, ради какой деятельности этот ресурс был использован. И если вы этого не разделяете, то вместо управленческого учета получаете бухгалтерскую кашу с аналитическими специями.
Например, «заработная плата» – это элемент затрат. Она говорит, что был потреблен трудовой ресурс. Но сама по себе она не объясняет, зачем этот ресурс был потреблен. Один и тот же труд может быть потрачен на продажу, производство, контроль качества, ремонт, обработку претензии, подготовку отчета или бесконечное совещание, после которого всем стало хуже, но зато появился протокол.
Для управления важно не только то, что вы что-то потратили. Важно понять, на какую деятельность вы это спалили.
Если вырос элемент «труд», это еще ни о чем не говорит. Может быть, компания стала больше производить. Может быть, выросла доля ручной обработки. Может быть, процессы деградировали. Может быть, менеджеры открыли новый вид спорта – согласование согласований.
Если выросла статья «затраты на обработку заказов», это уже предмет разговора. Почему выросла? Больше заказов? Больше ошибок? Дольше цикл? Плохая автоматизация? Избыточные проверки? Неправильное распределение ролей?
Вот здесь начинается управление. Элемент затрат отвечает на вопрос «что сожгли». Статья затрат отвечает на вопрос «зачем сожгли». А менеджер – что с этим нужно делать.
Именно поэтому в процессном бюджетировании статья затрат должна быть связана с процессом или его частью. Не «расходы на персонал» вообще. А «трудозатраты на обработку заказов». Не «расходы на транспорт» вообще. А «затраты на доставку товара потребителю». И не «прочие расходы». Потому что «прочие расходы» – это обычно кладбище управленческой мысли. Всё, что не смогли понять, сложили туда и сделали вид, что так и было задумано.
И вот здесь появляется приятный бонус от отделения управленческого учета от бухгалтерского. В бухгалтерском учете вы живете в мире элементов затрат, которые признает учетная система, стандарты и государство. Но государство не обязано понимать вашу бизнес-модель.
А вот в управленческом учете вы не обязаны жить в этом тесном загоне. Вы можете использовать те виды ресурсов, которые действительно важны для управления вашим бизнесом. Например, не нравится амортизация как элемент затрат? И правильно. Выкидывайте! Вам никто слова не скажет.
В нормальной системе учета элемент затрат и статья затрат должны жить вместе, но отвечать на разные вопросы. Без этого бюджетирование превращается в спор о том, какую строку урезать. А процессное бюджетирование должно отвечать на другой вопрос: какую работу изменить, чтобы получить нужный результат с меньшими ресурсами, меньшим риском и нормальным качеством.
С наступающим байрамом всех причастных! И хороших каникул тем, у кого они будут!
🐏
#бюджетирование #управленческийучет #процессы #менеджмент
Часть 5. Элемент затрат и статья затрат – не одно и то же
Когда перейдем к практике? Скоро, очень скоро. Но пока нам бы разобраться с понятиями. Чтобы мы одинаково понимали значения терминов, которые с неотвратимой неизбежностью нам придется применять, как только мы перейдем практическую область. Поэтому сейчас поговорим о вещи, на которой ломается половина разговоров про учет, планирование и бюджетирование.
Элемент затрат и статья затрат – это не одно и то же.
Звучит просто. Даже скучно. Но именно здесь часто начинается управленческий бардак, аккуратно оформленный в Excel.
Элемент затрат отвечает на вопрос: что потреблено? Труд. Материалы. Энергия. Внешняя услуга. Транспортный ресурс. Использование оборудования. Информационный ресурс. Деньги, в конце концов.
То есть элемент затрат описывает экономическую природу потребленного ресурса.
А статья затрат отвечает на другой вопрос: на что это потреблено? На привлечение потребителей. На обработку заказов. На контроль качества. На обслуживание оборудования. На урегулирование претензий. И так далее.
Разница принципиальная. Элемент затрат говорит, какой ресурс был использован. Статья затрат говорит, ради какой деятельности этот ресурс был использован. И если вы этого не разделяете, то вместо управленческого учета получаете бухгалтерскую кашу с аналитическими специями.
Например, «заработная плата» – это элемент затрат. Она говорит, что был потреблен трудовой ресурс. Но сама по себе она не объясняет, зачем этот ресурс был потреблен. Один и тот же труд может быть потрачен на продажу, производство, контроль качества, ремонт, обработку претензии, подготовку отчета или бесконечное совещание, после которого всем стало хуже, но зато появился протокол.
Для управления важно не только то, что вы что-то потратили. Важно понять, на какую деятельность вы это спалили.
Если вырос элемент «труд», это еще ни о чем не говорит. Может быть, компания стала больше производить. Может быть, выросла доля ручной обработки. Может быть, процессы деградировали. Может быть, менеджеры открыли новый вид спорта – согласование согласований.
Если выросла статья «затраты на обработку заказов», это уже предмет разговора. Почему выросла? Больше заказов? Больше ошибок? Дольше цикл? Плохая автоматизация? Избыточные проверки? Неправильное распределение ролей?
Вот здесь начинается управление. Элемент затрат отвечает на вопрос «что сожгли». Статья затрат отвечает на вопрос «зачем сожгли». А менеджер – что с этим нужно делать.
Именно поэтому в процессном бюджетировании статья затрат должна быть связана с процессом или его частью. Не «расходы на персонал» вообще. А «трудозатраты на обработку заказов». Не «расходы на транспорт» вообще. А «затраты на доставку товара потребителю». И не «прочие расходы». Потому что «прочие расходы» – это обычно кладбище управленческой мысли. Всё, что не смогли понять, сложили туда и сделали вид, что так и было задумано.
И вот здесь появляется приятный бонус от отделения управленческого учета от бухгалтерского. В бухгалтерском учете вы живете в мире элементов затрат, которые признает учетная система, стандарты и государство. Но государство не обязано понимать вашу бизнес-модель.
А вот в управленческом учете вы не обязаны жить в этом тесном загоне. Вы можете использовать те виды ресурсов, которые действительно важны для управления вашим бизнесом. Например, не нравится амортизация как элемент затрат? И правильно. Выкидывайте! Вам никто слова не скажет.
В нормальной системе учета элемент затрат и статья затрат должны жить вместе, но отвечать на разные вопросы. Без этого бюджетирование превращается в спор о том, какую строку урезать. А процессное бюджетирование должно отвечать на другой вопрос: какую работу изменить, чтобы получить нужный результат с меньшими ресурсами, меньшим риском и нормальным качеством.
С наступающим байрамом всех причастных! И хороших каникул тем, у кого они будут!
🐏
#бюджетирование #управленческийучет #процессы #менеджмент
👍8🔥3👏1🤝1
Бюджетирование на основе процессов.
Часть 6. ABC: честный путь, которым почти никто не пойдет
Вернемся к теме учета.
Мы уже договорились, что процессное бюджетирование нельзя строить на бухгалтерском учете. Но мало просто сказать: «давайте вести управленческий учет отдельно». Сразу возникает следующий вопрос: а каким методом?
Если мы хотим учитывать затраты не по принципу «куда получилось туда и положили», а по деятельности, то человечество уже придумало для этого метод. Называется Activity-Based Costing. Или ABC. По-русски обычно говорят «учет затрат по видам деятельности».
Идея появилась не вчера. Ее активно начали развивать в 1980-е годы, когда стало понятно, что традиционные методы учета затрат всё хуже объясняют реальную экономику сложных компаний. Накладные расходы росли, продукты становились сложнее, операции разнообразнее, а старая логика «размажем затраты по базе распределения и сделаем вид, что поняли себестоимость» начала плохо пахнуть.
ABC предложил более честный взгляд. Не продукт сам по себе потребляет ресурсы. Ресурсы потребляет деятельность. А уже деятельность выполняется ради продукта, клиента, заказа, услуги или другого объекта затрат. Схема очень простая. Почти неприлично простая.
Ресурсы → действия → драйверы → объекты затрат.
Расшифрую без академического шаманства.
Сначала у нас есть ресурсы. Люди, материалы, энергия, оборудование, услуги, вычислительные мощности – всё, что компания реально использует.
Потом есть действия. Обработать заказ. Принять поставку. Проверить качество. Настроить оборудование. Провести согласование. Исправить ошибку.
Действия потребляют ресурсы. Не «отдел продаж съел зарплату». А «обработка лидов потребила столько-то человеко-часов». Не «логистика потратила деньги». А «доставка заказов потребила столько-то рейсов, часов транспорта и складских операций».
Дальше появляются драйверы затрат. Драйвер – это показатель, который объясняет, почему затрата возникла и как её разумно разнести. Количество заказов, партий, проверок, переналадок.
И наконец есть объекты затрат. То, ради чего всё это делалось: продукт, заказ, клиент, канал продаж, проект, услуга, контракт, партия, поставка, бизнес-направление.
Вот и вся базовая логика ABC. Ресурсы не падают с неба сразу на продукт. Сначала они сгорают в деятельности. А уже деятельность создает, обслуживает или изменяет объект затрат.
Звучит красиво. И, что редкость, действительно разумно. ABC – это честный путь к процессному учету. Он заставляет увидеть, какие действия реально потребляют ресурсы, какие продукты или клиенты тянут на себя сложность, где рождаются накладные расходы, какие операции стоят дороже, чем казалось, и какие красивые управленческие легенды пора выбросить на помойку. Точнее его – только строгое решение системы дифференциальных уравнений, описывающих ваш бизнес.
Но теперь плохая новость. ABC сложен. Не «сложен, потому что консультанты хотят продать дорогой проект». Хотя они, конечно, хотят. Они всегда хотят. У них тоже дети, ипотека и презентация на 97 слайдов и тихо ускользающая на бесшумных лапах молодость. Но ABC сложен по существу.
Чтобы он заработал, нужно мало иметь нормальную модель процессов. Нужно четко понимать места возникновения затрат, выделить действия, определить ресурсы, правильно выбрать драйверы, научиться собирать данные. Нужно поддерживать дисциплину учета, автоматизировать всё это так, чтобы система не легла на второй день эксплуатации.
Можно ли сделать, например на 1С? Можно. Можно многое. Стоит ли начинать с этого всем? Вот здесь я бы сильно подумал.
Полноценный ABC – это не галочка в настройках. Это целая архитектура управленческого учета. ABC требует зрелости. Не лозунгов про цифровизацию, а настоящей управленческой зрелости: процессов, данных, ответственности, дисциплины и готовности жить не по красивым отчетам, а по неприятным фактам.
Большинство компаний к этому не готовы. Да, ABC – честный путь. Но дорогой и тяжелый.
Что делать вместо этого? Есть один читерский метод. Но для его применения нужна оговорка...
#бюджетирование #ABC #управленческийучет #процессы #менеджмент
Часть 6. ABC: честный путь, которым почти никто не пойдет
Вернемся к теме учета.
Мы уже договорились, что процессное бюджетирование нельзя строить на бухгалтерском учете. Но мало просто сказать: «давайте вести управленческий учет отдельно». Сразу возникает следующий вопрос: а каким методом?
Если мы хотим учитывать затраты не по принципу «куда получилось туда и положили», а по деятельности, то человечество уже придумало для этого метод. Называется Activity-Based Costing. Или ABC. По-русски обычно говорят «учет затрат по видам деятельности».
Идея появилась не вчера. Ее активно начали развивать в 1980-е годы, когда стало понятно, что традиционные методы учета затрат всё хуже объясняют реальную экономику сложных компаний. Накладные расходы росли, продукты становились сложнее, операции разнообразнее, а старая логика «размажем затраты по базе распределения и сделаем вид, что поняли себестоимость» начала плохо пахнуть.
ABC предложил более честный взгляд. Не продукт сам по себе потребляет ресурсы. Ресурсы потребляет деятельность. А уже деятельность выполняется ради продукта, клиента, заказа, услуги или другого объекта затрат. Схема очень простая. Почти неприлично простая.
Ресурсы → действия → драйверы → объекты затрат.
Расшифрую без академического шаманства.
Сначала у нас есть ресурсы. Люди, материалы, энергия, оборудование, услуги, вычислительные мощности – всё, что компания реально использует.
Потом есть действия. Обработать заказ. Принять поставку. Проверить качество. Настроить оборудование. Провести согласование. Исправить ошибку.
Действия потребляют ресурсы. Не «отдел продаж съел зарплату». А «обработка лидов потребила столько-то человеко-часов». Не «логистика потратила деньги». А «доставка заказов потребила столько-то рейсов, часов транспорта и складских операций».
Дальше появляются драйверы затрат. Драйвер – это показатель, который объясняет, почему затрата возникла и как её разумно разнести. Количество заказов, партий, проверок, переналадок.
И наконец есть объекты затрат. То, ради чего всё это делалось: продукт, заказ, клиент, канал продаж, проект, услуга, контракт, партия, поставка, бизнес-направление.
Вот и вся базовая логика ABC. Ресурсы не падают с неба сразу на продукт. Сначала они сгорают в деятельности. А уже деятельность создает, обслуживает или изменяет объект затрат.
Звучит красиво. И, что редкость, действительно разумно. ABC – это честный путь к процессному учету. Он заставляет увидеть, какие действия реально потребляют ресурсы, какие продукты или клиенты тянут на себя сложность, где рождаются накладные расходы, какие операции стоят дороже, чем казалось, и какие красивые управленческие легенды пора выбросить на помойку. Точнее его – только строгое решение системы дифференциальных уравнений, описывающих ваш бизнес.
Но теперь плохая новость. ABC сложен. Не «сложен, потому что консультанты хотят продать дорогой проект». Хотя они, конечно, хотят. Они всегда хотят. У них тоже дети, ипотека и презентация на 97 слайдов и тихо ускользающая на бесшумных лапах молодость. Но ABC сложен по существу.
Чтобы он заработал, нужно мало иметь нормальную модель процессов. Нужно четко понимать места возникновения затрат, выделить действия, определить ресурсы, правильно выбрать драйверы, научиться собирать данные. Нужно поддерживать дисциплину учета, автоматизировать всё это так, чтобы система не легла на второй день эксплуатации.
Можно ли сделать, например на 1С? Можно. Можно многое. Стоит ли начинать с этого всем? Вот здесь я бы сильно подумал.
Полноценный ABC – это не галочка в настройках. Это целая архитектура управленческого учета. ABC требует зрелости. Не лозунгов про цифровизацию, а настоящей управленческой зрелости: процессов, данных, ответственности, дисциплины и готовности жить не по красивым отчетам, а по неприятным фактам.
Большинство компаний к этому не готовы. Да, ABC – честный путь. Но дорогой и тяжелый.
Что делать вместо этого? Есть один читерский метод. Но для его применения нужна оговорка...
#бюджетирование #ABC #управленческийучет #процессы #менеджмент
🔥10❤4👍3👀1
Бюджетирование на основе процессов.
Часть 7. Почему дальше я буду говорить об ООП
К этому месту у читателя может возникнуть разумный вопрос.
Хорошо. Мы отделили управленческий учет от бухгалтерского. Разобрались с местами возникновения затрат. Поняли, что процесс без границ – это не объект управления. Развели элементы затрат и статьи затрат. И что дальше?
А дальше начинается практика.
Вообще бюджетирование можно строить на любой модели процессов. Хотите – на BPMN. Хотите – на EPC. Хотите – на таблицах. Хотите – на схеме, нарисованной фломастером на стене переговорки после третьего кофе и второго нервного срыва. Бюджетированию в узком техническом смысле всё равно.
Можно поставить аналитику, собрать затраты, разнести ресурсы, построить отчет и получить цифры. Даже красивые.
Но если модель процесса плохая, бюджетирование просто аккуратно посчитает стоимость хаоса. И вот тут я хочу сэкономить всем время.
Жизнь коротка. Я не вижу смысла тратить её на попытки бюджетировать десятикилометровые портянки в любой нотации, которую использовали не как инструмент мышления, а как способ превратить управленческую беспомощность в диаграмму. Поэтому дальше я буду говорить об объектно-ориентированном подходе к процессам.
Не потому, что это новая модная религия. Во-первых, он не новый. Во-вторых, он не модный. В-третьих, мне плевать на методологические религии. Я не люблю поклоняться нотациям, стандартам и красивым схемам. Они не святыня. Они инструмент. А инструмент надо оценивать просто: помогает он делать работу или нет.
А ООП помогает. Он быстрее приводит к вменяемой модели, которую можно считать, бюджетировать и внедрять.
Почему? Потому что ООП заставляет задать самый неудобный вопрос: с каким бизнес-объектом мы вообще работаем? Клиент. Заказ. Товар. Актив. Партия. Поставка. Договор. Претензия. Сотрудник. Капитал. Знание. Инцидент. Заявка.
Не «у нас есть процесс согласования». А состояние чего изменится в результате этого согласования? Не «у нас есть процесс обслуживания». А какой объект обслуживается и в какое состояние он должен перейти? Не «у нас есть процесс продаж». А как меняется состояние потребителя, заказа, товара, денег и обязательств?
Вот почему ООП быстрее дает четкие границы. Процесс оказывается связан не с фантазией аналитика, а с объектом и изменением его состояния. Было одно состояние – должно стать другое. Если вы не можете сказать, какой объект меняется, скорее всего, вы описываете не процесс, а корпоративный шум.
ООП быстрее определяет результат процесса – не «обеспечение взаимодействия», не «повышение эффективности», не «поддержка деятельности» и не другие кладбищенские формулировки из регламентов. Результат – новое состояние объекта.
Заявка обработана. Заказ принят. Партия произведена. Актив восстановлен. Клиент привлечен.
Сразу становится понятно, ради чего процесс существует.
ООП быстрее дает метрики. Если процесс меняет состояние объекта, можно измерять сам переход: длительность, стоимость, качество, риск, производительность, процент ошибок, повторные циклы, отклонения, нагрузку, очередь.
В ООП проще декомпозировать. У бизнес-объекта есть жизненный цикл. Его нужно инициировать, подготовить к использованию, использовать, оценить, воспроизвести, развить или вывести из системы. Жизненный цикл сам подсказывает структуру процессов.
Это не гарантирует, что аналитик внезапно станет умным. Но хотя бы снижает вероятность того, что он нарисует очередную карту болота и назовет её процессной архитектурой.
ООП легче внедрять. Потому что объектная модель ближе к данным, информационным системам и автоматизации. ERP, CRM, BPM, учетные системы, базы данных – все они так или иначе работают с объектами, состояниями, событиями, атрибутами, связями и действиями. А значит, модель проще превратить не только в красивый документ, но и в работающую систему управления.
Но это не всё! Есть ещё одна причина, почему дальше я буду использовать этот подход. С его помощью можно обойти сложность ABC в бюджетировании процессов.
Хорошего вам настроения!
#бюджетирование #процессы #управленческийучет #ООП #менеджмент
Часть 7. Почему дальше я буду говорить об ООП
К этому месту у читателя может возникнуть разумный вопрос.
Хорошо. Мы отделили управленческий учет от бухгалтерского. Разобрались с местами возникновения затрат. Поняли, что процесс без границ – это не объект управления. Развели элементы затрат и статьи затрат. И что дальше?
А дальше начинается практика.
Вообще бюджетирование можно строить на любой модели процессов. Хотите – на BPMN. Хотите – на EPC. Хотите – на таблицах. Хотите – на схеме, нарисованной фломастером на стене переговорки после третьего кофе и второго нервного срыва. Бюджетированию в узком техническом смысле всё равно.
Можно поставить аналитику, собрать затраты, разнести ресурсы, построить отчет и получить цифры. Даже красивые.
Но если модель процесса плохая, бюджетирование просто аккуратно посчитает стоимость хаоса. И вот тут я хочу сэкономить всем время.
Жизнь коротка. Я не вижу смысла тратить её на попытки бюджетировать десятикилометровые портянки в любой нотации, которую использовали не как инструмент мышления, а как способ превратить управленческую беспомощность в диаграмму. Поэтому дальше я буду говорить об объектно-ориентированном подходе к процессам.
Не потому, что это новая модная религия. Во-первых, он не новый. Во-вторых, он не модный. В-третьих, мне плевать на методологические религии. Я не люблю поклоняться нотациям, стандартам и красивым схемам. Они не святыня. Они инструмент. А инструмент надо оценивать просто: помогает он делать работу или нет.
А ООП помогает. Он быстрее приводит к вменяемой модели, которую можно считать, бюджетировать и внедрять.
Почему? Потому что ООП заставляет задать самый неудобный вопрос: с каким бизнес-объектом мы вообще работаем? Клиент. Заказ. Товар. Актив. Партия. Поставка. Договор. Претензия. Сотрудник. Капитал. Знание. Инцидент. Заявка.
Не «у нас есть процесс согласования». А состояние чего изменится в результате этого согласования? Не «у нас есть процесс обслуживания». А какой объект обслуживается и в какое состояние он должен перейти? Не «у нас есть процесс продаж». А как меняется состояние потребителя, заказа, товара, денег и обязательств?
Вот почему ООП быстрее дает четкие границы. Процесс оказывается связан не с фантазией аналитика, а с объектом и изменением его состояния. Было одно состояние – должно стать другое. Если вы не можете сказать, какой объект меняется, скорее всего, вы описываете не процесс, а корпоративный шум.
ООП быстрее определяет результат процесса – не «обеспечение взаимодействия», не «повышение эффективности», не «поддержка деятельности» и не другие кладбищенские формулировки из регламентов. Результат – новое состояние объекта.
Заявка обработана. Заказ принят. Партия произведена. Актив восстановлен. Клиент привлечен.
Сразу становится понятно, ради чего процесс существует.
ООП быстрее дает метрики. Если процесс меняет состояние объекта, можно измерять сам переход: длительность, стоимость, качество, риск, производительность, процент ошибок, повторные циклы, отклонения, нагрузку, очередь.
В ООП проще декомпозировать. У бизнес-объекта есть жизненный цикл. Его нужно инициировать, подготовить к использованию, использовать, оценить, воспроизвести, развить или вывести из системы. Жизненный цикл сам подсказывает структуру процессов.
Это не гарантирует, что аналитик внезапно станет умным. Но хотя бы снижает вероятность того, что он нарисует очередную карту болота и назовет её процессной архитектурой.
ООП легче внедрять. Потому что объектная модель ближе к данным, информационным системам и автоматизации. ERP, CRM, BPM, учетные системы, базы данных – все они так или иначе работают с объектами, состояниями, событиями, атрибутами, связями и действиями. А значит, модель проще превратить не только в красивый документ, но и в работающую систему управления.
Но это не всё! Есть ещё одна причина, почему дальше я буду использовать этот подход. С его помощью можно обойти сложность ABC в бюджетировании процессов.
Хорошего вам настроения!
#бюджетирование #процессы #управленческийучет #ООП #менеджмент
🔥5👏5👍4❤3
Бюджетирование на основе процессов.
Часть 8. Direct Costing в процессах – путь читерский, но рабочий.
Ранее я рассказал про ABC – Activity-Based Costing. Но полноценный ABC – тяжелая история. Он требует гораздо большего, чем людей, которые не падают в обморок при словах «место возникновения затрат». А бюджетировать процессы нам нужно сейчас.
И здесь нам поможет Direct Costing.
Если совсем просто, Direct Costing разделяет затраты на прямые и косвенные. Прямые затраты – это те, которые можно непосредственно отнести на объект учета без шаманства и распределительных плясок. Материал ушел на конкретную партию. Рабочее время потрачено на конкретную операцию. Подрядчик выполнил конкретную работу. Это прямые затраты.
Все, что нельзя нормально и честно отнести напрямую, уходит в косвенные или накладные. Освещение. Отопление. Управленческий персонал. Общая инфраструктура. Содержание помещений. Общие IT-сервисы. Административные расходы. Всё то, что вроде бы нужно для работы, но не прикручивается к конкретному действию без дополнительных правил.
Но нам нужно немного положить Direct Costing на бок – мы привяжем его процессу.
Каждый процесс получает две ведомости:
– ведомость прямых затрат;
– ведомость косвенных затрат.
Далее по местам возникновения затрат.
Ведомость прямых затрат показывает, какие ресурсы процесс потребил непосредственно. Ведомость косвенных затрат показывает, какие накладные расходы возникают в процессе.
Не идеально. Академически не безупречно. Зато понятно и внедряемо.
Дальше включается иерархия процессов. Стоимость родительского процесса складывается из стоимости дочерних процессов. Операция собирает свои прямые затраты. Блок работ собирает затраты операций. Подпроцесс собирает блоки работ. Процесс собирает подпроцессы.
А теперь главный читерский ход. В полноценном ABC для разных накладных затрат используются разные драйверы. Освещение – по площади. Отопление – по объему помещения. Зарплату руководителя – по численности персонала или управленческой нагрузке. IT-инфраструктуру – по пользователям, транзакциям или рабочим местам. Складские расходы – по паллето-местам, партиям или обороту.
Правильно? Да. Сложно? Тоже да. С Direct Costing можно сделать проще. Для каждого процесса использовать один основной драйвер: количество бизнес-объектов, прошедших через процесс. Вот зачем нужен был ООП.
Рассмотрим пример. Продажи. Зарплата владельца процесса и затраты на CRM систему попадут в ведомость накладных затрат процесса. И для получения полной стоимости процесса, нам нужно сложить итог ведомости накладных затрат с суммой полных затрат дочерних процессов. А для получения удельной стоимости результата процесса – разделить полученную сумму на их количество. Всё! Накладные затраты процесса распределяются на объекты, прошедшие через этот процесс.
То есть мы получаем управленческую стоимость обработки одного заказа, привлечения одного клиента, стоимость одного часа производственной линии или здания цеха.
Да, здесь есть подвох. Точность. Конечно, если строго следовать ABC, накладные расходы надо распределять по разным драйверам. А здесь мы берем и распределяем их на объекты, прошедшие через процесс. Это грубее.
Но давайте не будем изображать девственниц в публичном доме управленческого учета. Любая система учета затрат – это модель. ABC – тоже модель. Direct Costing процессов – модель. Котловой метод – тоже модель, хотя и очень скверная.
Вопрос не в абсолютной точности. Если хочется абсолютной точности, придется строить систему дифференциальных уравнений, а потом еще как-то её решить. Удачи, конечно!
Практический вопрос другой: помогает ли эта модель принимать лучшие управленческие решения, чем предыдущая? И вот здесь Direct Costing процессов + ООП играют с ABS почти на равных.
Да, это менее точно, чем полноценный ABC. Но это на порядок лучше того, что обычно есть в компаниях сейчас.
Главное преимущество этого подхода – он позволяет начать. И не закрывает возможности в нужный момент перейти на полноценный ABC.
Хороших вам выходных!
#бюджетирование #DirectCosting #управленческийучет #процессы #менеджмент
Часть 8. Direct Costing в процессах – путь читерский, но рабочий.
Ранее я рассказал про ABC – Activity-Based Costing. Но полноценный ABC – тяжелая история. Он требует гораздо большего, чем людей, которые не падают в обморок при словах «место возникновения затрат». А бюджетировать процессы нам нужно сейчас.
И здесь нам поможет Direct Costing.
Если совсем просто, Direct Costing разделяет затраты на прямые и косвенные. Прямые затраты – это те, которые можно непосредственно отнести на объект учета без шаманства и распределительных плясок. Материал ушел на конкретную партию. Рабочее время потрачено на конкретную операцию. Подрядчик выполнил конкретную работу. Это прямые затраты.
Все, что нельзя нормально и честно отнести напрямую, уходит в косвенные или накладные. Освещение. Отопление. Управленческий персонал. Общая инфраструктура. Содержание помещений. Общие IT-сервисы. Административные расходы. Всё то, что вроде бы нужно для работы, но не прикручивается к конкретному действию без дополнительных правил.
Но нам нужно немного положить Direct Costing на бок – мы привяжем его процессу.
Каждый процесс получает две ведомости:
– ведомость прямых затрат;
– ведомость косвенных затрат.
Далее по местам возникновения затрат.
Ведомость прямых затрат показывает, какие ресурсы процесс потребил непосредственно. Ведомость косвенных затрат показывает, какие накладные расходы возникают в процессе.
Не идеально. Академически не безупречно. Зато понятно и внедряемо.
Дальше включается иерархия процессов. Стоимость родительского процесса складывается из стоимости дочерних процессов. Операция собирает свои прямые затраты. Блок работ собирает затраты операций. Подпроцесс собирает блоки работ. Процесс собирает подпроцессы.
А теперь главный читерский ход. В полноценном ABC для разных накладных затрат используются разные драйверы. Освещение – по площади. Отопление – по объему помещения. Зарплату руководителя – по численности персонала или управленческой нагрузке. IT-инфраструктуру – по пользователям, транзакциям или рабочим местам. Складские расходы – по паллето-местам, партиям или обороту.
Правильно? Да. Сложно? Тоже да. С Direct Costing можно сделать проще. Для каждого процесса использовать один основной драйвер: количество бизнес-объектов, прошедших через процесс. Вот зачем нужен был ООП.
Рассмотрим пример. Продажи. Зарплата владельца процесса и затраты на CRM систему попадут в ведомость накладных затрат процесса. И для получения полной стоимости процесса, нам нужно сложить итог ведомости накладных затрат с суммой полных затрат дочерних процессов. А для получения удельной стоимости результата процесса – разделить полученную сумму на их количество. Всё! Накладные затраты процесса распределяются на объекты, прошедшие через этот процесс.
То есть мы получаем управленческую стоимость обработки одного заказа, привлечения одного клиента, стоимость одного часа производственной линии или здания цеха.
Да, здесь есть подвох. Точность. Конечно, если строго следовать ABC, накладные расходы надо распределять по разным драйверам. А здесь мы берем и распределяем их на объекты, прошедшие через процесс. Это грубее.
Но давайте не будем изображать девственниц в публичном доме управленческого учета. Любая система учета затрат – это модель. ABC – тоже модель. Direct Costing процессов – модель. Котловой метод – тоже модель, хотя и очень скверная.
Вопрос не в абсолютной точности. Если хочется абсолютной точности, придется строить систему дифференциальных уравнений, а потом еще как-то её решить. Удачи, конечно!
Практический вопрос другой: помогает ли эта модель принимать лучшие управленческие решения, чем предыдущая? И вот здесь Direct Costing процессов + ООП играют с ABS почти на равных.
Да, это менее точно, чем полноценный ABC. Но это на порядок лучше того, что обычно есть в компаниях сейчас.
Главное преимущество этого подхода – он позволяет начать. И не закрывает возможности в нужный момент перейти на полноценный ABC.
Хороших вам выходных!
#бюджетирование #DirectCosting #управленческийучет #процессы #менеджмент
🔥11👍7👏2
Бюджетирование на основе процессов.
Часть 9. Иерархия процессов и иерархия бюджетов
Теперь собираем конструкцию целиком. Мы начали с простой, но неприятной мысли: большинство компаний не бюджетирует деятельность. Они согласовывают будущие расходы и называют это бюджетированием. Потом отделили управленческий учет от бухгалтерского. Разобрались, где рождаются затраты. Поняли, что процесс без границ – не объект управления. Развели элементы затрат и статьи затрат. Посмотрели на ABC как на честный, но тяжелый путь. И нашли более простой стартовый вариант – Direct Costing процессов.
Теперь главный вопрос: что всё это дает, если соединить все элементы в одну систему?
Ответ простой. Если у вас есть нормальная иерархия процессов, вы можете построить иерархию бюджетов. Опс! Пламенный привет художникам от BPMN!
Не набор лимитов по подразделениям. Не священный Excel с заклинаниями БДР и БДДС. Не «давайте каждому отделу дадим денег, а потом посмотрим, что получится». А именно иерархию бюджетов деятельности.
Операция получает свою смету. Блок работ собирает сметы операций и формирует бюджет. Подпроцесс собирает бюджеты блоков работ. Процесс верхнего уровня собирает бюджеты подпроцессов. Так иерархия процессов превращается в иерархию бюджетов.
И вот здесь появляется управление и заканчивается любимая бухгалтерско-финансовая игра «придумай статью бюджета». В процессном бюджетировании статьи доходов и расходов не придумываются. Они выводятся из структуры процессов. Название процесса семантически превращается в статью: «Привлечение потребителей» в статью затрат «Затраты на привлечение потребителей» и в статью доходов «Доходы от привлечения потребителей и результаты деятельности». И так далее по всей иерархии процессов.
Тогда иерархия бюджетных статей полностью повторяет иерархию процессов. Поэтому бюджетная модель наконец перестает жить отдельной жизнью от бизнеса. Она становится отражением того, что компания реально делает.
И тогда бюджет процесса – это уже не просто сумма денег. Это договор реальный о деятельности:
– какой процесс должен быть выполнен;
– какой результат должен быть получен;
– какие ресурсы (всех видов) будут потреблены;
– какие ограничения должны быть соблюдены;
– какие показатели качества, сроков, производительности и риска должны быть выдержаны;
– кто отвечает за результат.
То есть бюджет перестает быть финансовой бумажкой и становится инструментом распределения ответственности. Потому что у процесса есть владелец. У результата есть измеритель. У ресурсов есть стоимость. У отклонений есть причина. У решений есть последствия.
Теперь можно спрашивать не «почему отдел потратил больше?», а точнее – почему процесс стал дороже? Или почему выросла стоимость обработки одного объекта? Почему увеличилась длительность цикла? И так далее, пока не прозвучит главное – что нужно предпринять.
Дальше появляется еще один важный момент. Планово-аналитический разрез должен быть один – процессный. Именно в процессном разрезе мы планируем деятельность. Именно здесь рождаются затраты, потребляются ресурсы и создаются результаты. А аналитических разрезов может быть сколько угодно.
Хотите посмотреть затраты по подразделениям – сворачивайте процессы к оргструктуре. Хотите посмотреть продуктовую прибыльность – сворачивайте процессы к продуктам. Хотите посмотреть P&L – собирайте финансовую проекцию. Хотите посмотреть клиентов, проекты, каналы, регионы, юрлица – пожалуйста. Но это уже проекции.
Первичная логика остается процессной. Сначала планируем деятельность. Потом смотрим, устраивает ли нас финансовая картина. Не наоборот.
Вот почему иерархия процессов так важна. Без иерархии у вас нет нормальной свертки. Без свертки у вас нет бюджетов верхнего уровня. Без бюджетов верхнего уровня у вас нет связи между операциями и финансовым результатом. Без этой связи у вас снова остаются отдельные цифры, отдельные начальники и отдельные легенды о том, почему всё пошло не так.
А завтра я расскажу, как это все внедрить без боли и героизма.
#бюджетирование #процессы #управленческийучет #менеджмент
Часть 9. Иерархия процессов и иерархия бюджетов
Теперь собираем конструкцию целиком. Мы начали с простой, но неприятной мысли: большинство компаний не бюджетирует деятельность. Они согласовывают будущие расходы и называют это бюджетированием. Потом отделили управленческий учет от бухгалтерского. Разобрались, где рождаются затраты. Поняли, что процесс без границ – не объект управления. Развели элементы затрат и статьи затрат. Посмотрели на ABC как на честный, но тяжелый путь. И нашли более простой стартовый вариант – Direct Costing процессов.
Теперь главный вопрос: что всё это дает, если соединить все элементы в одну систему?
Ответ простой. Если у вас есть нормальная иерархия процессов, вы можете построить иерархию бюджетов. Опс! Пламенный привет художникам от BPMN!
Не набор лимитов по подразделениям. Не священный Excel с заклинаниями БДР и БДДС. Не «давайте каждому отделу дадим денег, а потом посмотрим, что получится». А именно иерархию бюджетов деятельности.
Операция получает свою смету. Блок работ собирает сметы операций и формирует бюджет. Подпроцесс собирает бюджеты блоков работ. Процесс верхнего уровня собирает бюджеты подпроцессов. Так иерархия процессов превращается в иерархию бюджетов.
И вот здесь появляется управление и заканчивается любимая бухгалтерско-финансовая игра «придумай статью бюджета». В процессном бюджетировании статьи доходов и расходов не придумываются. Они выводятся из структуры процессов. Название процесса семантически превращается в статью: «Привлечение потребителей» в статью затрат «Затраты на привлечение потребителей» и в статью доходов «Доходы от привлечения потребителей и результаты деятельности». И так далее по всей иерархии процессов.
Тогда иерархия бюджетных статей полностью повторяет иерархию процессов. Поэтому бюджетная модель наконец перестает жить отдельной жизнью от бизнеса. Она становится отражением того, что компания реально делает.
И тогда бюджет процесса – это уже не просто сумма денег. Это договор реальный о деятельности:
– какой процесс должен быть выполнен;
– какой результат должен быть получен;
– какие ресурсы (всех видов) будут потреблены;
– какие ограничения должны быть соблюдены;
– какие показатели качества, сроков, производительности и риска должны быть выдержаны;
– кто отвечает за результат.
То есть бюджет перестает быть финансовой бумажкой и становится инструментом распределения ответственности. Потому что у процесса есть владелец. У результата есть измеритель. У ресурсов есть стоимость. У отклонений есть причина. У решений есть последствия.
Теперь можно спрашивать не «почему отдел потратил больше?», а точнее – почему процесс стал дороже? Или почему выросла стоимость обработки одного объекта? Почему увеличилась длительность цикла? И так далее, пока не прозвучит главное – что нужно предпринять.
Дальше появляется еще один важный момент. Планово-аналитический разрез должен быть один – процессный. Именно в процессном разрезе мы планируем деятельность. Именно здесь рождаются затраты, потребляются ресурсы и создаются результаты. А аналитических разрезов может быть сколько угодно.
Хотите посмотреть затраты по подразделениям – сворачивайте процессы к оргструктуре. Хотите посмотреть продуктовую прибыльность – сворачивайте процессы к продуктам. Хотите посмотреть P&L – собирайте финансовую проекцию. Хотите посмотреть клиентов, проекты, каналы, регионы, юрлица – пожалуйста. Но это уже проекции.
Первичная логика остается процессной. Сначала планируем деятельность. Потом смотрим, устраивает ли нас финансовая картина. Не наоборот.
Вот почему иерархия процессов так важна. Без иерархии у вас нет нормальной свертки. Без свертки у вас нет бюджетов верхнего уровня. Без бюджетов верхнего уровня у вас нет связи между операциями и финансовым результатом. Без этой связи у вас снова остаются отдельные цифры, отдельные начальники и отдельные легенды о том, почему всё пошло не так.
А завтра я расскажу, как это все внедрить без боли и героизма.
#бюджетирование #процессы #управленческийучет #менеджмент
🔥12❤4👏3👍1
Бюджетирование на основе процессов.
Часть 10. Таинство калькулирования себестоимости
Теперь поговорим о слове, при котором у нормального человека обычно слегка стекленеют глаза. Себестоимость.
Понимаю. Скучно. Но потерпите. Финал уже близко. Да и важно это!
Вокруг себестоимости много мистики. Где-то в недрах бухгалтерии добрые люди что-то собирают, распределяют, разносят, калькулируют, потом выносят наверх цифру и говорят: «Вот себестоимость». Все кивают. Пудинг – это Алиса. Алиса – это пудинг. Хотя никакой мистики здесь быть не должно.
Калькулирование себестоимости – это способ показать, как стоимость деятельности дошла до конечного продукта, услуги, клиента. До заказа, партии или контракта.
Себестоимость не появляется из воздуха. В процессной системе она сворачивается по логике процессов, формируется из их стоимости. Не «размазать расходы по подразделениям пропорционально ФОТ». Не «накинуть сверху процент». Не «как в прошлом году, только аккуратнее». А понять, какой процесс создал ресурс, какой процесс этот ресурс потребил и в какой продукт в итоге ушла стоимость.
Например, процесс обеспечения трудовыми ресурсами создает доступный трудовой ресурс. Потом этот ресурс потребляется в производстве, продажах, логистике, ремонте, контроле качества.
Процесс обеспечения активами и обслуживания оборудования создает доступную производственную мощность. Потом эта мощность потребляется в процессах производства или оказания услуг.
И так по всем процессам.
И внезапно выясняется страшное. Компания – это не набор отделов. Компания – это система внутренних перетоков стоимости. Один процесс создает ресурс, другой его потребляет. Именно с этого ракурса начинает таять призрак «добавленной стоимости» и проявляться цепочка создания ценности. Как и понимание того, что любая ценность тащит за собой эшелон издержек.
В процессной логике себестоимость собирается не по принципу «куда бухгалтерия отнесла», а по принципу «как стоимость деятельности двигалась внутри системы».
Сначала в модель попадает стоимость системообразующих процессов. Это не производство и не продажи, но без них бизнес просто не существует: согласование условий деятельности с группами влияния, управление бизнес-системой, развитие, поддержание управляемости. Это стоимость права и способности компании действовать.
Затем определяется стоимость продуктовой системы: разработка новых и совершенствование существующих продуктов и услуг. Потому что конечный продукт не возникает в момент производства. До производства кто-то должен был придумать, спроектировать, проверить и подготовить то, что компания собирается продавать.
Потом собирается стоимость инфраструктурных процессов: обеспечение трудовыми ресурсами, активами, поставками, капиталом, информацией и знаниями. Это стоимость готовности выполнять работу.
И только после этого стоимость этих процессов ложится на операционные процессы: производство, оказание услуг, продажи, логистику, обслуживание потребителей.
И в итоге всё это формирует конечную стоимость продукции и услуг. Так появляется управленческая себестоимость. Не бухгалтерская. Не налоговая. А та, которая показывает, во что компании реально обходится создание результата.
Себестоимость перестает быть абстрактным числом, которое «где-то посчитали». Она становится маршрутом стоимости через бизнес-систему: от условий существования бизнеса – к продукту, ресурсам, операциям и конечному объекту затрат. Процессная себестоимость показывает не только итоговую величину, но и путь ее формирования. Где стоимость родилась. Через какие процессы прошла. Какие ресурсы были потреблены. Где возникли накладные. Почему один продукт тянет на себя больше издержек, чем другой.
Вот зачем нужно калькулирование – ради понимания, где именно бизнес создает стоимость, где её теряет и где сам себе красиво врет.
Хорошего вам дня и новых мыслей!
#бюджетирование #себестоимость #управленческийучет #процессы #менеджмент
Часть 10. Таинство калькулирования себестоимости
Теперь поговорим о слове, при котором у нормального человека обычно слегка стекленеют глаза. Себестоимость.
Понимаю. Скучно. Но потерпите. Финал уже близко. Да и важно это!
Вокруг себестоимости много мистики. Где-то в недрах бухгалтерии добрые люди что-то собирают, распределяют, разносят, калькулируют, потом выносят наверх цифру и говорят: «Вот себестоимость». Все кивают. Пудинг – это Алиса. Алиса – это пудинг. Хотя никакой мистики здесь быть не должно.
Калькулирование себестоимости – это способ показать, как стоимость деятельности дошла до конечного продукта, услуги, клиента. До заказа, партии или контракта.
Себестоимость не появляется из воздуха. В процессной системе она сворачивается по логике процессов, формируется из их стоимости. Не «размазать расходы по подразделениям пропорционально ФОТ». Не «накинуть сверху процент». Не «как в прошлом году, только аккуратнее». А понять, какой процесс создал ресурс, какой процесс этот ресурс потребил и в какой продукт в итоге ушла стоимость.
Например, процесс обеспечения трудовыми ресурсами создает доступный трудовой ресурс. Потом этот ресурс потребляется в производстве, продажах, логистике, ремонте, контроле качества.
Процесс обеспечения активами и обслуживания оборудования создает доступную производственную мощность. Потом эта мощность потребляется в процессах производства или оказания услуг.
И так по всем процессам.
И внезапно выясняется страшное. Компания – это не набор отделов. Компания – это система внутренних перетоков стоимости. Один процесс создает ресурс, другой его потребляет. Именно с этого ракурса начинает таять призрак «добавленной стоимости» и проявляться цепочка создания ценности. Как и понимание того, что любая ценность тащит за собой эшелон издержек.
В процессной логике себестоимость собирается не по принципу «куда бухгалтерия отнесла», а по принципу «как стоимость деятельности двигалась внутри системы».
Сначала в модель попадает стоимость системообразующих процессов. Это не производство и не продажи, но без них бизнес просто не существует: согласование условий деятельности с группами влияния, управление бизнес-системой, развитие, поддержание управляемости. Это стоимость права и способности компании действовать.
Затем определяется стоимость продуктовой системы: разработка новых и совершенствование существующих продуктов и услуг. Потому что конечный продукт не возникает в момент производства. До производства кто-то должен был придумать, спроектировать, проверить и подготовить то, что компания собирается продавать.
Потом собирается стоимость инфраструктурных процессов: обеспечение трудовыми ресурсами, активами, поставками, капиталом, информацией и знаниями. Это стоимость готовности выполнять работу.
И только после этого стоимость этих процессов ложится на операционные процессы: производство, оказание услуг, продажи, логистику, обслуживание потребителей.
И в итоге всё это формирует конечную стоимость продукции и услуг. Так появляется управленческая себестоимость. Не бухгалтерская. Не налоговая. А та, которая показывает, во что компании реально обходится создание результата.
Себестоимость перестает быть абстрактным числом, которое «где-то посчитали». Она становится маршрутом стоимости через бизнес-систему: от условий существования бизнеса – к продукту, ресурсам, операциям и конечному объекту затрат. Процессная себестоимость показывает не только итоговую величину, но и путь ее формирования. Где стоимость родилась. Через какие процессы прошла. Какие ресурсы были потреблены. Где возникли накладные. Почему один продукт тянет на себя больше издержек, чем другой.
Вот зачем нужно калькулирование – ради понимания, где именно бизнес создает стоимость, где её теряет и где сам себе красиво врет.
Хорошего вам дня и новых мыслей!
#бюджетирование #себестоимость #управленческийучет #процессы #менеджмент
❤11🔥5👍3
Бюджетирование на основе процессов.
Часть 11. Учетная политика для процессов
Теперь следующий вопрос: как это безобразие оформить методически? Ответ скучно звучит, но на самом деле сильно облегчает жизнь. Вам нужна учетная политика. И это проще, чем кажется. Потому что управленческий учет нужен не государству. Он нужен вам. А значит, учетная политика для управленческого учета должна отвечать не на вопрос «как правильно отразить?», а на вопрос «как считать, чтобы принимать нормальные решения?».
Это принципиально другая задача. Поэтому не надо строить еще одну бухгалтерию. Не надо плодить второй план счетов ради красоты. Не надо пытаться запихнуть процессное бюджетирование в старые формы, а потом удивляться, что оно там умерло от удушья. Нужно сделать проще.
Позовите нормального консультанта. Лучше специалиста по МСФО или управленческому учету. И скажите ему человеческим языком:
нам нужна учетная политика, основанная на Direct Costing, в которой объектом планирования и анализа является не подразделение, а процесс.
Если консультант понимает Direct Costing и не молится только на проводки, он довольно быстро поймет, чего вы хотите. Потому что сама методология не экзотическая. Direct Costing – это не тайное знание тибетских монахов. На этой логике работает огромная часть управленческого и бухгалтерского учета в мире. А МФСО, думаете, это что? Это оно самое – Direct Costing.
Прямые затраты относятся туда, куда их можно честно отнести. Всё, что напрямую не относится, собирается как косвенное и распределяется по понятным правилам. В нашем случае мы просто меняем объект применения. Не продукт сразу. Не подразделение. А процесс.
Учетная политика для процессов должна зафиксировать несколько простых вещей.
Первое: что считается процессом для целей управленческого учета.
Не философски, не в стиле «совокупность взаимосвязанных действий», а практически – есть справочник процессов, есть коды процессов, есть уровни детализации, есть правила адаптации.
Второе: какие элементы затрат используются.
И здесь вы свободны. Вы не обязаны копировать государственный набор учетных категорий. Если вам нужно учитывать машино-часы, экспертные часы, токены, API-запросы, рейсы, паллето-места, обращения, транзакции – вводите их.
Третье: как прямые затраты относятся на процесс.
Какие документы, события, заявки, наряды, табели, акты или системные записи подтверждают, что ресурс потреблен именно этим процессом.
Четвертое: как косвенные затраты распределяются.
Какие группы накладных расходов существуют. На какие процессы они ложатся. Какие драйверы используются. Как часто правила пересматриваются.
Пятое: кто отвечает за качество данных.
Потому что, если за признак процесса никто не отвечает, он очень быстро превратится в кладбище «прочее». А «прочее» – это не статья учета. Это признание поражения.
Шестое: как управленческий учет отделен от бухгалтерского.
Бухгалтерию не трогаем. Не ломаем. Не насилуем. Она живет своей жизнью и делает свою работу. Рядом с ней строится управленческий слой. Бухгалтерская система фиксирует факт хозяйственной жизни. Управленческий слой добавляет смысл: к какому процессу это относится, какой ресурс потреблен, ради какого результата и кто отвечает.
И вот здесь важный практический совет. Не пытайтесь сразу сделать идеально. Сделайте первую версию учетной политики на 10–15 страниц. Не на 200. Не надо строить храм. Нужен рабочий регламент, который люди смогут понять, применить и не проклясть через неделю.
Методология должна расти вместе со зрелостью компании, а не падать на неё бетонной плитой. Самая большая ошибка – пытаться внедрить процессное бюджетирование как идеальную систему с первого дня. Так не бывает.
Хорошего дня, выходные уже скоро!
#бюджетирование #управленческийучет #процессы #DirectCosting #менеджмент
Часть 11. Учетная политика для процессов
Теперь следующий вопрос: как это безобразие оформить методически? Ответ скучно звучит, но на самом деле сильно облегчает жизнь. Вам нужна учетная политика. И это проще, чем кажется. Потому что управленческий учет нужен не государству. Он нужен вам. А значит, учетная политика для управленческого учета должна отвечать не на вопрос «как правильно отразить?», а на вопрос «как считать, чтобы принимать нормальные решения?».
Это принципиально другая задача. Поэтому не надо строить еще одну бухгалтерию. Не надо плодить второй план счетов ради красоты. Не надо пытаться запихнуть процессное бюджетирование в старые формы, а потом удивляться, что оно там умерло от удушья. Нужно сделать проще.
Позовите нормального консультанта. Лучше специалиста по МСФО или управленческому учету. И скажите ему человеческим языком:
нам нужна учетная политика, основанная на Direct Costing, в которой объектом планирования и анализа является не подразделение, а процесс.
Если консультант понимает Direct Costing и не молится только на проводки, он довольно быстро поймет, чего вы хотите. Потому что сама методология не экзотическая. Direct Costing – это не тайное знание тибетских монахов. На этой логике работает огромная часть управленческого и бухгалтерского учета в мире. А МФСО, думаете, это что? Это оно самое – Direct Costing.
Прямые затраты относятся туда, куда их можно честно отнести. Всё, что напрямую не относится, собирается как косвенное и распределяется по понятным правилам. В нашем случае мы просто меняем объект применения. Не продукт сразу. Не подразделение. А процесс.
Учетная политика для процессов должна зафиксировать несколько простых вещей.
Первое: что считается процессом для целей управленческого учета.
Не философски, не в стиле «совокупность взаимосвязанных действий», а практически – есть справочник процессов, есть коды процессов, есть уровни детализации, есть правила адаптации.
Второе: какие элементы затрат используются.
И здесь вы свободны. Вы не обязаны копировать государственный набор учетных категорий. Если вам нужно учитывать машино-часы, экспертные часы, токены, API-запросы, рейсы, паллето-места, обращения, транзакции – вводите их.
Третье: как прямые затраты относятся на процесс.
Какие документы, события, заявки, наряды, табели, акты или системные записи подтверждают, что ресурс потреблен именно этим процессом.
Четвертое: как косвенные затраты распределяются.
Какие группы накладных расходов существуют. На какие процессы они ложатся. Какие драйверы используются. Как часто правила пересматриваются.
Пятое: кто отвечает за качество данных.
Потому что, если за признак процесса никто не отвечает, он очень быстро превратится в кладбище «прочее». А «прочее» – это не статья учета. Это признание поражения.
Шестое: как управленческий учет отделен от бухгалтерского.
Бухгалтерию не трогаем. Не ломаем. Не насилуем. Она живет своей жизнью и делает свою работу. Рядом с ней строится управленческий слой. Бухгалтерская система фиксирует факт хозяйственной жизни. Управленческий слой добавляет смысл: к какому процессу это относится, какой ресурс потреблен, ради какого результата и кто отвечает.
И вот здесь важный практический совет. Не пытайтесь сразу сделать идеально. Сделайте первую версию учетной политики на 10–15 страниц. Не на 200. Не надо строить храм. Нужен рабочий регламент, который люди смогут понять, применить и не проклясть через неделю.
Методология должна расти вместе со зрелостью компании, а не падать на неё бетонной плитой. Самая большая ошибка – пытаться внедрить процессное бюджетирование как идеальную систему с первого дня. Так не бывает.
Хорошего дня, выходные уже скоро!
#бюджетирование #управленческийучет #процессы #DirectCosting #менеджмент
🔥6👍4❤2
Бюджетирование на основе процессов.
Часть 12. Как внедрять процессное бюджетирование без героизма
Теперь практический вопрос. Как всё это внедрять?
Обычный ответ консультанта звучит примерно так: «Нужно описать все процессы до уровня операций, собрать нормативы, разработать драйверы, внедрить учетную систему, обучить персонал, провести пилот, масштабировать решение…»
Дальше у собственника стекленеют глаза, финансовый директор начинает искать окно, а руководители подразделений тихо надеются, что проект умрет раньше, чем дойдет до них.
И знаете что? Они правы! Если начать процессное бюджетирование снизу, с операций, нормирования каждой гайки, каждой подписи, каждой минуты рабочего времени и каждого чиха кладовщика, проект быстро превратится в управленческий Сталинград.
Героизма будет много. Результата – как повезет. Поэтому начинать надо не снизу. Начинать надо сверху!
Не с операций. Не с попытки сразу посчитать себестоимость каждого вдоха компании. Начинать надо с процессов верхнего уровня.
Да, грубо. Да, не идеально. Но первый этап – это не про точность. Это про открытие управленческого зрения. Сначала нужно увидеть, где вообще находятся крупные контуры деятельности, где рождаются основные затраты, какие процессы потребляют ресурсы и какие результаты они должны давать.
Процессное бюджетирование не требует сразу построить идеальную модель. Оно требует начать с модели, которая лучше предыдущей. И для этого не нужен подвиг.
Начните с изучения объектно-ориентированного подхода. Не для красоты, а потому что он быстро возвращает вас к реальности – с каким бизнес-объектом мы работаем, в какое состояние его переводим, какой процесс это делает, какие ресурсы процесс потребляет, какой результат должен получиться.
Не надо с нуля рисовать очередную карту корпоративного болота. Не надо начинать с белого листа. Возьмите готовый классификатор процессов. Он дает скелет. Его нужно не копировать тупо,его нужно адаптировать к своей бизнес-системе.
Кто у вас потребитель? Что у вас считается продуктом? Какие активы создают ценность? Какие поставщики и подрядчики критичны? Какие ресурсы входят в систему? Как движется товар, услуга, заказ, капитал, информация? На первом шаге достаточно процессов верхнего уровня.
Это уже можно положить в учет. Не надо сразу требовать от людей указывать операцию, подпроцесс, блок работ, фазу жизненного цикла объекта и имя духа, который благословил проводку. Введите один признак: процесс верхнего уровня.
Потратили ресурс – укажите, к какому крупному процессу относится затрата. Это не идеальный процессный учет. Но это уже не слепота. И через месяц вы впервые увидите картину, которой раньше не было.
Не сколько стоит «отдел продаж», а сколько стоят продвижение и продажи. Не сколько стоит «склад и транспорт», а вся организация поставок. И так по всем основным направлениям деятельности.
И вот тут начинается самое интересное. Вы увидите, где стоит копать дальше. Не везде. Не сразу. Не героически. Только там, где есть управленческий смысл. Сначала накладные. Потом подпроцессы. Потом блоки работ. И здесь – сметы операций.
Сверху вниз. От грубого к точному. От видимости к управляемости. От крупных процессов к тем местам, где реально болит. А не наоборот.
Нужен всего лишь один признак в учете – процесс. Сначала крупный. Потом – глубже. Ровно настолько, насколько нужно для управления.
Есть еще один плюс этого подхода. Процессы верхнего уровня идеально подходят для обкатки самой бюджетной процедуры. Еще не нужно тонуть в деталях, спорить о каждой операции и устраивать мясорубку вокруг распределения копеек. Зато уже можно пройти полный цикл: планирование, согласование, утверждение, учет, план-факт, разбор отклонений и корректировка. То есть компания учится бюджетировать деятельность без героического самопожертвования.
Есть еще кое-что. Уловка. За процесс верхнего уровня не может отвечать стрелочник. Это уровень топ-менеджеров. А значит, вы автоматически вовлекаете в процессное бюджетирование тех, кто реально рулит. Вы начинаете с них!
Хорошего дня!
#бюджетирование #процессы #менеджмент
Часть 12. Как внедрять процессное бюджетирование без героизма
Теперь практический вопрос. Как всё это внедрять?
Обычный ответ консультанта звучит примерно так: «Нужно описать все процессы до уровня операций, собрать нормативы, разработать драйверы, внедрить учетную систему, обучить персонал, провести пилот, масштабировать решение…»
Дальше у собственника стекленеют глаза, финансовый директор начинает искать окно, а руководители подразделений тихо надеются, что проект умрет раньше, чем дойдет до них.
И знаете что? Они правы! Если начать процессное бюджетирование снизу, с операций, нормирования каждой гайки, каждой подписи, каждой минуты рабочего времени и каждого чиха кладовщика, проект быстро превратится в управленческий Сталинград.
Героизма будет много. Результата – как повезет. Поэтому начинать надо не снизу. Начинать надо сверху!
Не с операций. Не с попытки сразу посчитать себестоимость каждого вдоха компании. Начинать надо с процессов верхнего уровня.
Да, грубо. Да, не идеально. Но первый этап – это не про точность. Это про открытие управленческого зрения. Сначала нужно увидеть, где вообще находятся крупные контуры деятельности, где рождаются основные затраты, какие процессы потребляют ресурсы и какие результаты они должны давать.
Процессное бюджетирование не требует сразу построить идеальную модель. Оно требует начать с модели, которая лучше предыдущей. И для этого не нужен подвиг.
Начните с изучения объектно-ориентированного подхода. Не для красоты, а потому что он быстро возвращает вас к реальности – с каким бизнес-объектом мы работаем, в какое состояние его переводим, какой процесс это делает, какие ресурсы процесс потребляет, какой результат должен получиться.
Не надо с нуля рисовать очередную карту корпоративного болота. Не надо начинать с белого листа. Возьмите готовый классификатор процессов. Он дает скелет. Его нужно не копировать тупо,его нужно адаптировать к своей бизнес-системе.
Кто у вас потребитель? Что у вас считается продуктом? Какие активы создают ценность? Какие поставщики и подрядчики критичны? Какие ресурсы входят в систему? Как движется товар, услуга, заказ, капитал, информация? На первом шаге достаточно процессов верхнего уровня.
Это уже можно положить в учет. Не надо сразу требовать от людей указывать операцию, подпроцесс, блок работ, фазу жизненного цикла объекта и имя духа, который благословил проводку. Введите один признак: процесс верхнего уровня.
Потратили ресурс – укажите, к какому крупному процессу относится затрата. Это не идеальный процессный учет. Но это уже не слепота. И через месяц вы впервые увидите картину, которой раньше не было.
Не сколько стоит «отдел продаж», а сколько стоят продвижение и продажи. Не сколько стоит «склад и транспорт», а вся организация поставок. И так по всем основным направлениям деятельности.
И вот тут начинается самое интересное. Вы увидите, где стоит копать дальше. Не везде. Не сразу. Не героически. Только там, где есть управленческий смысл. Сначала накладные. Потом подпроцессы. Потом блоки работ. И здесь – сметы операций.
Сверху вниз. От грубого к точному. От видимости к управляемости. От крупных процессов к тем местам, где реально болит. А не наоборот.
Нужен всего лишь один признак в учете – процесс. Сначала крупный. Потом – глубже. Ровно настолько, насколько нужно для управления.
Есть еще один плюс этого подхода. Процессы верхнего уровня идеально подходят для обкатки самой бюджетной процедуры. Еще не нужно тонуть в деталях, спорить о каждой операции и устраивать мясорубку вокруг распределения копеек. Зато уже можно пройти полный цикл: планирование, согласование, утверждение, учет, план-факт, разбор отклонений и корректировка. То есть компания учится бюджетировать деятельность без героического самопожертвования.
Есть еще кое-что. Уловка. За процесс верхнего уровня не может отвечать стрелочник. Это уровень топ-менеджеров. А значит, вы автоматически вовлекаете в процессное бюджетирование тех, кто реально рулит. Вы начинаете с них!
Хорошего дня!
#бюджетирование #процессы #менеджмент
🔥7❤5👍2👏1
Бюджетирование на основе процессов.
Часть 13. Как глубоко нужно копать.
Теперь вопрос, на котором можно похоронить весь проект процессного бюджетирования. До какого уровня опускаться?
Очень хочется ответить, до самого низа. До каждого действия. До каждой гайки. До каждого вздоха мастера участка.
Прошу, не надо! Если начать каждый день бюджетировать даже операции, вы быстро получите не управление, а новую религию заполнения форм. Люди будут больше считать работу, чем работать. А потом тихо возненавидят процессное бюджетирование, вас, меня и всю управленческую науку заодно.
Блоки работ – основа бюджетирования. Операции – основа учета и нормирования.
Теперь важная вещь. Бюджет процесса удобно представлять как Т-счет. Не надо пугаться этого слова. Это не магия, это просто удобная форма мышления.
Слева – доходы и результаты деятельности. То, что пришло извне: деньги, заказ, ресурс, требование, объект обработки. Или то, что вышло из процесса как его результат: обработанный заказ, произведенная партия, привлеченный клиент, восстановленный актив, урегулированная претензия. Но так или иначе – это то, что на выходе процесса.
Справа – затраты. Постатейно. Полная стоимость дочерних процессов плюс накладные самого процесса. То есть прямые и косвенные затраты, которые нужны, чтобы получить результат слева.
И вот здесь иерархия процессов начинает работать как нормальная бюджетная машина. Процесс верхнего уровня собирает бюджеты подпроцессов. Подпроцесс собирает бюджеты блоков работ. Блок работ собирает стоимость операций. Стоимость этих операций лучше всего собирать через обычные сметы.
Да, обычные сметы. Работы плюс ресурсы. Без священного ужаса. Без «цифровой трансформации». Без трехлетнего проекта внедрения, после которого все забыли, зачем всё это начали.
Смета операции должна показывать, какие ресурсы нужны для выполнения работы. Например, услуги сторонних организаций, вспомогательные и расходные материалы, трудозатраты по видам работ и специальностям, спецтехника и механизмы, контрольно-измерительные приборы, инструмент и оснастка, запасные части, элементы агрегатов.
То есть всё очень земное. Что делаем, какие ресурсы нужны, сколько нужно в натуральном выражении, сколько это стоит. Вот и вся страшная магия.
Важный эффект: в сметах затратной части окажутся ресурсы, созданные другими процессами. Подготовленный сотрудник, исправное оборудование, данные, материалы. Так смета блока работ начинает показывать внутренние перетоки стоимости. Думали, что считаем один процесс, а получили единую экономическую модель компании: один процесс создает ресурс, другой его потребляет, третий превращает его в результат.
Сметы должны делать не финансисты. Смету делает тот, кто понимает работу – владелец блока работ вместе с технологом или профильным специалистом. Экономисты задают правила и ставки, проверяют логику и следят, чтобы смета не превратилась в список хотелок. Когда перейдете на процессное управление (организационная модель), это будут руководители линейных подразделений.
На первом этапе эти сметы могут быть экспертными. Потом, по мере накопления статистики, они дадут нормативы. Компания начинает понимать, сколько реально нужно человеко-часов, материалов, машинного времени, инструмента и внешних услуг на типовые операции. А нормативы начнут сильно упрощать трудозатраты на планирование и бюджетирование, откроют путь к простой автоматизации.
Но пока норм нет, можно жить. В качестве ориентиров используются показатели результативности и эффективности процессов. Самый простой показатель – отношение правой части бюджета к левой части, выраженной в стоимостных единицах. Грубо говоря, сколько ресурсов мы сжигаем, чтобы получить единичный результат.
Да, это не идеальная точность. Но это уже управление. Потому что, это достаточно точно, чтобы принимать осмотрительные и осознанные управленческие решения.
Хороших вам выходных!
#бюджетирование #процессы #управленческийучет #менеджмент
Часть 13. Как глубоко нужно копать.
Теперь вопрос, на котором можно похоронить весь проект процессного бюджетирования. До какого уровня опускаться?
Очень хочется ответить, до самого низа. До каждого действия. До каждой гайки. До каждого вздоха мастера участка.
Прошу, не надо! Если начать каждый день бюджетировать даже операции, вы быстро получите не управление, а новую религию заполнения форм. Люди будут больше считать работу, чем работать. А потом тихо возненавидят процессное бюджетирование, вас, меня и всю управленческую науку заодно.
Блоки работ – основа бюджетирования. Операции – основа учета и нормирования.
Теперь важная вещь. Бюджет процесса удобно представлять как Т-счет. Не надо пугаться этого слова. Это не магия, это просто удобная форма мышления.
Слева – доходы и результаты деятельности. То, что пришло извне: деньги, заказ, ресурс, требование, объект обработки. Или то, что вышло из процесса как его результат: обработанный заказ, произведенная партия, привлеченный клиент, восстановленный актив, урегулированная претензия. Но так или иначе – это то, что на выходе процесса.
Справа – затраты. Постатейно. Полная стоимость дочерних процессов плюс накладные самого процесса. То есть прямые и косвенные затраты, которые нужны, чтобы получить результат слева.
И вот здесь иерархия процессов начинает работать как нормальная бюджетная машина. Процесс верхнего уровня собирает бюджеты подпроцессов. Подпроцесс собирает бюджеты блоков работ. Блок работ собирает стоимость операций. Стоимость этих операций лучше всего собирать через обычные сметы.
Да, обычные сметы. Работы плюс ресурсы. Без священного ужаса. Без «цифровой трансформации». Без трехлетнего проекта внедрения, после которого все забыли, зачем всё это начали.
Смета операции должна показывать, какие ресурсы нужны для выполнения работы. Например, услуги сторонних организаций, вспомогательные и расходные материалы, трудозатраты по видам работ и специальностям, спецтехника и механизмы, контрольно-измерительные приборы, инструмент и оснастка, запасные части, элементы агрегатов.
То есть всё очень земное. Что делаем, какие ресурсы нужны, сколько нужно в натуральном выражении, сколько это стоит. Вот и вся страшная магия.
Важный эффект: в сметах затратной части окажутся ресурсы, созданные другими процессами. Подготовленный сотрудник, исправное оборудование, данные, материалы. Так смета блока работ начинает показывать внутренние перетоки стоимости. Думали, что считаем один процесс, а получили единую экономическую модель компании: один процесс создает ресурс, другой его потребляет, третий превращает его в результат.
Сметы должны делать не финансисты. Смету делает тот, кто понимает работу – владелец блока работ вместе с технологом или профильным специалистом. Экономисты задают правила и ставки, проверяют логику и следят, чтобы смета не превратилась в список хотелок. Когда перейдете на процессное управление (организационная модель), это будут руководители линейных подразделений.
На первом этапе эти сметы могут быть экспертными. Потом, по мере накопления статистики, они дадут нормативы. Компания начинает понимать, сколько реально нужно человеко-часов, материалов, машинного времени, инструмента и внешних услуг на типовые операции. А нормативы начнут сильно упрощать трудозатраты на планирование и бюджетирование, откроют путь к простой автоматизации.
Но пока норм нет, можно жить. В качестве ориентиров используются показатели результативности и эффективности процессов. Самый простой показатель – отношение правой части бюджета к левой части, выраженной в стоимостных единицах. Грубо говоря, сколько ресурсов мы сжигаем, чтобы получить единичный результат.
Да, это не идеальная точность. Но это уже управление. Потому что, это достаточно точно, чтобы принимать осмотрительные и осознанные управленческие решения.
Хороших вам выходных!
#бюджетирование #процессы #управленческийучет #менеджмент
🔥6👍5❤1