Методология и масштабирование в проекте

Практика

Автор:
Источник: Инталев
Опубликовано: 26 мая 2008

Наверное, вам хорошо знаком термин «масштабирование» применительно к техническим системам: масштабирование изображений, масштабирование сигналов, масштабирование ИТ-структур. Но такое понятие как «масштабирование методологии», скорее всего, ни разу не встречалось. В данной статье, в контексте методологии бюджетирования, пойдет речь о том, каким образом такая абстрактная и сложноосязаемая вещь как методология может масштабироваться.

Идентификация проблемы

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

Когда мы внедряем системы управления на предприятиях (разрабатываем системы бюджетирования и управленческого учета), нам тоже необходима такая «подушка», которая обеспечит устойчивость построенной системы при росте деятельности предприятия и сохранит существующие принципы управления. И это основная мысль, которую я покажу наглядно на базе практических примеров.

Идентифицируем проблемы, которые приводят предприятия к пониманию необходимости постановки бюджетного управления.

В небольших и средних компаниях руководство обычно считает, что сначала нужно «подрасти», закупить активы или набрать больше сотрудников, а потом начинать ими управлять и внедрять систему бюджетного управления. Но, как правило, когда активы накоплены, ставить систему управления бывает уже поздно, потому что закладывать камень в фундамент нужно на нулевом цикле строительства, иначе фундамент будет ограничением, система вырастет и получится «колосс на глиняных ногах». Мы наблюдали проекты, которые надо было реализовать «уже вчера», и это обстоятельство вызывает всегда дополнительные сложности при внедрении.

Для больших компаний, которые уже выросли, но продолжают развиваться, более актуальной задачей является внедрение комплексных решений. На форумах и семинарах ведутся разговоры о комплексных системах автоматизации не случайно. Зачастую процесс развития крупной компании сопровождается разрозненной автоматизацией различных подсистем, появляется так называемая «лоскутная автоматизация», которая, конечно, помогает удерживаться на плаву, но накопление инструментов управления, автоматизации, методологии приводит к тому, что эти «лоскутки» не стыкуются на самом верхнем уровне. В подобных ситуациях обостряется проблема соответствия методологии предметных областей инструментам их автоматизации, потому что методология так же получается «лоскутной» при таком подходе к решению задач. Такое «лоскутное одеяло» можно сшить, но оно все равно не будет единым целым. Поэтому при автоматизации постоянно звучит критерий комплексного подхода, как на уровне методологии, так и на уровне инструментов автоматизации. Естественно, говоря о методологии и автоматизации учета необходимо учитывать, что это взаимосвязанные вещи и нельзя взять одну методологию и добиться успеха, внедрив ее на инструменте автоматизации, который подразумевает другую методологию.

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

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

«Живой» пример

Попробую показать, что такое «масштабирование методологии» на примере рознично-сбытового холдинга с условным названием «ГиперТрейдХолдинг». Эта рознично-сбытовая сеть состоит из нескольких региональных бизнес-подразделений. Проект на стадии разработки и автоматизации системы управления должен был охватить при разработке два наиболее крупных подразделения компании, но затем растиражироваться на все остальные. Самый проблемный, но и самый интересный аспект, который оказался в этом проекте ключевым, заключался в том, что эти два огромных бизнес-подразделения никогда не встречались вместе и не выстаивали управление совместно. То есть управляющая компания видела только их отчетность, люди, работающие в разных городах и офисах, никогда не встречались друг с другом. В общей сложности мы получили 15 филиалов, 350 объектов реализации, которые нужно охватить системой. Проект был инициирован сверху, и задача, которая была поставлена – это построение инструмента, который будет выступать «мостиком» между централизованной системой управления и децентрализованной, так как назрела необходимость перехода от централизованного управления к децентрализации, а это всегда сложный и больной вопрос.

В больших компаниях мы всегда встречаемся с жесткой централизацией всех управленческих функций на уровне головной компании, и персонал, работающий в ней изо дня в день, почти все рабочее время занимается только контролем, и это мешает развитию компании. Внедрение в жизнь процессов децентрализации управления при помощи системы бюджетного управления явилось одной из основных целей проекта, поэтому изначально планировалось подключение к системе 150-200 пользователей на два региональных подразделения. Если система начнет масштабироваться дальше, в ней появится гораздо больше пользователей.

