Термин «масштабирование» применительно к техническим системам давно закрепился: масштабирование изображений, сигналов, ИТ структур. Возможно ли говорить о масштабировании методологии? Попытаемся рассмотреть эту проблему в контексте внедрения бюджетного управления в компании холдингового типа.
Для того чтобы понять, что такое масштабирование и какие возникают проблемы, предлагаем рассмотреть один градостроительный пример. Город Алматы, несмотря на то что совсем недавно был столицей Казахстана, долгое время оставался двухэтажным. Строить более высокие здания боялись ввиду сейсмической опасности и близости к горе. Если вы поедете в Алматы сегодня, то увидите, что горизонт украшают небоскребы из стекла и бетона. Причем парадокс в том, что чем выше в горы, тем больше этажей у зданий. А элитные кварталы располагаются почти на горе. Как этого удалось достичь? Была разработана технология, по которой на фундамент строится подобие «подушки», позволяющей держать многоэтажный дом, и даже сильные толчки нивелируются этой конструкцией, в результате чего город получил возможность расти вверх, а не только расползаться вширь.
Когда мы внедряем системы управления на предприятиях — разрабатываем системы бюджетирования и управленческого учета, — нам тоже необходима такая «подушка», которая обеспечит устойчивость построенной системы при росте деятельности предприятия и сохранит существующие принципы управления. В небольших и средних компаниях руководство обычно считает, что сначала нужно «подрасти», закупить активы или набрать больше сотрудников, а потом начинать ими управлять и внедрять систему бюджетного управления. Но, как правило, когда активы накоплены, ставить систему управления бывает уже поздно, потому что закладывать камень в фундамент нужно на нулевом цикле строительства. В противном случае фундамент становится ограничением, система вырастет, и получится «колосс на глиняных ногах». Внедрение систем управления в таких компаниях вызывает дополнительные сложности и увеличивает затраты. Для больших компаний, которые уже выросли, но продолжают развиваться, более актуальной задачей является внедрение комплексных решений. На форумах и семинарах не случайно ведутся разговоры о комплексных системах автоматизации. Зачастую процесс развития крупной компании сопровождается разрозненной автоматизацией различных подсистем, появляется так называемая «лоскутная автоматизация», которая, конечно, помогает удерживаться на плаву, но накопление инструментов управления, автоматизации, методологии приводит к тому, что эти «лоскутки» не стыкуются на самом верхнем уровне. В подобных ситуациях обостряется проблема соответствия методологии предметных областей инструментам их автоматизации, потому что при таком подходе к решению задач методология также получается «лоскутной». Такое «лоскутное одеяло» можно сшить, но оно все равно не будет единым целым. Поэтому при автоматизации постоянно звучит критерий комплексного подхода как на уровне методологии, так и на уровне инструментов автоматизации. Несмотря на различие проблематики средних и крупных компаний, общая тенденция современного отечественного бизнеса — это необходимость гибкости, поскольку сегодня бизнес либо растет и развивается, либо останавливается и умирает. А для обеспечения этой гибкости нужен такой фундамент, который позволит удержать систему. Система управления и система автоматизации, которая поддерживает это управление, должна также развиваться и быть гибкой по отношению к этой системе. Речь идет о гибкости всей системы управления, гибкости бюджетирования, гибкости планирования, реализации многосценарного подхода.
Существует иллюзия, что можно построить некую идеальную систему и внедрить ее один раз, но идеальных систем не бывает. Задача-максимум, которую можно ставить перед постановкой системы управления компанией, заключается в следующем. Можно внедрить систему, которая будет соответствовать развитию компании, а не текущему ее состоянию, систему, которая будет надперсональной, чтобы смена сотрудника, работающего в этой системе, не привела к критичным провалам в ее работе. Останутся регламенты, инструкции, бизнес-процессы, которые закладываются в основу построения системы. Пусть такая система неидеальна, но она будет адекватно отражать текущее состояние развития и удовлетворять текущие потребности. Поэтому при проектировании систем ставится задача получить их устойчивое функционирование сейчас и заложить некую «пилюлю роста», направленную на потребности развития.
Давайте рассмотрим «масштабирование методологии» на примере рознично-сбы-тового холдинга с условным названием «ГиперТрейдХолдинг». Эта рознично-сбытовая сеть состоит из нескольких региональных бизнес-подразделений. Проект охватывает два наиболее крупных подразделения компании, состоящие из 15 филиалов, 350 объектов реализации. В дальнейшем решение должно растиражироваться и на другие подразделения компании. Самый проблемный, но и самый интересный аспект, который оказался в этом проекте ключевым, заключался в том, что эти два огромных бизнес-подразделения никогда не встречались вместе и не выстраивали управление совместно. То есть управляющая компания видела только их отчетность, а люди, работающие в разных городах и офисах, никогда не встречались друг с другом.
Задача была инициирована сверху. Управляющая компания хотела получить инструмент, который будет выступать «мостиком» между головным офисом и подразделениями и поможет постепенно перейти к от централизованной системы управления к децентрализованной.
В больших компаниях мы всегда встречаемся с жесткой централизацией всех управленческих функций на уровне головной компании, и персонал, работающий в ней изо дня в день, почти все рабочее время занимается только контролем, что мешает развитию компании. Внедрение в жизнь процессов децентрализации управления при помощи системы бюджетного управления явилось одной из основных целей проекта, поэтому изначально планировалось подключение к системе 150-200 пользователей на два региональных подразделения. Если система начнет масштабироваться дальше, в ней появится гораздо больше пользователей.
Обобщенная структура всех компаний холдингового типа представляет собой «виноградную гроздь», где на верхушке находится управляющая компания, ниже — региональные бизнес-подразделения, филиалы и объекты реализации. В группе компаний «ГиперТрейдХолдинг» ключевым объектом управления являются объекты реализации, но ни в учете, ни в планировании, ни в контроле невозможно было увидеть ни одну цифру, разбитую по данной аналитике. Это означает, что нельзя было измерить эффективность той или иной точки реализации, нельзя было предсказать, когда она окупится, сложно было запланировать текущие расходы на месяц по 350 объектам реализации, так как основным инструментом планирования и сбора факта были таблицы Excel.
Соответственно, перед проектом были выделены основные задачи на автоматизацию и проработку методологической части:
- бюджетное управление;
- планирование и сбор факта;
- мониторинг инвестиционной деятельности;
- платежный календарь;
- электронный документооборот.
Самой главной задачей была интеграция всех движений на уровне управляющей компании в единую систему. До этого управляющая компания получала всю отчетность в печатном виде и сама на их базе составляла консолидированную отчетность. Отчеты иногда делались неделями, были большие задержки и риски предоставления недостоверных данных в этих отчетах. Система была необходима, чтобы управляющая компания могла в любой момент увидеть данные по каждому филиалу и контролировать работу практически любого экономиста, могла не просто смотреть отчеты, но и принимать решения прямо в этой системе для сохранения истории всех принятых решений по бюджетному, инвестиционному процессам, оперативному платежному календарю. Тем самым мы выходили не только на автоматизацию учета, но и на автоматизацию бизнес-процессов, связанных с финансовой сферой. Также одной из причин, подталкивающей к проекту со стороны управляющей компании, стала необходимость увеличить скорость и прозрачность получения данных.
Параметры роста
Для того чтобы начать говорить о масштабировании, необходимо дать определение этого термина. Итак, масштабирование — это свойство системы (в данном случае системы бюджетного управления) сохранять свои целевые качества при изменении (обычно при увеличении) какого-либо из параметров системы.
Основные вопросы, по которым можно заметить проблему, заключаются в следующем: «Будет ли система работоспособна, если увеличить один из ее параметров?» и «Будут ли при этом выдержаны ее целевые качества?». Если есть сомнения, значит, при создании такой системы никто не думал о потребностях развития.
На примере кейса проекта в «ГиперТрейдХолдинг» нами выделены 11 параметров, по которым необходимо было закладывать масштабируемость в ходе проекта.
- Методология управленческого учета.
- Организационная структура.
- Финансовая структура.
- Аналитика бюджетирования.
- Бюджеты и отчетность.
- Процесс бюджетного планирования.
- Участники процесса.
- Запуск в эксплуатацию.
- Адаптация и развитие системы.
- ИТ-архитектура.
- Функциональные задачи.
1. Единая методология управленческого учета на уровне всей компании для составления отчетности и управления внутри подразделений. Как понять, есть ли методология вообще и какие подразделения она охватывает? Для этого нужно обратиться к регламентным документам. Хороший показатель — это понимание, насколько широко охвачена единой методологией регламентная часть, то есть количество локальных регламентов, которые поглощает разрабатываемая система бюджетного управления, тем самым производя распространение методологии. Система бюджетирования начинает заменять все существовавшие ранее в компаниях, подразделениях, филиалах регламенты, присоединять созданные процедуры и делать единую управленческую учетную политику, которая нужна и управляющей компании, и помогает оперативной деятельности самим подразделениям.
Увеличить этот показатель можно за счет двух аспектов: базовой методологии бюджетного управления и знаний об особенностях процессов в компании сотрудниками заказчика.
2. Организационная структура самого предприятия является входящим параметром для построения финансовой структуры. На проекте сложилась ситуация, что оргструктуры двух, якобы одинаковых, распределенных территориально бизнес-подразделений не совпадали. Конечно, существовали шаблоны, утвержденные приказами, но на этапе совместного уточнения оргструктуры выявились значительные разногласия. Задача совместной команды состояла в том, чтобы выработать единый регламентирующий инструмент для описания организационной структуры, чтобы в будущем можно было ее масштабировать.
В зависимости от количества объектов реализации каждого филиала были разработаны типовые структуры. При этом мы не стали рассматривать особенности реального делопроизводства. Но в отличие от первоначальных, которые существовали только на бумаге, большое внимание было уделено отражению реальной ситуации, в процессе создания оргструктура несколько раз уточнялась и проверялась. В каждой версии документа проектная команда балансировала между желанием создать типовую схему и необходимостью учета конкретики. Очень важно было понять, какие особенности являются критическими, а чем можно пожертвовать для типизации. Потом на дальнейших этапах проекта с этой проблемой приходилось сталкиваться неоднократно. Успешно преодолеть этот этап позволило то, что в команде проекта со стороны заказчика находились не только функциональные консультанты, технический директор и методологический директор, но и те специалисты, которые непосредственно в дальнейшем будут работать с этой системой.
Вслед за типизацией оргструктуры потянулись все остальные решения, основным лозунгом которых была «типизация», соблюдающая баланс между универсальностью и конкретностью.
3. Финансовая структура. Компания разрабатывала финансовую структуру уже во второй раз, первая оказалась очень избыточной и неповоротливой.
К параметру «масштабирование» здесь предъявлялся скорее качественный признак, чем количественный. Финансовая структура должна быть полной, описывать весь бизнес компании, но в тоже время важна гибкость, чтобы она действительно помогала выделить ответственных людей и правильно очертить зоны ответственности. В типовую максимально полную финансовую структуру были заложены все виды деятельности, несмотря на то что некоторые виды деятельности в отдельных филиалах отсутствовали. Также была проведена работа по стыковке с реальными оргструктурами, так как если бы мы описали отдельно одно региональное подразделение и другое, мы бы получили две абсолютно разные финансовые структуры. В разработанной структуре не присутствуют сами филиалы (350 объектов реализации), в ней закреплена ответственность как по территориальному признаку (как основному аспекту стратегии компании), так и по всем видам деятельности.
4. Аналитика бюджетирования. Финансовая структура как набор ЦФО является главнейшей аналитикой системы бюджетного управления, поэтому разрабатывать ее нужно, внимательно просматривая каждый аналитический разрез, который необходимо
туда заложить. Но в проектах задача анализа деятельности всегда стоит шире, чем аналитичность финансовой структуры, и заключается в создании единого аналитического пространства, которое способно охватить специфику каждого вида деятельности и сделать максимально полную, доступную и понятную отчетность на уровне управляющей компании. Отсюда получаем следующий масштабируемый параметр — количество аналитических разрезов, от значения которого зависит глубина анализа управленческой отчетности.
Был разработан единый классификатор статей бюджета доходов и расходов и бюджета движения денежных средств в качестве центральной аналитики системы бюджетного управления. Далее по ходу проекта нам необходимо было разработать новый перечень дополнительных аналитических разрезов, а это уже понятный и масштабируемый показатель. Количество этих аналитических разрезов для такой аналитической системы должно быть большим.
Наш опыт различных крупных проектов говорит о том, что нужно делать единую аналитику на уровне управляющей компании. Поскольку центровая аналитика бюджетирования — это статья, статья бюджета доходов и расходов, статья движения денежных средств, то вся существующая и дополнительная аналитика по максимуму привязывалась к этим статьям. Благодаря этому получалась гибкая структура, определяя статью можно было определить всю остальную аналитику. Закрепление классификатора статей велось жестко только на верхнем уровне иерархии, внутри иерархии можно было добавлять одноименные расходы, но если, например, вдруг у третьего регионального подразделения появится не существовавшая ранее статья, она войдет в фиксированную группу и дополнит общий перечень статей холдинга. К статьям были привязаны другие всевозможные характеристики, в том числе была связка со статьями инвестиционной деятельности. Таким образом, получилось, что на статью как на шампур нанизываются все остальные аналитики.
5. Бюджеты и отчетность. В рамках этого блока необходимо сделать операционные бюджеты, функциональные бюджеты и весь набор отчетности, который должна получать управляющая компания. Соответственно, счетный и масштабируемый параметр — это количество бюджетов. Были разработаны такие функциональные бюджеты, которые отражают все основные функции на предприятии, отражают основную функциональную ответственность и поэтому если в будущем поменяется бизнес или структура ведения бизнеса, то просто появится новый функциональный бюджет.
6. Процесс бюджетного планирования. Автоматизировать процесс принятия решений — одна из задач, поставленных перед проектом. Необходимо было разработать единый сквозной процесс планирования по всей компании, позволяющий подключать новые подразделения в дальнейшем. Параметр, который должен масштабироваться в этом случае, — это количество подключаемых подразделений, филиалов и участников в этот процесс. Был не только создан, настроен, описан типовой процесс, но и автоматизирован, изюминка была именно в автоматизации этого процесса, который должен был быть разработан в независимости от количества филиалов и сотрудников, работающих в системе. В результате первичного описания получилось около ста видов решаемых задач и шесть подпроцессов.
7. Участники процесса. Количество участников процесса — следующий масштабируемый параметр, даже не столько количество, сколько конкретные фамилии, которые рано или поздно придется вписать в процесс и регламент, для того чтобы люди начали работать. Это очень сложно, так как в центральном офисе не знали фамилии сотрудников из других подразделений и не предполагали, кто это может делать. Необходимо было сделать так, чтобы настройка процесса не зависела от человеческого фактора. Было принято решение, что нужно поддерживать масштабирование количества участников, но не включая самих участников в топологию процесса, процесс должен быть максимально обезличен. Соответственно, мы делали типовые блоки решений, которые говорили о некой функциональности, и на каждый блок решений, на каждую функцию мы привязывали рабочую группу. Этот инструмент позволяет назначить не конкретного исполнителя, а рабочую группу. Таким образом, каждая функция процесса — это одна рабочая группа, участники которой прописаны в обычном справочнике. В нее включаются уже филиалы и, если нужно, фамилии конкретных людей. При таком подходе к автоматизации процесс децентрализации выглядит следующим образом: вначале стоит фамилия специалиста из центра. Как только система отработана, он удаляется из рабочей группы путем удаления его фамилии, и на его место встает специалист из филиала, так мы опустили функцию в филиал. Значит, болезненная процедура смены исполнителя никаким образом не затрагивает саму систему, она продолжает работать, достаточно поменять фамилию в списке.
8. Запуск в эксплуатацию. Одно дело настроить такую систему, и совершенно другое — ее запустить и сделать так, чтобы ею пользовались, так как внедрение новой корпоративной системы управления подразумевает кардинальные изменения в самой корпоративной культуре управления в компании, где каждый человек должен четко выполнять поставленную задачу в назначенный срок. Быстро и одновременно обучить такое количество пользователей не представляется возможным. Если проводить такое обучение в виде общих лекций и тренингов, то на это понадобилась бы пара месяцев. Поэтому была организована деловая игра, в которой участвовала проектная команда. Эта команда промоделировала бизнес-пример на базе своего реального годового плана, занесла все цифры в систему. Во-первых, они познакомились с самой системой и с конкретикой, какие цифры забивать, как они между собой связаны, какие формулы рассчитываются. По результатам деловой игры был создан документ «Руководство по работе с процессом», который описывал ход процесса, образцы заполнения каждой формы на примере данных, полученных в результате деловой игры. Весь описанный в руководстве процесс — реальный, живой, понятный всем подразделениям, был сфотографирован (сделаны скриншоты) и скриншоты были вставлены в руководство. С помощью такой процедуры была подготовлена масштабируемость запуска. В дальнейшем к системе подключали людей, которые и не знали, что в компании идет какой-то проект, им просто раздавали этот документ и по нему специалисты из проектной команды поясняли, что и как нужно делать.
9. Адаптация и развитие системы. Для дальнейшего развития системы, а она будет развиваться, стоят большие планы, какой параметр нужно отмасш-табировать для того, чтобы получить поддержку развитию и адаптации системы? Этот параметр — количество компетентных сотрудников, которые в дальнейшем могут составить внутренний методологический центр, организовать внутреннюю помощь. На первом же проектном заседании была обозначена потребность создания консультационно-внедренческого центра внутри компании, который будет поддерживать развитие и изменение модели управленческого учета централизованно. То есть любой пользователь знает, кому позвонить, рассказать, какие проблемы есть на его рабочем месте, а также может внести пожелания по улучшению системы, эти пожелания собираются, рассматриваются и система живет и развивается.
10. ИТ-архитектура. Масштабируемость ИТ-архитектуры была предрешена, и можно даже сказать, что проект начался идеально. В него изначально были заложены предпосылки для комплексного проекта. Несмотря на то что компания в тот момент параллельно внедряла систему единого бухгалтерского учета, мы выстроили единый модуль управленческого и бухгалтерского учета. Управляющие компании всегда имеют потребность проследить любую цифру вплоть до первичного документа, который внес конкретный пользователь, и иметь полную прозрачность и достоверность факта. Поэтому строили такую структуру, которая позволяет в каждом филиале поставить информационную базу, которая обменивается с центральной базой на уровне головной организации регионального подразделения, а потом данные передаются в общую базу управляющей компании холдинга. Все движения, которые там есть, будут «видны» в управляющей компании. Все процессы, которые происходят, перемещаются в рамках трех уровней. Инициирует процесс головная компания, задачи приходят в головной офис, потом опускаются в филиалы и все решения по ним могут мигрировать и снизу вверх. Также при этом всегда можно увидеть, кто и какое решение на каком месте принял. Внедрение единой конфигурации бухгалтерского учета помогло упростить создание ИТ-инфраструктуры.
Функциональные задачи. Все эти параметры относились только к одной функциональной области — бюджетное управление, на самом деле блоков гораздо больше. Нужно масштабировать количество самих функциональных блоков, количество сценариев, по которым будет вестись учет. Делается это на базе многосценарного подхода к учету и управлению. Сценарий — это учетно-аналитический разрез, показывающий тот или иной вариант развития событий. Чем больше сценариев — тем шире и гибче получается система управления.
То, о чем шла речь — это только небольшая часть функционального блока бюджетного планирования. Также планируются постановка управления инвестиционной деятельностью, платежного календаря, документооборота, и вся эта информация должна между собой корелировать и между собой взаимоотноситься. В процессе, в котором все эти блоки взаимосвязаны, решения принимаются одно на основании другого. И теперь мы можем посмотреть, как огромная 15-летняя инвестиционная программа на много миллионов долларов связана с конкретным платежом, который несется в данный момент на подписание заявки. Всегда можно понять достоверность, оправданность, нацеленность этой суммы и не запрашивать дополнительную информацию — все хранится в одной системе. В итоге мы получаем целостную систему для поддержания не только управленческого учета на предприятии, но и принятия управленческих решений.
Если бы мы не выдержали некую унификацию и оптимизацию на самом первом стартовом блоке бюджетного планирования, мы бы не заложили как раз тот фундамент, который позволяет наращивать по «шашлычной» технологии все остальные блоки, которые должны иметь в себе те же параметры масштабирования.
В заключение хотелось бы отметить, что построение системы управления под руководством вышеприведенных принципов — это неоценимый вклад в конкурентное преимущество компании в виде новой корпоративной культуры управления. Как известно, именно корпоративная культура составляет фундамент реализации долгосрочных целей в стратегии компании, а значит, компания получает нематериальный актив, позволяющий увеличить стоимость бизнеса.