Бюджетирование на основе процессов.
Часть 7. Почему дальше я буду говорить об ООП

К этому месту у читателя может возникнуть разумный вопрос.
Хорошо. Мы отделили управленческий учет от бухгалтерского. Разобрались с местами возникновения затрат. Поняли, что процесс без границ – это не объект управления. Развели элементы затрат и статьи затрат. И что дальше?

А дальше начинается практика.
Вообще бюджетирование можно строить на любой модели процессов. Хотите – на BPMN. Хотите – на EPC. Хотите – на таблицах. Хотите – на схеме, нарисованной фломастером на стене переговорки после третьего кофе и второго нервного срыва. Бюджетированию в узком техническом смысле всё равно.
Можно поставить аналитику, собрать затраты, разнести ресурсы, построить отчет и получить цифры. Даже красивые.

Но если модель процесса плохая, бюджетирование просто аккуратно посчитает стоимость хаоса. И вот тут я хочу сэкономить всем время.
Жизнь коротка. Я не вижу смысла тратить её на попытки бюджетировать десятикилометровые портянки в любой нотации, которую использовали не как инструмент мышления, а как способ превратить управленческую беспомощность в диаграмму. Поэтому дальше я буду говорить об объектно-ориентированном подходе к процессам.

Не потому, что это новая модная религия. Во-первых, он не новый. Во-вторых, он не модный. В-третьих, мне плевать на методологические религии. Я не люблю поклоняться нотациям, стандартам и красивым схемам. Они не святыня. Они инструмент. А инструмент надо оценивать просто: помогает он делать работу или нет.

А ООП помогает. Он быстрее приводит к вменяемой модели, которую можно считать, бюджетировать и внедрять.
Почему? Потому что ООП заставляет задать самый неудобный вопрос: с каким бизнес-объектом мы вообще работаем? Клиент. Заказ. Товар. Актив. Партия. Поставка. Договор. Претензия. Сотрудник. Капитал. Знание. Инцидент. Заявка.
Не «у нас есть процесс согласования». А состояние чего изменится в результате этого согласования? Не «у нас есть процесс обслуживания». А какой объект обслуживается и в какое состояние он должен перейти? Не «у нас есть процесс продаж». А как меняется состояние потребителя, заказа, товара, денег и обязательств?

Вот почему ООП быстрее дает четкие границы. Процесс оказывается связан не с фантазией аналитика, а с объектом и изменением его состояния. Было одно состояние – должно стать другое. Если вы не можете сказать, какой объект меняется, скорее всего, вы описываете не процесс, а корпоративный шум.

ООП быстрее определяет результат процесса – не «обеспечение взаимодействия», не «повышение эффективности», не «поддержка деятельности» и не другие кладбищенские формулировки из регламентов. Результат – новое состояние объекта.
Заявка обработана. Заказ принят. Партия произведена. Актив восстановлен. Клиент привлечен.
Сразу становится понятно, ради чего процесс существует.

ООП быстрее дает метрики. Если процесс меняет состояние объекта, можно измерять сам переход: длительность, стоимость, качество, риск, производительность, процент ошибок, повторные циклы, отклонения, нагрузку, очередь.

В ООП проще декомпозировать. У бизнес-объекта есть жизненный цикл. Его нужно инициировать, подготовить к использованию, использовать, оценить, воспроизвести, развить или вывести из системы. Жизненный цикл сам подсказывает структуру процессов.

Это не гарантирует, что аналитик внезапно станет умным. Но хотя бы снижает вероятность того, что он нарисует очередную карту болота и назовет её процессной архитектурой.

ООП легче внедрять. Потому что объектная модель ближе к данным, информационным системам и автоматизации. ERP, CRM, BPM, учетные системы, базы данных – все они так или иначе работают с объектами, состояниями, событиями, атрибутами, связями и действиями. А значит, модель проще превратить не только в красивый документ, но и в работающую систему управления.

Но это не всё! Есть ещё одна причина, почему дальше я буду использовать этот подход. С его помощью можно обойти сложность ABC в бюджетировании процессов.

Хорошего вам настроения!

#бюджетирование #процессы #управленческийучет #ООП #менеджмент