Обобщенная структура всех компаний холдингового типа представляет собой «виноградную гроздь», где на верхушке находится управляющая компания, ниже – региональные бизнес-подразделения, филиалы и объекты реализации. В группе компаний «ГиперТрейдХолдинг» ключевым объектом управления являются объекты реализации, но ни в учете, ни в планировании, ни в контроле невозможно было увидеть ни одной цифры, разбитой по данной аналитике. Это означает, что нельзя было измерить эффективность той или иной точки реализации, нельзя было предсказать, когда она окупится, сложно было запланировать текущие расходы на месяц по 350 объектам реализации, так как основным инструментом планирования и сбора факта были таблицы Excel .

Соответственно, перед проектом были выделены основные задачи на автоматизацию и проработку методологической части:

  • Бюджетное планирование
  • Сбор и учет фактического исполнения бюджетов
  • Мониторинг инвестиционной деятельности
  • Платежный календарь
  • Электронный документооборот

Самой главной задачей была интеграция всех движений на уровне управляющей компании в единую систему. До этого управляющая компания получала всю отчетность в печатном виде и сама на их базе составляла консолидированную отчетность. Отчеты иногда делались неделями, были большие задержки и риски предоставления недостоверных данных в этих отчетах. Система была необходима, чтобы управляющая компания могла в любой момент увидеть данные по каждому филиалу и контролировать работу практически любого экономиста, могла не просто смотреть отчеты, но и принимать решения прямо в этой системе для сохранения истории всех принятых решений по бюджетному, инвестиционному процессам, оперативному платежному календарю. Тем самым мы выходили не только на автоматизацию учета, но и на автоматизацию бизнес-процессов, связанных с финансовой сферой. Также одной из причин, подталкивающей к проекту со стороны управляющей компании, стала необходимость увеличить скорость и прозрачность получения данных.

Немного теории

Для того, чтобы начать говорить о масштабировании, необходимо дать определение этого термина. Итак, масштабирование – это свойство системы (в данном случае системы бюджетного управления) сохранять свои целевые качества при изменении (обычно при увеличении) какого-либо из параметров системы.

Основные вопросы, по которым можно заметить проблему заключаются в следующем: «Будет ли система работоспособна, если увеличить один из ее параметров?» и «Будут ли при этом выдержаны ее целевые качества?». Если есть сомнения, значит, при создании такой системы никто не думал о потребностях развития.

На примере кейса проекта в «ГиперТрейдХолдинг» нами выделены 11 параметров, по которым необходимо было закладывать масштабируемость в ходе проекта:

  1. Методология управленческого учета
  2. Организационная структура
  3. Финансовая структура
  4. Аналитика бюджетирования
  5. Бюджеты и отчетность
  6. Процесс бюджетного планирования
  7. Участники процесса
  8. Запуск в эксплуатацию
  9. Адаптация и развитие системы
  10. ИТ-архитектура
  11. Функциональные задачи

Немного о каждом

  1. Единая методология управленческого учета на уровне всей компании для составления отчетности и управления внутри подразделений . Как можно измерить показатель, который определяет наличие или отсутствие методологии? На мой взгляд, хорошая зацепка – это понимание, насколько широко охвачена единой методологией регламентная часть. То есть количество локальных регламентов, которые поглощает разрабатываемая система бюджетного управления, тем самым производя распространение методологии. Система бюджетирования начинает заменять все существовавшие ранее в компаниях, подразделениях, филиалах регламенты, присоединять созданные процедуры и делать единую управленческую учетную политику, которая нужна и управляющей компании и помогает оперативной деятельности самим подразделениям. В проекте получилось увеличить этот показатель за счет двух аспектов: базовой методологии бюджетного управления, в основу которой легла методология ИНТАЛЕВ «5 шагов к бюджетному управлению», и знаний об особенностях процессов в компании сотрудниками заказчика. Так как часть, отвечающую за методологию, знают консультанты, то в проекте важно понять, кто будет в команде со стороны заказчика. От того какие специалисты придут, и что они будут знать о специфике управленческих процессов, и как будут доносить особенности, которые есть у заказчика сейчас и те, которые необходимо реализовать, зависит успешность внедрения. Соответственно, в данном проекте жесткие требования предъявлялись к оргструктуре проектной команды со стороны заказчика. Был выделен менеджер проекта и эксперты, которые будут потребителями результатов, по тем или иным функциональным областям оценивать качество результатов, доносить их до руководства заказчика. Под управлением менеджера проекта также находятся функциональные консультанты и технический директор, и методологический директор, и те специалисты, которые непосредственно в дальнейшем будут работать с этой системой.

  2. Организационная структура самого предприятия является стартовым параметром для построения финансовой структуры. На проекте сложилась ситуация, что оргструктуры двух якобы одинаковых, распределенных территориально бизнес-подразделений не совпадали. Были шаблоны, утвержденные приказами, но когда команда заказчика собралась для работы на проекте, на этапе совместного уточнения оргструктуры выявились значительные разногласия. Наша задача состояла в том, чтобы выработать единый регламентирующий инструмент для описания оргструктуры, которая в будущем должна быть масштабируемая. Мы не стали рассматривать особенности реального делопроизводства, а, в зависимости от количества объектов реализации каждого филиала, были разработаны типовые структуры, и была поставлена задача проверки, уточнения, претворения в жизнь той оргструктуры, которую для своих подразделений предполагала управляющая компания. Вслед за типизацией оргструктуры потянулись все остальные решения, основным лозунгом которых была «типизация», соблюдающая баланс между универсальностью и конкретностью.
  3. Далее разрабатывалась финансовая структура. Компания разрабатывала финансовую структуру уже во второй раз. В первый раз она была очень избыточной и неповоротливой. При построении новой финансовой структуры учитывались знания о том, почему не прижилась первая версия. К параметру «масштабирование» здесь предъявлялся скорее качественный признак, чем количественный. Финансовая структура должна быть полной, описывать весь бизнес компании, но в тоже время она должна быть гибкой, чтобы действительно помогала выделить ответственных людей и правильно очертить зоны ответственности. В типовую, максимально полную финансовую структуру были заложены все виды деятельности, несмотря на то, что некоторые виды деятельности в отдельных филиалах отсутствовали. Также была проведена работа по стыковке с реальными оргструктурами, так как если бы мы описали отдельно одно региональное подразделение и другое, мы бы получили две абсолютно разные финансовые структуры. В разработанной структуре не присутствуют сами филиалы (350 объектов реализации), в ней закреплена ответственность как по территориальному признаку как основному аспекту стратегии компании, так и по всем видам деятельности.
  4. Аналитика бюджетирования. Финансовая структура как набор ЦФО является главнейшей аналитикой системы бюджетного управления, поэтому разрабатывать ее нужно внимательно, просматривая каждый аналитический разрез, который необходимо туда заложить. Но в проектах задача анализа деятельности всегда стоит шире, чем аналитичность финансовой структуры и заключается в создании единого аналитического пространства, которое способно охватить специфику каждого вида деятельности и сделать максимально полную, доступную и понятную отчетность на уровне управляющей компании. Соответственно, получаем следующий масштабируемый параметр – количество аналитических разрезов, от значения которого зависит глубина анализа управленческой отчетности. Был разработан единый классификатор статей бюджета доходов и расходов и бюджета движения денежных средств в качестве центральной аналитики системы бюджетного управления. При внедрении программного продукта «ИНТАЛЕВ: Корпоративный менеджмент» правильная работа с аналитиками – это залог будущего успеха. Далее по ходу проекта нам необходимо было разработать новый перечень дополнительных аналитических разрезов, а это уже понятный и масштабируемый показатель. Количество этих аналитических разрезов для такой аналитической системы должно быть большим. Наш опыт различных крупных проектов говорит о том, что нужно делать единую аналитику на уровне управляющей компании. Поскольку центровая аналитика бюджетирования – это статья, статья бюджета доходов и расходов, статья движения денежных средств, то вся существующая и дополнительная аналитика по максимуму привязывалась к этим статьям. Благодаря этому получалась достаточно гибкая структура: определяя статью можно было определить всю остальную аналитику. Закрепление классификатора статей велось жестко только на верхнем уровне иерархии, внутри иерархии можно было добавлять одноименные расходы, но если, например, вдруг у третьего регионального подразделения появится не существовавшая ранее статья, она войдет в фиксированную группу и дополнит общий перечень статей холдинга. К статьям были привязаны другие всевозможные характеристики, в том числе была связка со статьями инвестиционной деятельности. Таким образом получилось, что на статью как на шампур нанизываются все остальные аналитики.

  5. Бюджеты и отчетность. В рамках этого блока необходимо сделать операционные бюджеты, функциональные бюджеты и весь набор отчетности, который должна получать управляющая компания. Соответственно, счетный и масштабируемый параметр – это количество бюджетов. Были разработаны такие функциональные бюджеты, которые отражают все основные функции на предприятии, отражают основную функциональную ответственность и поэтому если в будущем бизнес поменяется или структура ведения бизнеса, то просто появится новый функциональный бюджет.

  6. Процесс бюджетного планирования. Автоматизировать процесс принятия решений – одна из задач, поставленных перед проектом. Необходимо было разработать единый сквозной процесс планирования по всей компании, позволяющий подключать новые подразделения в дальнейшем. Параметр, который должен масштабироваться в этом случае – это количество подключаемых подразделений, филиалов и участников в этот процесс. Был не только создан, настроен, описан типовой процесс, но и автоматизирован: изюминка была именно в автоматизации этого процесса, который должен был быть разработан в независимости от количества филиалов и сотрудников, работающих в системе. В результате первичного описания получилось около 100 видов решаемых задач и 6 подпроцесов.

  7. Участники процесса. Количество участников процесса – следующий масштабируемый параметр, даже не столько количество, сколько конкретные фамилии, которые рано или поздно придется вписать в процесс и регламент для того, чтобы люди начали работать. Это очень сложно, так как в центральном офисе не знали фамилии сотрудников из других подразделений и не предполагали, кто это может делать. Необходимо было сделать так, чтобы настройка процесса не зависела от человеческого фактора. Было принято решение, что нужно поддерживать масштабирование количества участников, но не включая самих участников в топологию процесса: процесс должен быть максимально обезличен. Соответственно мы делали типовые блоки решений, которые говорили о некой функциональности, и на каждый блок решений, на каждую функцию мы привязывали рабочую группу. Этот инструмент позволяет поставить назначить не конкретного исполнителя, а некую рабочую группу. Соответственно каждая функция процесса – это одна рабочая группа, участники которой прописаны в обычном справочнике. В нее включаются уже филиалы и, если нужно, фамилии конкретных людей. При таком подходе к автоматизации процесс децентрализации выглядит следующим образом: в начале стоит фамилия специалиста из центра; как только система отработана, он удаляется из рабочей группы путем удаления его фамилии, и на его место встает специалист из филиала. Таким образом, мы опустили функцию в филиал. Таким образом, болезненная процедура смены исполнителя никаким образом не затрагивает саму систему, она продолжает работать, достаточно поменять фамилию в списке.
  8. Запуск в эксплуатацию. Одно дело настроить такую систему, и совершенно другое – ее запустить и сделать так, чтобы ею пользовались, так как внедрение новой корпоративной системы управления подразумевает кардинальные изменения в самой корпоративной культуре управления в компании, где каждый человек должен четко выполнять поставленную задачу в назначенный срок. Быстро и одновременно обучить такое количество пользователей не представляется возможным. Если проводить такое обучение в виде общих лекций и тренингов, то для этого понадобилось бы обучать пару месяцев. Поэтому была организована деловая игра, в которой участвовала проектная команда. Эта команда промоделировала бизнес-пример на базе своего реального годового плана, занесла все цифры в систему. Во-первых, они познакомились с самой системой и с конкретикой, какие цифры забивать, как они между собой связаны, какие формулы рассчитываются. По результатам деловой игры был создан документ «Руководство по работе с процессом», который описывал ход процесса, образцы заполнения каждой формы на примере данных, полученных в результате деловой игры. Весь описанный в руководстве процесс – реальный, живой, понятный всем подразделениям – был сфотографирован (сделаны скриншоты) и скриншоты были вставлены в руководство. С помощью такой процедуры была подготовлена масштабируемость запуска. В дальнейшем к системе подключали людей, которые и не знали, что в компании идет какой-то проект, им просто раздавали это документ и по нему специалисты из проектной команды поясняли, что и как нужно делать.
  9. Адаптация и развитие системы. Для дальнейшего развития системы (а она будет развиваться) стоят достаточно большие планы, какой параметр нужно отмасштабировать для того чтобы получить поддержку развитию и адаптации системы? Этот параметр – количество компетентных сотрудников, которые в дальнейшем могут составить внутренний методологический центр, организовать внутреннюю помощь. На первом же проектом заседании была обозначена потребность создания консультационно-внедренческого центра внутри компании, который будет поддерживать развитие и изменение модели управленческого учета централизованно. То есть любой пользователь знает, кому позвонить, рассказать, какие проблемы есть на его рабочем месте, а также может внести пожелания по улучшению системы – эти пожелания собираются, рассматриваются и система живет и развивается.
  10. ИТ-архитектура. Масштабируемость ИТ-архитектуры была предрешена, и можно даже сказать, что проект начался идеально. В него изначально были заложены предпосылки для комплексного проекта. Несмотря на то, что компания в тот момент параллельно внедряла систему единого бухгалтерского учета, мы выстроили единый модуль управленческого и бухгалтерского учета. Управляющие компании всегда имеют потребность проследить любую цифру вплоть до первичного документа, который внес конкретный пользователь, и иметь полную прозрачность и достоверность факта. Поэтому строили такую структуру, которая позволяет в каждом филиале поставить информационную базу, которая обменивается с центральной базой на уровне головной организации регионального подразделения, а потом данные передаются в общую базу управляющей компании холдинга. Все движения, которые там есть, будут «видны» в управляющей компании. Все процессы, которые происходят, перемещаются в рамках трех уровней. Инициирует процесс головная компания, задачи приходят в головной офис, потом опускаются в филиалы, и все решения по ним могут мигрировать так же и снизу вверх. Так же при этом всегда можно увидеть, кто и какое решение на каком месте принял. Внедрение единой конфигурации бухгалтерского учета помогло упростить создание ИТ-инфраструктуры.

  11. Функциональные задачи. Все эти параметры относились только к одной функциональной области – бюджетное управление, на самом деле блоков гораздо больше. Нужно масштабировать количество самих функциональных блоков, количество сценариев, по которым будет вестись учет. Делается это на базе многосценарного подхода к учету и управлению. Сценарий – это учетно-аналитический разрез, показывающий тот или иной вариант развития событий. Чем больше сценариев – тем шире и гибче получается система управления.

    То, о чем шла речь – это только небольшая часть функционального блока бюджетного планирования. Также планируются постановка управления инвестиционной деятельностью, платежного календаря, документооборота, и вся эта информация должна между собой коррелировать и между собой взаимоотноситься. В процессе, в котором все эти блоки взаимосвязаны, решения принимаются одно на основании другого. И теперь мы можем посмотреть, как огромная 15-летняя инвестиционная программа на много миллионов долларов связана с конкретным платежом, который несется в данный момент на подписание заявки. Всегда можно понять достоверность, оправданность, нацеленность этой суммы и не запрашивать дополнительную информацию: все хранится в одной системе. В итоге мы получаем целостную систему для поддержания не только управленческого учета на предприятии, но и поддержания принятия управленческих решений.

    Если бы мы не выдержали некую унификацию и оптимизацию на самом первом стартовом блоке бюджетного планирования, мы бы не заложили как раз тот фундамент, который позволяет наращивать по «шашлычной» технологии все остальные блоки, которые должны иметь в себе те же параметры масштабирования.

    В заключение хотелось бы отметить, что построение системы управления под руководством вышеприведенных принципов – это неоценимый вклад в конкурентное преимущество компании в виде новой корпоративной культуры управления. Как известно, именно корпоративная культура составляет фундамент реализации долгосрочных целей в стратегии компании, а, значит, компания получает нематериальный актив, позволяющий увеличить стоимость бизнеса.

Автор: